Hi David,
Does the RAID 1 array give any performance benefits over a single drive? I'd guess that writes may be slower, reads may be faster (if balanced) but data security is improved.
Brent Wood
Does the RAID 1 array give any performance benefits over a single drive? I'd guess that writes may be slower, reads may be faster (if balanced) but data security is improved.
Brent Wood
| Brent Wood |
| Principal Technician - GIS and Spatial Data Management Programme Leader - Environmental Information Delivery |
| +64-4-386-0529 | 301 Evans Bay Parade, Greta Point, Wellington | www.niwa.co.nz |
 |
________________________________________
From: pgsql-general-owner@xxxxxxxxxxxxxx [pgsql-general-owner@xxxxxxxxxxxxxx] on behalf of David Rees [drees76@xxxxxxxxx]
Sent: Friday, April 4, 2014 8:32 AM
To: Merlin Moncure
Cc: bret_stern@xxxxxxxxxxxxxxxxxxxxx; PostgreSQL General
Subject: Re: SSD Drives
On Thu, Apr 3, 2014 at 12:13 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote:
> On Wed, Apr 2, 2014 at 2:37 PM, Bret Stern
> <bret_stern@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> Any opinions/comments on using SSD drives with postgresql?
>
> Here's a single S3700 smoking an array of 16 15k drives (poster didn't
> realize that; was to focused on synthetic numbers):
> http://dba.stackexchange.com/questions/45224/postgres-write-performance-on-intel-s3700-ssd
I just ran a quick test earlier this week on an old Dell 2970 (2
Opteron 2387, 16GB RAM) comparing a 6-disk RAID10 with 10k 147GB SAS
disks to a 2-disk RAID1 with 480GB Intel S3500 SSDs and found the SSDs
are about 4-6x faster using pgbench and a scaling factor of 1100. Some
sort of MegaRAID controller according to lspci and has BBU. TPS
numbers below are approximate.
RAID10 disk array:
8 clients: 350 tps
16 clients: 530 tps
32 clients: 800 tps
RAID1 SSD array:
8 clients: 2100 tps
16 clients: 2500 tps
32 clients: 3100 tps
So yeah, even the slower, cheaper S3500 SSDs are way fast. If your
write workload isn't too high, the S3500 can work well. We'll see how
the SMART drive lifetime numbers do once we get into production, but
right now we estimate they should last at least 5 years and from what
we've seen it seems that SSDs seem to wear much better than expected.
If not, we'll pony up and go for the S3700 or perhaps move the xlog
back on to spinning disks.
-Dave
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
From: pgsql-general-owner@xxxxxxxxxxxxxx [pgsql-general-owner@xxxxxxxxxxxxxx] on behalf of David Rees [drees76@xxxxxxxxx]
Sent: Friday, April 4, 2014 8:32 AM
To: Merlin Moncure
Cc: bret_stern@xxxxxxxxxxxxxxxxxxxxx; PostgreSQL General
Subject: Re: SSD Drives
On Thu, Apr 3, 2014 at 12:13 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote:
> On Wed, Apr 2, 2014 at 2:37 PM, Bret Stern
> <bret_stern@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> Any opinions/comments on using SSD drives with postgresql?
>
> Here's a single S3700 smoking an array of 16 15k drives (poster didn't
> realize that; was to focused on synthetic numbers):
> http://dba.stackexchange.com/questions/45224/postgres-write-performance-on-intel-s3700-ssd
I just ran a quick test earlier this week on an old Dell 2970 (2
Opteron 2387, 16GB RAM) comparing a 6-disk RAID10 with 10k 147GB SAS
disks to a 2-disk RAID1 with 480GB Intel S3500 SSDs and found the SSDs
are about 4-6x faster using pgbench and a scaling factor of 1100. Some
sort of MegaRAID controller according to lspci and has BBU. TPS
numbers below are approximate.
RAID10 disk array:
8 clients: 350 tps
16 clients: 530 tps
32 clients: 800 tps
RAID1 SSD array:
8 clients: 2100 tps
16 clients: 2500 tps
32 clients: 3100 tps
So yeah, even the slower, cheaper S3500 SSDs are way fast. If your
write workload isn't too high, the S3500 can work well. We'll see how
the SMART drive lifetime numbers do once we get into production, but
right now we estimate they should last at least 5 years and from what
we've seen it seems that SSDs seem to wear much better than expected.
If not, we'll pony up and go for the S3700 or perhaps move the xlog
back on to spinning disks.
-Dave
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
