AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 18.06.2018, 09:59   #1  
AlGol is offline
AlGol
Участник
 
277 / 93 (4) ++++
Регистрация: 24.12.2001
Адрес: Тверь.
Post «20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет
Неплохая статья про настройки производительности систем хранения под 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/
__________________
Ален ноби, ностра алис.
Что означает - если один человек построил, другой завсегда разобрать может.
За это сообщение автора поблагодарили: Ivanhoe (1), Logger (3), sukhanchik (5).
Старый 18.06.2018, 14:00   #2  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Я кстати вообще не понял статью. т.е. он в начале что-то долго и аргументированно расказывает что данные и логи надо разделять, потом идет фраза
Цитата:
Когда какая-нибудь загрузка данных на ноутбуке разработчика выполняется 5 минут, а на 40 ядерном сервере с 1 ТиБ RAM и СХД за полмиллиона долларов та же самая задача выполняется час, то даже у самых терпеливых заказчиков появятся вопросы обоснованности затрат.
ну т.е. вывод явно противоположный - дело явно не разделении

еще я считал, что для хранилища должен быть настроенный кеш на запись(с отдельной батарейкой), т.е. по идее должно быть все равно как там эти диски поделены
За это сообщение автора поблагодарили: Vadik (1).
Старый 18.06.2018, 14:33   #3  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от trud Посмотреть сообщение
ну т.е. вывод явно противоположный - дело явно не разделении
Ну почему ? Видимо предполагается, что на ноуте разработчика крутится только одна задача по загрузке данных, а на рабочем серваке помимо загрузки данных выполняется еще куча других запросов, при чем не обязательно тяжелых. В результате растет задержка на запись лога транзакций и соответственно замедление загрузки данных.
Цитата:
Если данные и журналы свалить в один LUN, то с точки зрения ОС это будет одна очередь IO
PS. Сам матерился, когда на дохлом тестовом сервере переиндексация одной и
той же большой таблицы в копии базы происходила в 2-3 раза быстрее, чем на навороченном рабочем, где было придушено подавляющее большинство тяжелых операций.
Старый 25.06.2018, 11:26   #4  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
145 / 334 (12) ++++++
Регистрация: 25.01.2007
Адрес: Toronto
Сложная для восприятия/прочтения статья. Но полезная.
Потому как основная метрика для OLTP СХД это не большое кол-во IOPS,а маленькое время отклика (latency).

Основные выводы, по моему мнению, верные
https://habr.com/post/414269/#chto-delat
Старый 25.06.2018, 11:32   #5  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Интересно, а почему так получается. Зачем писать строго в один лог.

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

В чем ошибка в таком рассуждении ?
Старый 28.06.2018, 14:48   #6  
AlexeyS is offline
AlexeyS
Участник
 
404 / 339 (12) ++++++
Регистрация: 15.06.2004
Адрес: москва
Цитата:
Сообщение от Logger Посмотреть сообщение
Интересно, а почему так получается. Зачем писать строго в один лог.

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

В чем ошибка в таком рассуждении ?
А зачем? при условии, что запись в журнал транзакций идет в один поток, производительности IO и так с запасом, поэтому просто нет смысла городить огород с разделением очереди на несколько файлов последующей сборкой очереди обратно.
Старый 28.06.2018, 15:14   #7  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от AlexeyS Посмотреть сообщение
А зачем? при условии, что запись в журнал транзакций идет в один поток, производительности IO и так с запасом,
С каким запасом ?

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

Вот я и подумал - если взять N дисков и писать параллельно на них каждая транзакция на свой диск. Возможно ли тогда поднять производительность в N раз.
Теги
iops, latency, oltp, performance, полезное, полезное очень, производительность, схд

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Блокировки при обработке журнолов Rage DAX: Администрирование 10 19.01.2010 18:44
при построении перекрёстных ссылок выдаётся сообщение об ошибках mmmax DAX: Программирование 10 21.01.2005 12:42
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 00:26.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.