В нашей производственной среде (SQL Server 2008 Enterprise) у нас были проблемы с использованием ЦП и использования сети. Исходя из технических характеристик имеющихся (нескольких) машин и общей функциональности нашего программного продукта, загрузите не должна быть проблемой.
Как разработчик я полагал, что проблема должна заключаться в другом, вероятно, в выполняемых запросах. Я подумал, что было бы неплохо прикрепить SQL Profiler к производственному экземпляру, чтобы выяснить, какие запросы (или даже код) являются горячими точками, и сначала поработать над оптимизацией этих областей. (Ни один из наших специалистов по аппаратному / сетевому оборудованию раньше этого не делал.)
Я прикрепил профилировщик к одному из наших экземпляров разработки на пару часов и определил, что у нас есть несколько проблемных областей:
SELECT * появляются запросы; также было довольно много непараметрических. Это большое подмножество №1, где запрос может отличаться только одним WHERE параметр.Основываясь на собранной мною сводной статистике, самые большие проблемные запросы относятся к типам №1 и №2. Однако я не могу сразу взять эти результаты и начать работу, потому что запросы экземпляров разработки - это, по сути, то, над чем другие разработчики работают в то время, а не то, что будет чаще всего выполняться в производственной среде.
Я читал, что прикрепление SQL Server Profiler к экземпляру проблематично из-за накладных расходов. По понятным причинам подключение в производственной среде должно быть как можно более легким.
Что мне нужно знать, так это то, что, учитывая три разных типа запросов, которые мне нужно определить, как мне настроить профилировщик так, чтобы он оказывал минимальное влияние на производительность? Есть ли другой инструмент, который я мог бы использовать для этого?
Ноты:
Вместо подключения SQL PRofiler используйте sp_trace_xxx процедуры. Причина, по которой профилировщик SQL не рекомендуется в производственной среде, заключается в том, что он может привести к блокировке сервера при ожидании сброса сетевого взаимодействия с профилировщиком («сеть» может означать локальную разделяемую память, расположение не имеет значения). Идея состоит в том, что однопоточный управляемый процесс с графическим интерфейсом пользователя не сможет справиться с полным потоком событий от многопоточного родного высокооптимизированного сервера. Используя вместо этого процедуры трассировки, вы исключаете графический интерфейс / профилировщик из уравнения и позволяете серверу сбрасывать события так быстро, как они могут быть записаны на диск на сервере, что всегда намного быстрее, чем это могло бы сделать профилировщик. обработать их. Если вы добавите приличный фильтр для событий (например, только трассировку событий RPC: Completed и Batch: Completed с продолжительностью более> 1 секунды или что-то подобное), то вы не окажете серьезного влияния на сервер.
Профилировщик графического интерфейса пользователя может сохранять трассировку в виде серии вызовов процедуры sp_trace, поэтому вам не нужно вручную создавать сценарий.
В идеале у вас также может быть промежуточная или тестовая среда, в которую вы помещаете код, который хотите тестировать, а не разрабатывать, а затем накладываете на него нагрузку производственного уровня. В этом случае вы сначала загрузите копию производственного кода и баз данных, запустите профилировщик, а затем позволите пользователям или тестерам использовать его, как производственную систему.
После того, как вы это сделаете и оптимизируете некоторые вещи, вы загрузите этот код обратно в свою тестовую среду и снова протестируете его, чтобы увидеть, не найдете ли вы еще одно узкое место.
Теперь, если вы не можете этого сделать, у вас должна быть идея запустить профилировщик в среде разработки, если он будет достаточно легким (или нет), чтобы попытаться запустить его напрямую в производственной среде.
Запустите профилировщик с другого сервера / рабочей станции.