Поделиться через

  • Статья

Диагностика проблем регулятора ресурсов

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

  • ошибки;

  • непредвиденные результаты;

  • проблемы и ошибки, связанные с производительностью.

Ошибки регулятора ресурсов

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

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

Код ошибки

Сообщение об ошибке

Решение

8645

Истекло время ожидания ресурсов памяти для выполнения запроса в пуле ресурсов «myTestPool» (257). Повторите запрос.

Увеличьте пороговое значение времени ожидания запроса или уменьшите нагрузку по запросам на сервер.

8651

Не удалось выполнить операцию, поскольку в пуле ресурсов «myTestPool» (257) не оказалось требуемого для выделения объема памяти. Повторите запрос, уменьшите нагрузку по запросам или проверьте параметр конфигурации регулятора ресурсов.

Повторите запрос несколько позже. Уменьшите нагрузку по запросам на сервер. Обратитесь к администратору, чтобы проверить параметр конфигурации регулятора ресурсов.

8657

Не удалось получить объем выделения памяти 1024 КБ, поскольку эта величина превышает предел, заданный в конфигурации группы рабочей нагрузки «myTestGroup» (267) и пула ресурсов «myTestPool» (257). Обратитесь к администратору сервера, чтобы увеличить лимит используемой памяти.

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

Администратор может настроить один или оба следующих параметра:

  • max_memory_percent в пуле ресурсов, который устанавливает максимальный объем выделения физической памяти для всех запросов;

  • request_max_memory_grant_percent для групп рабочей нагрузки, который устанавливает лимит для каждого запроса.

Администратор может получить значение реального физического ограничения из столбца max_target_memory_kb таблицы sys.dm_exec_query_resource_semaphores.

Лимит для одного запроса можно вычислить следующим образом: max_target_memory_kb * request_max_memory_grant_percent.

ПримечаниеПримечание
Администратор должен проверить, что требуемая память, указанная в сообщении об ошибке, не превышает предел для одного запроса, вычисленный по приведенной выше формуле. Однако следует заметить, что при увеличении параметра request_max_memory_grant_percent возникает побочный эффект в виде уменьшения параллелизма при выполнении больших запросов. Например, при значении параметра по умолчанию, равном 25%, пользователи могут запускать одновременно три больших запроса, а при значении параметра 40% — только два.

10900

Не удалось настроить регулятор ресурсов при запуске. Проверьте наличие специальных сообщений об ошибках в журнале ошибок SQL Server или проверьте целостность базы данных master, выполнив инструкцию DBCC CHECKCATALOG('master').

Попробуйте выполнить инструкцию DBCC CHECKCATALOG('master').

10901

У пользователя отсутствует разрешение на изменение конфигурации регулятора ресурсов.

Предоставьте пользователю разрешение на изменение настроек регулятора ресурсов и попробуйте повторить операцию.

10902

Определяемая пользователем функция «dbo.rgclassifier_v1» не существует в базе данных master, либо у пользователя отсутствует разрешение на доступ к ней.

Создайте определяемую пользователем функцию-классификатор в базе данных master или предоставьте нужные разрешения существующей определяемой пользователем функции-классификатору.

10903

Указанное имя схемы «dbo» для определяемой пользователем функции-классификатора не существует, либо у пользователя отсутствует разрешение на доступ к ней.

Используйте другое имя схемы или получите нужные разрешения на эту схему.

10904

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

Отключите все активные сеансы в этих группах и повторите попытку.

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

10905

Не удалось завершить настройку регулятора ресурсов, поскольку не хватает памяти. Сократите нагрузку на сервер или повторите операцию, используя выделенное административное соединение.

Сократите нагрузку на сервер или повторите операцию настройки, используя выделенное административное соединение.

10906

Объект «dbo».«gclassifier_v1» не является допустимой определяемой пользователем функцией-классификатором регулятора ресурсов. Такая функция должна быть привязана к схеме, должна возвращать значение типа sysname и не должна иметь параметров.

Укажите допустимую определяемую пользователем функцию-классификатор. Допустимая определяемая пользователем функция-классификатор регулятора ресурсов:

  • должна возвращать значение типа sysname;

  • не должна иметь параметров;

  • должна быть создана с параметром SCHEMABINDING.

