Подходящий размер файла подкачки Windows O / S для SQL Server - PullRequest
16 голосов
/ 05 августа 2008

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

Ответы [ 8 ]

12 голосов
/ 06 октября 2011

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

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

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

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

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

10 голосов
/ 23 ноября 2009

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

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

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

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

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

3 голосов
/ 03 августа 2010

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

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

2 голосов
/ 10 сентября 2009

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

2 голосов
/ 23 декабря 2008

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

1 голос
/ 24 мая 2011

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

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

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

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

1 голос
/ 11 августа 2008

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

0 голосов
/ 04 апреля 2014

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

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...