From: | Justin <justin(at)emproshunts(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Benchmark: Dell/Perc 6, 8 disk RAID 10 |
Date: | 2008-03-14 08:31:29 |
Message-ID: | 47DA37E1.6050104@emproshunts.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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)
From | Date | Subject | |
---|---|---|---|
Next Message | Enrico Sirola | 2008-03-14 10:17:12 | Re: 8.3 write performance |
Previous Message | Greg Smith | 2008-03-14 08:19:25 | Re: Benchmark: Dell/Perc 6, 8 disk RAID 10 |