@lists: "Well, 
After reading several glowing reviews of the new OCZ Vertex3 SSD last spring, 
we did some performance testing in dev on RHEL6. (CentOS) 
The results were nothing short of staggering. Complex query results returned 
in 1/10th the time as a pessimistic measurement. System loads dropped from 2+ 
to 0.1 or less. 
Wow. 
So after months of using this SSD without any issues at all, we tentatively 
rolled this out to production, and had blissful, sweet beauty until about 2 
weeks ago, now we are running into sudden death scenarios. We have excellent 
backup system, so the damage is reduced to roadbumps, but are looking for a 
longer term solution that doesn't compromise performance too much. 
The config is super-basic, basically no tuning at all was done: 
# fdisk /dev/NNN; 
mke2fs -j $partn; 
mount $partn /var/lib/pgsql; 
rsync -vaz /var/lib/pgsql.old /var/lib/pgsql; 
service postgresql start; 
I don't mind spending some money. Can anybody comment on a recommended drive 
in real world use?
After some review I found: 
1) Micron P300 SSD: claims excellent numbers, can't find them for sale 
anywhere. 
2) Intel X25E - good reputation, significantly slower than the Vertex3. We're 
buying some to reduce downtime. 
3) OCZ "Enterprise" - reviews are mixed. 
4) Kingston "Enterprise" drives appear to be identical to consumer drives with 
a different box. 
5) STEC drives are astronomically expensive. (EG: "You're kidding, right?") 
6) Corsair consumer drives getting excellent reviews, Aberdeen Inc recommended 
in use with RAID 1. 
7) Seagate Pulsar drives, XT.2 drives are expensive SLC but can't find a 
vendor, Pulsar .2 drives are more available but having trouble finding reviews 
other than rehashed press releases. 
Thanks! 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @mmoncure: "On Wed, Nov 2, 2011 at 12:01 PM, Benjamin Smith
<quote>
The X25-E is now essentially being replaced by the 710.  I would look there.
merlin
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @david_list: "<quote>
If you don't mind spending money, look at the new 710 Series from Intel.
Not SLC like the X25E, but still specified with a very high write endurance.
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @pierce: "you really need to watch out for excess write caching on SSDs.   only a 
few are safe against power failures while under heavy database write 
activity.
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @pierce: "<quote>
actually, SSD's have issues with committed small block (8K) random 
writes such as databases do a lot of.   the SSD has a rather large block 
size that has to be written all at once, so what they tend to do is 
accumulate random writes in a buffer, then write them all at once to a 
contiguous block (remapping the logical LBA sector address to an actual 
block/offset address).
as a test at work, I compared a 2 x 100GB SAS enterprise SSD RAID0 with 
a 20 x 146GB SAS 15k HD RAID10, both raids using a HP p410 hardware raid 
controller with 1Gb cache, and both using XFS.    Both file systems are 
approximately the same in sustainable random writes from postgres, up 
around 12000 wr/sec during heavy sustained pgbench activity (scaling 
factor of 500, 48 clients, 24 threads, on a 12 core 24 thread dual xeon 
e5660 48gb server).    The HD raid is faster at sustained large block 
writes from iozone (1.2GB/sec vs 800MB/sec for the SSD).  of course, the 
HD raid10 is 1.3TB of data, while the SSD raid0 is 200GB of data.
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @yebhavinga: "<quote>
Could you tell a bit more about the sudden death? Does the drive still 
respond to queries for smart attributes?
What firmware is on the Vertex 3? Anandtech talks about timing issues 
between certain IO controllers and the SandForce 2281 chipset, which 
appear to have been resolved in firmware 2.09 
(<url> 
regards,
Yeb
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @lists: "<quote>
Important enough that we back everything up hourly. Because of this, we 
decided to give the SSDs a try. 
Which is what we're trying next, X25E. 710's apparently have 1/5th the rated 
write endurance, without much speed increase, so don't seem like such an 
exciting product. 
It's advice about some of the "crazy expensive enterprise" stuff that I'm 
seeking...? I don't mind spending some money if I get to keep up this level of 
performance, but also am not looking to make somebody's private plane payment, 
either. 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @lists: "<quote>
Just that. It's almost like somebody physically yanked them out of the=20
machine, after months of 24x7 perfect performance. A cold reboot seems to=
=20
restore order for a while, but the drives die again similarly fairly soon=
=20
after a failure like this.=20
=46rom what I can tell, SMART is not worth much with SSDs.=20
-Ben=20
=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
=20
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @yebhavinga: "<quote>
I've tested the 710 with diskchecker.pl and it doesn't lie about it's 
cache status. I'm note sure about the X25E. that might also be a factor 
in the equation. According to Greg Smith the X25E is not ok - 
<url>
Also I'm *really* interested to know from one of the bad vertex 3's, 
what firmware is on it. (hdparm -I /dev/sdX or smartctl -i /dev/sdX).
 Yeb
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @kamauallan: "<quote>
How about SSDs on Raid 1+0 (I have no experience on SSD and RAID
though) and have replication to another server having the same setup
and still do frequent backups. The Crucial m4 SSDs seem to be
reasonably priced and perform well.
The savings on power and cooling may be used in offsetting some of
cost of the warm standby server.
Allan.
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @rob: "On Wed, Nov 2, 2011 at 11:02 PM, Benjamin Smith
<quote>
There's a pretty varied mix of speed, durability, and price with any
SSD based architecture, but the two that have proven best in our
testing and production use (for ourselves and our clients) seem to be
Intel (mostly 320 series iirc), and Fusion-IO. I'd start with austindaniel@example.com.
Robert Treat
conjecture: xzilla.net
consulting: omniti.com
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @lists: "<quote>
This is *exactly* the type of feedback that I've been looking for - thanks! 
The Fusion IO looks to be in the "if you have to ask about prices you probably 
can't afford it" range, although getting a million IOPS is damned impressive. 
I'm surprised a bit by the Intel 320 referenced, since this is typically 
touted as a consumer device, but we've consequently decided to give the 710 a 
shot since it's basically a 320 with some reliability upgrades, and see how it 
goes. 
I will post my results here later, time permitting. 
Thanks again. 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @kurtbuff: "<quote>
Oddly enough, Tom's Hardware has a review of the Intel offering today
- might be worth your while to take a austindaniel@example.com.
Kurt
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @miesi: "Am 03.11.2011 18:59, schrieb Robert Treat:
<quote>
Stec (<url> or texas memory systems 
(<url> do the kind of ssds you want for enterprise 
application. Reading the specs for intel 320, 710 you can calculate how 
long ssds will live when loaded with maximum random io workload.
intel 320  80GB   10TB written 10000 4k IOPS
  about 3 days to the of end design lifetime
intel 710 100GB  500TB written  2700 4k IOPS
  about 575 days to the of end design lifetime
If you are using Linux you can use the values in /proc/iostats to get a 
rough idea what your system is doing and how many tb get written per day.
stec offers a wear resistant ssd which is composed from 8GB RAM, a big 
capacitor, 8GB Flash and some logic to write the ram contents into flash 
when the power has gone.
see
<url>
<url>
<url>
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @yebhavinga: "<quote>
Thanks for that link! Seeing media wearout comparisons between 'consumer 
grade' and 'enterprise' disks was enough for me to stop thinking about 
the vertex 3 and intel 510 behind hardware raid: I'm going to stick with 
Intel 710 and Vertex 2 Pro on onboard SATA.
Tom's Hardware also showed how to test wearout using the workload 
indicator, so I thought lets do that with a pgbench workload.
First, if your'e interested in doing a test like this yourself, I'm 
testing on ubuntu 11.10, but even though this is a brand new 
distribution, the smart database was a few months old. 
'update-smart-drivedb' had as effect that the names of the values turned 
into something useful: instead of #LBA's written, it now shows #32MiB's 
written. Also there are now three 'workload' related parameters.
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   
Always       -       108551
226 Workld_Media_Wear_Indic 0x0032   100   100   000    Old_age   
Always       -       17
227 Workld_Host_Reads_Perc  0x0032   100   100   000    Old_age   
Always       -       0
228 Workload_Minutes        0x0032   100   100   000    Old_age   
Always       -       211
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  
Always       -       0
233 Media_Wearout_Indicator 0x0032   100   100   000    Old_age   
Always       -       0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   
Always       -       108551
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   
Always       -       21510
Tom's hardware on page 
<url> 
shows how to turn these numbers into useful values.
The numbers above were taken 211 minutes after I cleared the workload 
values with smartctl -t vendor,0x40 /dev/sda. If you do that, the 
workload values become 0, then after a few minutes they all become 65535 
and not before 60 minutes of testing you'll see some useful values returned.
During the test, I did two one hour pgbench runs on a md raid1 with the 
intel 710 and vertex 2 pro, wal in ram.
pgbench -i -s 300 t (fits in ram)
pgbench -j 20 -c 20 -M prepared -T 3600 -l  t  (two times)
% mediawear by workload is Workld_Media_Wear_Indic / 1024
17/1024 = .0166015625 %
Lets turn this into # days. I take the most pessimistic number of 120 
minutes of actual pgbench testing, instead of the total minutes since 
workload reset of 211 minutes.
120/(17/1024/100)/60/24 = 501.9608599031 days
The Host_Reads_32MiB value was 91099 before the test, now it austindaniel@example.com.
(108551-91099)*32/1024 = 545 GB written during the test.
(108551-91099)*32/1024/1024/(17/1024/100) = 3208 TB before media wearout.
This number fits between Tom's hardware's calculated wearout numbers, 
7268 TB for sequential and 1437 TB for random load.
 Yeb
PS: info on test setup
Model Number:       INTEL SSDSA2BZ100G3  Firmware Revision:  6PB10362
Model Number:       OCZ-VERTEX2 PRO      Firmware Revision:  1.35
partitions aligned on 512kB boundary.
workload on ~20GB software raid mirror (drives are 100GB).
Linux client46 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 
2011 x86_64 x86_64 x86_64 GNU/Linux
PostgreSQL 9.2devel on x86_64-unknown-linux-gnu, compiled by gcc 
(Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1, 64-bit
/proc/sys/vm/dirty_background_bytes set to 178500000
non standard parameters of pg are:
maintenance_work_mem = 1GB # pgtune wizard 2011-10-28
checkpoint_completion_target = 0.9 # pgtune wizard 2011-10-28
effective_cache_size = 16GB # pgtune wizard 2011-10-28
work_mem = 80MB # pgtune wizard 2011-10-28
wal_buffers = 8MB # pgtune wizard 2011-10-28
checkpoint_segments = 96
shared_buffers = 5632MB # pgtune wizard 2011-10-28
max_connections = 300 # pgtune wizard 2011-10-28
Latency and tps graphs of *one* of the 20 clients during the second 
pgbench test are here: <url> - note that max latency 
has dropped from ~ 3 seconds from earlier tests to ~ 1 second - this is 
mainly due to an increase of checkpoint segments from 16 to 96.
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @david_list: "<quote>
I submitted the patch for these to smartmontools a few weeks ago and it 
is now in the current db but not yet in any of the distro update 
packages. I probably forgot to mention in my post here that you need the 
latest db for the 710. Also, if you pull the trunk source code and build 
it yourself it has the ability to decode the drive stats log data 
(example pasted below). I haven't yet found a use for this myself, but 
it does seem to have a little more informaiton than the SMART 
attributes. (Thanks to Christian Franke of the smartmontools project for 
implementing this feature)
Your figures from the workload wear roughly match mine. In production we 
don't expect to subject the drives to anything close to 100% of the 
pgbench workload (probably around 1/10 of that on average), so the 
predicted wear life of the drive is 10+ years in our estimates, under 
production loads.
The big question of course is can the drive's wearout estimate be 
trusted ? A little more information from Intel about how it is 
calculated would help allay concerns in this area.
# ./smartctl -l devstat,0 /dev/sda
smartctl 5.42 2011-10-10 r3434 [x86_64-linux-2.6.32-71.29.1.el6.x86_64] (local build)
Copyright (C) 2002-11 by Bruce Allen,<url>
Device Statistics (GP Log 0x04) supported pages
Page Description
   0  List of supported log pages
   1  General Statistics
   4  General Errors Statistics
   5  Temperature Statistics
   6  Transport Statistics
   7  Solid State Device Statistics
# ./smartctl -l devstat /dev/sda
smartctl 5.42 2011-10-10 r3434 [x86_64-linux-2.6.32-71.29.1.el6.x86_64] (local build)
Copyright (C) 2002-11 by Bruce Allen,<url>
Device Statistics (GP Log 0x04)
Page Offset Flg Size       Value  Description
   1  =====  ==  =              =  == General Statistics (rev 2) ==
   1  0x008  V-  4             10  Lifetime Power-On Resets
   1  0x010  V-  4            200  Power-on Hours
   1  0x018  V-  6     +1-501-570-7385  Logical Sectors Written
   1  0x020  V-  6      248189788  Number of Write Commands
   1  0x028  V-  6       54653524  Logical Sectors Read
   1  0x030  V-  6        2626204  Number of Read Commands
   4  =====  ==  =              =  == General Errors Statistics (rev 1) ==
   4  0x008  V-  4              0  Number of Reported Uncorrectable Errors
   4  0x010  V-  4              0  Resets Between Cmd Acceptance and Completion
   5  =====  ==  =              =  == Temperature Statistics (rev 1) ==
   5  0x008  V-  1             21  Current Temperature
   5  0x010  V-  1             20  Average Short Term Temperature
   5  0x018    1             20  Average Long Term Temperature
   5  0x020  V-  1             30  Highest Temperature
   5  0x028  V-  1             17  Lowest Temperature
   5  0x030  V-  1             23  Highest Average Short Term Temperature
   5  0x038  V-  1             18  Lowest Average Short Term Temperature
   5  0x040    1           -128  Highest Average Long Term Temperature
   5  0x048    1           -128  Lowest Average Long Term Temperature
   5  0x050  V-  4              0  Time in Over-Temperature
   5  0x058  V-  1             70  Specified Maximum Operating Temperature
   5  0x060  V-  4              0  Time in Under-Temperature
   5  0x068  V-  1              0  Specified Minimum Operating Temperature
   6  =====  ==  =              =  == Transport Statistics (rev 1) ==
   6  0x008  V-  4             77  Number of hardware resets
   6  0x010  V-  4             22  Number of ASR Events
   6  0x018  V-  4              0  Number of Interface CRC Errors
   7  =====  ==  =              =  == Solid State Device Statistics (rev 1) ==
   7  0x008  V-  1              0  Percentage Used Endurance Indicator
             ||_ N normalized
             |__ V valid
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @vivek: "<quote>
We have been using the RamSan-620 from Texas Memory Systems
<<url> for over a year now on a heavy write load.  I
have a pair of them for redundancy on two servers replicated using
Slony.  Nobody would ever call these things cheap, but the technology
behind them is nothing short of phenomenal.
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @yebhavinga: "<quote>
TLDR: some numbers after three week media wear testing on a software 
mirror with intel 710 and ocz vertex 2 pro.
The last couple of weeks I've been running pgbench for an hour then 
sleep for 10 minutes in an infinite loop, just to see how values would grow.
This is the intel 710 mirror leg:
225 Host_Writes_32MiB       0x0032   100   100   000    Old_age   
Always       -       3020093
226 Workld_Media_Wear_Indic 0x0032   100   100   000    Old_age   
Always       -       2803
227 Workld_Host_Reads_Perc  0x0032   100   100   000    Old_age   
Always       -       0
228 Workload_Minutes        0x0032   100   100   000    Old_age   
Always       -       21444
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  
Always       -       0
233 Media_Wearout_Indicator 0x0032   098   098   000    Old_age   
Always       -       0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   
Always       -       3020093
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   
Always       -       22259
Note: raw value of 226 (E2) = 2803. According to 
<url> 
you have to divide it by 1024 to get a percentage. That would be 2%. 
This matches with 098 of the (not raw) value at 233 (E9).
This is the ocz vertex 2 PRO mirror leg:
   5 Retired_Block_Count     0x0033   100   100   003    Pre-fail  
Always       -       0
  12 Power_Cycle_Count       0x0032   100   100   000    Old_age   
Always       -       22
100 Gigabytes_Erased        0x0032   000   000   000    Old_age   
Always       -       21120
170 Reserve_Block_Count     0x0032   000   000   000    Old_age   
Always       -       34688
177 Wear_Range_Delta        0x0000   000   000   000    Old_age   
Offline      -       3
230 Life_Curve_Status       0x0013   100   100   000    Pre-fail  
Always       -       100
231 SSD_Life_Left           0x0013   100   100   010    Pre-fail  
Always       -       0
232 Available_Reservd_Space 0x0000   000   000   000    Old_age   
Offline      -       33
233 SandForce_Internal      0x0000   000   000   000    Old_age   
Offline      -       21184
234 SandForce_Internal      0x0032   000   000   000    Old_age   
Always       -       94656
235 SuperCap_Health         0x0033   100   100   002    Pre-fail  
Always       -       0
241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   
Always       -       94656
242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   
Always       -       960
Here the 177 (B1) wear range delta is on a raw value of 3 - this isn't 
ssd life left, but Delta between most-worn and least-worn Flash blocks. 
I really wonder at which point SSD life left will change to 99 on this 
drive..
regards,
Yeb Havinga
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
    @yebhavinga: "<quote>
Bingo! On the OCZ Vertex 2 PRO, SSD life left to 99 after just over 
100PB written.
230 Life_Curve_Status       0x0013   100   100   000    Pre-fail  
Always       -       100
231 SSD_Life_Left           0x0013   099   099   010    Pre-fail  
Always       -       0
232 Available_Reservd_Space 0x0000   000   000   000    Old_age   
Offline      -       33
233 SandForce_Internal      0x0000   000   000   000    Old_age   
Offline      -       22848
234 SandForce_Internal      0x0032   000   000   000    Old_age   
Always       -       101952
235 SuperCap_Health         0x0033   100   100   002    Pre-fail  
Always       -       0
241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   
Always       -       101952
242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   
Always       -       960
The Intel 710 now shows media wearout of 97.
226 Workld_Media_Wear_Indic 0x0032   100   100   000    Old_age   
Always       -       3028
227 Workld_Host_Reads_Perc  0x0032   100   100   000    Old_age   
Always       -       0
228 Workload_Minutes        0x0032   100   100   000    Old_age   
Always       -       22966
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  
Always       -       0
233 Media_Wearout_Indicator 0x0032   097   097   000    Old_age   
Always       -       0
241 Host_Writes_32MiB       0x0032   100   100   000    Old_age   
Always       -       3255685
242 Host_Reads_32MiB        0x0032   100   100   000    Old_age   
Always       -       22259
regards,
Yeb Havinga
Sent via pgsql-general mailing list (<email_address>)
To make changes to your subscription:
<url>"
{'source': 'USENET', 'other_information': '{"reply_count": 18, "forum_name": "mailing.database.pgsql-general.20141106.mbox"}', 'file': 'data/output/usenet-mailing.database.parquet'}