Re: Bench marking performance or experience using Solid State Disk Drives (SSD) with postgres - Mailing list pgsql-general

From Stephen Tyler
Subject Re: Bench marking performance or experience using Solid State Disk Drives (SSD) with postgres
Date
Msg-id 51549ea20911052005w60ed979bye7125ed8e59e7b04@mail.gmail.com
Whole thread Raw
Responses Re: Re: Bench marking performance or experience using Solid State Disk Drives (SSD) with postgres  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-general
Chris Barnes wrote:
>> Does anyone use solid state drives for postgres?
>>  Has there been any benchmark that states whether mechanical disk drives out perform solid state drives?
>>  Is there any benefit, they are quite expensive.

I am currently running PostgreSQL 8.4.1 on a Mac Pro 2009 with a RAID
0 array consisting of 2 Intel X-25M 160G disks (50nm version).

Assuming postgresql is running properly (Snow Leopard 64 bit seems to
have created a few hassles) I get the following speed:

1) Up to around 10K random reads/second for small reads that are not CPU limited
2) Up to around 4K random writes/second for smallish writes that are
not CPU limited
3) Around 400MB/second sustained read (with less than 600 read I/Os,
and not CPU limited)
4) Around 140-160MB/second sustained writes
[These are not the drive specs, they are what I observe in "Activity Monitor"]

There is very little difference between sequential I/O and random I/O
speeds for most practical applications, which is wonderful.
Typically, in my normal environment, when postgres is busy,  I see 2K
- 3K reads / second, and up to 1K writes / second, as reported by
"Activity Monitor".

However, some things in postgresql run much slower than I would expect
on my machine.  pg_dump seems peak at only 60MB/s on the read side.
And "VACUUM FULL" typically grinds along at only around 1MB/s on large
tables.  And each transaction seems to cause a delay.  Under postgres,
I'm not very happy with my transactions per second - but I don't
really know what the bottleneck is here.

My previous system was Linux MySQL on a RAID 5 array consisting of 6 x
SCSI U320/ 15K disks.
Performance was dominated by the random seek time, which was around
4ms for that system (100us for my current system).

Most non-bulk operations are radically faster on the SSD.  It could
well be 40x faster under random I/O, but I haven't benchmarked it.

And I can report that the SSD drives are radically quieter and cooler.
 My old system was like a leaf-blower (14 fans, kept the room warm).
I can't even hear my SSDs :)


The specification of my SSD drives is kind of depressing:
http://www.intel.com/design/flash/nand/mainstream/technicaldocuments.htm

"The drive will have a minimum of 5 years of useful life under typical
client workloads with up to 20 GB of host writes per day."

That equates to only 40TB cumulative writes, or only 228 complete
drive rewrites.  At that rate, I could wear out the drive in only 6
days of continuous, flat-out writing.

But I'm hoping that the drive will be good for say 10,000 complete
cumulative rewrites, or 1600TB per drive, as modern quality flash
memory supports much more than 10K rewrites.  The cost of the drives
has already halved in the few months I have had them, so they should
be virtually free by the time they wear out and need replacement :)

So far I have encountered zero errors on the SSD drives, and SMART
status is OK.  The SCSI U320 15K drives have given a few soft errors
over the past few years.

Stephen

pgsql-general by date:

Previous
From: Chris
Date:
Subject: Re: Three fields table: id-data-date_time, how to get max() and date_time same time?
Next
From: John DeSoi
Date:
Subject: Re: MD5 Authentication