James Mansion <james(at)mansionfamily(dot)plus(dot)com> wrote:
>> 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.
> UNIX systems have routinely managed large numbers of runnable
> processes where the run queue lengths are long without such an
> issue.
Hmmm... Did you think the queues I mentioned where OS run queues? In
case that's a source of misunderstanding, let me clarify.
Sybase ASE (and derivatives) have a number of queues to schedule work.
When something needs doing, it's put on a queue. The "engines" cycle
through checking these queues for work, using non-blocking methods for
I/O where possible. There is a configurable parameter for how many
times an engine should check all queues without finding any work to do
before it voluntarily yields its CPU. This number was always a tricky
one to configure, as it would starve other processes on the box if set
too high, and would cause the DBMS to context switch too much if set
too low. Whenever a new release came out, or we changed the other
processes running on a database server, we had to benchmark to see
where the "sweet spot" was. We ranged from 16 to 20000 for this value
at various times.
Those are the queues I meant.
-Kevin