Высокое использование ЦП на сервере SQL - Медленные запросы [закрыты]

Наш MS SQL Server использует около 95% мощности процессора.

После перезагрузки сервера (аппаратного обеспечения) или перезапуска SQL-Service использование составляет 0% и медленно увеличивается в течение 1-3 дней. В зависимости от того, насколько он используется.

Когда он превышает 80%, каждый запрос выполняется очень медленно.

Наш сайт имеет дело с большим количеством запросов, поэтому некоторые из них занимают 45-60 секунд. После перезагрузки (использование процессора менее 80%) для одного и того же запроса требуется 11-20 секунд.


Как я могу это исправить? Я читал в Интернете, что манеры близости могут регулировать использование ЦП, но настройки Affinity отключены. Я не могу их изменить. Это потому, что у меня только 1 процессор?

Существует множество трюков с самими запросами, но наши веб-сайты и сервисы довольно большие, и есть слишком много изменений.

Большинство из них уже довольно хорошо оптимизированы.


Я не могу перезапустить SQL-Service, хотя это занимает всего 2 секунды, потому что у нас есть служба сигнализации, которая позволяет людям звонить и записывать сообщение, затем вызываемая группа будет вызываться и слышать записанное сообщение.

Эта система используется сотнями команд поиска и спасения, и если SQL-Service перезапустится во время тревоги, она прекратится, и человек, который ее вызвал, не будет уведомлен.


Я искал повсюду, но не нашел ничего, кроме материала о «Affinity Masks», который я не могу изменить.

Должен быть способ очистить кеш процессора, не прерывая текущих запросов ... правильно?


SQL: Microsoft SQL Server 11.0.2100.60
OS: Windows Server 2012 x64
Processor: 2.30 GHz
RAM: 4.00 GB
10 голосов | спросил Levi Johansen 14 J0000006Europe/Moscow 2013, 16:43:51

3 ответа


17

Affinity не «регулирует использование ЦП» (например, в вашем случае заставить процессоры работать меньше), он позволяет либо выключать процессор (возможно, сделать его доступным для другого экземпляра на том же компьютере), либо установить CPU для помощи только с вводом /выводом. Даже если у вас было несколько процессоров, вы бы не смогли использовать первое, чтобы помочь в достижении своей цели, и мы не можем догадаться о последнем, потому что мы не знаем, что заставляет ваше использование процессора так высоко. Это может быть связано с чрезвычайно плохим индексированием, чрезмерными компиляциями, обилием скалярных UDF, сбоем ввода-вывода, кто знает? (И причина, по которой причина ввода-вывода может быть причиной, заключается в том, что если ваша база данных превышает 3 ГБ или около того, ей постоянно приходится менять данные в буферную память пула и из нее, и это сказывается на процессоре.)

Кэш-память CPU также является кроличьей дырой, которую вам не нужно снижать. Я очень сомневаюсь, что ваш процессор разбивается на 95% из-за проблем с кешем вашего процессора.

Чтобы уменьшить источник давления в ЦП и предполагая, что вы используете хранимые процедуры, вы можете посмотреть этот диагностический запрос от Glenn Berry ( из источника здесь ) - убедитесь, что вы запускаете его в контексте права база данных:

-- Top Cached SPs By Total Worker time (SQL Server 2012). 
-- Worker time relates to CPU cost  (Query 44) (SP Worker Time)

SELECT TOP (25) 
  p.name AS [SP Name], 
  qs.total_worker_time AS [TotalWorkerTime], 
  qs.total_worker_time/qs.execution_count AS [AvgWorkerTime], 
  qs.execution_count, 
  ISNULL(qs.execution_count/DATEDIFF(Second, qs.cached_time, GETDATE()), 0) 
    AS [Calls/Second],
  qs.total_elapsed_time, 
  qs.total_elapsed_time/qs.execution_count AS [avg_elapsed_time], 
  qs.cached_time
FROM sys.procedures AS p WITH (NOLOCK)
INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK)
ON p.[object_id] = qs.[object_id]
WHERE qs.database_id = DB_ID()
ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE);

-- This helps you find the most expensive cached stored procedures from a CPU perspective
-- You should look at this if you see signs of CPU pressure

Если вы не используете хранимые процедуры, этот пример от Джона Самсона может помочь изолировать специальные запросы ( из источника ):

SELECT TOP (25)
    qs.sql_handle,
    qs.execution_count,
    qs.total_worker_time AS Total_CPU,
    total_CPU_inSeconds = --Converted from microseconds
    qs.total_worker_time/1000000,
    average_CPU_inSeconds = --Converted from microseconds
    (qs.total_worker_time/1000000) / qs.execution_count,
    qs.total_elapsed_time,
    total_elapsed_time_inSeconds = --Converted from microseconds
    qs.total_elapsed_time/1000000,
    st.text,
    qp.query_plan
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS apply sys.dm_exec_query_plan (qs.plan_handle) AS qp
ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE);

Вы также можете взглянуть на sp_WhoIsActive , хранимая процедура, которая может быстро анализировать все текущие запросы и позволяет сортировать ее, как вы хотите (например, в вашем случае @sort_order = '[CPU] DESC')

Первое, что я хотел бы сделать, - особенно, если это действительно критически важно для поисковых и спасательных команд, - это покупка лучшего оборудования. У вас должно быть больше процессоров и больше ОЗУ для обслуживания вашего приложения. Вам также абсолютно необходима высокая доступность (например, кластеризация, зеркалирование или группы доступности). Нет причин, по которым перезагрузка физической машины должна полностью отключить ваше приложение - у нас есть лучшие решения для этой проблемы. И, наконец, я предполагаю, что у этого «сервера» есть только один дисковый накопитель. Это означает, что все операции ввода-вывода - из ОС, из файлов данных SQL Server, файлов журналов, tempdb и т. Д. - все проходят через один контроллер и совместно используют операции чтения /записи на одном диске. Получите больше дисков. Получите SSD, если /где вы можете. Используйте RAID и старайтесь максимально расширить возможности ввода-вывода.

Что все сказано, бросать аппаратное обеспечение в проблему не будет единственной частью исправления. Вам необходимо изолировать именно то, что вызывает чрезмерное использование ЦП, и затем атаковать эти проблемы независимо от того, на каком оборудовании вы находитесь.

Также см. этот вопрос StackOverflow для некоторых других идей:

https://stackoverflow.com /вопросы /945063 /, как-д-я-найти выход-что-это-ударной-мой-SQL-сервер

ответил Aaron Bertrand 14 J0000006Europe/Moscow 2013, 17:38:30
0

Следующие предложения - это «выстрел в темноте», потому что я не вижу фактического кода.

Во-первых, SP может открывать курсоры и оставлять их открытыми. Прочитайте курсоры, особенно Close и Deallocate. Кто-то может закрывать, но не освобождать курсоры. Поведение, возможно, изменилось из-за обновления, 2012 может относиться к остальным курсорам иначе, чем к 2008 R2.

Во-вторых, могут быть блокировки таблиц, которые не очищаются. Опять же, я на расстоянии, поэтому я не могу сказать, но он предположил бы, что кто-то создает глобальную временную таблицу после «начинающей транзакции», и либо «конечная транзакция» не выполняется, либо хранимая процедура не дает блокировки таблица занимает пространство в tempdb.

Используете ли вы WinLink? Что-то об этом звучит смутно знакомо.

ответил Meredith Poor 16 J0000006Europe/Moscow 2013, 02:32:00
-4

У вас должен быть механизм кэширования, подобный memcached, для повышения производительности

ответил 14 J0000006Europe/Moscow 2013, 16:34:18

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132