Re: Wierd context-switching issue on Xeon

As a cross-ref to all the 7.4.x tests people have sent in, here's 7.2.3 (Redhat 7.3), Quad Xeon 700MHz/1MB L2 cache,
3GBRAM. 

Idle-ish (it's a production server) cs/sec ~5000

3 test queries running:
   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache   si  so    bi    bo   in    cs   us  sy  id
 3  0  0  23380 577680 105912 2145140   0   0     0     0  107 116890  50  14  35
 2  0  0  23380 577680 105912 2145140   0   0     0     0  114 118583  50  15  34
 2  0  0  23380 577680 105912 2145140   0   0     0     0  107 115842  54  14  32
 2  1  0  23380 577680 105920 2145140   0   0     0    32  156 117549  50  16  35

HTH

Matt

> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org]On Behalf Of Tom Lane
> Sent: 20 April 2004 01:02
> To: josh@agliodbs.com
> Cc: Joe Conway; scott.marlowe; Bruce Momjian; lutzeb@aeccom.com;
> pgsql-performance@postgresql.org; Neil Conway
> Subject: Re: [PERFORM] Wierd context-switching issue on Xeon
>
>
> Here is a test case.  To set up, run the "test_setup.sql" script once;
> then launch two copies of the "test_run.sql" script.  (For those of
> you with more than two CPUs, see whether you need one per CPU to make
> trouble, or whether two test_runs are enough.)  Check that you get a
> nestloops-with-index-scans plan shown by the EXPLAIN in test_run.
>
> In isolation, test_run.sql should do essentially no syscalls at all once
> it's past the initial ramp-up.  On a machine that's functioning per
> expectations, multiple copies of test_run show a relatively low rate of
> semop() calls --- a few per second, at most --- and maybe a delaying
> select() here and there.
>
> What I actually see on Josh's client's machine is a context swap storm:
> "vmstat 1" shows CS rates around 170K/sec.  strace'ing the backends
> shows a corresponding rate of semop() syscalls, with a few delaying
> select()s sprinkled in.  top(1) shows system CPU percent of 25-30
> and idle CPU percent of 16-20.
>
> I haven't bothered to check how long the test_run query takes, but if it
> ends while you're still examining the behavior, just start it again.
>
> Note the test case assumes you've got shared_buffers set to at least
> 1000; with smaller values, you may get some I/O syscalls, which will
> probably skew the results.
>
>             regards, tom lane
>
>