10907

Атрибут «MIN_CPU_PERCENT» имеет значение 50, что превышает значение атрибута «MAX_CPU_PERCENT», равное 40.

Задайте минимальное значение, меньшее или равное максимальному значению.

10908

Атрибут «MAX_MEMORY_PERCENT» имеет значение 40, что меньше значения атрибута «MIN_MEMORY_PERCENT», равного 60.

Задайте максимальное значение, большее или равное минимальному значению атрибута.

10909

Не удалось создать пул ресурсов. Максимальное количество пулов ресурсов, включая стандартные пулы ресурсов, не может превышать текущее предельное значение, равное 20.

Удалите пулы ресурсов, без которых можно обойтись.

10910

Не удалось завершить операцию. Применение указанного значения параметра «MIN_CPU_PERCENT», которое равно 25, приводит к тому, что сумма минимальных значений для всех пулов ресурсов превышает 100 процентов. Сократите это значение или измените параметры других пулов ресурсов, чтобы сумма минимальных значений составляла менее 100 процентов.

Уменьшите значение параметра MIN_CPU_PERCENT.

10911

Не удается выполнить запрошенную операцию, поскольку пул ресурсов «myTestPool2» не существует.

Запросите представление каталога sys.resource_governor_resource_pools, чтобы узнать, какие пулы ресурсов определены в данный момент. Выберите существующий пул или создайте новый.

10912

Не удалось завершить операцию. Удаление стандартной группы рабочей нагрузки не допускается.

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

10913

Пользователям не разрешается удалять группу рабочей нагрузки «internal» в пуле ресурсов «internal».

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

10914

Имя группы рабочей нагрузки «#mygroup» не может начинаться с # и ##.

Нельзя использовать символы # и ## при создании групп рабочей нагрузки и пулов.

10915

Не удалось завершить операцию. Изменение группы рабочей нагрузки «internal» не допускается.

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

Примечание.   Разрешается изменение конфигурации группы по умолчанию или пула ресурсов.

10916

Не удается удалить пул ресурсов «myTestPool», поскольку он содержит группу рабочей нагрузки «myTestGroup». Удалите все группы рабочей нагрузки, использующие этот пул ресурсов, перед удалением самого пула.

Удалите или переместите в другие пулы все группы рабочей нагрузки, использующие этот пул ресурсов, а затем удалите сам пул.

10917

Не удалось выполнить инструкцию ALTER WORKLOAD GROUP. Необходимо указать предложение «WITH» или предложение «USING».

В инструкции ALTER WORKLOAD GROUP должно присутствовать предложение «WITH» или предложение «USING».

10918

Не удается создать пул ресурсов «myTestPool», поскольку он уже существует.

Выберите другое имя пула ресурсов.

10919

При считывании конфигурации регулятора ресурсов из базы данных master произошла ошибка. Проверьте целостность базы данных master или обратитесь к системному администратору.

Попробуйте выполнить инструкцию DBCC CHECKCATALOG('master').

10920

Не удается удалить определяемую пользователем функцию-классификатор «dbo.myclassifer». Она используется в качестве функции-классификатора регулятора ресурсов.

Нет.

10921

Не удалось переместить группу рабочей нагрузки «default» из пула ресурсов «default».

Неприменимо.

10981

Конфигурация регулятора ресурсов изменена успешно.

Это сообщение записывается в журнал событий SQL Server.

10982

Не удалось запустить определяемую пользователем функцию-классификатор регулятора ресурсов. Подробности см. в предыдущих сообщениях журнала ошибок SQL Server для сеанса с идентификатором 58. Затрачено времени классификатором: 800 мс.

Это сообщение записывается в журнал ошибок SQL Server.

Примечание.   Предыдущие сообщения журнала ошибок SQL Server с тем же идентификатором серверного процесса (SPID) могут содержать указания на конкретные причины ошибки. Если выполнение классификатора продолжается достаточно долго, может истечь время ожидания входа пользователя. Проверьте, сколько времени прошло с момента запуска классификатора и не превышено ли время ожидания входа клиента.

10983

Изменение конфигурации регулятора ресурсов отменено пользователем.

Неприменимо.

10984

Ошибка изменения конфигурации регулятора ресурсов.

Неприменимо.

Непредвиденные результаты

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

Классификация сеансов

Сеансы классифицируются в группу рабочей нагрузки по умолчанию при выполнении следующих условий.

  • Определяемая пользователем функция-классификатор не существует или не включена.

  • Определяемая пользователем функция-классификатор помещает сеансы в группу рабочей нагрузки по умолчанию, что свидетельствует об ошибочной логике функции.

Устранение основных неполадок

Если определяемая пользователем функция-классификатор не работает, сеансы автоматически помещаются в группу рабочей нагрузки по умолчанию. После создания определяемой пользователем функции-классификатора нужно проверить, что она зарегистрирована в регуляторе ресурсов и что конфигурация, хранимая в памяти, обновлена.

Создание, регистрация и включение определяемой пользователем функции-классификатора представляет собой трехэтапный процесс.

  • Вначале нужно создать функцию.

    CREATE FUNCTION function_name() RETURNS <something> 
WITH SCHEMABINDING

  • Потом зарегистрировать ее в регуляторе ресурсов.

    ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION=schema_name.function_name)

  • Затем нужно обновить конфигурацию регулятора ресурсов, хранимую в памяти.

    ALTER RESOURCE GOVERNOR RECONFIGURE

При диагностике проблем классификатора нужно в первую очередь убедиться, что созданная функция зарегистрирована в регуляторе ресурсов и конфигурация регулятора ресурсов обновлена. С помощью следующего запроса можно получить имя схемы (schema_name) и имя функции-классификатора (function_name) для определяемой пользователем функции-классификатора, в настоящее время используемой регулятором ресурсов.

USE master
SELECT 
      object_schema_name(classifier_function_id) AS [schema_name],
      object_name(classifier_function_id) AS [function_name]
FROM sys.dm_resource_governor_configuration

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

Диагностика проблем повышенной сложности

Иногда созданная пользователем очень сложная функция-классификатор не дает ожидаемых результатов или чрезмерно интенсивно потребляет ресурсы. Если основные действия по устранению неполадок не дали результата, нужно проверить логику работы функции. В худшем варианте неправильная логика программы приведет к бесконечному циклу или выходу запроса из-под контроля.

Чтобы устранить неполадки неправильно написанной функции-классификатора, можно использовать выделенное административное соединение, поскольку оно не подлежит классификации и может использоваться, даже если регулятор ресурсов работает и выполняет классификацию входящих сеансов. Дополнительные сведения см. в разделе Использование выделенного административного соединения.

ПримечаниеПримечание

Если выделенное административное соединение недоступно для устранения неполадок, можно перезапустить систему в однопользовательском режиме. Хотя однопользовательский режим не подлежит классификации, нельзя выполнить диагностику классификации регулятора ресурсов, пока он работает.

Сведения о функции-классификаторе можно получить путем запроса к следующим объектам:

  • sys.dm_exec_query_stats. (содержит информацию об инструкциях, но не саму функцию);

  • sys.dm_exec_sql_text (используется совместно с объектом sql_handle, полученным с помощью запроса к sys.dm_exec_query_stats);

  • класс событий PreConnect:Starting (предоставляет идентификатор и имя функции-классификатора).

Не удается провести изменение конфигурации

Регулятор ресурсов не использует измененные метаданные при запуске сеансов, пока не завершит работу инструкция ALTER RESOURCE GOVERNOR RECONFIGURE. Выполнение инструкции ALTER RESOURCE GOVERNOR RECONFIGURE завершается неудачей в результате попытки удаления группы, содержащей активные или открытые сеансы, а также при попытке удаления пула ресурсов, содержащего группы рабочей нагрузки.

