Подходящий размер файла подкачки операционной системы Windows для SQL Server

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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

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

Answer 8

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

Для серверов, работающих под управлением SQL Server (обычно с очень большим объемом оперативной памяти), большая часть физической оперативной памяти выделена процессу SQL Server и должна быть (при правильной настройке) заблокирована в физической памяти, предотвращая ее выгрузку в файл подкачки.SQL Server очень тщательно управляет своей собственной памятью с учетом производительности, используя большую часть оперативной памяти, выделенной его процессу, в качестве кэша данных для сокращения дисковых операций ввода-вывода.Нет смысла выводить эти страницы кэша данных в файл подкачки, поскольку единственной целью хранения этих данных в оперативной памяти в первую очередь является сокращение дискового ввода-вывода.(Обратите внимание, что ОПЕРАЦИОННАЯ система Windows также использует доступную оперативную память аналогично дисковому кэшу для ускорения работы системы.) Поскольку SQL Server уже управляет своим собственным пространством памяти, это пространство памяти не следует считать "доступным для просмотра страниц" и не включать в расчет размера файла подкачки.

Что касается MEM_COMMIT, упомянутого Remus, терминология сбивает с толку, потому что на языке виртуальной памяти "зарезервировано" никогда не относится к фактическому распределению, а к предотвращению использования адресного пространства (не физического пространства) другим процессом.Память, доступная для "фиксации", в основном равна сумме физической оперативной памяти и размера файла подкачки, и выполнение MEM_COMMIT просто уменьшает объем, доступный в фиксированном пуле.Это так и есть нет выделите соответствующую страницу в файле подкачки в это время.Когда зафиксированная страница памяти фактически записана, то есть когда система виртуальной памяти выделит страницу физической памяти и, возможно, перенесет другую страницу памяти из физической оперативной памяти в файл подкачки.Смотрите MSDN's Функция VirtualAlloc ссылка.

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

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

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