В этом случае нормальная рекомендация в 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 врастать в файл подкачки в этой ситуации может избавить от сообщений об ошибках, но это контрпродуктивно, поскольку ранее указывалось на причину кеша данных.