My<cod/>.net
Соответствующий размер файла подкачки Windows O/S для сервера SQL
Знает ли кто-нибудь хорошее эмпирическое правило для соответствующего размера файла подкачки для сервера Windows 2003 под управлением сервера SQL?
При всем моем уважении к Ремусу (которого я очень уважаю), я категорически не согласен. Если ваш файл подкачки достаточно велик, чтобы поддерживать полный дамп, он будет выполнять полный дамп каждый раз. Если у вас есть очень большое количество RAM, это может привести к тому, что крошечная вспышка станет серьезным отключением.
Вы не NOT хотите, чтобы ваш сервер должен был записать 1 TB из RAM на диск, если есть одноразовая временная проблема. Если возникает повторяющаяся проблема, можно увеличить размер файла подкачки, чтобы получить полный дамп. Я бы подождал, чтобы сделать это, пока вы не были уничтожены PSS (или кто-то другой, квалифицированный для анализа полного дампа) запросит вас захватить полный дамп. Очень маленький процент DBAs знает, как анализировать полный дамп. Мини-дамп достаточен для устранения большинства проблем, которые так или иначе всплывают.
Кроме того, если ваш сервер настроен на разрешение полного дампа 1 TB и возникает повторяющаяся проблема, сколько свободного места на диске вы бы рекомендовали иметь под рукой? Вы могли бы заполнить весь SAN за один уик-энд.
Файл подкачки 1.5*RAM был нормой еще в те времена, когда вам повезло иметь сервер SQL с 3 или 4 GB из RAM. Это уже не тот случай. Я оставляю файл подкачки с размером Windows по умолчанию и настройками на всех производственных серверах (за исключением сервера SSAS, испытывающего нехватку памяти).
И просто для уточнения, я работал с серверами в диапазоне от 2 GB из RAM до 2 TB из RAM. После более чем 11 лет мне пришлось только один раз увеличить файл подкачки, чтобы захватить полный дамп.
Независимо от размера RAM, вам все равно нужен файл подкачки по крайней мере в 1.5 раз больше физического RAM. Это верно, даже если у вас есть машина 1 TB RAM, вам понадобится 1.5 TB pagefile на диске (звучит безумно, но это правда).
Когда процесс запрашивает MEM_COMMIT memory через VirtualAlloc/VirtualAllocEx,, запрошенный размер должен быть зарезервирован в файле подкачки. Это было верно в первой системе Win NT, и до сих пор верно сегодня смотрите управление виртуальной памятью в Win32 :
Когда память зафиксирована, физическая выделяются страницы памяти и в файле подкачки зарезервировано место .
В некоторых крайних нечетных случаях сервер SQL всегда будет запрашивать страницы MEM_COMMIT. И учитывая тот факт, что SQL использует динамическую политику управления памятью , которая резервирует заранее как можно больше буферного пула (резервирует и фиксирует в терминах VAS), SQL сервер запросит при запуске огромное резервирование места в файле подкачки. Если файл подкачки не имеет правильного размера, ошибки 801/802 начнут появляться в файле SQL и операциях ERRORLOG.
Это всегда вызывает некоторую путаницу, так как администраторы ошибочно полагают, что большой RAM устраняет необходимость в файле подкачки. На самом деле происходит наоборот, большой RAM увеличивает потребность в файле подкачки, просто из-за внутренней работы диспетчера памяти Windows NT. Зарезервированный файл подкачки, надеюсь, никогда не используется.
По словам Microsoft, " по мере увеличения количества RAM в компьютере потребность в файле подкачки уменьшается. Далее в статье описывается, как использовать журналы производительности для определения того, какая часть файла подкачки фактически используется. Для начала попробуйте установить файл подкачки в системную память 1.5X, затем выполните рекомендуемый мониторинг и внесите необходимые изменения.
Как определить соответствующий размер файла подкачки для 64-разрядных версий Windows
Недавно у нас возникли некоторые проблемы с производительностью с одним из наших серверов SQL, которые мы не смогли полностью сузить, и фактически использовали один из наших билетов поддержки Microsoft, чтобы помочь им устранить неполадки. Был выбран оптимальный размер файла подкачки для использования с сервером SQL, и Microsoft рекомендует, чтобы он был в 1 1/2 раза больше размера RAM .
Чем больше, тем лучше до размера рабочего набора приложения, где вы начнете получать убывающие доходы. Вы можете попытаться найти это, медленно увеличивая или уменьшая размер, пока не увидите значительное изменение в скорости попадания в кэш. Однако, если скорость попадания в кэш превышает 90% или около того, вы, вероятно, OK. Как правило, вы должны следить за этим в производственной системе, чтобы убедиться, что она не переросла свое распределение RAM.
После долгих исследований наши выделенные серверы SQL под управлением Enterprise x64 на Windows 2003 Enterprise x64 не имеют файла подкачки.
Просто файл подкачки-это кэш для файлов, которым управляет OS, а SQL имеет свою собственную систему управления внутренней памятью.
В статье MS, на которую ссылаются, не указано, что этот совет предназначен для OS запущенных out-of-the-box служб, таких как общий доступ к файлам.
Наличие файла подкачки просто обременяет дисковый ввод-вывод, потому что Windows пытается помочь, когда только ОС SQL может выполнить эту работу.
В этом случае нормальная рекомендация 1.5 раз общего физического RAM не является лучшей. Эта очень общая рекомендация предоставляется в предположении, что вся память используется процессами "normal", которые обычно могут перемещать свои наименее используемые страницы на диск, не создавая больших проблем с производительностью для процесса приложения, которому принадлежит память.
Для серверов под управлением SQL Server (как правило, с очень большими объемами RAM) большая часть физического RAM фиксируется в процессе SQL Server и должна быть (если она настроена правильно) заблокирована в физической памяти, предотвращая ее выгрузку в файл подкачки. SQL сервер очень тщательно управляет своей собственной памятью с учетом производительности, используя большую часть RAM, выделенную для его процесса в качестве кэша данных, чтобы уменьшить диск I/O. нет смысла выводить эти страницы кэша данных на экран. pagefile, поскольку единственной целью наличия этих данных в RAM в первую очередь является сокращение дискового I/O. (обратите внимание, что Windows OS также использует доступный RAM аналогично дисковому кэшу для ускорения работы системы.) Поскольку сервер SQL уже управляет своим собственным пространством памяти, это пространство памяти не должно рассматриваться как "pageable" и не должно включаться в расчет размера файла подкачки.
Что касается MEM_COMMIT, упомянутого Ремусом, то эта терминология вызывает путаницу, поскольку на языке виртуальной памяти "reserved" никогда не относится к фактическому распределению, а к предотвращению использования адресного пространства (не физического пространства) другим процессом. Память, доступная для "committed", в основном равна сумме физического RAM и размера файла подкачки, и выполнение MEM_COMMIT просто уменьшает объем, доступный в фиксированном пуле. В это время он не выделяет соответствующую страницу в файле подкачки. Когда фиксированная страница памяти фактически записывается, то есть когда система виртуальной памяти выделит физическую страницу памяти и, возможно, переместит другую страницу памяти из физического RAM в файл подкачки. Смотрите ссылку на функцию MSDN VirtualAlloc .
Windows OS отслеживает давление памяти между процессами приложения и его собственным механизмом дискового кэша и решает, когда он должен переместить незащищенные страницы памяти из физического файла в файл подкачки. Я понимаю, что наличие файла подкачки, который слишком велик по сравнению с фактическим незащищенным пространством памяти, может привести к тому, что Windows чрезмерно усердно подкачивает память приложения к файлу подкачки, в результате чего эти приложения страдают от последствий пропусков страниц (медленная производительность).
Пока на сервере не запущены другие процессы, требующие много памяти, размер файла подкачки в 4 ГБ должен быть достаточным. Если вы настроили сервер SQL для разрешения блокировки страниц в памяти, то следует также рассмотреть возможность установки параметра max memory сервера SQL таким образом, чтобы он оставил некоторые физические RAM доступными для OS для себя и других процессов.
802 ошибки в SQL сервере указывают на то, что система не может зафиксировать больше страниц для кэша данных. Увеличение размера файла подкачки поможет в этой ситуации только в том случае, если Windows способен выводить страницы памяти из процессов сервера, не являющихся SQL. Разрешение SQL памяти сервера расти в файл подкачки в этой ситуации может привести к избавлению от сообщений об ошибках, но это контрпродуктивно, поскольку ранее было указано, что причина кэша данных в первую очередь.