pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedQuestion: BlockSize > 8192 with FusionIO
7+ messages / 5 participants
[nested] [flat]
* Question: BlockSize > 8192 with FusionIO
@ 2011-01-04 00:33 Strange, John W <john.w.strange@jpmchase.com>
2011-01-04 02:13 ` Re: Question: BlockSize > 8192 with FusionIO Greg Smith <greg@2ndquadrant.com>
0 siblings, 1 reply; 7+ messages in thread
From: Strange, John W @ 2011-01-04 00:33 UTC (permalink / raw)
To: pgsql-performance
Has anyone had a chance to recompile and try larger a larger blocksize than 8192 with pSQL 8.4.x? I'm finally getting around to tuning some FusionIO drives that we are setting up. We are looking to setup 4 fusionIO drives per server, and then use pgpooler to scale them to 3 servers so that we can scale up to 72 processors. I'm almost done with the configuration to start heavily testing but wanted to know if anyone has really messed with the blocksize options?
If anyone has done load balancing with pgpooler I'd love to hear their experience with it as well. I have attached the randwrite performance test below, as you can see going from 8K -> 32K -> 1M blocksize the drives really start to move.
Thanks,
- John
[v025554@athenaash05 /]$ fio --filename=/fusionIO/export1/test1 --size=25G --bs=8k --direct=1 --rw=randwrite --numjobs=8 --runtime=30 --group_reporting --name=file1
file1: (g=0): rw=randwrite, bs=8K-8K/8K-8K, ioengine=sync, iodepth=1
...
file1: (g=0): rw=randwrite, bs=8K-8K/8K-8K, ioengine=sync, iodepth=1
Starting 8 processes
Jobs: 8 (f=8): [wwwwwwww] [100.0% done] [0K/138M /s] [0/17K iops] [eta 00m:00s]
file1: (groupid=0, jobs=8): err= 0: pid=23287
write: io=3,819MB, bw=127MB/s, iops=16,292, runt= 30001msec
clat (usec): min=41, max=1,835K, avg=268.42, stdev=3627.29
bw (KB/s) : min= 4, max=142304, per=15.13%, avg=19714.31, stdev=8364.40
cpu : usr=0.16%, sys=3.13%, ctx=1123544, majf=0, minf=176
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/488779, short=0/0
lat (usec): 50=14.81%, 100=58.17%, 250=0.28%, 500=22.33%, 750=3.67%
lat (usec): 1000=0.16%
lat (msec): 2=0.35%, 4=0.09%, 10=0.11%, 20=0.01%, 50=0.01%
lat (msec): 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
lat (msec): 2000=0.01%
Run status group 0 (all jobs):
WRITE: io=3,819MB, aggrb=127MB/s, minb=130MB/s, maxb=130MB/s, mint=30001msec, maxt=30001msec
Disk stats (read/write):
md0: ios=0/514993, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%
fiod: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
fioc: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
fiob: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
fioa: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
[v025554@athenaash05 /]$ fio --filename=/fusionIO/export1/test1 --size=25G --bs=32k --direct=1 --rw=randwrite --numjobs=8 --runtime=30 --group_reporting --name=file1
file1: (g=0): rw=randwrite, bs=32K-32K/32K-32K, ioengine=sync, iodepth=1
...
file1: (g=0): rw=randwrite, bs=32K-32K/32K-32K, ioengine=sync, iodepth=1
Starting 8 processes
Jobs: 8 (f=8): [wwwwwwww] [100.0% done] [0K/343M /s] [0/11K iops] [eta 00m:00s]
file1: (groupid=0, jobs=8): err= 0: pid=23835
write: io=9,833MB, bw=328MB/s, iops=10,487, runt= 30002msec
clat (usec): min=64, max=227K, avg=349.31, stdev=1517.64
bw (KB/s) : min= 883, max=171712, per=16.25%, avg=54548.49, stdev=13973.76
cpu : usr=0.18%, sys=2.82%, ctx=669138, majf=0, minf=176
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/314659, short=0/0
lat (usec): 100=84.14%, 250=8.73%, 500=0.07%, 750=2.45%, 1000=3.19%
lat (msec): 2=0.29%, 4=0.17%, 10=0.22%, 20=0.23%, 50=0.31%
lat (msec): 100=0.13%, 250=0.05%
Run status group 0 (all jobs):
WRITE: io=9,833MB, aggrb=328MB/s, minb=336MB/s, maxb=336MB/s, mint=30002msec, maxt=30002msec
Disk stats (read/write):
md0: ios=0/455522, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%
fiod: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
fioc: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
fiob: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
fioa: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
[v025554@athenaash05 /]$ fio --filename=/fusionIO/export1/test1 --size=25G --bs=1M --direct=1 --rw=randwrite --numjobs=8 --runtime=30 --group_reporting --name=file1
file1: (g=0): rw=randwrite, bs=1M-1M/1M-1M, ioengine=sync, iodepth=1
...
file1: (g=0): rw=randwrite, bs=1M-1M/1M-1M, ioengine=sync, iodepth=1
Starting 8 processes
Jobs: 8 (f=8): [wwwwwwww] [100.0% done] [0K/912M /s] [0/890 iops] [eta 00m:00s]
file1: (groupid=0, jobs=8): err= 0: pid=24877
write: io=25,860MB, bw=862MB/s, iops=861, runt= 30004msec
clat (usec): min=456, max=83,766, avg=5599.02, stdev=2026.74
bw (KB/s) : min=28603, max=216966, per=11.93%, avg=105311.22, stdev=10668.06
cpu : usr=0.06%, sys=2.03%, ctx=91888, majf=0, minf=176
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w: total=0/25860, short=0/0
lat (usec): 500=12.74%, 750=20.60%, 1000=7.37%
lat (msec): 2=3.12%, 4=6.57%, 10=26.95%, 20=21.37%, 50=1.12%
lat (msec): 100=0.14%
Run status group 0 (all jobs):
WRITE: io=25,860MB, aggrb=862MB/s, minb=883MB/s, maxb=883MB/s, mint=30004msec, maxt=30004msec
Disk stats (read/write):
md0: ios=0/500382, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=0/0, aggrmerge=0/0, aggrticks=0/0, aggrin_queue=0, aggrutil=0.00%
fiod: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
fioc: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
fiob: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
fioa: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=nan%
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Question: BlockSize > 8192 with FusionIO
2011-01-04 00:33 Question: BlockSize > 8192 with FusionIO Strange, John W <john.w.strange@jpmchase.com>
@ 2011-01-04 02:13 ` Greg Smith <greg@2ndquadrant.com>
2011-01-04 16:48 ` Re: Question: BlockSize > 8192 with FusionIO Merlin Moncure <mmoncure@gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: Greg Smith @ 2011-01-04 02:13 UTC (permalink / raw)
To: Strange, John W <john.w.strange@jpmchase.com>; +Cc: pgsql-performance
Strange, John W wrote:
> Has anyone had a chance to recompile and try larger a larger blocksize than 8192 with pSQL 8.4.x?
While I haven't done the actual experiment you're asking about, the
problem working against you here is how WAL data is used to protect
against partial database writes. See the documentation for
full_page_writes at
http://www.postgresql.org/docs/current/static/runtime-config-wal.html
Because full size copies of the blocks have to get written there,
attempts to chunk writes into larger pieces end up requiring a
correspondingly larger volume of writes to protect against partial
writes to those pages. You might get a nice efficiency gain on the read
side, but the situation when under a heavy write load (the main thing
you have to be careful about with these SSDs) is much less clear.
I wouldn't draw any conclusions whatsoever from what fio says about
this; it's pretty useless IMHO for simulating anything like a real
database workload. I don't even use that utility anymore, as I found it
just wasted my time compared with moving straight onto something that
tries to act to like a database application simulation. You might try
running pgbench with the database scale set to large enough that the
resulting database is large relative to total system RAM instead.
P.S. Make sure you put the FusionIO drives under a heavy write load and
power down the server hard, so you can see what happens if there's a
real-world crash. Recovery time to remount the drives in that situation
is the main drawback of their design. It does the right thing to
protect your data as far as I know, but the recovery can be quite time
intensive.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Question: BlockSize > 8192 with FusionIO
2011-01-04 00:33 Question: BlockSize > 8192 with FusionIO Strange, John W <john.w.strange@jpmchase.com>
2011-01-04 02:13 ` Re: Question: BlockSize > 8192 with FusionIO Greg Smith <greg@2ndquadrant.com>
@ 2011-01-04 16:48 ` Merlin Moncure <mmoncure@gmail.com>
2011-01-04 18:36 ` Re: Question: BlockSize > 8192 with FusionIO Ben Chobot <bench@silentmedia.com>
2011-01-05 06:41 ` Re: Question: BlockSize > 8192 with FusionIO Scott Carey <scott@richrelevance.com>
0 siblings, 2 replies; 7+ messages in thread
From: Merlin Moncure @ 2011-01-04 16:48 UTC (permalink / raw)
To: Greg Smith <greg@2ndquadrant.com>; +Cc: Strange, John W <john.w.strange@jpmchase.com>; pgsql-performance
On Mon, Jan 3, 2011 at 9:13 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> Strange, John W wrote:
>>
>> Has anyone had a chance to recompile and try larger a larger blocksize
>> than 8192 with pSQL 8.4.x?
>
> While I haven't done the actual experiment you're asking about, the problem
> working against you here is how WAL data is used to protect against partial
> database writes. See the documentation for full_page_writes at
> http://www.postgresql.org/docs/current/static/runtime-config-wal.html
> Because full size copies of the blocks have to get written there, attempts
> to chunk writes into larger pieces end up requiring a correspondingly larger
> volume of writes to protect against partial writes to those pages. You
> might get a nice efficiency gain on the read side, but the situation when
> under a heavy write load (the main thing you have to be careful about with
> these SSDs) is much less clear.
most flash drives, especially mlc flash, use huge blocks anyways on
physical level. the numbers claimed here
(http://www.fusionio.com/products/iodrive/) (141k write iops) are
simply not believable without write buffering. i didn't see any note
of how fault tolerance is maintained through the buffer (anyone
know?).
assuming they do buffer, i would expect a smaller blocksize would be
better/easier on the ssd, since this would mean less gross writing,
higher maximum throughput, and less wear and tear on the flash; the
advantages of the larger blocksize are very hardware driven and
already managed by the controller.
if they don't buffer (again, I'm very skeptical this is the case), a
larger block size, possibly even a much larger block size (like 256k)
would be an interesting test. i'm pretty skeptical about the fusion
i/o product generally, because i don't think the sata interface is a
bottleneck save for read caching, and the o/s is already buffering
reads. the storage medium is still the bottleneck for the most part
(even if it's much faster at certain things). note fusion is still
useful for some things, but the nice is narrower than it looks on the
surface.
merlin
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Question: BlockSize > 8192 with FusionIO
2011-01-04 00:33 Question: BlockSize > 8192 with FusionIO Strange, John W <john.w.strange@jpmchase.com>
2011-01-04 02:13 ` Re: Question: BlockSize > 8192 with FusionIO Greg Smith <greg@2ndquadrant.com>
2011-01-04 16:48 ` Re: Question: BlockSize > 8192 with FusionIO Merlin Moncure <mmoncure@gmail.com>
@ 2011-01-04 18:36 ` Ben Chobot <bench@silentmedia.com>
2011-01-04 19:01 ` Re: Question: BlockSize > 8192 with FusionIO Strange, John W <john.w.strange@jpmchase.com>
1 sibling, 1 reply; 7+ messages in thread
From: Ben Chobot @ 2011-01-04 18:36 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; +Cc: pgsql-performance
On Jan 4, 2011, at 8:48 AM, Merlin Moncure wrote:
>
> most flash drives, especially mlc flash, use huge blocks anyways on
> physical level. the numbers claimed here
> (http://www.fusionio.com/products/iodrive/) (141k write iops) are
> simply not believable without write buffering. i didn't see any note
> of how fault tolerance is maintained through the buffer (anyone
> know?).
FusionIO buffers. They have capacitors onboard to protect against crashing and power failure. They passed our crash attempts to corrupt writes to them before we put them into production, for whatever that's worth, but they do take a long time to come back online after an unclean shutdown.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Question: BlockSize > 8192 with FusionIO
2011-01-04 00:33 Question: BlockSize > 8192 with FusionIO Strange, John W <john.w.strange@jpmchase.com>
2011-01-04 02:13 ` Re: Question: BlockSize > 8192 with FusionIO Greg Smith <greg@2ndquadrant.com>
2011-01-04 16:48 ` Re: Question: BlockSize > 8192 with FusionIO Merlin Moncure <mmoncure@gmail.com>
2011-01-04 18:36 ` Re: Question: BlockSize > 8192 with FusionIO Ben Chobot <bench@silentmedia.com>
@ 2011-01-04 19:01 ` Strange, John W <john.w.strange@jpmchase.com>
2011-01-04 20:31 ` Re: Question: BlockSize > 8192 with FusionIO Strange, John W <john.w.strange@jpmchase.com>
0 siblings, 1 reply; 7+ messages in thread
From: Strange, John W @ 2011-01-04 19:01 UTC (permalink / raw)
To: Ben Chobot <bench@silentmedia.com>; Merlin Moncure <mmoncure@gmail.com>; +Cc: pgsql-performance
This has gotten a lot better with the 2.x drivers as well.
I'm completely aware of the FusionIO and it's advantages/disadvantages.. I'm currently getting the following pgbench results but still only hitting the array for about 800MB/sec, short of the 3GB/sec that it's capable of. This is simply a trash DB for us to store results in for short periods of time. If something bad was to happen we can regenerate the results. So performance with limited risk is what we are looking to achieve.
asgprod@ASH01_riskresults $ pgbench -v -j 4 -t 200000 -c 16 -h localhost -p 4410 pgbench_10000
starting vacuum...end.
starting vacuum pgbench_accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 10000
query mode: simple
number of clients: 16
number of threads: 4
number of transactions per client: 200000
number of transactions actually processed: 3200000/3200000
tps = 16783.841042 (including connections establishing)
tps = 16785.592722 (excluding connections establishing)
-----Original Message-----
From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Ben Chobot
Sent: Tuesday, January 04, 2011 12:37 PM
To: Merlin Moncure
Cc: pgsql-performance@postgresql.org Performance
Subject: Re: [PERFORM] Question: BlockSize > 8192 with FusionIO
On Jan 4, 2011, at 8:48 AM, Merlin Moncure wrote:
>
> most flash drives, especially mlc flash, use huge blocks anyways on
> physical level. the numbers claimed here
> (http://www.fusionio.com/products/iodrive/) (141k write iops) are
> simply not believable without write buffering. i didn't see any note
> of how fault tolerance is maintained through the buffer (anyone
> know?).
FusionIO buffers. They have capacitors onboard to protect against crashing and power failure. They passed our crash attempts to corrupt writes to them before we put them into production, for whatever that's worth, but they do take a long time to come back online after an unclean shutdown.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Question: BlockSize > 8192 with FusionIO
2011-01-04 00:33 Question: BlockSize > 8192 with FusionIO Strange, John W <john.w.strange@jpmchase.com>
2011-01-04 02:13 ` Re: Question: BlockSize > 8192 with FusionIO Greg Smith <greg@2ndquadrant.com>
2011-01-04 16:48 ` Re: Question: BlockSize > 8192 with FusionIO Merlin Moncure <mmoncure@gmail.com>
2011-01-04 18:36 ` Re: Question: BlockSize > 8192 with FusionIO Ben Chobot <bench@silentmedia.com>
2011-01-04 19:01 ` Re: Question: BlockSize > 8192 with FusionIO Strange, John W <john.w.strange@jpmchase.com>
@ 2011-01-04 20:31 ` Strange, John W <john.w.strange@jpmchase.com>
0 siblings, 0 replies; 7+ messages in thread
From: Strange, John W @ 2011-01-04 20:31 UTC (permalink / raw)
To: pgsql-performance
Test,
Sorry trying to fix why my email is getting formatted to bits when posting to the list.
- John
-----Original Message-----
From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Strange, John W
Sent: Tuesday, January 04, 2011 1:01 PM
To: Ben Chobot; Merlin Moncure
Cc: pgsql-performance@postgresql.org Performance
Subject: Re: [PERFORM] Question: BlockSize > 8192 with FusionIO
This has gotten a lot better with the 2.x drivers as well.
I'm completely aware of the FusionIO and it's advantages/disadvantages.. I'm currently getting the following pgbench results but still only hitting the array for about 800MB/sec, short of the 3GB/sec that it's capable of. This is simply a trash DB for us to store results in for short periods of time. If something bad was to happen we can regenerate the results. So performance with limited risk is what we are looking to achieve.
asgprod@ASH01_riskresults $ pgbench -v -j 4 -t 200000 -c 16 -h localhost -p 4410 pgbench_10000
starting vacuum...end.
starting vacuum pgbench_accounts...end.
transaction type: TPC-B (sort of)
scaling factor: 10000
query mode: simple
number of clients: 16
number of threads: 4
number of transactions per client: 200000
number of transactions actually processed: 3200000/3200000
tps = 16783.841042 (including connections establishing)
tps = 16785.592722 (excluding connections establishing)
-----Original Message-----
From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Ben Chobot
Sent: Tuesday, January 04, 2011 12:37 PM
To: Merlin Moncure
Cc: pgsql-performance@postgresql.org Performance
Subject: Re: [PERFORM] Question: BlockSize > 8192 with FusionIO
On Jan 4, 2011, at 8:48 AM, Merlin Moncure wrote:
>
> most flash drives, especially mlc flash, use huge blocks anyways on
> physical level. the numbers claimed here
> (http://www.fusionio.com/products/iodrive/) (141k write iops) are
> simply not believable without write buffering. i didn't see any note
> of how fault tolerance is maintained through the buffer (anyone
> know?).
FusionIO buffers. They have capacitors onboard to protect against crashing and power failure. They passed our crash attempts to corrupt writes to them before we put them into production, for whatever that's worth, but they do take a long time to come back online after an unclean shutdown.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: Question: BlockSize > 8192 with FusionIO
2011-01-04 00:33 Question: BlockSize > 8192 with FusionIO Strange, John W <john.w.strange@jpmchase.com>
2011-01-04 02:13 ` Re: Question: BlockSize > 8192 with FusionIO Greg Smith <greg@2ndquadrant.com>
2011-01-04 16:48 ` Re: Question: BlockSize > 8192 with FusionIO Merlin Moncure <mmoncure@gmail.com>
@ 2011-01-05 06:41 ` Scott Carey <scott@richrelevance.com>
1 sibling, 0 replies; 7+ messages in thread
From: Scott Carey @ 2011-01-05 06:41 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; +Cc: Greg Smith <greg@2ndquadrant.com>; Strange, John W <john.w.strange@jpmchase.com>; pgsql-performance
On Jan 4, 2011, at 8:48 AM, Merlin Moncure wrote:
> On Mon, Jan 3, 2011 at 9:13 PM, Greg Smith <greg@2ndquadrant.com> wrote:
>> Strange, John W wrote:
>>>
>>> Has anyone had a chance to recompile and try larger a larger blocksize
>>> than 8192 with pSQL 8.4.x?
>>
>> While I haven't done the actual experiment you're asking about, the problem
>> working against you here is how WAL data is used to protect against partial
>> database writes. See the documentation for full_page_writes at
>> http://www.postgresql.org/docs/current/static/runtime-config-wal.html
>> Because full size copies of the blocks have to get written there, attempts
>> to chunk writes into larger pieces end up requiring a correspondingly larger
>> volume of writes to protect against partial writes to those pages. You
>> might get a nice efficiency gain on the read side, but the situation when
>> under a heavy write load (the main thing you have to be careful about with
>> these SSDs) is much less clear.
>
> most flash drives, especially mlc flash, use huge blocks anyways on
> physical level. the numbers claimed here
> (http://www.fusionio.com/products/iodrive/) (141k write iops) are
> simply not believable without write buffering. i didn't see any note
> of how fault tolerance is maintained through the buffer (anyone
> know?).
Flash may have very large erase blocks -- 4k to 16M, but you can write to it at much smaller block sizes sequentially.
It has to delete a block in bulk, but it can write to an erased block bit by bit, sequentially (512 or 4096 bytes typically, but some is 8k and 16k).
Older MLC NAND flash could be written to at a couple bytes at a time -- but drives today incorporate too much EEC and use larger chunks to do that. The minimum write size now is caused by the EEC requirements and not the physical NAND flash requirements.
So, buffering isn't that big of a requirement with the current LBA > Physical translations which change all writes -- random or not -- to sequential writes in one erase block.
But performance if waiting for the write to complete will not be all that good, especially with MLC. Turn off the buffer on an Intel SLC drive for example, and write IOPS is cut by 1/3 or more -- to 'only' 1000 or so iops.
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2011-01-05 06:41 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-01-04 00:33 Question: BlockSize > 8192 with FusionIO Strange, John W <john.w.strange@jpmchase.com>
2011-01-04 02:13 ` Greg Smith <greg@2ndquadrant.com>
2011-01-04 16:48 ` Merlin Moncure <mmoncure@gmail.com>
2011-01-04 18:36 ` Ben Chobot <bench@silentmedia.com>
2011-01-04 19:01 ` Strange, John W <john.w.strange@jpmchase.com>
2011-01-04 20:31 ` Strange, John W <john.w.strange@jpmchase.com>
2011-01-05 06:41 ` Scott Carey <scott@richrelevance.com>
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