Re: Benchmark: Dell/Perc 6, 8 disk RAID 10 - Mailing list pgsql-performance
From | Justin |
---|---|
Subject | Re: Benchmark: Dell/Perc 6, 8 disk RAID 10 |
Date | |
Msg-id | 47DA37E1.6050104@emproshunts.com Whole thread Raw |
In response to | Re: Benchmark: Dell/Perc 6, 8 disk RAID 10 ("Scott Marlowe" <scott.marlowe@gmail.com>) |
Responses |
Re: Benchmark: Dell/Perc 6, 8 disk RAID 10
|
List | pgsql-performance |
> Is this on a 64 bit or 32 bit machine? We had the problem with a 32 > bit linux box (not sure what flavor) just a few months ago. I would > not create a filesystem on a partition of 2+TB > Yes this machine is 64bit > You do know that effective_cache_size is the size of the OS level > cache. i.e. it won't show up in postgresql's memory usage. On a > machine with (I assume) 12 or more gigs or memory, you should have > your shared_buffers set to a much higher number than 100Meg. (unless > you're still running 7.4 but that's another story.) Sorry for my ignorance of linux, i'm used to windows task manager or performance monitor showing all the memory usage. I decided to move to Linux on the new server to get 64bit so still in the learning curve with that I played with shared_buffer and never saw much of an improvement from 100 all the way up to 800 megs moved the checkpoints from 3 to 30 and still never saw no movement in the numbers. i agree with you, those numbers are terrible i realized after posting i had the option -C turned on if i read the option -C correctly it is disconnecting and reconnecting between transactions. The way read -C option creates the worst case. The raid controller setting is set to make sure it don't lie on fsync shared_buffers = 800megs temp_buffers 204800 work_mem 256MB fsync_on wal_syns_method fysnc C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 10 -t 10000 -v -h 192.168.1.9 -U postgres empro Password: starting vacuum...end. starting vacuum accounts...end. transaction type: TPC-B (sort of) scaling factor: 100 number of clients: 10 number of transactions per client: 10000 number of transactions actually processed: 100000/100000 tps = 1768.940935 (including connections establishing) tps = 1783.230500 (excluding connections establishing) C:\Program Files\PostgreSQL\8.3\bin>pgbench -c 40 -t 10000 -v -h 192.168.1.9 -U postgres empro Password: starting vacuum...end. starting vacuum accounts...end. transaction type: TPC-B (sort of) scaling factor: 100 number of clients: 40 number of transactions per client: 10000 number of transactions actually processed: 400000/400000 tps = 567.149831 (including connections establishing) tps = 568.648692 (excluding connections establishing) --------------now with just Select -------------- C:\Program Files\PostgreSQL\8.3\bin>pgbench -S -c 10 -t 10000 -h 192.168.1.9 -U postgres empro Password: starting vacuum...end. transaction type: SELECT only scaling factor: 100 number of clients: 10 number of transactions per client: 10000 number of transactions actually processed: 100000/100000 tps = 16160.310278 (including connections establishing) tps = 17436.791630 (excluding connections establishing) C:\Program Files\PostgreSQL\8.3\bin>pgbench -S -c 40 -t 10000 -h 192.168.1.9 -U postgres empro Password: starting vacuum...end. transaction type: SELECT only scaling factor: 100 number of clients: 40 number of transactions per client: 10000 number of transactions actually processed: 400000/400000 tps = 18338.529250 (including connections establishing) tps = 20031.048125 (excluding connections establishing)
pgsql-performance by date: