SSD v serverech - MySQL

V dnešní době již není nasazení SSD do produkčních serverů považováno za nějaký extrém. Pokud se člověk z principu nebojí nových technologií, v řadě případů může jít o velký posun k lepšímu ve výkonu celého serveru a následně systému, na něm provozovanému.

Pozitiva a přínos

1. znatelný nárůst IOPS, obrovská výhoda pro databáze, které se nevejdou do RAM resp. innodb buffer pool nepojme všechna hot data, konec dob kdy se při 200tps už systém začíná potit, s SSD jsou hranice tps v řádech tisíců, 5000 a více
2. seek time řádově 10x až 100x rychlejší
3. velká výhoda SSD je v random zápisu (a mysql server zapisuje opravdu hodně, a to jak random = updaty tabulek, tak i sekvenčně = binlogy, innodb transakční logy, doubblewrite...)
4. rychlejší sekvenční načítání dat do RAM při startu serveru, platí za předpokladu, že SSD disk má rychlejší čtení než SAS disky v raidu, tedy obecně všechny SSD se čtením 200MB/s ++
5. velmi malá spotřeba el. enegie SSD disku, příkon bývá něco kolem 4-5W (týká se pouze SATA, PCIE karty požírají více jak 20W, tedy dost nad hranici SAS 15K disků...) 
6. SSD bývají cenově velmi výhodné oproti  RAID polím, spolehlivý SSD je levnější v poměru cena/výkon než enterprise disk 15K (cheetah, savvio...). V praxi  je téměř vždy nutné použít kombinaci SAS (s kvalitním řadičem) + SSD, takže úsporu za RAID řadič nemůžeme uvažovat

Negativa

1. obrovský problém je RAID řadič, starší značkové servery mají takové řadiče, které SSD nepodporují oficiálně vůbec, neoficiálně možná ano ale SSD bude značně degradované ve svém výkonu, silně je doporučeno mít FBWC
2. nový RAID řadič může být celkem drahý cca 10 000 CZK
3. klasické SATA SSD běží rychleji bez RAIDu než s ním
4. kapacita je v řádech 100G, 400G kvalitní SSD už je celkem drahá záležitost
5. problém může být nepřítomnost kondenzátoru (má ho například Intel 320) kvůli výpadku napájení, pokud je však server postaven za UPC, neměl by to být problém, tedy pokud nevypadne napájení celého bloku serverovny, což se nám už také stalo...
6. pokud disk nemá kondenzátor, hrozí při zapnuté write cache, že pří výpadku el. se nezapíší data z cache do permanentní paměti, tedy dojde ke ztrátě dat
7. s vypnutou write cache jsou SSD značně pomalé
8. pokud disk nemá kondenzátor, lze to ještě řešit přes raid řadič s FBWC (Flash based write cache), ale pro MySQL bych v každém případě doporučil SSD s kondenzátorem (Intel SSD 320, Intel SSD DC S3700, většina PCIE SSD karet...)
9. levnější SSD není vhodné pro dlouhodobé sekvenční zápisy kvůli omezení počtu přepisu, u řady Intel S3700 podle parametrů, již tohle nehrozí, u Intel 200G S3700 byste museli denně zapsat 2T dat, což je 83GB/hod, jde to, ale je to dost extrém. Nicméně na sekvenční logy bych stále použil SAS/SATA, SSD je pro ně škoda.

Řešení v praxi, instalace SSD do MySQL serveru

1. v DB serveru nám teď běží Intel SSD 910 400G
2. ale aktuálně vůbec bych se nebál použít 2x  Intel SSD DC S3700 - 200GB v raid 0, za poloviční cenu
3. disk naformátován na ext4
4. mount parition options: noatime, nobarrier, 
5. ioscheduler: deadline
6. použit Percona server 5.5.x, hlavně kvůli optimalizačním direktivám, které standardní Mysql nemá

config my.cnf, uvádím pouze speciální optimalizace pro SSD

[mysqld]

• datadir = /path/at-ssd-disk #SSD
• innodb_data_home_dir = /path/at-ssd-disk #SSD
• innodb_doublewrite_file  = /path/to/file/at-sas-disk  #SAS
• tmpdir  = /path/at-ssd-disk #SSD
• log-bin = /path/at-sas-disk #SAS
• innodb_io_capacity  = 20000
• innodb_flush_method       = O_DIRECT
• innodb_write_io_threads = 16
• innodb_read_io_threads = 16
• innodb_log_file_size = 4G
• innodb_log_files_in_group = 2
• innodb_file_per_table = 1
• innodb_log_block_size = 4096
• innodb_file_format = Barracuda
• innodb_read_ahead = none
• innodb_adaptive_flushing_method = keep_average
• innodb_flush_neighbor_pages = 0

[mysqld_safe]

• numa_interleave = on
• flush_caches = on