patternsqlModerate
Postgres Write Performance on Intel S3700 SSD
Viewed 0 times
postgress3700ssdwriteintelperformance
Problem
I'm not seeing the Postgres write performance increases I thought I would with a single SSD vs a hardware RAID 10 array of (16) 15k RPM SAS drives.
I have a Dell R820 with a PERC H700 hardware RAID card and 16 15k RPM SAS drives in a RAID 10 array, as well as an 800GB Intel s3700 SSD. The server has 128GB of RAM and 64 cores of Xeon E5-4640 at 2.40GHz, running CentOS 6.4 and Postgres 9.2.4.
I'm using pgbench to compare the SAS drives in a RAID 10 array to the single SSD.
15k RPM SAS RAID 10 Results
pgbench -U postgres -p 5432 -T 50 -c 10 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 50 s
number of transactions actually processed: 90992
tps = 1819.625430 (including connections establishing)
tps = 1821.417384 (excluding connections establishing)
Single Intel s3700 SSD Results
pgbench -U postgres -p 5444 -T 50 -c 10 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 50 s
number of transactions actually processed: 140597
tps = 2811.687286 (including connections establishing)
tps = 2814.578386 (excluding connections establishing)
In real world usage we have a very write-intensive process that takes about 7 minutes to complete, and the RAID 10 array and SSD are within 10 or 15 seconds of each other.
I expected far better performance from the SSD.
Here are Bonnie++ results for the SSD:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
openlink2.rady 252G 532 99 375323 97 183855 45 1938 99 478149 54 +++++ +++
Latency 33382us 82425us 168ms 12966us 10879us 10208us
Version 1.96 ------Sequential Create------ --------Random Create----
I have a Dell R820 with a PERC H700 hardware RAID card and 16 15k RPM SAS drives in a RAID 10 array, as well as an 800GB Intel s3700 SSD. The server has 128GB of RAM and 64 cores of Xeon E5-4640 at 2.40GHz, running CentOS 6.4 and Postgres 9.2.4.
I'm using pgbench to compare the SAS drives in a RAID 10 array to the single SSD.
15k RPM SAS RAID 10 Results
pgbench -U postgres -p 5432 -T 50 -c 10 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 50 s
number of transactions actually processed: 90992
tps = 1819.625430 (including connections establishing)
tps = 1821.417384 (excluding connections establishing)
Single Intel s3700 SSD Results
pgbench -U postgres -p 5444 -T 50 -c 10 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
duration: 50 s
number of transactions actually processed: 140597
tps = 2811.687286 (including connections establishing)
tps = 2814.578386 (excluding connections establishing)
In real world usage we have a very write-intensive process that takes about 7 minutes to complete, and the RAID 10 array and SSD are within 10 or 15 seconds of each other.
I expected far better performance from the SSD.
Here are Bonnie++ results for the SSD:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
openlink2.rady 252G 532 99 375323 97 183855 45 1938 99 478149 54 +++++ +++
Latency 33382us 82425us 168ms 12966us 10879us 10208us
Version 1.96 ------Sequential Create------ --------Random Create----
Solution
I'm not really sure this is a problem in itself, because, as you can see, a single SSD drive can outperform an 8 disk RAID 10 setup in many tests.
Almost all the tests point to a better speed of the single SSD drive:
In a single case that SSD was outperformed, and that was sequential writes. Which, I'd say, is most usual for batches, not for an OLTP style of load. So if you're having mostly these kind of writes, maybe a single SSD is not a solution for you now.
And we're not talking about Fusion-IO drives (which I suspect might bring you that next level you'll expect, but at a next level price).
From the point of view of the DBA that had to work with crappy storage over the years, this is a fair advancement in technology and they seem to work properly, but maybe I have set my expectations too low.
I would expect to see more improvements from your SSD in testing the benchmark with more threads and with higher concurrency, as this is where the SSDs shine. So if you could repeat your tests with way more clients and more threads, I'd be curious about that comparison result.
Almost all the tests point to a better speed of the single SSD drive:
- better latencies
- lower CPU usage (if I'm reading correctly in some case it's 44% vs 95%)
- no of transactions per second is bigger with 55%
- no of transactions in total is bigger with the same 55%
In a single case that SSD was outperformed, and that was sequential writes. Which, I'd say, is most usual for batches, not for an OLTP style of load. So if you're having mostly these kind of writes, maybe a single SSD is not a solution for you now.
And we're not talking about Fusion-IO drives (which I suspect might bring you that next level you'll expect, but at a next level price).
From the point of view of the DBA that had to work with crappy storage over the years, this is a fair advancement in technology and they seem to work properly, but maybe I have set my expectations too low.
I would expect to see more improvements from your SSD in testing the benchmark with more threads and with higher concurrency, as this is where the SSDs shine. So if you could repeat your tests with way more clients and more threads, I'd be curious about that comparison result.
Context
StackExchange Database Administrators Q#45224, answer score: 10
Revisions (0)
No revisions yet.