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
>
>
