Комментарии 10
Для базы данных до 4 ТБ можем гарантировать до 200 000 IOPS с задержками менее 1 мс при 100% чтении блоком 4k.
Поскольку статья называется "Как мы разгоняли кластер для нагруженных баз Microsoft SQL и получали заветные 200 000 IOPS", расскажите, пожалуйста, при каких операциях SQL Server использует чтение блоком 4k?
В нашем примере – замеры производительности хранилища в целом, но нет паттерна для SQL-нагрузки.
Летом мы получали 200 000 IOPS для чтения блоком 64k, но не привели здесь результаты этих тестов, так как там было 2 хоста, а не 3, как сделали в итоговом решении.
![image](https://habrastorage.org/webt/so/dg/93/sodg934a98wz8axd_i_m4tdoad0.jpeg)
Претензия-то справедливая. Нельзя 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 1.
Как мы разгоняли кластер для нагруженных баз Microsoft SQL и получали заветные 200 000 IOPS