system tuning

[Kevin Carter_3]

I manage an Alpha DS20E with dual 667 mhz CPUs and 4 GIGS of memory. The system supports an Oracle database with about 120 concurrent users, the database queries are normally very short in nature but there are also ad hock queries from time to time.

My question is: what is the current rule of thumb for setting QUANTUM. The philosophy use to be to reduce QUANTUM from the default of 20 to something between 5 and 8.

[John Eerenberg]

I'm sure this is good for a debate, but personally, I set all my Alpha systems to a quantum of 2 when short queries dominate with ad hock and batch from time to time. The improvement is worth it to me.

I have over 1,500 users running MUMPS on an EV6 525MHz (6 CPUs) system and quantum is 2. Time and testing has shown that was a good move. IOTA has to be set to 1.

Why did I set it so low?

Consider that quantum of 20 was designed for a VAX11/780. Alphas are many times more fast.

I have benchmarked quantum's impact. An Alpha is capable of doing well over 10,000 context swtiches/second; specialK ASTs can drive several times that rate. You have a much faster CPU then I benchmarked years ago. Unless you have something out of the ordinary, 120 concurrent users on a DS20E and a quantum of 2 *and* an IOTA of 1 should give satisfactory CPU performance.

[Hein van den Heuvel]

What problem are you trying to solve?
Is your intent to minimize the impact of the ad-hoc queries on the regular queries or to mamimize the performance of the ad-hoc query at the expense of the regulare queries. Pick one. Your description is open to either interpretation.

Fortunately, IMHO, the answer is probably that quantum plays no role whatsoever. Quantum is important for longer lasting cpu bound jobs. This is rarely the case for Oracle queries. They hit IOs and background task (REDO) sync all the time. The typical proirity boost after an IO then plays a far greater role.

Admittedly 200ms is an awful lot of cpu cycles these days. And indeed a modern VMS systems can do thousands of context switches making the direct overhead of the context switch sub-millisecond. So I would also lean towards a lower quantum, even though I epext zero effect.

Lets say an oracle tasks is sitting there doign a lot of computes (joining mutliple cached tables? doing a complicated parse?). How long could that possibly take?

If that would take say 50ms, I would feel bad about interupting it about 20 ms and loose the cache context, and hold some locks and so on.
If it were to take 500 ms, clearly it would be nice to allow lots of little tasks to complete in the mean time.

You'll need a better (cpu) resource management tool than (any) OS can offer.
You'll beed co-operation from Oracle and/or the application. Maybe some tool like Oracle's "Database Resource Manager"? See for example:
http://www.oracle.com/technology/oramag/oracle/04-nov/o64tuning.html

The final answer will be 'it depends'. And the only way to tell will be to come up with some repeatable high-usage ad-hoc queries and measure. Fortunately, QUANTUM is a dynamic parameter. For purpose of testing I would try 20 (default), 2 and 100.

fwiw,
Hein.


From the vms doco:
"Each time a process starts to execute, it is assigned a slice of computer processing time called a quantum. The process will continue to execute until one of three possible events occurs:
- A higher priority process becomes executable. In this case the lower priority process is preempted and the higher priority process starts to execute.
- The process enters a wait state, for example, in order to wait for the completion of an I/O operation.
- The assigned quantum expires. If no other process of equal or higher priority is ready to execute, the current process obtains a new quantum and continues execution. If another process of equal priority is already waiting to execute, the current process must now wait and the new process obtains the CPU for the duration of 1 quantum."

[Karl Rohwedder]

Please note that VMS V8.2 lowers the defaults for QUANTUM to 5 and for IOTA to 1.

mfg Kalle