From: | Stephen Tyler <stephen(at)stephen-tyler(dot)com> |
---|---|
To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Re: Bench marking performance or experience using Solid State Disk Drives (SSD) with postgres |
Date: | 2009-11-06 14:02:32 |
Message-ID: | 51549ea20911060602s647c7bc1maac2924aff63f964@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Nov 6, 2009 at 5:05 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> Have you noticed any fall off in performance as they get re-written a
> lot? I'm wondering just how much of the issues with fragmentation
> have been fixed versus just putting the problem further into the
> future...
There has been no drop-off in sequential read speed (around 400MB/s,
or 200MB/s per drive) that I have noticed. As for write speed, I
haven't benchmarked it with a system that is sufficiently repeatable
to detect minor differences, but it still seems as fast as ever.
I've overwritten my disk many, many times (not erased - just lots of
database inserts and deletes). It should be as completely fragmented
as it is ever going to get.
Right now I'm getting 110MB/s when I copy a large file from one part
of the SSD array to another part (so simultaneous 110MB/s read and
110MB/s write, on an array that is 89% full, and one CPU core at 100%
doing something else, and a database doing around 50 reads and 10
writes per second elsewhere on the same disks). It would probably do
a little better if I could try it on a fully idle system, but I don't
think it would make much of a difference. Halve those numbers for the
speed of a single X-25M.
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Ries van Twisk | 2009-11-06 14:12:11 | Re: xml import/export tools and performance |
Previous Message | Albe Laurenz | 2009-11-06 13:56:51 | Re: MD5 Authentication |