Комментарии 20
Я правильно понял что Azure SQL database не поддерживает?
Хорошая статья, но хотелось бы видеть практический опыт применения(в начале вы начали с конкретного примера). Вот Brent Ozar утверждает что Resource Governor на практике делает только хуже, усложняя оптимизацию www.brentozar.com/blitz/resource-governor-enabled
Спасибо!
Честно говоря, не увидел противоречий своего поста со статьёй Брента. Да, Resource Governor не позволяет управлять всей памятью — про это у меня написано неоднократно; да, если ограничить запросы по CPU и IO, они могут выполняться дольше; да, из-за этого они будут дольше удерживать блокировки и избыточные гранты (если они есть в этих запросах) тоже будут держаться больше, соответственно, другим запросам будет доступно меньше памяти.
Я и не могу давать никаких конкретных реальных примеров использования, поскольку когда речь заходит о конкретике в настройках — ответ всегда один — it depends. Совсем не факт, что они помогут, а навредить могут запросто.
Один из примеров применения у меня: я ограничиваю запросы от системы мониторинга бизнес-метрик по CPU (только MAX_CPU_PERCENT, чтобы не резать CPU, когда нагрузки нет) и IO (тоже только максимальное количество). При этом у меня везде используется READ COMMITTED SNAPSHOT, соответственно, при чтении мониторинг блокировок не накладывает. Функция классификации очень похожа на ту, что указана в посте.
Честно говоря, не увидел противоречий своего поста со статьёй Брента. Да, Resource Governor не позволяет управлять всей памятью — про это у меня написано неоднократно; да, если ограничить запросы по CPU и IO, они могут выполняться дольше; да, из-за этого они будут дольше удерживать блокировки и избыточные гранты (если они есть в этих запросах) тоже будут держаться больше, соответственно, другим запросам будет доступно меньше памяти.
Я и не могу давать никаких конкретных реальных примеров использования, поскольку когда речь заходит о конкретике в настройках — ответ всегда один — it depends. Совсем не факт, что они помогут, а навредить могут запросто.
Один из примеров применения у меня: я ограничиваю запросы от системы мониторинга бизнес-метрик по CPU (только MAX_CPU_PERCENT, чтобы не резать CPU, когда нагрузки нет) и IO (тоже только максимальное количество). При этом у меня везде используется READ COMMITTED SNAPSHOT, соответственно, при чтении мониторинг блокировок не накладывает. Функция классификации очень похожа на ту, что указана в посте.
Ну и в статье по ссылке я не увидел утверждения, что он делает только хуже, усложняя оптимизацию — всё-таки он пишет о том, что некорректная конфигурация может сделать хуже.
Ну да, он как раз пишет что чаще всего конфигурацию как раз делают некорректную(я так понимаю довольно сложно сделать все правильно). Т.е. вот у вас — «система мониторинга бизнес-метрик» — сколько она сама по себе потребляет и как включение ограничений помогло другим операциям в системе(и помогло ли). Что-то стало работать быстрее?
Что-то стало работать быстрее?
Быстрее относительно чего? В моменты пиковой загрузки запросы мониторинга метрик стали работать дольше — в 10-100-1000 раз, в зависимости от того, нужен им был только CPU, или диск тоже. Запросам от приложения, при этом, доступны практически все ресурсы, но они и так борются между собой за эти ресурсы, просто из борьбы мы большей частью «исключаем» мониторинг.
Как вы хотите, чтобы я оценил «сколько она сама по себе потребляет»? Вот есть ряд запросов от мониторинга, которые прилетают раз в 30-60 секунд, каждый из которых требует несколько сотен миллисекунд процессорного времени и несколько десятков тысяч логических чтений. Если всё хорошо, то чтения и будут логическими, но могут ведь быть и физическими. А могут стать физическими только у одного запроса, да и то не все, а могут — все у всех стать физическими.
А нагрузка, генерируемая приложением — это не какая-то статичная нагрузка, которую я могу описать. Это может быть куча мелких запросов на запись, а может быть несколько жирных на чтение. А может быть несколько на чтение и небольшая кучка на запись.
Предложите методику тестирования и оценки, возможно, тогда я смогу ответить. Сейчас ответ, как обычно, один — it depends.
довольно сложно сделать все правильно
офигеть как сложно сделать всё правильно, и для того, чтобы это сделать, нужно понимать свою нагрузку и компромиссы, на которые придётся пойти
Ну вот именно об этом и пишет Брент. Что вы настроили какую-ту штуку(которая сама по себе потребует администрирования и времени для настройки), плюс к тому же ее не тестировали.
Под тестированием я понимаю решение каких-то практических задач, т.е. вот у вас пример с продажей товара. К примеру неделю работает сервер без Resource Governor, вы замеряете время выполнения операции продажи, считаете среднее.
Дальше включаете эту штуку, выполняете аналогичные замеры в течении какого-то времени
Получаете к примеру какую-то разницу(или не получаете, тогда делаете вывод что проблема в чем-то другом).
Сейчас как я понял вы получили только негативный эффект «метрики стали работать дольше»
Под тестированием я понимаю решение каких-то практических задач, т.е. вот у вас пример с продажей товара. К примеру неделю работает сервер без Resource Governor, вы замеряете время выполнения операции продажи, считаете среднее.
Дальше включаете эту штуку, выполняете аналогичные замеры в течении какого-то времени
Получаете к примеру какую-то разницу(или не получаете, тогда делаете вывод что проблема в чем-то другом).
Сейчас как я понял вы получили только негативный эффект «метрики стали работать дольше»
К примеру неделю работает сервер без Resource Governor, вы замеряете время выполнения операции продажи, считаете среднее.
Вы проводили у себя такие замеры на стороне БД? Безотносительно resource governor. Поделитесь опытом? Имеет ли такой замер смысл?
Что будем считать — время выполнения запроса? А если бизнес-процесс продажи включает в себя сотню запросов, мы считаем каждый запрос отдельно или все вместе? А как учесть параллельную нагрузку от работы других подразделений? Т.е. нужно ли нам считать, что вот когда маркетинг что-то делает, у нас продажа вот этого продукта занимает столько времени, а вот этого — столько; когда плановый отдел — вот столько; когда они вместе — столько? А нагрузку сети мы как учтём? А нагрузку на серверах приложений? А может на сервер СУБД кто-то залез по RDP и запустил дефрагментацию диска?
Чтобы оценить именно влияние Resource Governor, по-моему, есть один способ — собирать трассы, проигрывать их на аналогичном оборудовании и уже там делать замеры чего угодно. Очень легко задача решается, только кто ж даст так сделать?
негативный эффект «метрики стали работать дольше»
Я это вижу как «метрики стали оказывать меньшее влияние на производительность системы продаж». И вот тут я уже могу оценить — допустимо для меня такое ухудшение производительности системы мониторинга, или нет.
У нас есть три кастрюли с едой (CPU, RAM, IO) и куча по-разному голодных людей, которые по очереди подходят, зачёрпывают и отходят. И с помощью Resource Governor мы можем одним дать поварёжки, а дргуим — чайные ложки. Но их не станет меньше, они продолжат толкаться и мешать друг другу, а те, с чайными ложками, ещё и озлобиться могут, и начать пинаться, да.
Ну вот именно об этом и пишет Брент
Не очень понимаю о чём «об этом». На мой взгляд он пишет о том, что RG может замедлить работу и сделать хуже.
Да я больше скажу — RG и нужен для того, чтобы сделать чью-то работу хуже, чтобы другие в это время могли выполнять свою работу более эффективно.
чтобы другие в это время могли выполнять свою работу более эффективно.
Ну вот он пишет что в большинстве случаев это не работает. Замерять надо бизнес процессы, у вас же вначале идет пример «продажа товара становится настолько медленной, что покупатели отказываются от покупки». Т.е. замеряете среднее время открытия страницы до включения и после.
Если вы это не можете замерить, то какой смысл включения?
Ну вот он пишет что в большинстве случаев это не работает.
Приведите цитату, пожалуйста, где он это пишет.
Если вы это не можете замерить, то какой смысл включения?
Ещё раз — какой смысл в этой метрике? Что она показывает? От чего зависит? Нужно учесть миллиард вещей, которые оказывают влияние на «среднее время открытия страницы». Единственное, что она может делать — это служить сигналом, что пора разбираться что там на самом деле сейчас происходит.
пора разбираться что там на самом деле сейчас происходит.
С этим я согласен. В вашем случае вы разобрались и решили что включение Resource Governor решит проблему? или как-то по другому было. Если как-то по другому — то зачем вы его включали?
Я всё-таки прошу вас приложить цитату, где Брент Озар в той статье пишет, что «в большинстве случаев это не работает», а то какая-то игра в одни ворота получается.
Конечно нет — это не серебряная пуля. Мы увидели, что часть второстепенных систем, включая систему мониторинга, активно участвует в борьбе за ресурсы и ограничили их хотелки. Запросы от критически важных систем получили больше ресурсов, смогли выполняться быстрее, чем до включения RG.
Не могу понять к чему вы ведёте. Вы можете высказать свою точку зрения, а не подводить меня к ней?
решили что включение Resource Governor решит проблему?
Конечно нет — это не серебряная пуля. Мы увидели, что часть второстепенных систем, включая систему мониторинга, активно участвует в борьбе за ресурсы и ограничили их хотелки. Запросы от критически важных систем получили больше ресурсов, смогли выполняться быстрее, чем до включения RG.
Не могу понять к чему вы ведёте. Вы можете высказать свою точку зрения, а не подводить меня к ней?
Review why you have Resource Governor configured, test your classifier function, and make sure your performance fix isn’t slowing you down.
Я просто пытаюсь понять — откуда такая уверенность что что-то стало выполняться быстее. Страницы стали быстрее открываться или что? если стали, то на сколько?
Ну точка зрения описана у Брента, что если вы не можете это протестировать — не включайте, это усложнит дальнейшую оптимизацию
Review why you have Resource Governor configured, test your classifier function, and make sure your performance fix isn’t slowing you down.
Окей. Где здесь про большинство случаев?
Ну точка зрения описана у Брента, что если вы не можете это протестировать — не включайте, это усложнит дальнейшую оптимизацию
Можете её описание тоже цитатами приложить? У него такой точки зрения не вижу. Я не большой фанат изложений типа «что хотел сказать автор». Давайте тогда конкретные цитаты обсуждать.
Ну, т.е., когда некий хрен с горы, в лице меня, «заочно спорит» с Брентом Озаром — это одна история, достаточно глупая, причём — где я, и где он. Когда просто два хабраюзера между собой её обсуждают — совершенно другая.
Страницы стали быстрее открываться или что? если стали, то на сколько?
У запросов, ради которых всё затевалось, снизились ожидания SOS_SCHEDULER_YIELD. Суммарный выигрыш не более 5-10%, но в ряде случаев уменьшилось количество отваливаний по тайматуам.
Причём эти числа 5-10%, могут быть любыми — они никому не могут помочь понять поможет ли RG ему на его нагрузке, в его БД, на его оборудовании, с его возможностями по классификации соединений.
Про тестирование во всём тексте вижу только одно место, как раз в приложенной цитате, где он говорит о функции классификации. Её как раз можно протестировать, если есть сомнения.
да зачем «ему». хотелось бы узнать про конкретные бизнес случаи, а не про абстрактные примеры. бизнес операции стали работать быстрее на 5-10%? Это довольно много конечно.
Не бизнес-операции, а конкретные запросы. И только в ряде случаев, потому что не только то, на что мы можем влиять с помощью RG влияет на время выполнения запроса (и бизнес-операции, тем более), а таких факторов множество.
Ок. т.е. вашем случае какие-то запросы стали работать немного лучше. На уровне бизнес операций вы этого не заметили(из за наличия других факторов совокупное влияние меньше чем погрешность измерения).
По сути первые параграфы в статье не выполняются
Отказ от покупок от медленной работы это получается не решило
По сути первые параграфы в статье не выполняются
Что если при такой нагрузке продажа товара становится настолько медленной, что покупатели отказываются от покупки?
Отказ от покупок от медленной работы это получается не решило
Суммарный выигрыш не более 5-10%, но в ряде случаев уменьшилось количество отваливаний по тайматуам
Не очень понял — что именно не выполняется? В процитированной вами части есть какие-то «обещания» или «гарантии» (то, что должно выполняться)? По-моему, следующий абзац в тексте ясно говорит о чём, собственно, пост.
Ну, в смысле, из вашего комментария у меня сложилось впечатление, что мой пост не оправдывает каких-то ваших ожиданий и вы спорите не с постом, а с ними. Жаль, конечно, но тут уж ничего не поделаешь
на уровне бизнес-операций я далеко не всегда могу разделять влияние разных методов оптимизаций, не только на уровне БД, но и на других уровнях, чтобы сказать — вот это нам даёт выигрыш 10%, а это 15%. При том, что метрика «время бизнес-операции» вообще ничего-ничегошеньки нам не говорит, кроме того — есть проблемы с производительностью, или нет.
Ну, в смысле, из вашего комментария у меня сложилось впечатление, что мой пост не оправдывает каких-то ваших ожиданий и вы спорите не с постом, а с ними. Жаль, конечно, но тут уж ничего не поделаешь
на уровне бизнес операций вы этого не заметили
на уровне бизнес-операций я далеко не всегда могу разделять влияние разных методов оптимизаций, не только на уровне БД, но и на других уровнях, чтобы сказать — вот это нам даёт выигрыш 10%, а это 15%. При том, что метрика «время бизнес-операции» вообще ничего-ничегошеньки нам не говорит, кроме того — есть проблемы с производительностью, или нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что нам стоит Resource Governor настроить