Рекомендований розмір файлу сторінки для SQL 2008R2 для Windows 2008R2

Ця стаття Microsoft - Як визначити відповідний розмір файлу сторінки для 64-розрядних версій Windows Server 2008 та / або Windows 2008 R2, надає вказівки щодо обчислення розміру файлу сторінки для 64-бітних Windows 2008 та Windows 2008R2. Це, без сумніву, добре працює для серверів загального призначення. Мені цікаво, які вказівки стосуються SQL Server 2008R2, який працює на Windows 2008 / R2 64 біт?

Я припускаю, що ми хочемо, щоб як мінімум даних пам'яті потрапляло у файл сторінки, інакше SQL може двічі потрапляти на диск. Чи допускає навіть SQL Server дані в пам'яті для потрапляння у файл сторінки? Я полював через SQL Server 2008 R2 Books Online для ознайомлення, але поки не знайшов жодної згадки про використання файлів сторінки.

Ось потенційний сценарій використання: Враховуючи фізичний сервер із 64 ГБ оперативної пам’яті, чи потрібний файл сторінки для всіх 64 Гб оперативної пам’яті? Чи повинні ми забезпечити його на 96 ГБ файлу сторінок? Це здається трохи надмірним для одного файлу. Я знаю, що загальноприйнята мудрість полягала в тому, що Windows париє файли сторінки в пам'ять, намагаючись полегшити заміну програм на оперативній пам’яті, але це правда? Чи буде тут заважати файлам сторінок менше 64 Гб?

Не існує спеціальних налаштувань для SQL Server, який нормально використовує лише фізичну пам'ять

Просто робіть те, що кажуть MS для Windows, і все

О, і купуйте більше оперативної пам’яті все одно, поки ми один предмет ... ;-)

Загляньте lock pages in memory. Таким чином, ви можете надати перевагу для свого облікового запису служби SQL використовувати доступну оперативну пам’ять, а не підключення до диска. Щоб прочитати більше на блокованих сторінках пам'яті, перевірте це посилання . Наступний фрагмент:

Параметр "Блокування сторінок у пам'яті" для політики Windows за замовчуванням вимкнено. Цей привілей повинен бути включений для налаштування розширень віконних адрес (AWE). Ця політика визначає, які облікові записи можуть використовувати процес для збереження даних у фізичній пам'яті, не даючи системі передати дані на віртуальну пам'ять на диску. У 32-бітних операційних системах встановлення цього привілею, коли не використовується AWE, може істотно погіршити продуктивність системи. Блокування сторінок у пам'яті не потрібно в 64-бітних операційних системах.

Перевірте цю функцію перед використанням у ваших системах.

Так, для 64 ГБ оперативної пам’яті вам потрібно принаймні 64 ГБ файлу підкачки (рекомендується 96 ГБ). Не через можливі заміни, а через дизайн Менеджера пам'яті Windows. Я писав про цю проблему раніше в розмірі файлу системних сторінок на машинах з великою оперативною пам’яттю :

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

Коли відбувається пам'ять, виділяються фізичні сторінки пам'яті та залишається місце у файлі сторінки.

Альтернативою було б щось на кшталт oom_killer .

Отож, дотримуйтесь рекомендації, іноді речі є дещо складнішими, ніж вони виглядають. І я навіть не торкнувся ускладнень AWE та привілей заблокованих сторінок ...