Чтобы получить конфигурацию, находящуюся в памяти, и хранимую конфигурацию, запросите соответственно sys.dm_resource_governor_configuration и sys.resource_governor_configuration. Значение 1 для свойства is_reconfiguration_pending (sys.dm_resource_governor_configuration) означает, что конфигурация сеанса не обновлена. В этом случае доступны следующие варианты действий.

  • Подождать, пока сеансы завершатся или в них будет разорвано соединение.

  • В явном виде остановить активный сеанс или разорвать соединение сеанса.

  • Создать повторно удаленную группу или пул, изменить их настройки и снова запустить инструкцию ALTER RESOURCE GOVERNOR RECONFIGURE.

Проблемы и ошибки, связанные с производительностью

Если при использовании регулятора ресурсов возникают проблемы производительности, нужно понять, связаны ли эти проблемы с конфигурацией регулятора ресурсов. Советы по диагностике, приведенные в этом разделе, разделяются на две категории:

  • классификация сеансов;

  • выполнение запроса.

Классификация сеансов

Если триггер входа или определяемая пользователем функция-классификатор работают в течение длительного времени, это может негативно сказаться на производительности сервера. Если триггер входа или определяемая пользователем функция-классификатор требует значительного времени на выполнение, то истекает время ожидания соединения. Однако триггер или функция продолжит работу, расходуя ресурсы сервера.

Если есть основание полагать, что некоторые сеансы работают в состоянии с установленным ранее соединением, то следует войти в систему через выделенное административное соединение и проверить класс событий Класс событий PreConnect:Starting, чтобы узнать, нет ли в системе множественных запросов или начатых и незавершенных сеансов.

Чтобы решить эту проблему и предотвратить ее повторение, нужно:

  • остановить сеансы;

  • выявить возможные причины слишком длительного выполнения функции или триггера входа;

  • удалить и заменить проблемный триггер или функцию.

Выполнение запроса

После классификации и выполнения запроса он может перестать отвечать (зависнуть) или завершиться ошибкой. Возможно, причиной проблемы являются текущие параметры регулятора ресурсов. Нужно рассмотреть следующие параметры настройки регулятора ресурсов.

  • Регулирование количества запросов.

  • Максимальная загрузка ЦП.

  • Регулирование пропускной способности ЦП.

  • Объем выделения памяти.

  • Ошибка, связанная с истечением времени ожидания при выделении памяти.

  • Ошибка, связанная с нехваткой памяти.

  • Неоптимальный план запроса.

Регулирование количества запросов

В этом случае пользователь сообщает о падении производительности, и есть основания полагать, что система регулирует количество запросов.

Сначала нужно проверить, настроено ли явным образом регулирование количества запросов для группы, к которой принадлежит пользователь. Это можно сделать, проверив членство пользователя в группе, чтобы узнать, включен ли параметр GROUP_MAX_REQUESTS. Если параметр GROUP_MAX_REQUESTS не включен, то явное регулирование числа запросов не выполняется. Следует продолжить исследование причин, выполнив следующие действия.

  • Выполнить запрос к объекту sys.dm_os_waiting_tasks с целью выяснения того, не имеются ли ожидающие запросы с типом ожидания RESMGR_THROTTLED. Если такие запросы есть, это значит, что регулирование количества запросов включено.

  • Запустите системный монитор и соберите данные с помощью счетчиков Запросы в очереди и Активные запросы. Если значение счетчика Запросы в очереди не равно нулю, это значит, что регулирование количества запросов включено.

  • Проверьте, соответствует ли значение счетчика Активные запросы значению параметра GROUP_MAX_REQUESTS. Если значение счетчика Активные запросы выше значения параметра GROUP_MAX_REQUESTS, значит, в группе могут быть запросы, не подлежащие регулированию (например, открытые транзакции).

  • Если значение счетчика Запросы в очереди равно нулю, проверьте значение счетчика Активные запросы для всех групп рабочей нагрузки, использующих один и тот же пул ресурсов, потому что этот пул может быть перегружен слишком большим количеством запросов.

Максимальная загрузка ЦП

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

В этой ситуации нужно решить, не слишком ли низко установлено пороговое значение загрузки ЦП (REQUEST_MAX_CPU_TIME_SEC), заданное для обнаружения запросов, чрезмерно загружающих ЦП.

