Есть ли быстрый способ узнать, какой сайт на сервере будет использовать весь ЦП с помощью 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 не поможет, вы можете начать думать о любой возможной атаке червя.