Как разрешить RESOURCE_SEMAPHORE и RESOURCE_SEMAPHORE_QUERY_COMPILE типы ожидания

13

Мы пытаемся выяснить основную причину медленного выполнения запросов к серверу sql, попадающих / извлекающих данные из одной из баз данных, размером 300 ГБ, размещенной на сервере со следующей конфигурацией:

Windows Server 2003 R2, SP2, Enterprise Edition, 16 ГБ оперативной памяти, 12-битный процессор 32

SQL Server 2005, SP4, Enterprise Edition, 32-разрядная.

Мы уже сообщили бизнесу о переходе на 64-разрядную версию, которая займет более месяца.

Но что касается текущей проблемы, мы пытаемся собрать данные, если сможем решить проблему нехватки памяти или, наконец, придем к выводу об увеличении ОЗУ.

Действие выполнено: Переиндексация и обновление статистики подходят для этой БД.

Как показано ниже, мы замечали тип ожидания семафора в течение последних 5 дней, запускаемых в часы загрузки:

waittype

Немного информации после запросов ниже: размер буфера = 137272

SELECT SUM(virtual_memory_committed_kb)
FROM sys.dm_os_memory_clerks
WHERE type='MEMORYCLERK_SQLBUFFERPOOL'

и семафорная память = 644024 на запрос ниже

 SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores

Ниже еще информация собрана из dm_exec_query_resource_semaphoresи sys.dm_exec_query_memory_grantsDMV годов

dmvserror

Таким образом, из вышеприведенной информации, собранной в соответствии с данными SP_Blitz, семафор ресурса, кажется, является проблемой.

Память 'target_memory_kb', выделенная для идентификатора семафора ресурса, слишком мала по сравнению с 16 ГБ доступной оперативной памяти.

Примечание * на анализ за 8 часов работы 'target_memory_kb' всегда меньше 1 ГБ по сравнению с 16 ГБ?

что может быть проблема здесь и как решить, пожалуйста, предложите

Благодарность

KASQLDBA
источник
Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат . Дальнейшие не по теме комментарии будут просто удалены.
Пол Уайт 9

Ответы:

25

О боже, у меня здесь плохие новости.

В 32-разрядной ОС SQL Server использует только первые 4 ГБ памяти для таких вещей, как рабочее пространство запросов. (И он борется с ОС за эти 4 ГБ тоже - любые другие работающие приложения также будут бороться за эту память.)

4ГБ может звучать как много, но относительно легко написать запрос, для работы которого требуется несколько ГБ памяти. Когда достаточное количество запросов требует достаточно памяти, SQL Server выдает RESOURCE_SEMAPHORE, ожидая, потому что запросы не могут получить достаточно памяти для запуска. RESOURCE_SEMAPHORE_QUERY_COMPILE означает, что они даже не могут получить достаточно памяти для составления плана выполнения - и да, это довольно плохо.

Так как же это исправить?

  • Переключитесь на 64-битную ОС (операционная система, которую вы используете, в любом случае давно не поддерживается)
  • Переключиться на 64-битную сборку SQL Server
  • Уменьшите требования к памяти на сервере (не запускайте никакие другие приложения на этом боксе, а это особенно важно для 32-битных боксов, поскольку мы ограничены всего 4 ГБ)
  • Используйте больше памяти с переключателями AWE / PAE - за исключением того, что это не работает для ожиданий RESOURCE_SEMAPHORE, потому что SQL Server может использовать только эти первые 4 ГБ для рабочей области запроса
  • Настройте запросы и индексы, чтобы им требовалось меньше памяти

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

Брент Озар
источник