Проверить настройку порогового значения загрузки ЦП можно при помощи следующих действий.

  • Запустите сеанс SQL-трассировки и соберите все события класса CPU Threshold Exceeded. Событие SQL-трассировки создается сервером автоматически, когда пользовательский запрос достигает порогового значения загрузки ЦП. Если для параметра установлено слишком низкое значение, будет создаваться большое количество таких событий.
ПримечаниеПримечание

Это событие также доступно в виде уведомления о событии сервера. Можно создать сценарий, который будет реагировать на это событие.
  • Запустите системный монитор и соберите данные с помощью счетчика Max request cpu time (ms). Значение этого счетчика можно использовать как ориентировочную величину при установке соответствующего порогового значения для группы рабочей нагрузки.

Регулирование пропускной способности ЦП

В данной ситуации существует подозрение, что система регулирует пропускную способность ЦП, потому что значение счетчика производительности CPU usage % сравнялось или почти сравнялось со значением параметра регулятора ресурсов MAX_CPU_PERCENT. Следующий запрос возвращает загрузку ЦП в процентах для всех групп рабочей нагрузки и пулов ресурсов экземпляра SQL Server.

select * from sys.dm_os_performance_counters where counter_name = 'cpu usage %'

Дополнительные сведения см. в разделе sys.dm_os_performance_counters (Transact-SQL).

Чтобы определить, происходит ли регулирование пропускной способности ЦП, нужно проверить следующие параметры системы.

  • Проверьте общий уровень загрузки ЦП сервера. Если на сервере в настоящий момент выполняются другие приложения помимо SQL Server, они могут мешать выполнению диагностируемого запроса.

  • Проверьте распределение ресурса ЦП среди пулов ресурсов. Пул ресурсов может подвергнуться регулированию, если у другого пула задано высокое минимальное значение загрузки ЦП. Сравните показатели ожидаемой (вычисляемой) загрузки ЦП с реальной загрузкой.

  • Проверьте все группы рабочей нагрузки, назначенные соответствующему пулу ресурсов. Нагрузка от других групп рабочей нагрузки может повлиять на работу пользователей того же пула ресурсов.

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

  • Возможно, рабочая нагрузка блокируется другими сеансами, а не подвергается регулированию под действием настроек регулятора ресурсов.

  • Проверьте число параллельных сеансов, в настоящее время выполняющих запросы в системе. По мере роста числа одновременных запросов на выполнение SQL Server пытается выделить каждому из них хотя бы минимальное количество времени ЦП, чтобы предотвратить нехватку ресурсов ЦП для данного запроса.

Объем выделения памяти

В этом случае есть подозрение, что медленное выполнение запроса обусловлено текущим размером выделяемой памяти.

Регулятор ресурсов обеспечивает соблюдение лимита памяти для запроса, снижая объем выделяемой памяти, чтобы большие запросы могли уложиться в лимит. Если запрос получает меньше 100% нужного объема выделенной памяти, может возникнуть необходимость сброса временных данных и записи их на диск, что заметно влияет на производительность.

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

  • Узнать текущее состояние выделения объемов памяти с помощью запроса к таблице sys.dm_exec_query_memory_grants. Значение столбца ideal_memory_kb показывает оптимальную величину, вычисленную на основе оценки количества элементов. Значение столбца requested_memory_kb показывает запрашиваемую величину, которая может быть уменьшена после достижения максимально допустимого количества запросов. Если значение requested_memory_kb существенно ниже значения ideal_memory_kb, запрос будет вынужден часто сбрасывать временные данные (исходя из предположения, что оценка количества элементов верна).

  • Запустите системный монитор и соберите данные с помощью счетчика Reduced memory grants/sec. Значение этого счетчика представляет собой относительное количество запросов на выделение памяти, которым выделено меньше оптимального объема из-за того, что максимальный объем выделенной памяти уже был достигнут ранее. Большие запросы могут выполняться намного медленнее тех, которые получают оптимальный объем памяти, потому что им приходится сбрасывать данные на диск, чтобы уложиться в предел выделяемой памяти.

Чтобы компенсировать проблему с выделением памяти, можно увеличить максимальный размер пула или максимальный объем выделения памяти.

ПримечаниеПримечание

Если будет увеличен только максимальный объем выделения памяти, это может привести к проблемам при параллельном выполнении нескольких больших запросов.

