Часть 9. Что такое IOPS и стоит ли SSD на ставить на SATA2
У носителей информации есть еще один важный параметр — IOPS.
Это аббревиатура от английского input/output operations per second — количество операций ввода-вывода в секунду.
Как и многие другие — это скорее теоретический параметр, но, тем не менее, он позволяет продемонстрировать преимущества твердотельных накопителей перед жесткими дисками в плане производительности.
От чего зависит IOPS
Как понятно из названия параметра, чем больше будет его значение, тем выше производительность у тестируемого устройства.
В первую очередь величина IOPS зависит от конструкции устройства.
Жесткие диски — это электромеханические устройства и при считывании данных, расположенных в случайных блоках, IOPS будет в первую очередь зависеть от скорости работы механической части, то есть от времени, которое потребуется на позиционирование головки в нужном месте пластины.
Скорость доступа к данным в SSD зависит только от микроконтроллера, то есть от электронного устройства.
Насколько производительность SSD выше
Условно оценить разницу в производительности жестких дисков и твердотельных накопителей, можно из таблицы, которую можно найти в Википедии.
Да, это тесты в неких идеальных условиях и данные в Википедии уже несколько устарели. Но тем не менее, они показывают, что производительность SSD в разы выше, нежели жестких дисков. И если цифровые значения могут сейчас несколько отличаться, то разница в порядках сохранилась.
И именно количество возможных операций в секунду в конечном итоге преобразуется в более понятные нам мегабайты в секунду (МБ/c).
Утилита CrystalDiskMark
В прошлой заметке речь шла о максимальной скорости передачи данных, которую может обеспечить как сам носитель информации, так и интерфейс, через который он подключен к компьютеру.
Часто для тестирования носителей информации используют утилиту CrystalDiskMark. Именно ее скриншоты выкладывают пользователи после покупки и тестов жестких дисков или SSD.
И что же нам должны сказать цифры с этого скриншота?
Нужно понимать, что утилита — эта лишь инструмент. Параметры тестов задает пользователь и о них довольно подробно написано как в справочной системе, так и на множестве тематических сайтов. По этой причине не буду углубляться в детали, а лишь в двух словах поясню результаты.
Фактически о производительности носителей информации делается заключение по скорости последовательных и случайных операций записи/чтения.
На скриншоте мы видим две колонки с результатами — в первой выведены значения тестов на чтение, во второй на запись.
Всего выводятся результаты четырех тестов.
Первый тест — последовательное чтение (запись) данных блоками по 1 МБ в один поток с очередью в 32. Очередь — это количество отложенных операций ввода-вывода. Все эти цифры отражены в названии теста.
Здесь мы видим самые высокие цифры на скриншоте и они отвечают максимальным скоростям чтения и записи, которые заявляет производитель и которые, как правило, можно найти в описании устройства на сайте интернет-магазина.
Эти цифры могут отличаться у разных пользователей, тестирующих одно и то же устройство на своих компьютерах. Дело в том, что результаты тестов зависят от очень многих параметров, начиная от начальных условий самого теста и заканчивая настройками операционной системы, в которой происходит тестирование.
Однако это далеко не самые важные цифры.
На практике подобная скорость будет лишь в ряде определенных ситуаций, например, при копировании или переносе больших файлов из папки в папку или при создании архивов.
Тем не менее подавляющее большинство файловых операций на диске имеют совсем не последовательный, а скорее случайный характер. И именно его мы и можем оценить по четвертому тесту, который демонстрирует скорость передачи данных блоками по 4КБ в один поток и длиной очереди в 1. На практике это как раз и есть те самые обычные файловые операции, которые выполняются на диске операционной системой или запущенными программами.
Четвертый — это, пожалуй, самый важный для нас тест, а вот второй и третий тесты мало информативны для рядового пользователя и на них внимание можно не обращать.
Подведу краткий итог.
Итак, при оценке скорости копирования больших файлов показательным будет первый тест.
Для оценки производительности носителя информации в рядовых задачах будет актуален четвертый тест.
Оцениваем разницу в производительности
Ну а теперь, основываясь на скриншотах пользователей, можно оценить разницу в производительности разных типов носителей.
Подчеркну еще раз, что результаты тестов зависят от значительного количества сопутствующих факторов, однако общую тенденцию можно определить из некоторой выборки значений.
Очевидно, что производительность SSD в рядовых файловых операциях в разы выше, нежели жестких дисков.
Но следует учитывать, что большинство таких тестов проводились при оптимальном подключении, то есть SSD был подключен через интерфейс SATA 3.
Возникает закономерный вопрос, а имеет ли смысл подключать SSD к SATA 2?
Очевидно, что максимальная скорость при последовательных операциях чтения/записи будет ограничена возможностью SATA 2. Напомню, это приблизительно 300 Мбайт/c.
Однако значительно большее значение IOPS сократит задержки в файловых операциях в несколько раз, и, как видно из тестов, скорость случайных операций значительно ниже пропускной способности SATA 2.
Но и тут не все так однозначно.
Как показывают тесты, при подключении к SATA 2 падает и это значение…
Тем не менее, оно все равно значительно выше, нежели у жестких дисков. Поэтому, с моей точки зрения, установка SSD на SATA 2 все равно оправдана — мы получаем возможный максимум при последовательных операциях и в пять-десять раз ускоряем рядовые файловые операции.
Итак, с производительностью определились, осталось разобраться с долговечностью.
«20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
Поводом написать эту статью стал весьма достойный обзор Как мы тестировали VMware vSAN. компании КРОК. Обзор-то достойный, но в нем есть фраза, с которой я борюсь уже больше десятка лет. Админы СХД, виртуализаторы и интеграторы раз за разом повторяют: «Задержки в 5 мс — это отличный показатель». Даже цифра в 5 мс десять лет не меняется. Я это слышал вживую от весьма уважаемых админов уже не меньше десятка раз. От менее уважаемых — десятки, а уж сколько раз читал в интернете… Нет, нет, нет. Для OLTP нагрузок 5 мс, особенно так, как их обычно измеряют — это epic fail. Мне приходилось объяснять причины этого уже много раз, на этот раз я решил собрать свои мысли в переиспользуемую форму.
Сразу оговорюсь, что в упомянутой выше статье этих ошибок нет, скорее фраза сработала как триггер.
Типичное начало
Всё что описано в данной статье, верно для распространенных СУБД, используемых для типичной бизнесовой OLTP. Больше всего у меня опыт с MS SQL Server, но, как минимум, для PostgeSQL, Oracle и Sybase многие моменты и выводы также останутся верны.
На этом уровне уже сервер не стоит под столом директора, диски уже не внутри сервера, а в СХД, разработчики знают про индексы, а администраторы уже умеют PowerShell, и менеджеры ИТ начинают говорить умные слова типа SLA и RPO/RTO. Вот на этом уровне возникает интересная ситуация:
Кстати, всё вышесказанное не только про «свои» сервера, но и про облачные сервисы и виртуализацию. Там есть кучка своей специфики, но типичная клиническая картина примерно та же: в меру оптимизированная БД, неглупые сотрудники разработки и сопровождения, по процессору и памяти резерв есть, «выхлоп» от дальнейших вложений почти равен нулю.
Так вот. Эта вся песня про «5 мс» чушь и ерунда. Если вы сами такое говорите — читайте эту статью. А если вам такое говорят — готовьте аргументы. Раньше, когда я слышал эти слова, я злился, но я уже не злюсь. У меня, как у того горшка с петуньей из «Автостопом по галактике» только одна мысль: «Ну вот опять. «.
Кто виноват?
Почему БД такая медленная? Ну казалось бы, типичный сервер с 20-64 ядрами на частоте 2-3 ГГц способен выполнить 50-150 миллиардов простых операций, а максимальные (синтетические) тесты баз данных показывают на подобных машинах всего лишь 10000-50000 транзакций в секунду. Эй! Это ж от миллиона до десятка возможных миллионов операций на транзакцию. Это не просто много, это очуметь как много.
Такого оверхеда стоят ACID-требования к транзакциям.
К слову, буква-в-букву эти требования не выполняются почти нигде и никогда, а в распределённых системах просто никогда (CAP-теорема мешает). Для нашей ситуации скорее всего дороже других стоит требование «D», это требование обеспечивается ключевым механизмом всех распространенных OLTP СУБД: WAL, write-ahead log (PostgeSQL), он же журнал транзакций (SQL Server), он же REDO log (Oracle). Вот он — камень на шее производительности, и он же фундамент Durability транзакций.
Что такое WAL
Давайте ненадолго забудем про современные SSD, про крутые СХД. Пусть у нас есть сервер, в нем один или несколько дисков.
Любая транзакция, даже вставка одной записи, как минимум потенциально, а на самом деле почти всегда и реально — неатомарное действие. Нам почти всегда нужно изменить не только ту страницу, где лежит запись, но и страницы индексов, возможно, служебные страницы. При этом в одной транзакции одна и та же страница может поменяться много раз. Плюс у нас параллельно могут выполняться другие транзакции. Более того — соседние во времени транзакции постоянно «теребят» одни и те же страницы. Если мы будем дожидаться записи каждой страницы на диск перед продолжением действий, а именно это по сути требуется в Durability, то нам придётся записывать во много раз больше и ждать обязательного окончания каждой записи на энергонезависимый носитель. Никаких кешей, никакой перестановки операций в очереди, а иначе не будет целостности! Более того, нам как-то надо отмечать какие данные уже по фиксированным транзакциям, а какие — ещё нет (и какие были данные раньше). Для понимания — типичный одиночный жёсткий диск (HDD) в таком режиме даст 50-100 IOPS и это константа уже 20 лет. На одну даже маленькую транзакцию потребуется 5-10 операций записи. Ах, да, чтобы знать, что записывать — надо прочитать. Даже очень-очень высоконагруженные на запись OLTP системы читают в раза 3 больше чем пишут. Таким образом наша транзакция стоит 20-40 IO, а значит 0,2-0,8 секунд на диск.
2 транзакции в секунду. Маловато? Давайте попробуем раскидать по дискам? Ой, а нам надо всё равно дожидаться пока предыдущий запишется и параллельность в итоге отсутствует. Как быть? А давайте заведем файл-журнал в который будем последовательно записывать все операции записи в БД и отметки транзакций! Плюсы:
Такой журнал и называется write-ahead log/transaction log/REDO log.
Ура! Супер! Было 2 транзакции в секунду, стало 300 — улучшили в 150 раз. А какой ценой? Как выясняется, цена значительна:
Это объяснение очень упрощенное, «на пальцах». Для нашей темы этого хватит. WAL — ключевой, фундаментальный механизм обеспечения транзакционности, он обязательно write-through, доступ однопоточный только на последовательную запись, с точки зрения хранилища глубина очереди 1.
Тему write-ahead logging в БД должен хотя бы в минимальном объёме знать каждый, кто так или иначе администрирует СУБД, или инфраструктуру СУБД, или разрабатывает базы данных.
WAL и СХД
Производители СХД «с рождения» сталкиваются с СУБД. Именно для баз данных бизнес покупает эти безумно дорогие комплексы: от street price хранилищ Dell-EMC, HP, Hitachi, NetApp при верстке бюджета глаза наполняются слезами у большинства топ-менеджеров, если они, конечно, не получат процент от этой цены. Но тут есть инженерно-маркетинговый конфликт. Я его поясню на примере Dell-EMC, но только потому что помню, где у них документация.
А маркетологам надо продавать. Гиперконвергентность! Виртуализация! Гибкость развертывания! Дедупликация! Простота настройки! Много-много IOPS! Красивые презентации, уверенный голос, строгие костюмы. Ну а как иначе продать решение с 6-7-значным ценником в долларах? За этим как-то забывается, что от СХД можно добиться либо latency, либо throughput, но не обоих сразу, что какая-нибудь лицензия на балансировщик нагрузки стоит как еще одна полка, что если интенсивная запись будет длиться больше часа, то оперативной памяти контроллеров не хватит и производительность просядет до «как будто кеша нет», что обучение сотрудников заказчика стоит еще 100000 рублей за первый курс, ну и подобные уловки…
То ли наслушавшись-начитавшись маркетологов, то ли от лени, то ли ещё из-за каких-то тараканов, но почему-то часто админы СХД делают примерно так. Берем большую полку, всю её объединяем в что-то плоское, нарезаем на thin provisioned LUNs и раздаём по LUN на сервер. Или по два, потому что «системный раздел хорошо дедуплицируется». А когда, я вижу, что с дисковой подсистемой со стороны SQL ад-ад-ад, то начинается та самая песня, что «5 мс отличный показатель», что «100000 IOPS», «Ваша нагрузка на СХД менее 5%»
Когда какая-нибудь загрузка данных на ноутбуке разработчика выполняется 5 минут, а на 40 ядерном сервере с 1 ТиБ RAM и СХД за полмиллиона долларов та же самая задача выполняется час, то даже у самых терпеливых заказчиков появятся вопросы обоснованности затрат.
| Средняя задержка на разделе с WAL | никогда не будет в секунду больше транзакций, чем: |
|---|---|
| 5 мс | 200 |
| 1 мс | 1000 |
| 0,5 мс | 2000 |
| 0,1 мс | 10000 |
| 0,05 мс | 20000 |
Что делать
Советы администраторам и DBA
Для OLTP перестаньте считать «утилизацию» и IOPS. Отдельно замечу — совсем не смотрите на IOPS с большой глубиной очереди: даже на разделах с данными большие очереди обычно короткий всплеск или что-то, что не влияет на реальную производительность OLTP.
Делить дисковое пространство на LUN — это не прихоть DBA. У базы данных есть несколько разных профилей нагрузки дисковой подсистемы. Как минимум можно выделить следующее:
Есть и другие виды нагрузки, но они слегка экзотичны (например, может быть хранилище файлов, хранящихся в БД в виде каталога FileStream). У всех этих видов нагрузки разные, зачастую противоречащие требования к дискам. Если они все свалены на один раздел, то вы не только ухудшаете производительность, но очень важно, что лишаетесь возможности понять из-за чего система тормозит, а также лишаетесь возможности улучшить только ту часть которая требует улучшения без глобальных улучшений/апгрейдов СХД. Поэтому главная рекомендация:
Ознакомьтесь с рекомендациями производителя СХД и СУБД, постарайтесь разобраться «почему они так советуют» и спроектируйте систему с учетом разных видов нагрузки. Разнесите принципиально разные виды нагрузки на разные разделы.
MS SQL Server
Если говорить про MS SQL, то на самом деле есть некоторое количество способов снизить нагрузку на bottleneck журнала транзакций, может кому-то поможет:
Вот и всё. Нет никой магии. 20000 IOPS с 5 мс latency и с очередью 4-16 ничего не говорит о производительности СХД для задач OLTP. Для OLTP надо правильно размечать СХД, правильно выбирать метрику производительности и уметь измерять её.
На горизонте есть очень интересный новый участник борьбы за производительность систем хранения для БД. Это Intel Optane. У нынешних SSD «красивые» цифры производительности начинаются от глубины очереди 4, что на самом деле не очень жизненно. Плюс эта производительность на запись обеспечивается некоторым объёмом оперативной памяти внутри SSD, и, если запись идёт достаточно интенсивно, то потом наступает существенная деградация производительности. А еще у SSD ограничен ресурс. Да, у современных серверных и топовых «гражданских» он достаточно большой, но совсем не бесконечный. И тут на сцене появляется Intel Optane: судя по тестам несерверных моделей (раз, два ) задержки на случайных операциях на очереди глубины 1 выходят на уровень около 20 микросекунд. Это по сути без кеширования, без деградации. SSD при таком же профиле начинают тупить до 100-300 мкс. Ресурс уже сейчас выходит за типичный ресурс SSD.
Ну цена, да. Но потенциально эта железка открывает новые горизонты производительности OLTP «традиционной», не in-memory архитектуры без отказа от ACID. А с другой стороны latency 20 мкс заставляет задуматься о судьбе «обычных» СХД. На low-latency требованиях им будет очень тяжело конкурировать с Optane (снова привет встроенным системам хранения?).
Это всё очень круто и я надеюсь на успех (и подешевление) Optane.
eugeneb0 и apatyukov за добрые советы и вычитку.
Iops дисков что это
Калькулятор IOPS позволяет оценить производительность дисковой подсистемы сервера.
В зависимости от типа контроллера и накопителей, режима кэш, числа накопителей, глубины очереди и характера нагрузки вычисляются производительность, задержка и емкость для массивов RAID 0/10/5/6.
Операция ввода/вывода – операция чтения или записи, выполняемая дисковой подсистемой. Различают операции последовательного и случайного доступа.
Запрос – задание дисковой подсистеме на выполнение операции чтения или записи.
Глубина очереди – количество одновременных запросов на чтение или запись.
Задержка – среднее время выполнения запроса.
Strip – блок данных, который записывается на один диск RAID-массива. Размер этого блока задается при создании RAID-массива.
Stripe – суммарный размер одной записи на всех дисках RAID-массива без учета данных четности.
Калькулятор IOPS поддерживает все типы RAID-контроллеров, которые используются в серверных системах нашей сборки:
Для контроллеров с кэш-памятью возможен выбор режимов Write Through и Write Back.
Выбор контроллера накладывает ограничения на максимальное количество дисков, а также их интерфейс.
Например, для встроенных контроллеров количество дисков ограничено числом портов – 4, 6 или 8. Хотя эти контроллеры могут работать с расширителями портов, на практике это применяется редко.
Для SATA-контроллеров нельзя выбрать диски с интерфейсом SAS. Кроме того, не все контроллеры поддерживают все типы RAID-массивов.
Калькулятор IOPS поддерживает все типы используемых нами в производстве серверов Team современных серверных жестких дисков: 2.5″ и 3.5″ с интерфейсами SAS и SATA и скоростью вращения 7200, 10000 и 15000 оборотов в минуту.
Калькулятор также поддерживает современные твердотельные накопители (SSD) с интерфейсами SATA3 (6Gb/s), SAS3 (12Gb/s), NVMe (4GB/s).
Жесткие диски одного класса, но разных производителей (например, диски SAS 2.5″ со скоростью вращения 7200 оборотов в минуту), могут заметно различаться по производительности. Наличие промежуточной неотключаемой энергонезависимой кэш-памяти в некоторых моделях накопителей позволяет в разы увеличить скорость на операциях случайной записи.
В подавляющем большинстве приложений дисковая подсистема сервера работает в режиме случайного доступа, осуществляя чтение и запись данных, расположенных в массиве произвольным образом.
Когда необходимо оценить производительность последовательного чтения или записи, можно считать, что скорость массива будет кратна количеству дисков в массиве (при условии, что размер блока данных больше размера Stripe). Это справедливо даже для массивов с вычислением четности, поскольку в этом случае выполняется запись целого страйпа и блока четности без предварительного чтения «старых» данных.
Глубина очереди – это количество одновременных запросов на чтение или запись, которые сервер посылает дисковой подсистеме. Если глубина очереди равна единице, то следующий запрос посылается только после получения подтверждения о выполнении предыдущего запроса. Если глубина очереди больше единицы, сервер сразу посылает несколько запросов и в дальнейшем поддерживает заданную глубину очереди по мере их выполнения.
Для начала рассмотрим понятие глубины очереди применительно к одиночному диску.
Чем больше глубина очереди, тем больше запросов жесткий диск может обработать за единицу времени. Это объясняется тем, что диск выстраивает последовательность обработки запросов таким образом, чтобы маршрут движения головок был оптимальным с точки зрения минимизации времени операций. Чем больше глубина очереди, тем больше у диска выбор и тем эффективнее оптимизация.
Диски SATA могут обрабатывать до 32 одновременных запросов, диски SAS – до 64. При максимальной глубине очереди производительность диска увеличивается примерно в три раза по сравнению с одиночными запросами.
Когда мы говорим о глубине очереди применительно к RAID-массиву, картина меняется. При глубине очереди 1 мы не получим выигрыша в производительности по сравнению с одиночным диском, поскольку в массиве будет работать всегда только один диск. А вот если массив получит сразу столько запросов, сколько он имеет дисков в своем составе, мы получим рост производительности, пропорциональный числу дисков.
Правда, следует заметить, что запросы совсем необязательно распределятся равномерно между всеми дисками массива, поэтому реальный рост производительности будет меньше. Например, для массива из двух дисков только в половине возможных случаев запросы будут приходиться на разные диски, поэтому производительность вырастет всего в полтора раза (на самом деле немного больше, поскольку в другой половине случаев на каждый диска придет по два запроса и производительность дисков вырастет за счет оптимизации). Наш Калькулятор IOPS точно учитывает эти моменты для любого количества дисков и любой глубины очереди.
Оптимальным является вариант, когда на каждый диск массива приходится один запрос. При дальнейшем увеличении глубины очереди производительность массива растет гораздо медленнее задержки, которая прямо пропорциональна глубине очереди. Именно поэтому при расчете производительности массива глубина очереди по умолчанию принимается равной количеству дисков. Однако ее можно поменять, чтобы увидеть, как при этом будут меняться производительность и величина задержки.
В массиве RAID 0 чтение будет выполняться параллельно с каждого диска массива, поэтому производительность массива будет равна произведению производительности одного диска на число дисков в массиве.
Для RAID 5 и RAID 6 картина точно такая же. Поскольку данные четности распределены между всеми дисками равномерно, при чтении будут задействованы все диски.
А вот для RAID 10 с аппаратным контроллером производительность будет даже выше, чем у RAID 0, поскольку чтение будет выполняться с того диска зеркальной пары, головки которого ближе к нужному сектору.
Для операций записи ситуация другая, кроме RAID 0. Для RAID 0 производительность по мере увеличения количества дисков в массиве растет так же, как в случае с чтением. RAID 10 медленнее в два раза, поскольку должен записывать одни и те же данные на два диска.
Для массива RAID 5 каждый запрос на запись порождает 4 операции: чтение «старого» блока данных, чтение четности, запись «новых» данных и запись четности. Поэтому теоретически RAID 5 при том же количестве дисков медленнее RAID 0 примерно в 4 раза. Однако на самом деле производительность определяется типом контроллера. Для контроллеров Adaptec реальная производительность неплохо согласуется с теоретической, а вот для контроллеров LSI с увеличением количества дисков производительность не растет, хотя при небольшом количестве дисков они работают быстрее, чем Adaptec. Разница объясняется тем, что LSI максимально оптимизирует свои алгоритмы для работы с массивами с небольшим числом дисков, поскольку не делает контроллеры с количеством портов более 8, в то время как Adaptec ориентируется в том числе и на массивы с большим количеством дисков и предлагает контроллеры и с 16 и с 24 портами.
Все вышесказанное относится и к массивам RAID 6 с той разницей, что для выполнения одного запроса на запись требуется уже шесть операций: три чтения и три записи.
Включение кэша контроллера на запись (режим Write Back) увеличивает производительность массивов любого типа примерно на порядок, поскольку данные записываются сначала в «быструю» память контроллера. Перенос данных из кэша на диски осуществляется в фоновом режиме, при этом контроллер «выжимает» из массива максимально возможную производительность в IOPS за счет оптимизации внутренней очереди запросов, поскольку величина задержки при переносе данных из кэша на диски в этом случае не имеет значения.
В реальных серверных конфигурациях включение режима Write Back рекомендуется только при наличии защиты кэша контроллера от потери питания (батарейной или на базе флэш-модулей). В противном случае велик риск потери большого объема данных.
Все современные жесткие диски имеют некоторый объем «быстрой» кэш-памяти – обычно 64 или 128 MB. Если эта память включена (Disk Cache ON), то данные записываются сначала в эту память и запрос считается выполненным. Затем диск в фоновом режиме переписывает информацию на магнитные пластины. Включение кэш значительно (в разы) увеличивает производительность диска, поскольку диск переписывает содержимое кэш на пластины, оптимизируя процесс перемещения головок.
Поскольку кэш-память дисков обычно энергозависима, потеря питания приведет к потере всех данных в кэш диска, поэтому включать ее рекомендуется только при наличии резервирования по питанию.
Одновременное включение кэш-памяти дисков и контроллера не всегда дает прирост производительности по сравнению с включением только кэша контроллера. В отдельных конфигурациях производительность может несколько снизиться. Причина в том, что фоновые процессы дисков могут тормозить работу алгоритмов контроллеров.
Производители жестких дисков и твердотельных накопителей указывают емкость этих устройств в GB (Гигабайтах) или TB (Терабайтах). При этом под одним гигабайтом понимается величина 10 9 байт, а 1 TB – это 10 12 байт.
Емкость RAID-массива обычно указывается тоже в Гигабайтах или Терабайтах, но при этом 1 GB считается равным 1024 3 байт, а 1 TB – 1024 4 байт.
Большое спасибо за предложение! Такая возможность появится в следующей версии калькулятора.
