Статьи, в которых предлагалось выносить tempDB в ram-диск уже были на Infostart (//infostart.ru/public/330256/).
В данной мне хотелось рассказать более подробно об опыте подобной настройки на системах, работающих 24/7.
Для начала посмотрим на метрики, какой же прирост производительности может быть получен от использования RAM-диска.
Безусловно, данный тест является синтетическим и не отражает реальный профит(который будет ниже), но разница в цифрах является весьма показательной.
При использовании RAM-диска у нас всегда будет возникать одна проблема - что будет, если размер tempDB выйдет за пределы RAM-диска?
Эта проблема решается весьма просто - MSSQL позволяет создавать дополнительные файлы данных и логов, в том числе для tempDB.
Таким образом общие рекомендации сводятся к следующему:
Первый файл данных tempDB - на RAM-диске, фиксированного размера (я ставлю 75%) от размера RAM-диске. Отключен autogrowth.
Первый файл логов tempDB - на RAM-диске, фиксированного размера (я ставлю 25%) от размера RAM-диске. Отключен autogrowth.
Второй файл данных tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.
Второй файл логов tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.
Таким образом, при росте размера tempDB и выходе его "из берегов" RAM-диска он просто расширится на медленные диски.
Чтобы сжать дополнительные файлы БД, если tempDB выросла в их размеры, настраивается простенький план обслуживания на ночь:
USE [tempdb]
DBCC SHRINKFILE (N'tempdev_ext', EMPTYFILE);
DBCC SHRINKFILE (N'tempdev_ext', TRUNCATEONLY)
DBCC SHRINKFILE (N'templog_ext', EMPTYFILE);
DBCC SHRINKFILE (N'templog_ext', TRUNCATEONLY);
P.S. Лишь внедрением RAM TempDB мы смогли ускорить закрытие месяца в ERP в два раза.
