Sybase

Jeff Tallman replied to a question on how to avoid unnecessary reorgs. He graciously agreed to let me post his response here

You can avoid most (if not all) of the reorgs by doing:

1. setting the exp_row_size to something that covers about 90% of the space each row takes up
2. changing enable housekeeper GC to a 4 or 5

Both of these are a *MUST* do for DOL (datapages or datarows). See manuals on ‘enable housekeeper GC’ for correct setting of 4 or 5 (refers to whether deletes are batch or OLTP).

You can also watch for housekeeper overflows in monEngine/monOpenObjectActivity……and if you see any HKGC pending – wait a few before shutting down.

Jeff wrote up an excellent article, Locking Redux – APL vs. DOL and Tuning, that goes into detail why this is the case.

Jeff Tallman also provided us with the MDA posters for Sybase 15.0.3 last year.

ASE 15.0.3 MDA table diagram

Thanks Jeff for creating them!

MyDatabases Volume 1 Issue 1

Geek Spotlight:  Michael Peppler
Sybase ASE on Ubuntu 8.04
Multicore Processors
VMware Virtualization
Logical Process Manager

Jeff hits the nail on the head.  You have a voice with the ISUG enhancements process. Use it.  And yes, you have to be paid member to vote. Sorry, but we are a non-profit and your membership fees keep us running!  You can vote as a Basic Member – you do not need to join at the higher membership levels (but you should so you can read all the wonderful articles Jeff writes for us).  The more votes, the easier it is for engineering to justify spending staff resources on it when they go to management.  Encourage all of your peers to join and vote as well.  If you work for a business with several Sybase users, convince your boss to pay for a corporate membership and get all your colleagues to vote as well.

Regards,

Mike Harrold
Executive Director

and

Having an “internal enhancement” (aka a CR) doesn’t mean it gets implemented.  It means there’s a CR for it.  It might be a great idea, but without backing (and a user request + an engineer doesn’t mean it has backing; look how long it took for UDFs, mathematical functions, etc.) it doesn’t get allocated any development resources.  Without development resources, it doesn’t get implemented.

Bottom line, a CR doesn’t mean it’s a “planned” feature.

Regards,

Mike Harrold
Executive Director
International Sybase User Group

I would recommend voting for the ISUG enhancements (this week).  I and several other ISUG Board members will be going through the ISUG enhancements this weekend to present a subset to Sybase product management at TechWave next month.

I haven’t seen many ISUG enhancements being requested lately or voted upon for that matter.  The higher the votes for a particular enhancement, the more likely Sybase will pick it up.

So please, everyone go vote on the ISUG enhancements!

From: Jeff Tallman <tallmanATsybaseZeDOTcom>
To: sybase-l@lists.isug.com
Subject: [sybase-l] – RE: Multicore processors and ASE

As always a lot depends on the application profile.   Something to consider for any multicore processor are factors:

1. The number of FPU units per chip (FPU = Floating Point Unit)
   
2. The number and capacity (in IOPS) of IO processors per chip
3. The type of chip multi-threading

With respect to #1, most DBMS (at least the commercial ones) use statistics for query optimization – so while the actual query processing doesn’t use a lot of FPU instructions (assuming a minimum of float datatypes, etc.).  Each query requires a pretty good smack of the FPU time to do the floating point math on the stats.  The impact of this could be lessened by doing statement caching or fully prepared statements…or other means at reducing the optimizer load.

The second problem is one of capacity vs. bandwidth.   All network and disk IO obviously need to use the IO processor.   With 4 dual core chips, usually, you have 4 IO processors.

With a single chip with 8 cores, it is likely that you will have only a single IO processor.   The single IO processor has 8 cores all making requests.  The number of IO operations per second it can handle becomes a real key factor in the box’s scalability.

The chip multi-threading is an interesting issue as there are ~3 different flavors today:

1. Intel’s Hyperthreading (no longer implemented on XEON and I don’t think implemented at all anymore)
2. Sun’s Chip Multi-Threading (CMT)
3. IBM’s SMT

Some instructions require multiple cycles to complete due to they are waiting on a fetch from main memory or whatever.   The thread/process of execution typically blocks in these cases, resulting in a fairly idle core.   By making use of this idle time, CMT or SMT can increase the throughput overall — ignoring HT as it was fairly ineffective at this – and appears to have been dropped by Intel lately.

The question that comes up is how do you manage the threading?  Do you do a form of timeslicing (i.e. when you suspend on process that is blocked on a call, do you let the one that replaced it run for a certain length of time or until it blocks before returning back to the original) or do you do an interrupt based/preemptive mechanism in which when the blocked call returns, that you suspend the other thread?   Both have advantages and disadvantages, and do allow more engines than cores.

However, it may also mean tuning ASE to be more reactive, such as reducing the ‘runnable process search count’.  You also need to be careful that engines running on CMT’s don’t get woken back up on another core (especially if the L2 cache is split between the cores) as well as other considerations.

A rule of thumb to think about is that if you have a multi-core CPU that supports chip threading, if you have a lengthy list of SPIDs in a ‘runnable’ state, enabling extra engines on the threads will likely help.   If you don’t – i.e. you are IO bound – that it probably won’t help.

Currently, Sun uses a timeslicing mechanism that is more along the lines of ASE’s SPID management – and as a consequence, it shows scalability when the various tasks do a lot of blocking calls such as fetches from main memory.  It does have the detrimental effect of only providing a percentage of cpu time to the ASE engine (i.e. 25% when 4 threads per core).   The more parallelism is used within your application, such as higher numbers of concurrent users in ASE, the more it can be distributed across the engines.

You have to be careful as net engine affinity and short query’s (i.e. DML).  They can have a negative impact, which may be controllable using engine groups.   Overall, a cpu-intensive/cpu bound application can benefit from the Sun CMT implementation.  An IO bound application does not.