On Wed, Sep 29, 2010 at 10:30 PM, David Kreuter
<[email protected]> wrote:

> Hi Martha: If it is at all possible for you to do I suggest that you
> work with your Oracle DBA to identify viral SQL statements.  If I hadn't
> experienced this myself with a multiple virtual CPU Linux Oracle
> environment  I wouldn't have believed it - but one miscreant SQL
> statement took 40% of a z9BC IFL. Tuning the application while it was
> growing in demand, size of DB, and code paid off big time reducing from
> 6 to 4 IFLs. So it wasn't a one time deal but saved big $$.

When total CPU resources are limited (number of z/VM logical CPUs or
contention) then adding virtual CPUs to the Linux guest will give it
still the same CPU cycles, but as multiple slow CPUs. When the
workload is truly multi-threaded, overall progress is still made, just
with a bit more overhead in Linux and z/VM (apart from issues with
locking that get really worse).
But if the workload does not have that many threads, we seem to get a
funny game where Linux starts to move threads between virtual CPUs. I
believe this is part of the CPU affinity that only makes sense on bare
metal. The net effect is that the virtual machine shows more CPU wait
even when the real CPUs are not completely busy.

Mark is right that this shows in steal% for the virtual CPUs (though I
don't like the terminology). This normally improves by taking virtual
CPUs away (so get less faster CPUs).

Don't know enough about Oracle internals to be real dangerous, but I
could imagine that execution of a single SQL statement is single
threaded, so involves a single virtual CPU. When you give the CPU
resources in the form of many slower virtual CPUs, that PITA process
can consume only a small part of the total resources, and you still
get capacity for other work.

One of the cases we looked at in the past was with Lotus Notes. The
application schedules user tasks and batch work to run on its threads.
Sometimes it would prefer to run the batch tasks and starve the user
tasks. By giving it two virtual CPUs (even though they did not run at
the same time) we forced the application to also spend some time
service the users...

Rob

-- 
Rob van der Heij
Velocity Software
http://www.velocitysoftware.com/

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Reply via email to