8

My SSD:

I have a Samsung 970 EVO Plus NVMe M.2 1TB (PCIe 3.0) SSD. The SSD has a TBW of 650.

My HDD:

I have a Seagate BarraCuda 1 TB – 3.5 Inch SATA 6 Gb/s 7200 RPM 64 MB Cache (ST1000DM010-2EP102) HDD.

Now, obviously the SSD is way faster than the HDD. But, as we all must know: the SSD has a limited write endurance, but the HDD does not have a limited read/write endurance.

I am using Linux.

My server has a MySQL database which most of the time performs INSERT and UPDATE commands, for example: 2-3 of these commands per minute, depending on the usage of the website. And all the others are SELECT commands, probably: 50 times per minute.

And, I constantly compile, and create programs in the same machine, i.e. ./configure, make, make install, rm -rf /usr/local/installedprogramfolder, and repeat the same many times a day, probably about 500 times a day.

Due to the above, I think compiling and creating programs, removing then repeating the same is not so good for the TBW of the SSD. But, The hard drive is slower than the SSD, resulting in less work done in a day, i.e. lower efficiency.

And the above ^ is where I am unable to decide if I need to use the SSD or the HDD!

Yes, this question might need answers based on opinion, but, still, I have narrowed it as much as possible.

I could go with an Enterprise SSD, but my budget is under Indian Rupees. 20,000 (about 275 USD), and the current SSD would just go to waste unless I assign a specific use to it.

About Backups:

The stuff inside the server is very confidential. Passwords and chat messages in the MySQL database. But, the stuff are encrypted. A remote backup wouldn't be really good for privacy in terms of this I believe; I keep backups in multiple External 3 TB drives.

Other stuff:

Someone suggested me to use RAID, to combine multiple drives.

I will try that trick later, when I buy another HDD. Maybe in a few weeks. Sorry.

Surely, someday, I will have the money to keep buying these SSDs, but not today though.

Btw, now, I have understood that HDDs are also a victim of wear I forgot that HDDs wear down because of the spinning disc inside of it.

Improve this question
4
  • Comments are not for extended discussion; this conversation has been moved to chat. – DavidPostill♦ Jan 22 at 12:23
  • I don't know about Linux, but there is definitely a Windows app from Samsung that shows the drive health and "wear out" level. Try getting that and see what it tells you. – Vilx- Jan 22 at 14:21
  • I too am a developer, and after 3.5 years my work SSD (an older Transcend 230S) is at 97% of full health. So, barely any wear at all. But it does sound like you use your SSD more heavily than me since I work with interpreted languages that don't need compiling. – Vilx- Jan 22 at 14:23
  • "A remote backup wouldn't be really good for privacy in terms of this I believe" If it's encrypted I'm not sure what you're worried about. And having at least one off-site backup means you won't lose anything if you have just one single fire at home... just don't keep your encryption keys in one place!! – Asteroids With Wings Jan 22 at 20:09
20

If you have a system with similar load profile and it already runs for some extended time under near expected load, you can have a estimate how much writes and reads it is doing, using iostat -th (from the package sysstat):

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           4,8%    0,0%    1,7%    0,5%    0,0%   93,1%

      tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn Device
    86,51         1,7M       590,7k       2,9T    1014,8G sda
     3,47        29,5k       734,9k      50,6G       1,2T sdb

and compare that with uptime value:

 10:54:04 up 20 days, 20:26,  1 user,  load average: 2,18, 2,13, 1,94

As you can see, sda on this system reads of around 2.9T/20.8days = 140G per day, and writes of around 48G per day. This value must be compared with desired SSD's datasheet value, TBW, to calculate how long it will endure this particular load.

I am sure your your fears are in vain. I found a cheapest SSD in our local store, it has a TBW value of 70 TB. That SSD will be able to endure that load for 1458 days or slightly less than 4 years. Note, my load is from an office hypervisor, there is some accountancy VM, file server; also we run many test labs there and more.

I mean, it's quite hard to wear out a modern SSD, even cheapest one! It'll likely break earlier by different reason other that expected wear out.

Improve this answer
3
  • SQL really may write that often. It must really write data to the non-volatile storage before it replies an application that transaction is successful. So it tries to write data immediately, bypassing or flushing any write caches, creating so called write barriers and so on, to be sure it'll be consistent even after hard power fail. Think it doesn't have any write cache, or that write cache only lasts for single transaction only. Sometimes you even want to redesign an application, disable any autocommit and so on, to optimise writes. – Nikita Kipriyanov Jan 21 at 16:41
  • 2
    Well, this is Windows rather than Linux but I have recently put about 10TB of writes onto the work laptop's SSD in maybe 2-3 months... How? To little RAM and paging for what I am doing at present... - Also consider that small writes on multi layer NAND may be less efficient than on single lawyer NAND. But in the grand scheme I concur, there is no need to worry (though some monitoring every now and then is a good idea.) – DetlevCM Jan 21 at 20:16
  • 2
    Monitoring of your storage is always a good idea. No matter what. – Nikita Kipriyanov Jan 22 at 7:46
10

Buy yourself lots of RAM, create a ramdisk (/etc/fstab), and do all compiling, linking, etc there, i.e. in memory.

This is my setup and I am saving gigabytes of the SSD wearing everyday. Another benefit: all file related operations are lightning fast!

Improve this answer
9
  • 3
    Yep. I'd also suggest moving mysql temp files to the ramdisk as that's where a lot of writes happen stackoverflow.com/questions/11990887/… – Papa Jan 22 at 0:24
  • Shouldn’t there also be an option to increase your file system’s write cache and write-back time to avoid writing the database to disk all the time? – Michael Jan 22 at 10:06
  • (or use existing RAM if you already had a lot). In case anyone is wondering, this isn't too good to be true. It's not a joke. Using a "RAM Drive"/"ramdisk"/"Memory Filesystem" can work very well precisely as described by this answer. – TOOGAM Jan 22 at 11:14
  • 7
    @Michael You DON'T want to delay writing to disk on a database. Transactions must be committed to disk as son as possible or you risk database corruption and/or data inconsistency if something weird happens to the database (like OS crash or sudden power-cut). See also the comment by Nikita Kipriyanov on one of the other answers. – Tonny Jan 22 at 12:27
  • 1
    @Michael but data must be on persistent storage before the DB manager signals a complete transaction to the client. Everything that isn't committed hasn't really happened and doesn't hurt when lost due to a crash - what is committed must be restorable even after a crash. – piet.t Jan 22 at 13:02
9

Nikita is right. The SSD's will last long enough to out weigh their wear rating. SQL, being such an important structure component, affects so many other systems. I would always suggest getting the fastest response and read/write performance from SQL as you can. That is important above all else, except having a proper backup strategy completely implemented.

If you are worried about the endurance aspect of an SSD, but not sure you would be happy with the performance of an HDD, then I would suggest you look into the datacenter realm of SSD's. Yes, they are more expensive, but when you are working with critical data, do you really want to run it on a "should be good enough" hardware strategy?

There are a multitude of option available to you, and some at not too crazy of a price. Intel datacenter SSD's are one I would suggest you look into for this. Is it needed? Nope. if you are writing that much on a daily basis, I would absolutely look at a more purpose built component.

I wish you luck!

Improve this answer
0
6

as we all must know: the SSD has a limited write endurance, but the HDD does not have a limited read/write endurance.

This is wrong. Hard drives do not have unlimited endurance. They have moving parts which are subject to material fatigue and can fail spontaneously. Anyone who ever had a hard drive with important data fail on them without warning learned that the hard way. Hard drives in datacenters are usually run as redundant RAID arrays so that when one hard drive fails it can be replaced without having to restore from backups. Replacing failed hard drives is a routine maintenance task.

The reason why this myth keeps propagating is because when the SSD technology was new, it was also hyped because lack of moving parts suggested longer lifetime. This was false, so people had to be taught about NAND read/write limits. Unfortunately this education overshot its goal and suggested to people that the new techonlogy was even less reliable than the existing one, which was and is not necessarily true.

Whether SSDs or HDDs have better long-term reliability is a lengthy debate which depends more on the manufacturer, usage patterns and operating environment than on what basic storage technology is used. But this article from 2016 came to the conclusion:

calculating the limit until data becomes compromised at 300TB, an SSD like the Samsung 840 Series is theoretically reliable up to 21.4 years. Compare that to the fact that an HD drive is 50% likely to fail after 6 years.

But that was in their test setup with the drives they tested. Others might come to completely different results.

The difference between SSDs and HDDs which actually matters is mostly that SSDs are faster but more expensive per GB of storage.

A common pattern is to not choose one or the other but actually use both. An SSD for programs and other data where fast access matters and a HDD for bulk storage of large data.

Improve this answer
0