Kevin Grittner wrote:
Sure, but the architecture of those products is based around all the
work being done by "engines" which try to establish affinity to
different CPUs, and loop through the various tasks to be done. You
don't get a context switch storm because you normally have the number
of engines set at or below the number of CPUs. The down side is that
they spend a lot of time spinning around queue access to see if
anything has become available to do -- which causes them not to play
nice with other processes on the same box.
This is just misleading at best. I'm sorry, but (in particular) UNIX
systems have routinely
managed large numbers of runnable processes where the run queue lengths are
long without such an issue. This is not an issue with the number of
runnable threads,
but with the way that they wait and what they do.
The context switch rate reported does not indicate processes using their
timeslices
productively, unless the load is from a continuous stream of trivial
RPCs and that
doesn't stack up with the good performance and then problematic load
that the
OP reported.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
