Соответствующий размер файла подкачки ОС Windows для SQL Server

Кто-нибудь знает хорошее эмпирическое правило для соответствующего размера файла подкачки для сервера Windows 2003, на котором работает SQL Server?

Ответов (8)

Решение

Независимо от размера ОЗУ, вам все равно нужен файл подкачки, по крайней мере, в 1,5 раза превышающий объем физической ОЗУ. Это верно, даже если у вас есть машина с ОЗУ 1 ТБ, вам понадобится файл подкачки 1,5 ТБ на диске (звучит безумно, но это правда).

Когда процесс запрашивает память MEM_COMMIT через VirtualAlloc / VirtualAllocEx, запрошенный размер должен быть зарезервирован в файле подкачки. Это было верно в первой системе Win NT, и актуально и сегодня, см. Управление виртуальной памятью в Win32 :

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

В некоторых крайних странных случаях SQL Server всегда запрашивает страницы MEM_COMMIT. А учитывая тот факт, что SQL использует политику динамического управления памятью, которая заранее резервирует максимально возможный буферный пул (резервирует и фиксирует в терминах VAS), SQL Server при запуске запрашивает огромное резервирование места в файле подкачки. Если размер файла подкачки имеет неправильный размер, ошибки 801/802 начнут появляться в файле ERRORLOG SQL и операциях.

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

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

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

Недавно у нас возникли некоторые проблемы с производительностью с одним из наших SQL Server, которые мы не смогли полностью сузить, и фактически использовали один из наших билетов в службу поддержки Microsoft, чтобы они помогли устранить неполадки. Подобрался оптимальный размер файла подкачки для использования с SQL Server, и Microsoft рекомендует, чтобы он в 1,5 раза превышал объем оперативной памяти .

В этом случае обычная рекомендация увеличения общего объема физической ОЗУ в 1,5 раза не самая лучшая. Эта очень общая рекомендация дается в предположении, что вся память используется «нормальными» процессами, которые, как правило, могут перемещать наименее используемые страницы на диск, не создавая серьезных проблем с производительностью для процесса приложения, которому принадлежит память.

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

Что касается MEM_COMMIT, упомянутого Ремусом, терминология сбивает с толку, потому что на языке виртуальной памяти «зарезервировано» никогда не относится к фактическому распределению, а относится к предотвращению использования адресного пространства (не физического пространства) другим процессом. Память, доступная для "фиксации", в основном равна сумме физического ОЗУ и размера файла подкачки, а выполнение MEM_COMMIT просто уменьшает количество, доступное в выделенном пуле. В это время он не выделяет соответствующую страницу в файле подкачки. Когда на самом деле записывается зафиксированная страница памяти, то есть когда система виртуальной памяти выделяет страницу физической памяти и, возможно, переносит другую страницу памяти из физической ОЗУ в файл подкачки. См. Справку по функциям VirtualAlloc в MSDN .

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

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

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

Согласно Microsoft, «по мере увеличения объема оперативной памяти компьютера потребность в файле подкачки уменьшается». Затем в статье описывается, как использовать журналы производительности, чтобы определить, какая часть файла подкачки фактически используется. Для начала попробуйте установить для файла подкачки значение 1,5X системной памяти, затем выполните рекомендуемый мониторинг и внесите изменения оттуда.

Как определить подходящий размер файла подкачки для 64-битных версий Windows

После долгих исследований наши выделенные серверы SQL, работающие под управлением Enterprise x64 на Windows 2003 Enterprise x64, не имеют файла подкачки.

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

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

Наличие файла подкачки просто обременяет дисковый ввод-вывод, потому что Windows пытается помочь, когда только ОС SQL может выполнять эту работу.

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

Вы НЕ хотите, чтобы вашему серверу приходилось записывать 1 ТБ ОЗУ на диск, если возникает разовая временная проблема. Если возникает повторяющаяся проблема, вы можете увеличить файл подкачки, чтобы получить полный дамп. Я бы подождал, чтобы сделать это, пока PSS (или кто-то другой, имеющий право анализировать полный дамп) не попросит вас записать полный дамп. Чрезвычайно небольшой процент администраторов баз данных умеет анализировать полный дамп. Мини-дампа достаточно для устранения большинства возникающих проблем.

Кроме того, если ваш сервер настроен на полный дамп размером 1 ТБ и возникает повторяющаяся проблема, сколько свободного места на диске вы бы порекомендовали иметь под рукой? Вы можете заполнить всю сеть SAN за один уик-энд.

Файл подкачки 1,5 * ОЗУ был нормой в те дни, когда вам повезло иметь SQL Server с 3 или 4 ГБ ОЗУ. Это уже не так. Я оставляю файл подкачки с размером и настройками по умолчанию Windows на всех производственных серверах (за исключением сервера SSAS, который испытывает нехватку памяти).

И просто для пояснения, я работал с серверами с объемом оперативной памяти от 2 ГБ до 2 ТБ. По прошествии более чем 11 лет мне достаточно было увеличить размер файла подкачки, чтобы получить полный дамп один раз.