Re: Testing Sandforce SSD

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Testing Sandforce SSD
Date: 2010-07-26 09:22:34
Message-ID: 4C4D53DA.3070909@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Yeb Havinga wrote:
> Greg Smith wrote:
>> Put it on ext3, toggle on noatime, and move on to testing. The
>> overhead of the metadata writes is the least of the problems when
>> doing write-heavy stuff on Linux.
> I ran a pgbench run and power failure test during pgbench with a 3
> year old computer
>
On the same config more tests.

scale 10 read only and read/write tests. note: only 240 s.

starting vacuum...end.
transaction type: SELECT only
scaling factor: 10
query mode: prepared
number of clients: 10
duration: 240 s
number of transactions actually processed: 8208115
tps = 34197.109896 (including connections establishing)
tps = 34200.658720 (excluding connections establishing)

yeb(at)client45:~$ pgbench -c 10 -l -M prepared -T 240 test
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 10
query mode: prepared
number of clients: 10
duration: 240 s
number of transactions actually processed: 809271
tps = 3371.147020 (including connections establishing)
tps = 3371.518611 (excluding connections establishing)

----------
scale 300 (just fits in RAM) read only and read/write tests

pgbench -c 10 -M prepared -T 300 -S test
starting vacuum...end.
transaction type: SELECT only
scaling factor: 300
query mode: prepared
number of clients: 10
duration: 300 s
number of transactions actually processed: 9219279
tps = 30726.931095 (including connections establishing)
tps = 30729.692823 (excluding connections establishing)

The test above doesn't really test the drive but shows the CPU/RAM limit.

pgbench -c 10 -l -M prepared -T 3600 test
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 300
query mode: prepared
number of clients: 10
duration: 3600 s
number of transactions actually processed: 8838200
tps = 2454.994217 (including connections establishing)
tps = 2455.012480 (excluding connections establishing)

------
scale 2000

pgbench -c 10 -M prepared -T 300 -S test
starting vacuum...end.
transaction type: SELECT only
scaling factor: 2000
query mode: prepared
number of clients: 10
duration: 300 s
number of transactions actually processed: 755772
tps = 2518.547576 (including connections establishing)
tps = 2518.762476 (excluding connections establishing)

So the test above tests the random seek performance. Iostat on the drive
showed a steady just over 4000 read io's/s:
avg-cpu: %user %nice %system %iowait %steal %idle
11.39 0.00 13.37 60.40 0.00 14.85
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 4171.00 0.00 60624.00 0.00
29.07 11.81 2.83 0.24 100.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 0.00 0.00 0.00

pgbench -c 10 -l -M prepared -T 24000 test
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 2000
query mode: prepared
number of clients: 10
duration: 24000 s
number of transactions actually processed: 30815691
tps = 1283.979098 (including connections establishing)
tps = 1283.980446 (excluding connections establishing)

Note the duration of several hours. No long waits occurred - of this
last test the latency png is at http://yfrog.com/f/0vlatencywp/ and the
TPS graph at http://yfrog.com/f/b5tpsp/

regards,
Yeb Havinga

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Vitalii Tymchyshyn 2010-07-26 09:25:18 Re: Big difference in time returned by EXPLAIN ANALYZE SELECT ... AND SELECT ...
Previous Message Craig Ringer 2010-07-26 09:15:12 Re: Big difference in time returned by EXPLAIN ANALYZE SELECT ... AND SELECT ...