Опасен ли SQL profiler?

    Недавно с некоторым удивлением узнал, что в одном из департментов огромной фирмы, где я работаю, запрещен запуск SQL profiler в business hours.


    Не знаю, как они выкручиваются для анализа проблем с производительностью, происходящей как раз в бизнес часы. Ведь performance views часто не дают точной картины, особенно если тормозит одна/две процедуры/квери, не нагружая особенно сам сервер. Крошечная кверь, выполняющаяся несколько раз в час и работающая 10 секунд вместо одной (но делающая очень важного клиента очень нервным) точно не попадет в DMV views. А select с CROSS APPLY по текстам кверей сам нагружает сервер очень нехило.

    Однако мне интересно понять, откуда происходит эта боязнь. В некоторых фирмах SQL profiler – рабочий инструмент, в некоторых его боялись, как огня (какое то время я занимался консалтингом и мог сравнивать). Я почти уверен, что дело было так:


    Хьюстон, у нас проблемы. Тормозит база. Разберись




    Здесь столько галочек… Что же мне нужно?




    Ладно, поставлю все галочки и потом решу.



    Что остается в голове высокого начальства? Кто-то то запустил SQL profiler и все встало колом. И потом рассказывают это друг другу за партией в гольф.

    Кстати, особую пикатность придает попытка записать такие ‘пишем все’ трейсы не в файл, а в базу на этом же сервере – один раз я был свидетелем такого случая.

    А как у вас обстоят дела? Поучаствуйте в опросе пожалуйста

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Можно ли у вас запускать SQL profiler на PROD?

    Поделиться публикацией

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

      +3
      Ну вы бы хоть пару тестов сделали бы для приличия, со всеми галочками и только с нужными. А то ведь те, кому нельзя запускать, и показать нужную статью с доказательствами не могут.
        0

        Это очень зависит от количества запросов, от того, насколько они легкие — много коротких или мало длинных, или


        Мое правило, SQL:BatchCompleted и RPC:Completed с фильтром Duration>100ms точно безопасен.

          0
          Подскажите, пожалуйста, как безопасно в нем отследить что блокирует выполнение процедуры вплоть до ее завершения по таймауту?
            0
            Либо ловить event lock graph
            Либо косвенно по тому что Duration >> того что можно ожидать из чисел CPU, Reads, Writes
        0

        Кстати, у нас была ситуация, когда пошаговая отладка процедура роняла сервер. Ещё на 2008 сервере. На 2012 не пробовали ) зато у 2012 частенько врёт actual execution plan (некорректно показывает проценты у отдельных запросов в процедуре), и без профайлера с включенным sp:Statement completed реально не обойтись...

          0
          зато у 2012 частенько врёт actual execution plan (некорректно показывает проценты у отдельных запросов в процедуре), и без профайлера с включенным sp:Statement completed реально не обойтись...


          вполне даже обойтись
          set statistics time on 

          наше все, ну и туда же
          set statistics io on 

          правда статистика io может не все показать — например траблшутил запрос, вроде и план плюс минус нормальный, IO по таблицам низкий
          но при этом statistics time показывает высокую нагрузку на CPU и высокий duration и это при том что по плану видно что ни хэширования ни сортировки нету, откуда ж такая нагрузка на CPU… ну и пристальнее взглянув увидел скалярную функцию в которой много всякого интресного происходило, а statistics io этого не показывала :(
          +1
          Напомнило анекдот:
          Поспорили терапевт с ветеринаром у кого работа сложнее. Спорили-спорили, не могут договориться. Ветеринар предлагает:
          — Давай тестовый приём проведём?
          — Давай!
          — Ну вот представь, я пришёл к тебе на приём. Что бы будешь делать?
          — На что жалуетесь?
          — Э, нет! Так каждый дурак может!
            +4
            Без проблем.
            — Вот вам таблетка. Если не поможет, завтра усыпим.
              0
              Это, я так понимаю (если вернутся к ситуации в статье), приметно так:
              — Накатите вот это патч. Если не поможет — грохните прод, он всё равно не работал.
            +1
            Есть разница, запускать профайлер через GUI или запустить Server Side Trace скриптом. На более свежих версиях предлагают забить на профайлер и использовать Extended Events.
              0
              это предлагают почти с самого появления Extended Events, но они не так удобны и сложнее правильно настроить. в последних версиях SSMS появился «Extended Events Profiler», запускается по сути Extended Events сессия, но в обертке GUI привычного всем профайлера. правда количество ивентов которые можно через него отлавливать сильно ограничено, но наиболее нужное RPC Completed, Batch Completed и иже с ними конечно же присутствуют
              0

              У нас около 1 000 000 запросов в час, немного, но пару раз запускали с настройками "как есть" что бы найти запросы от предыдущих талантов. Сервер не падал, нагрузка росла, но не критично

                0
                Да, пока нагрузка далека от 100% разумные трейсы лишь увеличивают CPU, не просаживая саму производительность
                  0

                  Все должно быть в приделах разумного. У нас кстати был удивительный случай — монитор активности и запрос с записью во временную таблицу 200 000 записей наглухо вешали сервер вообще по памяти и цп, приходилось рубить на уровне виртуализации

                +1

                У нас в компании используют несколько профилей, для выявления разных проблем: дедлоки, долгие запросы. Переходим сейчас на extended events, эту технологию рекомендует MS, поскольку сам профайлер deprecated. Плюсы EE более гибкая система получения информации о работе приложения, меньше проседает производительность по сравнению с профайлером, соответственно с меньшим риском можно запустить на проде

                  0
                  Это да
                  Но вот это

                  рекомендует MS, поскольку сам профайлер deprecated. Плюсы EE более гибкая система получения информации о работе приложения, меньше проседает производительность по сравнению с профайлером, соответственно с меньшим риском можно запустить на проде


                  достатточно, чтобы победить параною?
                    0
                    ну опять таки, если внимательно посмотреть в настройки Extended Events сессии то для некоторых ивентов можно увидеть вот такое предостережение, например для события query_post_execution_showplan:
                    «Using this event can have a significant performance overhead so it should only be used when troubleshooting or monitoring specific problems for brief periods of time.»
                    поэтому хоть и eEvents и легче чем server side trace, тем не менее при неосторожном применении так же может стать причиной проседания производительности.
                    так что для параноии всегда будет место :)))
                    0
                    я бы еще добавил что через eEvents можно отследить события которые в профайлере в принципе отсутствуют. например все (или почти все) события из канала Debug

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое