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
