«20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет

[AlGol]

Неплохая статья про настройки производительности систем хранения под OLTP:
Источник: https://habr.com/post/414269/
==============
«20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
17 июня 2018 г., 19:33

КДПВ

Поводом написать эту статью стал весьма достойный обзор Как мы тестировали VMware vSAN... компании КРОК. Обзор-то достойный, но в нем есть фраза, с которой я борюсь уже больше десятка лет. Админы СХД, виртуализаторы и интеграторы раз за разом повторяют: "Задержки в 5 мс — это отличный показатель". Даже цифра в 5 мс десять лет не меняется. Я это слышал вживую от весьма уважаемых админов уже не меньше десятка раз. От менее уважаемых — десятки, а уж сколько раз читал в интернете… Нет, нет, нет. Для OLTP нагрузок 5 мс, особенно так, как их обычно измеряют — это epic fail. Мне приходилось объяснять причины этого уже много раз, на этот раз я решил собрать свои мысли в переиспользуемую форму.

Сразу оговорюсь, что в упомянутой выше статье этих ошибок нет, скорее фраза сработала как триггер.
==============
Источник: https://habr.com/post/414269/

[trud]

Я кстати вообще не понял статью. т.е. он в начале что-то долго и аргументированно расказывает что данные и логи надо разделять, потом идет фраза

Цитата:

Когда какая-нибудь загрузка данных на ноутбуке разработчика выполняется 5 минут, а на 40 ядерном сервере с 1 ТиБ RAM и СХД за полмиллиона долларов та же самая задача выполняется час, то даже у самых терпеливых заказчиков появятся вопросы обоснованности затрат.

ну т.е. вывод явно противоположный - дело явно не разделении

еще я считал, что для хранилища должен быть настроенный кеш на запись(с отдельной батарейкой), т.е. по идее должно быть все равно как там эти диски поделены

[Alexius]

Цитата:

Сообщение от trud

ну т.е. вывод явно противоположный - дело явно не разделении

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

Цитата:

Если данные и журналы свалить в один LUN, то с точки зрения ОС это будет одна очередь IO

PS. Сам матерился, когда на дохлом тестовом сервере переиндексация одной и
той же большой таблицы в копии базы происходила в 2-3 раза быстрее, чем на навороченном рабочем, где было придушено подавляющее большинство тяжелых операций.

[vmoskalenko]

Сложная для восприятия/прочтения статья. Но полезная.
Потому как основная метрика для OLTP СХД это не большое кол-во IOPS,а маленькое время отклика (latency).

Основные выводы, по моему мнению, верные
https://habr.com/post/414269/#chto-delat

[Logger]

Интересно, а почему так получается. Зачем писать строго в один лог.

Неужели нельзя распараллелить запись в лог по аналогии с созданием нескольких файлов для TempDB. Все равно ведь можно потом при считывании инфы логически выстроить ее в строгую последовательность как будто это был один лог.

В чем ошибка в таком рассуждении ?

[AlexeyS]

Цитата:

Сообщение от Logger

Интересно, а почему так получается. Зачем писать строго в один лог.

Неужели нельзя распараллелить запись в лог по аналогии с созданием нескольких файлов для TempDB. Все равно ведь можно потом при считывании инфы логически выстроить ее в строгую последовательность как будто это был один лог.

В чем ошибка в таком рассуждении ?

А зачем? при условии, что запись в журнал транзакций идет в один поток, производительности IO и так с запасом, поэтому просто нет смысла городить огород с разделением очереди на несколько файлов последующей сборкой очереди обратно.

[Logger]

Цитата:

Сообщение от AlexeyS

А зачем? при условии, что запись в журнал транзакций идет в один поток, производительности IO и так с запасом,

С каким запасом ?

Весь смысл статьи в том что не хватает производительности, чтобы писать в один лог с маленьким latency и это ограничивает сверху максимальное число транзакций в секунду. Нет там никакого запаса.

Вот я и подумал - если взять N дисков и писать параллельно на них каждая транзакция на свой диск. Возможно ли тогда поднять производительность в N раз.