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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

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

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

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

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

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