У нас есть сервер Windows 2008 R2, на котором работает SQL Server 2008. Внезапно процесс SQLServer отказывается использовать ЦП выше 20%. По состоянию на прошлую неделю, при выполнении тяжелого запроса к базе данных, оно возрастало до 100%, как я ожидал. У нас есть этот сервер какое-то время, и кажется странным, что у него внезапно появился этот предел. Это ограничение приводит к тому, что наши запросы выполняются намного дольше, чем обычно. Никто (по крайней мере, сознательно) не вносил никаких изменений в конфигурацию сервера.
После небольшого исследования я обнаружил представление sys.dm_os_sys_memory. Это показывает, что «доступная физическая память высока», но в то же время доступная физическая память составляет 339552 КБ, тогда как общее количество составляет 4193848 КБ. Стоит отметить, что это виртуальный сервер, работающий на vmware.
Есть ли где-нибудь в SQL Server параметр, который устанавливает максимальное использование ЦП? Я нашел настройки в регуляторе ресурсов, хотя в настоящее время он отключен, как всегда.
Недавно мы начали использовать Spotlight для SQL Server от Quest Software. База данных воспроизведения была расположена на этом сервере в течение короткого времени этим утром, я впервые заметил проблему вскоре после этого, хотя до этого я не делал никаких запросов, поэтому я не знаю, является ли это моментом, в котором проблема началось, однако база данных работала, как и ожидалось, в пятницу днем. Журнал Windows показывает, что следующие параметры были применены к базе данных SpotlightPlaybackDatabase при ее создании.
Могли ли какие-либо из этих изменений параметров изменить параметры, применяемые ко всему серверу?
Редактировать # 1: Удалось решить эту проблему, перезапустив сервер sql, не зная, в чем проблема. Несмотря на то, что проблема решена, у меня все еще есть некоторые проблемы с io, о которых я раньше не знал.
Редактировать # 2: Проблема возникла снова. Решение состояло в том, чтобы отключить анализ трассировки в центре внимания на SQL Server, это было тем, что все тянуло вниз.
Вы не можете управлять использованием ЦП, но можете управлять Соответствие ЦП. То есть кто-то ограничил SQL Server использованием одного процессора?
В том же духе кто-то изменил глобальная настройка maxdop? Это ограничивает все запросы одним ЦП, но любой отдельный запрос будет выполняться на одном из доступных ЦП.
Предполагая, что не было изменений конфигурации привязки к процессору или MAXDOP, как указано gbn, существует несколько возможностей.
Во-первых, план запроса для вашего запроса изменился, потому что значительно изменилось распределение индексов или данных базовой таблицы. Попробуйте оптимизировать или перестроить индексы в базовых таблицах.
Во-вторых, теперь вы можете быть привязаны к вводу-выводу, либо читая данные из вашего основного файла базы данных, либо работая в tempdb (где SQL будет хранить промежуточные части запроса, если они слишком велики для ОЗУ). Используйте perfmon и следите за средним значением. длина дисковой очереди. В среднем оно должно быть меньше, чем количество физических дисков на сервере. Если он выскакивает во время вашего «тяжелого запроса», в то время как ЦП остается низким, ЦП просто ожидает ввода-вывода диска и, следовательно, не может работать на 100%, выполняя полезную работу. В этом случае у вас есть несколько вариантов: больше ОЗУ (чтобы уменьшить потребность в использовании диска), более быстрый диск (SSD?) Или оптимизировать запросы, индексы и схему для уменьшения дискового ввода-вывода. Последний вариант может иметь наибольшее влияние (буквально улучшая ситуацию в 100 и более раз). Но это также может быть самым сложным, в зависимости от вашей структуры данных и запросов. Прочтите планы выполнения SQL; купите книги.
Проверьте sys.dm_os_waiting_tasks и посмотрите, какие ресурсы ожидания. В основном посмотрите на wait_type и посмотрите, что там. Запустите этот запрос и отправьте результаты обратно.
select wait_type, sum(wait_duration_ms) sum_wait_duration_ms, avg(wait_duration_ms) avg_wait_duration_ms, count(*) waits
from sys.dm_os_waiting_tasks
group by wait_type
У вас может быть проблема, аналогичная той, о которой я говорил сегодня утром мой блог.
Одна вещь, которую вы можете сделать, - это точно увидеть, что происходит с процессом, выполняющим запрос. Если вы продолжите мониторинг активности spids и посмотрите, какой тип ожидания является наиболее распространенным. Вы, вероятно, обнаружите, что существует ресурс, такой как disk io, который ожидает spid, что означает, что процессор простаивает для запроса до завершения чтения / записи на диск.
Эта проблема была решена перезапуском sql-сервера, хотя я не знаю, что в первую очередь вызвало это. Спасибо всем за ваши ответы.