pg.ddx.io pgsql-performance@postgresql.org mailing list archive help / color / mirror / Atom feed From: Yeb Havinga <yebhavinga@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: Testing Sandforce SSD
Date: Wed, 28 Jul 2010 17:18:27 +0200
Message-ID: <4C504A43.3000304@gmail.com> (raw )
In-Reply-To: <4C503473.5080105@gmail.com >
References: <4C4A9452.9070100@gmail.com >
<4C4B1F84.5030306@2ndquadrant.com >
<4C4C83DF.3010703@gmail.com >
<4C4C8CCC.7080406@gmail.com >
<alpine.DEB.2.00.1007261045470.20471@aragorn.flymine.org >
<4C4D6396.5020707@gmail.com >
<4C4DAAE8.3060501@2ndquadrant.com >
<4C4DE50B.1060102@gmail.com >
<4C4DE5C9.8090004@2ndquadrant.com >
<AANLkTimwAqzvWvSfscqDKJDG3Yod=6KQ6e0Xo+c+k6s=@mail.gmail.com >
<e7e05556-9a42-11df-9b6a-001cc0cda50c@msgid.mathom.us >
<4C503473.5080105@gmail.com >
Yeb Havinga wrote:
> Michael Stone wrote:
>> On Mon, Jul 26, 2010 at 03:23:20PM -0600, Greg Spiegelberg wrote:
>>> I know I'm talking development now but is there a case for a pg_xlog
>>> block
>>> device to remove the file system overhead and guaranteeing your data is
>>> written sequentially every time?
>>
>> If you dedicate a partition to xlog, you already get that in practice
>> with no extra devlopment.
> Due to the LBA remapping of the SSD, I'm not sure of putting files
> that are sequentially written in a different partition (together with
> e.g. tables) would make a difference: in the end the SSD will have a
> set new blocks in it's buffer and somehow arrange them into sets of
> 128KB of 256KB writes for the flash chips. See also
> http://www.anandtech.com/show/2899/2
>
> But I ran out of ideas to test, so I'm going to test it anyway.
Same machine config as mentioned before, with data and xlog on separate
partitions, ext3 with barrier off (save on this SSD).
pgbench -c 10 -M prepared -T 3600 -l 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: 10856359
tps = 3015.560252 (including connections establishing)
tps = 3015.575739 (excluding connections establishing)
This is about 25% faster than data and xlog combined on the same filesystem.
Below is output from iostat -xk 1 -p /dev/sda, which shows each second
per partition statistics.
sda2 is data, sda3 is xlog In the third second a checkpoint seems to start.
avg-cpu: %user %nice %system %iowait %steal %idle
63.50 0.00 30.50 2.50 0.00 3.50
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 6518.00 36.00 2211.00 148.00 35524.00
31.75 0.28 0.12 0.11 25.00
sda1 0.00 2.00 0.00 5.00 0.00 636.00
254.40 0.03 6.00 2.00 1.00
sda2 0.00 218.00 36.00 40.00 148.00 1032.00
31.05 0.00 0.00 0.00 0.00
sda3 0.00 6298.00 0.00 2166.00 0.00 33856.00
31.26 0.25 0.12 0.12 25.00
avg-cpu: %user %nice %system %iowait %steal %idle
60.50 0.00 37.50 0.50 0.00 1.50
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 6514.00 33.00 2283.00 140.00 35188.00
30.51 0.32 0.14 0.13 29.00
sda1 0.00 0.00 0.00 3.00 0.00 12.00
8.00 0.00 0.00 0.00 0.00
sda2 0.00 0.00 33.00 2.00 140.00 8.00
8.46 0.03 0.86 0.29 1.00
sda3 0.00 6514.00 0.00 2278.00 0.00 35168.00
30.88 0.29 0.13 0.13 29.00
avg-cpu: %user %nice %system %iowait %steal %idle
33.00 0.00 34.00 18.00 0.00 15.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 3782.00 7.00 7235.00 28.00 44068.00
12.18 69.52 9.46 0.09 62.00
sda1 0.00 0.00 0.00 1.00 0.00 4.00
8.00 0.00 0.00 0.00 0.00
sda2 0.00 322.00 7.00 6018.00 28.00 25360.00
8.43 69.22 11.33 0.08 47.00
sda3 0.00 3460.00 0.00 1222.00 0.00 18728.00
30.65 0.30 0.25 0.25 30.00
avg-cpu: %user %nice %system %iowait %steal %idle
9.00 0.00 36.00 22.50 0.00 32.50
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 1079.00 3.00 11110.00 12.00 49060.00
8.83 120.64 10.95 0.08 86.00
sda1 0.00 2.00 0.00 2.00 0.00 320.00
320.00 0.12 60.00 35.00 7.00
sda2 0.00 30.00 3.00 10739.00 12.00 43076.00
8.02 120.49 11.30 0.08 83.00
sda3 0.00 1047.00 0.00 363.00 0.00 5640.00
31.07 0.03 0.08 0.08 3.00
avg-cpu: %user %nice %system %iowait %steal %idle
62.00 0.00 31.00 2.00 0.00 5.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s
avgrq-sz avgqu-sz await svctm %util
sda 0.00 6267.00 51.00 2493.00 208.00 35040.00
27.71 1.80 0.71 0.12 31.00
sda1 0.00 0.00 0.00 3.00 0.00 12.00
8.00 0.00 0.00 0.00 0.00
sda2 0.00 123.00 51.00 344.00 208.00 1868.00
10.51 1.50 3.80 0.10 4.00
sda3 0.00 6144.00 0.00 2146.00 0.00 33160.00
30.90 0.30 0.14 0.14 30.00
view thread (60+ messages) latest in thread
Message-ID: <4C504A43.3000304@gmail.com>
Permalink: ../4C504A43.3000304@gmail.com/
Also on: postgresql.org/message-id/4C504A43.3000304@gmail.com
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: yebhavinga@gmail.com
Subject: Re: Testing Sandforce SSD
In-Reply-To: <4C504A43.3000304@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox