https://flashdba.com/category/storage-for-dbas/understanding...
For SOHO yes, where no serious database usage is expected. But server/datacenter SSDs are categorized: read-intensive, write-intensive and mixed-usage.
Not every application will read in a specific size, but 4KiB isn't uncommon.
As an example in this Micron product brief the Latency for the read-intensive vs mixed use product are the same: https://assets.micron.com/adobe/assets/urn:aaid:aem:e71d9e5e...
Of course the footnote says that latency is a median at QD=1 random 4K IO.
From the paper the PM9A3 which is 1 DWPD has better P99.9 write latency under load vs the 7450 Pro (3 DWPD mixed use).
If you can borrow systems, you can do it yourself, too.
Otherwise, there are too many variables to calculate now. In the past it was easier. Now it's much more complicated.
Through metrics I noticed that some SSD in a cluster were much slower than others despite being uniform hardware. After a bit of investigation it was found that the slow devices had been in service longer, and we were mot sending DISCARDs to the SSDs due to a default in dm-crypt: https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discar...
The performance penalty for our drives (Samsung DC drives) was around 50% if TRIM was never run. We now run blkdiscard when provisioning new drives and enable discards on the crypt devices and things seem to be much better now.
Reflecting a bit more, this makes me more bullish on system integrators like Oxide as I have seen so many times software which was misconfigured to not use the full potential of the hardware. There is a size of company between a one person shop and somewhere like facebook/google where they are running their own racks but they don’t have the in house expertise to triage and fix these performance issues. If for example you are getting 50% less performance out of your DB nodes, what is the cost of that inefficiency?
Switched to some Intel 480GB DC drives and performance was in the low milliseconds as I would have thought any drive should be.
Not sure if I was hitting the DRAM limit of the Samsungs or what, spent a bit of time t-shooting but this was a home lab and used Intel DCs were cheap on eBay. Granted, the Samsung EVOs weren't targeted to that type of work.
Another thing you will notice is the 850 EVO is 500GB capacity while the Intel one is 480GB. The difference is capacity is put towards overprovisioning which reduces write amplification. The idea is if you have sufficient free space available, whole NAND blocks will naturally get invalidated before you run out of free blocks.
Consumer drives can definitely have some quirks. The 2TB 960 Pro also just had weird write latency, even under relatively moderate load. Like 2-4ms instead of <1ms. It didn't really get much worse with extra load and concurrency, except that if there's writes enqueued the reads end up waiting behind them for some reason and also seeing the latency penalty.
They can also be weird behind RAID controllers, though I'm not sure if JBOD counts there. For whatever reason, the 860 EVO line wouldn't pass TRIM through the SAS RAID controller, but the 860 PRO would.
jeffbee•5mo ago
djoldman•5mo ago