Ошибка, связанная с истечением времени ожидания при выделении памяти

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

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

Оптимальные параметры пула ресурсов можно определить при помощи следующих действий.

  • Выяснить количество операций выделения памяти и количество ожидающих запросов данной группы и данного пула с помощью запроса к таблице sys.dm_exec_query_memory_grants.

  • Узнать текущее состояние выделенных объемов памяти и целевые показатели с помощью запроса к таблице sys.dm_exec_query_resource_semaphores.

Если потребность в выделенной памяти превышает доступный объем, можно рассмотреть возможность повышения максимального размера пула ресурсов.

Ошибки, связанные с нехваткой памяти

Выполнение запроса завершается ошибкой из-за недостатка памяти.

Устранение основных неполадок

Определить оптимальные параметры для группы рабочей нагрузки можно при помощи следующих действий.

  • Получить информацию об относительном распределении памяти и трендах пула ресурсов с помощью запроса к таблице sys.dm_os_memory_brokers. Слишком большое количество запросов в небольшом объеме памяти может привести к перегрузке пула ресурсов или группы рабочей нагрузки и вызвать ошибки нехватки памяти.

  • Запустите системный монитор и с помощью счетчиков, имеющих отношение к пулу ресурсов памяти, соберите данные о целевой и реальной загрузке памяти для выделенных объемов памяти, памяти кэша и памяти компилятора/оптимизатора. Если текущие значения выше целевых, значит пул ресурсов перегружен. Рассмотрите возможность повышения лимитов памяти пула.

  • Запустите системный монитор и соберите данные с помощью счетчика request max memory grant. Если значение счетчика выше значения параметра REQUEST_MAX_MEMORY_GRANT_PERCENT группы рабочей нагрузки, то запрос, скорее всего, завершится ошибкой. Рассмотрите возможность повышения лимитов памяти для группы рабочей нагрузки.

Диагностика проблем повышенной сложности

Ошибка «Нехватка памяти» (701) представляет собой стандартную ошибку, возвращаемую, если в каких-то задачах попытка выделить блок памяти через диспетчер памяти завершается неудачей. Дополнительные сведения см. в разделе MSSQLSERVER_701.

Эта ошибка может быть вызвана одним из следующих условий.

  • Пул памяти достиг своего общего предельного размера.
ПримечаниеПримечание

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

  • Выделение многостраничного или виртуального адресного пространства завершается неудачей, потому что в виртуальном адресном пространстве нет свободного блока нужной величины. Это часто случается в системах с 32-разрядной архитектурой и маловероятно для системы с 64-разрядной архитектурой.

  • Выделение многостраничного или виртуального адресного пространства завершается неудачей, потому что общий объем выделенной памяти в системе достигает предела выделенной виртуальной памяти. Это возможно в системах и с 32-разрядной архитектурой, и с 64-разрядной архитектурой.

При возникновении ошибки нехватки памяти лучше всего начинать диагностику с журнала ошибок. Журнал содержит сообщения примерно следующего вида:

2006-01-28 04:27:15.43 spid51 Не удалось выделить страницы: FAIL_PAGE_ALLOCATION 1

Возможные сообщения, занесенные в журнал ошибок, следующие.

  • FAIL_PAGE_ALLOCATION, а затем количество страниц, по отношению к которым была предпринята попытка распределения.

  • FAIL_VIRTUAL_RESERVE, а затем число байтов, по отношению к которым была предпринята попытка резервирования.

  • FAIL_VIRTUAL_COMMIT, а затем число байтов, по отношению к которым была предпринята попытка фиксации.

Важно понимать, что задача, которая вызвала появление ошибки нехватки памяти, и задача, которая является первопричиной ошибки, часто бывают разными. Если речь не идет о вышедшем из-под контроля запросе, ошибка нехватки памяти обычно является результатом одновременного выполнения нескольких задач. В результате при изучении причин обычной с виду ошибки FAIL_PAGE_ALLOCATION часто приходится рассматривать работу системы в более широком плане.

