Назад | Перейти на главную страницу

SQL Server, использующий 100% ЦП

Есть ли быстрый способ узнать, какой сайт на сервере будет использовать весь ЦП с помощью SQL-запроса? Так же случайно процессор просто сидит на 100%, и я не знаю почему?

Это определенно поможет узнать, какую версию SQL Server вы используете.

Я считаю, что вы используете SQL Server 2005 как наиболее распространенный в наши дни. Чтобы определить причину проблемы, я рекомендую вам скачать Панель управления производительностью отчеты. После установки настраиваемых отчетов и запуска сценария развертывания, как описано в разделе «Дополнительная информация» на странице загрузки, вы открываете настраиваемый performance_dashboard_mail.rdl отчет в SQL Server Management Studio. Оттуда у вас есть ссылки на отчеты об использовании ЦП, которые покажут общее время, затраченное на каждый запрос в вашей системе. Самые популярные запросы в этих отчетах, скорее всего, приведут систему к 100% загрузке ЦП. Вам нужно будет проанализировать план выполнения этих запросов и определить, почему они так дороги. Визуализатор плана SSMS помогает в этом, просто следуйте толстый линии на плане, потому что они представляют большие потоки данных. В конце этих дорогостоящих потоков данных вы, скорее всего, найдете операторы сканирования кластерного индекса, которые возвращают все строки в таблице. Вам нужно будет понять запрос и структуру таблицы, чтобы решить, почему следует выбрать сканирование кластерного индекса, и вам, вероятно, придется решить, добавить ли один или два индекса. Панель Performance Dashboard снова может помочь, так как на самом деле в ней есть отчеты, в которых используется какая-то эзотерическая информация из sys.dm_db_missing_index_details и представить его в удобном для чтения формате, точнее показать предложенные CREATE INDEX заявление.

Другие интересные ресурсы:

  • sys.dm_exec_query_stats собирает информацию о выполнении запроса. запросы с максимальными значениями в total_worker_time - это те, которые потребляют больше всего ЦП. Крест применить sys.dm_exec_sql_text для получения текста запроса.
  • sys.dm_exec_procedure_stats аналогично статистике запросов, но для процедур. Только в SQL Server 2008.
  • sys.dm_db_index_usage_stats собирает информацию о том, как осуществляется доступ к таблицам и индексам. Посмотрите на user_seeks, user_scans, user_lookups чтобы узнать, как часто и каким образом читается таблица. смотреть на user_updates чтобы увидеть, как часто это записывается.
  • sys.dm_db_index_operational_stats собирает, среди прочего, информацию о конкуренции за доступ к индексам. Посмотрите на различные xxx_wait_ms и xxx_wait_count столбцы, чтобы понять, где возникает конфликт. Поскольку у вас 100% ЦП, маловероятно, что проблема заключается в разногласиях, но я все равно должен предоставить эту информацию другим читателям, которые ее обсуждают.

По завершении этого исследования вы сможете определить проблему:

  • Сканы таблиц. Это будет отображаться как запросы на панели мониторинга производительности, которые выполняются относительно несколько раз, но длятся долгое время при каждом выполнении. Другие симптомы сильные user_scans рассчитывать на sys.dm_db_index_usage_stats для индексов с большим количеством записей большие числа для total_physical_reads в sys.dm_exec_query_stats.
  • Табличные функции, которые слишком часто вызываются при выполнении. Это можно определить по очень большой execution_count в режиме просмотра статистики и на панелях мониторинга производительности. Типичными примерами являются функции для разделения строки, разделенной запятыми, на реляционное представление (если бы я получал десять центов за каждый раз ...).
  • Спулинг и сортировка. Я не буду вдаваться в подробности, сначала сделайте домашнее задание и исследую простые сценарии выше.

Успех!

В Microsoft SQL Management Studio есть Activity Monitor, который покажет самые дорогие запросы и время их процессора. Просто щелкните правой кнопкой мыши сервер в окне проводника сервера и выберите «Монитор активности».

Ты должен бежать Профайлер SQL Server чтобы помочь вам определить, где есть несколько неэффективных запросов, вызывающих большое время чтения / записи.

Что касается быстрого ... Ну, вы можете запустить его в течение минуты или двух, и это должно дать вам представление о том, есть ли некоторые SP / запросы, которые выполняются больше, чем ожидалось.

Пожалуйста, прочтите также этот вопрос и принятый на него ответ.

Если SQL Server Profiler не поможет, вы можете начать думать о любой возможной атаке червя.