James Mansion <james@xxxxxxxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
