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? Есть ли главный недостаток? Существуют ли какие-либо поставщики, которые специально выбирают или избегают?

11 голосов | спросил d-_-b 13 Jam1000000amFri, 13 Jan 2017 06:43:36 +030017 2017, 06:43:36

2 ответа


6

Во-первых, патч: убедитесь, что вы в 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.

ответил Brent Ozar 27 Jpm1000000pmFri, 27 Jan 2017 15:28:14 +030017 2017, 15:28:14
1

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

ответил Edward Coyle 14 J000000Saturday18 2018, 02:56:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132