База данных SQL Server на диске RAM?

Наша база данных приложений вендоров очень интенсивно использует TempDB.

Сервер является виртуальным (VMWare) с 40 ядрами и 768 ГБ ОЗУ под управлением SQL 2012 Enterprise SP3.

Все базы данных, включая TempDB, находятся на SSD уровня 1 в сети SAN. У нас есть 10 файлов данных tempdb, каждый предварительно увеличен до 1 ГБ, и они никогда не растут автоматически. То же самое с лог-файлом 70 ГБ. Флаги трассировки 1117 и 1118 уже установлены.

sys.dm_io_virtual_file_stats показывает более 50 терабайт, прочитанных / записанных в файлы данных и журналов tempdb за прошедший месяц, с совокупным значением io_stall 250 часов или 10 дней.

За последние 2 года мы уже настроили код поставщика и SP.

Теперь мы думаем о размещении файлов tempdb на RAM-диске, так как у нас есть тонна памяти. Так как tempdb уничтожается / воссоздается при перезагрузке сервера, он является идеальным кандидатом для размещения в энергозависимой памяти, которая также сбрасывается при перезагрузке сервера.

Я проверил это в более низкой среде, и это привело к более быстрому времени запроса, но увеличило использование ЦП, потому что ЦП выполняет больше работы вместо ожидания на медленном диске tempdb.

Кто-нибудь еще помещал свои базы данных tempdb в ОЗУ в системах с высоким oltp? Есть ли существенный недостаток? Есть ли какие-либо поставщики, чтобы специально выбрать или избежать?

Во-первых, исправление: убедитесь, что вы используете накопительный пакет обновления 10 (SP1) 2012 или более поздней версии. В 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 */

Посмотрите на раздел статистики по файлам и сконцентрируйтесь на физических записях. Данные SinceStartup могут немного вводить в заблуждение, поскольку они также включают в себя время, когда CHECKDB запущен, и это действительно может забить вашу TempDB.

Если средняя задержка записи превышает 3 мс, то да, возможно, в вашей SAN есть твердотельное хранилище, но оно все еще не быстрое.

Сначала рассмотрим локальные SSD для TempDB. Хорошие локальные твердотельные накопители (например, карты Intel PCIe NVMe стоимостью менее 2 тыс. Долл. США, особенно в описываемых вами размерах) имеют чрезвычайно низкую задержку, которая ниже, чем вы можете достичь с помощью общего хранилища. Однако в условиях виртуализации это имеет недостаток: вы не можете vMotion гостя с одного хоста на другой реагировать на нагрузку или проблемы с оборудованием.

Рассмотрим ОЗУ в последнюю очередь. Есть два больших недостатка с таким подходом:

Во-первых, если у вас действительно есть большая активность записи в TempDB, скорость изменения памяти может быть настолько высокой, что вы не сможете vMotion гостя с одного хоста на другой, чтобы все не заметили. Во время vMotion вы должны копировать содержимое оперативной памяти с одного хоста на другой. Если он действительно меняется так быстро, быстрее, чем вы можете скопировать его в вашей сети vMotion, вы можете столкнуться с проблемами (особенно если этот блок связан с зеркалированием, AG или отказоустойчивым кластером).

Во-вторых, ОЗУ являются программными. В ходе нагрузочного тестирования, которое я провел, меня не впечатлила их скорость при очень большой активности TempDB. Если он настолько тяжелый, что SSD корпоративного уровня не может справиться с этим, то вам придется облагать налогом и программное обеспечение накопителей RAM. Вы действительно захотите выполнить нагрузочное тестирование перед тем, как начать работу - попробуйте такие вещи, как множество одновременных перестроений индексов для разных индексов, все с использованием sort-in-tempdb.

Создание ОЗУ должно быть тривиальным. Многие загрузочные флеш-накопители Linux и оптические приводы создают ОЗУ и хранят там файлы ОС. Корневая файловая система находится в памяти. В Windows, в тот день, RAM-диск был загружен в качестве драйвера устройства в config.sys. Обычно драйвер загружался в большой объем памяти. На мой взгляд, это очень хорошее и простое решение. Если бы вы создали ваше решение, используя привод RAM, я бы хотел услышать об этом. Я хотел бы сделать что-то подобное, но хотел бы делать записи в постоянное хранилище и хранить БД в ОЗУ. В моем случае у нас есть машины, которые могут установить больше оперативной памяти, чем может использовать ОС. Создание RAM-диска до загрузки ОС позволит использовать RAM, иначе ОС не увидит.