В това продължение на моята поредица за „настройване на производителност на коляното“ бих искал да обсъдя твърдите дискове (SSD) и някои от проблемите, които виждам при използването им в среда на SQL Server. За задълбочено описание на SSD дисковете вижте тази статия в Уикипедия.
Какво правят SSD дисковете за производителност на SQL сървър?
SSD дисковете нямат движещи се части, така че когато се случи четене или запис, почти няма I/O латентност. Латентността при въртящо се устройство идва от две неща:
- Преместване на главата на диска в дясната пътека на повърхността на диска (известно като време за търсене)
- Изчаква се дискът да се завърти до правилната точка на пистата (известна като ротационна латентност)
Това означава, че SSD дисковете осигуряват голям тласък на производителността, когато има входно/изходно затруднение.
Толкова е просто.
Има малко усложнение, което си струва да се спомене, но извън обхвата на тази статия, за да се задълбочим:производителността на SSD може да започне да се влошава, когато устройството стане наистина пълно (разследвано и обяснено подробно в тази статия от AnandTech). Възможно е също така да е необходима известна системна памет за драйвера на SSD, за да помогне за изравняването на износването (удължаване на живота на NAND клетките в SSD) и това ще варира в зависимост от доставчика. Стига с това – обратно към нещата за SQL Server.
Избягвайте лоши интернет съвети
Има два много лоши съвета, които виждам в интернет относно SQL Server и SSD.
Първият е относно това какво да поставите на SSD, където съветът е винаги да поставяте tempdb и вашите регистрационни файлове за транзакции на SSD. На пръв поглед това звучи като добър съвет, тъй като регистрационните файлове на транзакциите и tempdb обикновено са тесни места в системата.
Но какво ще стане, ако не са?
Вашето работно натоварване може да бъде предимно за четене, в който случай регистрационният файл на транзакциите вероятно няма да бъде пречка за работното натоварване и така поставянето му на SSD може да е загуба на скъп SSD.
Вашият tempdb може да не се използва много според натовареността ви, така че поставянето му на SSD може да е загуба на скъп SSD.
Когато обмисляте коя част от средата на SQL Server да преместите на SSD, искате да проучите къде са тесните места за вход/изход. Това може да се направи много лесно с помощта на кода, който публикувах миналата седмица, който използва sys.dm_io_virtual_file_stats DMV, за да предостави моментна снимка на I/O латентностите за всички файлове във всички бази данни на потребителския модел. За да разберете числата си за закъснения и да ги сравните с добри/лоши стойности, прочетете тази дълга публикация, която направих специално за tempdb и закъсненията в регистрационния файл на транзакции.
И тогава, дори и да имате големи латентности, не се колебайте и не мислете, че единственото решение е да преместите лошо работещите файлове на SSD:
- За закъснения за четене на файлове с данни, проучете защо има толкова много четения. Покривам това тук.
- За латентностите при запис на регистрационни файлове помислете за всички начини за настройка на производителността на регистрационния файл и това, което се записва. Разкривам това тук, тук и тук.
Най-лошият възможен случай е, когато ви дадат куп SSD дискове, следвайте съветите в Интернет, за да преместите tempdb и вашите регистрационни файлове към тях, и тогава няма увеличение на производителността на работното натоварване. Това няма да насърчи ръководството ви да ви предостави по-скъпи SSD.
Вторият лош съвет е относно фрагментирането на индекса, където съветът е, че тъй като SSD дисковете са толкова бързи, не е нужно да се притеснявате за фрагментацията на индекса, когато използвате SSD.
Какви глупости!
Има три начина да опровергая този лош съвет:
- SSD дисковете по никакъв начин не спират причината за фрагментирането на индекса:страницата се разделя от страници, нуждаещи се от свободно пространство за произволно вмъкване или увеличаване на размера на ред. Разделянето на страница генерира същото количество регистрационен файл на транзакциите, използване на ресурси и потенциално изчакване на нишки, независимо къде се съхраняват данните/регистрационните файлове.
- Фрагментацията на индекса включва наличието на много страници с данни/индекс с ниска плътност на страниците (т.е. много празно свободно пространство). Наистина ли искате вашите скъпи SSD дискове да съхраняват много празно пространство? SSD дисковете изобщо не помагат тук.
- Моят колега Джонатан Кехайяс направи задълбочено проучване, използвайки разширени събития, на I/O модели около фрагментацията на индекса специално, за да се справи с този лош съвет и установи, че все още има спад в производителността от фрагментиране на индекса при използване на SSD. Можете да прочетете дългата му публикация тук.
Единственото нещо, което SSD дисковете правят около фрагментирането на индекса, е да карат четенията да стават по-бързо, така че има по-малко намаление на производителността при сканиране на диапазон на индекси, когато съществува фрагментация на индекс, но точка 3 по-горе показва, че все още има наказание.
SSD дисковете не променят начина, по който се справяте и/или предотвратяват фрагментирането на индекса във вашата среда на SQL Server.
Уверете се, че сте защитили данните си
Един от основните грехове, които виждам, че хората извършват наоколо с помощта на SSD, е използването само на един от тях. Само с едно устройство, какво ниво на RAID използвате? нула. RAID-0 изобщо не осигурява излишък.
Ако ще използвате SSD, тогава трябва да използвате поне два, в RAID-1 (огледална) конфигурация. Няма смисъл да увеличавате производителността, ако жертвате наличността на системата като компромис.
Едно натискане, което понякога използвам поне два SSD диска, е, че SSD картата предоставя два диска на Windows и така със сигурност създаването на огледален обем на Windows върху двете устройства е същото като RAID-1 в два физически отделни SSD?
Не, не е. Все още е един физически SSD, без излишък. Виждали ли сте някога половината от SSD карта да се повреди? Не, аз също. Направете го правилно и използвайте два от тях и получете реална излишък на данните си.
Другото отблъскване, което получавам, е, че те са SSD дискове, а не въртящи се устройства, така че няма да се провалят. Това е грешно. SSD дисковете могат и се провалят точно като въртящите се устройства. Аз лично видях два SSD диска от корпоративен клас се провалят по време на тестване в нашата лабораторна среда. Според тази статия в StorageReview.com, SSD дисковете за потребителски клас имат MTBF от 2 милиона часа срещу 1,5 милиона часа за въртящи се устройства от потребителски клас и бих очаквал подобни резултати за устройства от корпоративен клас, но SSD дисковете се провалят.
Резюме
Не попадайте в капана на мисълта, че каквото и да поставите на SSD диска, означава, че ще получите тласък на производителността – трябва да избирате внимателно. И не вярвайте на глупостите за игнорирането на фрагментацията на индекса при използване на SSD.
SSD дисковете са много полезен начин за повишаване на производителността, но за тяхната цена, вие искате да сте сигурни, че увеличавате максимално възвръщаемостта на инвестицията на вашата компания, като ги използвате правилно и само когато е подходящо.
В следващата статия от поредицата ще обсъдя друга често срещана причина за настройка на производителността на коляното. Дотогава, щастливо отстраняване на неизправности!
