Josh Berkus wrote:
I'd be thrilled to test it too, if for no other reason that to determine
whether what I'm experiencing really is the "CS problem".
Hmmm ... Gavin's patch is built against 8.0, and any version of the patch would require linux 2.6, probably 2.6.7 minimum. Can you test on that linux version? Do you have the resources to back-port Gavin's patch?
I don't currently have any SMP Xeon systems running a 2.6 kernel, but it could be arranged. As for back-porting the patch to 7.4.5, probably so, but I'd have to see it first.
tps = 369.717832 (including connections establishing)
tps = 370.852058 (excluding connections establishing)
Doesn't seem too bad to me. Have anything to compare it to?
Yes, about 280 tps on the same machine with the data directory on a 3-disk RAID 5 w/ a 128MB cache, rather than the SSD. I was expecting a much larger increase, given that the RAID does about 3MB/s of random 8k writes, and the SSD device does about 70MB/s of random 8k writes. Said differently, I thought my CPU bottleneck would be much higher, as to allow for more than a 30% increase in pgbench TPS when I took the IO bottleneck out of the equation. (That said, I'm not tuning for pgbench, but it is a useful comparison that everyone on the list is familiar with, and takes out the possibility that my app just has a bunch of poorly written queries).
What's in your postgresql.conf?
Some relevant parameters: shared_buffers = 16384 sort_mem = 2048 vacuum_mem = 16384 max_fsm_pages = 200000 max_fsm_relations = 10000 fsync = true wal_sync_method = fsync wal_buffers = 32 checkpoint_segments = 6 effective_cache_size = 262144 random_page_cost = 0.25
Everything else is left at the default (or not relevant to this post). Anything blatantly stupid in there for my setup?
Thanks,
Bill Montgomery
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
