Как стать автором
Обновить

Как мы разгоняли кластер для нагруженных баз Microsoft SQL и получали заветные 200 000 IOPS

Время на прочтение4 мин
Количество просмотров9.2K
Всего голосов 18: ↑18 и ↓0+18
Комментарии10

Комментарии 10

Для базы данных до 4 ТБ можем гарантировать до 200 000 IOPS с задержками менее 1 мс при 100% чтении блоком 4k.

Поскольку статья называется "Как мы разгоняли кластер для нагруженных баз Microsoft SQL и получали заветные 200 000 IOPS", расскажите, пожалуйста, при каких операциях SQL Server использует чтение блоком 4k?
Да, конечно, для разных операций – разный диапазон чтения/записи, и они динамически меняются. Например, операции с записью в журнал транзакций идут блоками, начиная от 512 байт и до 60КБ.
В нашем примере – замеры производительности хранилища в целом, но нет паттерна для SQL-нагрузки.
Летом мы получали 200 000 IOPS для чтения блоком 64k, но не привели здесь результаты этих тестов, так как там было 2 хоста, а не 3, как сделали в итоговом решении.
image
У вас, наверное, и правда крутое хранилище. Просто связи с SQL Server не видно — нет у него чтения (ещё и последовательного, наверное?) блоком 4кб, с блоком 64k было бы интереснее.

Претензия-то справедливая. Нельзя IOPSы так механически применять.
У SQL Server по факту 2 больших паттерна нагрузки, несколько "вспомогательных", и в рамках первых двух есть некоторая разница в зависимости от задач.
2 главных паттерна


  • LDF — как справедливо написали — последовательная write-through запись блоками 0,5-60 киБ, а чтения редкие и предсказуемые (читалки логов, отмена больших транзакций и бэкапы)
  • MDF — в обычной работе относительно случайное чтение и запись (write back обычно) блоками 8 или 64 киБ. В типичных OLTP чтений 80-95%. Плюс не забыть про крупные загрузки, перестроения индексов и т.п. Если раздел отформатирован в блоки по 64к, то блок только 64к.

В первом паттерне на IO очереди нет (она может быть в SQL Server). Во втором — вполне может быть. Плюс есть специфичная tempdb, плюс надо понять не становится ли бэкап узким местом. При смешивании нагрузок всё ухудшается и усложняется.
Можно ли ваше тестирование использовать для корректной оценки?

Нам была нужна методика тестирования, которая продемонстрирует возможности хранилища в целом. При всем желании у нас бы не получилось ответить на этот вопрос применительно к каждой конкретной ситуации. Если у вашего бизнеса есть конкретная задача или проект, где необходим такой кластер, — готовы обсуждать пробный доступ.

Ну тогда MS SQL Server тут ни при чём (кроме того, что стоит на том же железе). Сами же написали в статье:


Я покажу, на каком железе, софте и конфигурации сети мы проводили тесты быстродействия БД

А показали быстродействие не БД, а дисков. С паттерном, которого у MS SQL Server тупо нет.
И еще интересно, как используется Intel Optane DC Persistent Memory (кстати, ваша ссылка ведет на 404).

Результаты с -o 32 никому не интересны.
Нужны результаты с -o 1.
НЛО прилетело и опубликовало эту надпись здесь
За полгода интенсивного нагрузочного тестирования деградации дисков мы не выявили.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий