From: | Alan Stange <stange(at)rentec(dot)com> |
---|---|
To: | Gaetano Mendola <mendola(at)bigfoot(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Excessive context switching on SMP Xeons |
Date: | 2004-10-07 03:14:20 |
Message-ID: | 4164B48C.9060202@rentec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Here's a few numbers from the Opteron 250. If I get some time I'll post
a more comprehensive comparison including some other systems.
The system is a Sun v20z. Dual Opteron 250, 2.4Ghz, Linux 2.6, 8 GB
memory. I did a compile and install of pg 8.0 beta 3. I created a
data base on a tmpfs file system and ran pgbench. Everything was "out
of the box", meaning I did not tweak any config files.
I used this for pgbench:
$ pgbench -i -s 32
and this for pgbench invocations:
$ pgbench -s 32 -c 1 -t 10000 -v
clients tps
1 1290
2 1780
4 1760
8 1680
16 1376
32 904
How are these results useful? In some sense, this is a speed of light
number for the Opteron 250. You'll never go faster on this system with
a real storage subsystem involved instead of a tmpfs file system. It's
also a set of numbers that anyone else can reproduce as we don't have to
deal with any differences in file systems, disk subsystems, networking,
etc. Finally, it's a set of results that anyone else can compute on
Xeon's or other systems and make a simple (and naive) comparisons.
Just to stay on topic: vmstat reported about 30K cs / second while
this was running the 1 and 2 client cases.
-- Alan
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2004-10-07 07:18:42 | Re: Caching of Queries |
Previous Message | Tom Lane | 2004-10-07 03:12:14 | Re: Caching of Queries |