Поддержка и разрешение проблем процессорной архитектуры NUMA в SQL Server 2005
Страница 4. Разрешение проблем, связанных с работой SQL Server на платформе с архитектурой NUMA

Разрешение проблем, связанных с работой SQL Server на платформе с архитектурой NUMA

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

Это самая распространённая проблема. Основной её причиной является истощение памяти во время исполнения запроса на узле, которое могло произойти по нескольким причинам:

1. Узел 0 создаёт проблемы, т.к. вся память этого узла использована во время запуска операционной системы. Возможное решение этой проблемы состоит в том, чтобы изменить для SQL Server маску affinity так, что бы узел 0 работал автономно, т.е. не использовался для нужд СУБД.
2. Проблемы создаёт узел N, т.к. вся память этого узла использована другими приложениями или кэшем файловой системы (также см. ниже Misconfigured System File Cache). Вы можете поискать пути разрешения этой проблемы анализируя размер SFC и потребление памяти другими приложениями, а также объем памяти, используемый SQL Server на каждом узле, исполнив команду dbcc memorystatus. Возможное решение этой проблемы состоит в том, чтобы успеть захватить всю память для SQL Server перед запуском других приложений. Вы можете добиться этого, используя: max server memory, динамическое планирование и клиентское affinity. Идея решения в том, что нужно запустить первый узел, одновременно подключаясь к узлу и нагружая его работой, чтобы память для узла была распределена. Потом запустить следующий узел, нагрузить его, обеспечить распределение памяти и так далее. В довершение ко всему, сделайте минимальный и максимальный объёмы памяти одинакового размера, чтобы SQL Server не сокращал объём памяти при загрузке. Ниже представлена последовательность шагов, которые необходимо для этого предпринять:
   1. Настройте SQL Server для работы с множеством узлов и с портом для каждого узла.
   2. Настройте клиентов для каждого узла.
   3. Подготовьте большой запрос, например, переиндексацию, который будет потреблять не менее DesirableMemory/#Nodes памяти (желательной для работы СУБД объём памяти) и будет выступать в роли рабочей нагрузки.
   4. Запустите SQL Server.
   5. Переведите все узлы кроме узла 0 в автономное состояние, используя для этого sp_configure.
   6. Установить "max server memory" равным DesirableMemory/#Nodes, также используя sp_configure.
   7. Подключитесь к узлу 0.
   8. Запустите на него рабочую нагрузку.
   9. Увеличение "max server memory" на величину DesirableMaxMemory/#Nodes, используя sp_configure.
   10. Сделайте активным следующий узел, используя для этого sp_configure.
   11. Повторите пункты 7-10 для оставшихся узлов.
   12. Установить "max server memory" = "min server memory" = DesirableMaxMemory.
3. Проблема: Misconfigured System File Cache. Эта проблема связана с проблемой, описанной в пункте B. Если FSC неправильно настроен, он может поглотить всю память сервера. Вы можете проверить наличие этой проблемы, посмотрев на размер FSC через Диспетчер Задач или через Системный Монитор. Устранить проблему можно перейдя к: "My Computer"-> "Properties"->"Advanced"->"Performance Settings"-> "Advanced"->"Memory Usage Programs" ->"Ok" и перезагрузить сервер, если Вы изменили выбор установки приоритета использования памяти с системного кэша на программы. Проблема может возникать у приложений даже в том случае, если система настроена так, как только что было показано, т.е. приоритет памяти для программ, но кэш файловой системы по-прежнему может потреблять очень много памяти. Если это происходит, можно написать специальную утилиту, которая будет периодически урезать размер кэша файловой системы.