Slashdot Mirror
Tweaking Solid State Drive Performance On Linux
perlow writes "While Solid State Drives are expensive and shouldn't be used exclusively for primary storage, they perform exceedingly well for things like MySQL databases, provided you tweak your kernel, BIOS, and filesystems accordingly. Here's a few tips to get excellent performance out of your new $500-$900 investment on a Linux system."
I'm interested how useful this could be for my EeePC since it only uses SSDs. let's see
Thanks to SSD performance tweaks.
SSD Drives are nice and all, but a Major MYSQL DB would eat a flash disk alive, all those writes, even if the drive supports 10 billion writes, for a big mysql DB, it could eat that in a year, You will still need a shit ton of ram cache for the main DB so all the minor writes dont kill the disk, there is the fact of data loss in the power loss... all writes stored in memory will be lost... HDs are slow yes, but SSD is just not there just yet
WulframII - Free Online Mutiplayer 3D Tank Shooting Game
to be extract
personally, i prefer tweaking on meth.
I've just purchased a 4gb transcend 300x card (udma5) and an addonics IDE to CF adapter. This article comes along at a great time, since scouring the net for information on "flash linux" usually results in some article regarding USB installations, which are about 2x (or more, depending on drive used) slower than this solution.
The only thing that this PC runs is minor browsing when looking up a car repair, or Amarok (with a MySQL backend.) Regarding the mysql backend, it doesn't seem like there will be enough action on the disk to even begin to worry about the flash failing.
In addition, the transcend I purchased (and most high end == costly) is an SLC device, which I've read is faster as well as can sustain more writes over the lifetime of the drive. I see this as worthwhile in a system such as this, as I want it to be an "install and forget" type of system. Using a spinning platter in the variable humidity and temperature conditions just doesn't seem to make sense - especially when most of the media used would be in a server in my basement.
I'm also looking into network booting; however the PC that I've slated for use in the garage would probably require a bootable floppy/cd since it's old enough to not be bootable from an installed NIC. Maybe I just need to add a newer NIC - but I've not spent a lot of time researching that.
If anyone has other articles I could enhance my knowledge with - and possibly doing something similar to my setup - I'd love to read them.
Karnal
He recommends disabling journalling and using RAID instead?
So exactly how will a RAID make sure the filesystem metadata is still intact when I yank out the power cable for fun and no profit, as opposed to using a filesystem with a journal?
Sheesh... that's just begging for an accident to happen.
np: Yello - You Gotta Say Yes To Another Excess (Orb Goes The Weasel Mix) (Auntie Aubrey's Excursions Beyond The Call Of Duty (Disc 2))
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
I'm surprised I've heard very little about using Unix/Linux partitioning to get the best out of SSDs.
Seems to me that the best use of an SSD on a normal system is to buy a smallish one (say 16GB) and use it for the read-mainly partitions: say /usr, /opt, maybe /lib.
It would be good to get users' "dot" files in there too. Maybe create a /homedot on the SSD and symlink /home/myname/.example to /homedot/myname/.example.
Even if this doesn't make your applications run much faster, the faster read and seek times are going to make the machine boot faster, load applications faster (especially including the desktop environments, if user directories like .kde and .gnome are on SSD) and compile code faster (with /usr/include, etc on SSD).
s but the article then advocates some dangerous behavior. Write back cache only works if you don't think you will have a power failure, and as we saw on /. previously, that can be real disaster. He also advocates forgoing journaling in favor of RAIDs, but again that can be dangerous if your machine somehow gets into a weird state. Not sure I would trust mission critical data without Journaling or Write-through unless that data was backed up somewhere else.
Monstar L
Here some SSD benchmarks for MySQL with a conclusion of "with the relatively low cost of the technology, you could net 10X+ performance increase on your database servers for under $2000."
Does MySQL allow one to store the indices in a separate file/drive from the rest of the database entries? That would speed things up significantly without needing a large SSD drive.
Buy a drive intelligently. Maybe they should check out these drives. http://www.newegg.com/Product/Product.aspx?Item=N82E16820227344 http://www.hothardware.com/News/OCZ_Core_Series_SSD_Vs_VelociRaptor_Sneak_Peek/ The 32GB version that would be suitable for a linux boot drive is going to have a $140-160 price point I believe. I'm considering a 64GB for my Vista laptop to reduce the heat it generates.
Do the math. Most flash media are good for at least 100,000 writes. They also use wearing algorithms so that each block averages out to about the same. Even if you try to write to a certain block over and over, the algorithms take over and move blocks that are not written very often to those locations, so blocks end up being written to about the same.
With that in mind, let's take the 64 gb model for $899 as an example. Let's say you have a huge workload and are writing at the max of 35MB/sec. At 100,000 writes, 64GB gives you 6.4e15 bytes that can be written before the disk wears out. At 3.5e7 bytes per second, that comes to 1.83e8 seconds. There are 3.16e7 seconds in a year.
That means that at THE MAX write rate and only 100,000 write cycles (not 10 billion), the drive should last at least 5.8 years. Unless you are simply writing to a logging database, you won't be using anywhere near the max write speed and the drive should last decades.
If you have a power failure during a write to an SSD, you are very dependent on the FTL (Flash Translation Layer) between the FS and the device: if it does its job properly it can recover from this, detecting blocks that are invalid because they were partially written. If not, the whole device can be unrecoverable... This is one reason why using an SSD in a laptop (i.e. with battery) or a server with UPS is a good idea.
Having looked at the very long lifetimes of most flash devices (see http://www.storagesearch.com/ssdmyths-endurance.html) I would only use ext2 instead of ext3 if performance was critical and I had good backups on another system. The main issue with ext3 is likely to be performance.