SQL Server tempdb на RAM-диске?
Наша база данных приложений для поставщиков очень интенсивно работает с TempDB.
Сервер виртуальный (VMWare) с 40 ядрами и оперативной памятью 768 ГБ, работающий под управлением SQL 2012 Enterprise SP3.
Все базы данных, включая TempDB, находятся на SSD уровня 1 в SAN. У нас есть 10 файлов данных tempdb, каждый из которых вырос до 1 ГБ, и они никогда не растут автоматически. То же самое с файлом журнала 70GB. Trace Flags 1117 & 1118 уже установлены.
sys.dm_io_virtual_file_stats показывает более 50 терабайт, считанных /записанных на данные tempdb & журнальные файлы в прошлом месяце, с совокупным io_stall объемом 250 часов или 10 дней.
Мы уже настроили код поставщика и SP за последние 2 года.
Теперь мы думаем о размещении файлов tempdb на RAM-диске, так как у нас есть тонна памяти. Поскольку tempdb уничтожается /воссоздается при перезагрузке сервера, он является идеальным кандидатом для размещения в энергозависимой памяти, которая также выгружается при перезагрузке сервера.
Я тестировал это в более низкой среде, и это привело к более быстрому времени запросов, но увеличило использование ЦП, потому что процессор делает больше работы вместо ожидания на медленном диске tempdb.
Кто-нибудь еще помещает их tempdb в оперативную память в системах с высоким уровнем oltp? Есть ли главный недостаток? Существуют ли какие-либо поставщики, которые специально выбирают или избегают?
2 ответа
Во-первых, патч: убедитесь, что вы в 2012 году с пакетом обновления 1 накопительное обновление 10 или новее. В SQL 2014 Microsoft изменила TempDB на меньше не хотят писать на диск , а они удивительно обратил его в 2012 SP1 CU10 , так что может облегчить много давления на печать TempDB.
Во-вторых, получите точные числа в вашей задержке. Проверьте sys.dm_io_virtual_file_stats , чтобы увидеть средний стол для хранения ваших файлов TempDB. Мой любимый способ сделать это:
sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */
Посмотрите раздел статистики файлов и сосредоточьтесь на физической записи. Данные, полученные с помощью SystemStartup, могут быть немного вводящими в заблуждение, так как в него также включены моменты, когда CHECKDB запущен, и которые могут действительно забивать ваш TempDB.
Если средняя латентность записи превышает 3 мс, то да, у вас может быть твердотельное хранилище в вашей SAN, но оно все еще не быстро.
Сначала рассмотрите локальные SSD-файлы для TempDB. Хорошие локальные SSD-накопители (такие как карты PCIe NVMe от Intel, размер которых ниже $ 2 тыс., особенно при описанных вами размерах) имеют чрезвычайно низкую задержку, ниже, чем вы может достичь с общим хранилищем. Однако при виртуализации это имеет недостаток: вы не можете vMotion гость от одного узла к другому, чтобы реагировать на нагрузку или на проблемы с оборудованием.
Рассмотрим последний привод RAM. При таком подходе есть две большие ошибки:
Во-первых, если у вас действительно есть тяжелая активность записи TempDB, скорость изменения в памяти может быть настолько высокой, что вы не сможете vMotion гость от одного узла к другому, не заметив все. Во время vMotion вам необходимо скопировать содержимое ОЗУ с одного узла на другой. Если это действительно так быстро, быстрее, чем вы можете скопировать его по сети vMotion, вы можете столкнуться с проблемами (особенно если это поле связано с зеркалированием, AG или отказоустойчивым кластером.)
Во-вторых, RAM-диски - это программное обеспечение. В нагрузочном тестировании, которое я сделал, я не был настолько впечатлен своей скоростью при действительно тяжелой активности TempDB. Если это так тяжело, что SSD корпоративного уровня не может идти в ногу со временем, тогда вы также будете облагать налогом программное обеспечение RAM. Вы действительно захотите загрузить тест, прежде чем идти вживую - попробуйте такие вещи, как много одновременных перестроек индексов на разных индексах, все с помощью sort-in-tempdb.
Создание RAM-диска должно быть тривиальным. Многие загрузочные жесткие диски и оптические диски Linux создают RAM-диск и хранят там файлы ОС. Корневая файловая система затем находится в памяти. В окнах, в тот же день, RAM-диск был загружен как драйвер устройства в config.sys. Обычно драйвер загружался в большую память. На мой взгляд, это очень хорошее и простое решение. Если вы создали свое решение с помощью RAM-накопителя, я бы хотел услышать об этом. Я хотел бы сделать что-то подобное, но хотел бы делать записи в постоянное хранилище и хранить db в ОЗУ. В моем случае у нас есть машины, которые могут устанавливать больше оперативной памяти, чем может использовать ОС. Создание RAM-диска до загрузки ОС позволит использовать ОЗУ, которые ОС не увидит иначе.