Следующим важным источником информации, которая содержится в журнале ошибок, является состояние памяти. В зависимости от конкретной ошибки необходимо проверять относящиеся к конкретным клеркам памяти количественные значения по одностраничным и многостраничным операциям, операциям виртуального резервирования или фиксации. Далее в процессе диагностики важно определить объекты или процессы, расходующие больше всего памяти. Обычно больше всего требовательны к памяти следующие объекты или процессы.

  • Параметр MEMORYCLERK_* означает, что конфигурация сервера или рабочая нагрузка требует определенного выделения памяти. Компонентам SQL Server соответствуют свои клерки памяти, и отдельные компоненты могут иметь несколько клерков памяти. Дополнительные сведения см. в разделе sys.dm_os_memory_clerks. Иногда по данным клерков памяти можно выяснить, какая рабочая нагрузка вызывает проблему. Но чаще всего приходится исследовать объекты памяти, связанные с клерками, для выяснения того, чем вызвано потребление больших объемов памяти.

  • CACHESTORE_*, USERSTORE_*, OBJECTSTORE_* представляют собой типы кэшей. Если кэш потребляет большое количество памяти, это может означать следующее.

    • Память в кэше выделена, но еще не вставлена в виде записи, которую можно удалить из кэша. Это очень похоже на описанную выше ситуацию с объектом MEMORYCLERK.

    • Все записи кэша используются, так что ни одну из них нельзя удалить. Это можно выяснить, посмотрев на счетчики sys.dm_os_memory_cache_counters и сравнив значения столбцов entries_count и entries_in_use_count.

  • Параметр MEMORYCLERK_SQLQERESERVATIONS показывает, сколько памяти зарезервировано выполнением запроса для запуска запросов с сортировкой или соединением. Если этот показатель высок и при этом возникает ошибка нехватки памяти, это обычно служит признаком программной ошибки в сервере.

Показатель состояния памяти в журнале ошибок также указывает, какой именно пул памяти исчерпан. Брокеры памяти для каждого пула показывают распределение памяти между заимствованной (компиляция), кэшированной и зарезервированной (выделенной) памятью. Показатели для трех брокеров соответствуют предыдущим объектам памяти, связанным с клерками памяти. Можно узнать, сколько памяти выделено данному пулу с помощью данного клерка или объекта памяти, получив информацию из полного дампа с помощью пользовательского сценария, а динамическое административное представление sys.dm_os_memory_cache_entries показывает идентификатор пула pool_id, с которым связана каждая запись.

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

  • Журнал ошибок, в котором показана ошибка нехватки памяти и вывод состояния памяти на момент ошибки.

  • Вывод следующих инструкций:

    dbcc memorystatus
dbcc sqlperf(spinlockstats)
select * from sys.dm_os_memory_clerks
select * from sys.dm_os_wait_stats order by wait_type
select * from sys.dm_os_waiting_tasks
select * from sys.dm_os_ring_buffers where ring_buffer_type='RING_BUFFER_OOM'
select * from sys.dm_os_ring_buffers where ring_buffer_type='RING_BUFFER_RESOURCE_MONITOR'
select * from sys.dm_os_ring_buffers where ring_buffer_type='RING_BUFFER_MEMORY_BROKER'
select * from sys.dm_os_memory_cache_clock_hands

  • По возможности, дамп системы, вызванный нехваткой памяти и собранный с помощью устройства T8004. Этот минидамп содержит ценную информацию, такую как статистические показатели кольцевых буферов, а также спин-блокировок и (или) ожидания. Счетчик дампа для устройства T8004 можно сбросить, не перезапуская сервер, если выключить T8004 и снова включить.

Неоптимальный план запроса

Существует подозрение, что запрос выполняется медленно, потому что относящийся к нему план запроса не оптимален. Оптимизатор запросов может создать неоптимальный план запроса, если получит недостаточно памяти из-за низкого максимального объема памяти, выделенного в настройках пулу ресурсов.

Оптимальные параметры пула ресурсов можно определить при помощи следующих действий.

  • Определить, компилируется ли для данной группы рабочей нагрузки большое количество запросов, по счетчику Query optimizations/sec.

  • Определить, часто ли оптимизатор запросов создает неоптимальные планы, по счетчику Suboptimal plans/sec.

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