SSD for a logging drive

[Garet Jax]

I am building a couple of machines for test boxes for enterprise IBM software. These software packages create humongous log files and this is generally a bottle neck that you need to work around.

I have thought of using SSDs for these test boxes and wanted to get opinion on it.

I have read that having lots and lots of little updates is very hard on these drives and wears them out much more quickly that having fewer but larger updates.

So:

1) Would using SSDs as logging directories speed up ultimate performance if there were multiple log files that were being written to by various threads?

2) Would using SSDs as logging drives shorten the ultimate lifespan of these drives?

3) Are there features or attributes of a SSD that you would recommend as a must have for this purpose (ie SLC vs MLC)?

Thanks a lot.

 

[lsv]

I am building a couple of machines for test boxes for enterprise IBM software. These software packages create humongous log files and this is generally a bottle neck that you need to work around.

I have thought of using SSDs for these test boxes and wanted to get opinion on it.

I have read that having lots and lots of little updates is very hard on these drives and wears them out much more quickly that having fewer but larger updates.

Get an enterprise drive such as the X-25E and this won't be as big of an issue.

So:

1) Would using SSDs as logging directories speed up ultimate performance if there were multiple log files that were being written to by various threads?

Yes

2) Would using SSDs as logging drives shorten the ultimate lifespan of these drives?

Yes (but this will happen to any drive being used a whole bunch- enterprise level SSDs will last much longer)

3) Are there features or attributes of a SSD that you would recommend as a must have for this purpose (ie SLC vs MLC)?

Get an Enterprise level SLC drive with Trim support, such as an X25-E for increased performance and durability.

Lower priced drives usually use multi-level cell (MLC) flash memory, which is slower and less reliable than single-level cell (SLC) flash memory. This can be mitigated or even reversed by the internal design structure of the SSD, such as interleaving, changes to writing algorithms, and more excess capacity for the wear-leveling algorithms to work with. (Wikipedia)

Thanks a lot.

I hope that helps.

 

[Garet Jax]

I hope that helps.

Thanks a lot for your answers. They did help.

Unfortunately the X25-E is well out of my price range especially since these comps are for professional/personal development and each comp only cost me ~$600.

I am looking at the Kingston SSDNow V-Series 30GB Serial ATA Internal Solid State Disk (SSD) 2.5" Kit which can be had for around 1/6 of the cost of the X25-E.

Are your answers still the same for the Kingston SSD?

 

[lsv]

Thanks a lot for your answers. They did help.

Unfortunately the X25-E is well out of my price range especially since these comps are for professional/personal development and each comp only cost me ~$600.

I am looking at the Kingston SSDNow V-Series 30GB Serial ATA Internal Solid State Disk (SSD) 2.5" Kit which can be had for around 1/6 of the cost of the X25-E.

Are your answers still the same for the Kingston SSD?

Generally... yes. However I do recommend an SLC drive if possible once you build the final box.

 

[StarTech]

These software packages create humongous log files and this is generally a bottle neck that you need to work around.

The first thing that comes to mind is that "humongous" is an undefined term. There is not such a thing as an standard HumongoByte, so your humoungus may or may not be insignificant vs what an SSD can take as punishment without noticeable degradation. There are many references out there as to how much you would have to write daily to a drive to kill it in a number of years.

Also, there is another aspect to it. Either you need to get those tests done in a short time, or you don't. If you do, and you drive the drive very hard and it happens to die in a year, then so what.. (<$200) I would go for an MLC and do not worry about it. At the end, probably it will log at most a few GB per day. Not a problem.

 

[Barnaby W. Füi]

Are these contiguous or scattered writes? That will make all the difference. The SSD will probably only be a dramatic improvement if they are scattered writes.

 

[lsv]

Are these contiguous or scattered writes? That will make all the difference. The SSD will probably only be a dramatic improvement if they are scattered writes.

He wrote;
1) Would using SSDs as logging directories speed up ultimate performance if there were multiple log files that were being written to by various threads?

I assume random writes, not sequential. If his budget is low Then the Kingston will be a massive improvement over a magnetic drive but not to what some SSDs can get.

Then again let OP answer.

 

[Emulex]

logging is sequential but that is irrelevant to ssd imo since you don't consider fragmentation much.

sql server i assume you are talking about. logs are written immediately then the core sql storage lazy writes the data as it has time. separating random (core filegroups) from sequential only has massive gains.

also lets you do space savings like raid-5 for core database and raid-1/10 for logs/tmp to leverage maximum performance and more space.

i prefer raid-10 for primary filegroups, raid-1 for tmp, raid-1 for log - per database. can never go wrong. but if you can't afford a san raid-5 for filegroups, raid-1 for log can work well. it is far superior to a single raid-1 or raid-5 that is for damn sure

 

[LokutusofBorg]

Unless you're comparing to a RAID array of spindle drives then an SSD will be faster no matter the usage scenario (unless you buy a POS SSD).

In one of Anand's SSD articles he did larger scale enterprise testing, and at the end what stuck in my mind was an ideal setup for a DB server: an array of SSDs for the data files, and an array of high-RPM SAS drives for the log files.

For a typical RDBMS the IO profile for the data files is random and for the log files it's sequential. When you RAID enough SAS drives together, they can surpass the sequential speeds of SSDs, even multiple SSDs.

The logging you describe doesn't sound like it correlates to typical database server logs, so your IO profile is likely more random in nature. An SSD will trounce spindle drives in that case.

 

[beginner99]

As far as I understood it's server/pc for testing. So these logs are not mission-critical. Hence a consumer sdd will probably be ok too. I suggest to buy one and test if it does help before ordering for all pc's or ask IBM directly.

 

[sub.mesa]

Lower priced drives usually use multi-level cell (MLC) flash memory, which is slower and less reliable than single-level cell (SLC) flash memory.

I do not particularly agree with this:

1) MLC 34nm NAND in X25-M G2 is faster than SLC 50nm NAND in X25-E; lower read access latency
2) less reliable is so vague; you mean less write cycles; but MLC can have more NAND pages; the total write endurance (say 5TB) is actually all that counts. Double capacity SSDs could have double the write endurance, or the same if they use the same number of chips (like Intel X25-M 80GB versus 160GB not much difference!)
3) SLC will disappear and MLC will be used in enterprise SSDs; the upcoming successor of X25-E will use MLC memory. The difference here lies in spare area; the enterprise disks will have alot more dedicated spare area and do not require TRIM at all. Ideally, up to 50&#37; of capacity would be given as spare area. This would make sure write amplification remains close to 1.00 and that the SSD would not slow down over time.
4) Other than Intel, the only SLC drives are mostly SuperTalent and other 'controllerless' SSDs; these are very cheap, very slow and low quality. So the "SLC is better quality than MLC" doesn't really work in todays world.

As for the intended usage: there is another issue: lost writes on power failures. If the power is cut, Intel X25-E and X25-M will lose writes which makes it a bad log devices. A good log devices will have a supercapacitor. Some Sandforce models have this, and it would allow safe writes; just like a BBU on a hardware RAID. But supercaps are much smaller, of course.