Рекомендации по оборудованию для In-Memory OLTP в SQL Server

In-Memory OLTP использует память и диск различными способами, чем традиционные таблицы на основе дисков. Улучшение производительности, которое вы видите с помощью In-Memory OLTP, зависит от используемого оборудования. В этой статье мы обсудим несколько общих соображений по оборудованию и предоставим универсальные рекомендации по использованию оборудования с In-Memory OLTP.

ЦП

In-Memory OLTP не требует высокоуровневого сервера для поддержки рабочей нагрузки OLTP высокой пропускной способности. Рекомендуется использовать сервер среднего диапазона с двумя сокетами ЦП. В связи с повышенной пропускной способностью, обеспечиваемой In-Memory OLTP, два сокета, скорее всего, будет достаточно для потребностей вашего бизнеса.

Мы рекомендуем включить поддержку одновременной многопоточности (SMT) с In-Memory OLTP. При некоторых рабочих нагрузках OLTP, мы наблюдали увеличение производительности до 40% при использовании SMT.

Memory

Все оптимизированные для памяти таблицы находятся полностью в памяти. Таким образом, необходимо иметь достаточно физической памяти для таблиц и поддержания рабочей нагрузки, выполняемой в базе данных. Сколько памяти действительно необходимо, зависит от нагрузки, но в качестве отправной точки нужно иметь достаточно свободной памяти примерно в два раза больше размера данных. Кроме того, требуется достаточно памяти для буферного пула, если рабочая нагрузка также работает в традиционных таблицах на основе дисков.

Чтобы определить, сколько памяти использует оптимизированная для памяти таблица, выполните следующий запрос:

select object_name(object_id), * from sys.dm_db_xtp_table_memory_stats;

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

Важно помнить, что при использовании In-Memory OLTP необязательно, чтобы вся база данных помещалась в память. У вас может быть база данных с несколькими терабайтами и по-прежнему воспользоваться In-Memory OLTP, если размер горячих данных (то есть оптимизированных для памяти таблиц) не превышает 256 ГБ. Максимальное количество файлов данных контрольных точек, которым sql Server может управлять для одной базы данных, составляет 4000, при этом каждый файл составляет 128 МБ. Хотя это дает теоретический максимум 512 ГБ, чтобы гарантировать, что SQL Server способен поддерживать слияние файлов контрольных точек и не достигнет лимита в 4000 файлов, мы поддерживаем объём до 256 ГБ. Это ограничение применяется только к таблицам, оптимизированным для памяти; Нет такого ограничения размера для традиционных дисковых таблиц в той же базе данных SQL Server.

Не устойчивые таблицы, оптимизированные для памяти (NDTs), то есть оптимизированные для памяти таблицы с помощью DURABILITY=SCHEMA_ONLY не сохраняются на диске. Хотя количество файлов контрольных точек для NDTs не ограничено, поддерживается объём только до 256 ГБ. Рекомендации по журналированию и данным накопителей, описанные в оставшейся части этого сообщения, не применяются к неустойчивым таблицам, так как данные существуют только в памяти.

Диск для логов

Записи журналов, относящиеся к таблицам, оптимизированным для памяти, записываются в журнал транзакций базы данных вместе с другими записями журнала SQL Server.

Всегда важно размещать файл журнала на диске с низкой задержкой, чтобы транзакции не ждали слишком долго, и чтобы предотвратить конкуренцию при вводе-выводе журнала. Система работает так быстро, как самый медленный компонент (закон Amdahl). Необходимо убедиться, что при запуске In-Memory OLTP устройство ввода-вывода журнала не становится узким местом. Рекомендуется использовать устройство хранения с низкой задержкой, по крайней мере SSD.

Оптимизированные для памяти таблицы используют меньше пропускной способности журнала, чем таблицы на основе дисков, так как они не регистрируют операции индексов и не регистрируют записи UNDO. Это может помочь облегчить конкуренцию ввода-вывода журнала.

Диск данных

Сохраняемость оптимизированных для памяти таблиц с помощью файлов контрольных точек использует потоковую передачу ввода-вывода. Таким образом, эти файлы не нуждаются в диске с низкой задержкой или быстрым случайным вводом-выводом. Вместо этого основным фактором для этих дисков является скорость последовательного ввода-вывода и пропускной способности адаптера шины узла (HBA). Таким образом, для файлов контрольных точек не требуются SSD; Их можно разместить на шпинделях высокой производительности (например, SAS), если скорость их последовательного ввода-вывода соответствует вашим требованиям.

Самым большим фактором определения требования скорости является RTO [Цель времени восстановления] на перезапуске сервера. Во время восстановления базы данных все данные в оптимизированных для памяти таблицах должны считываться с диска в память. Восстановление базы данных происходит на последовательной скорости чтения подсистемы ввода-вывода; диск является узким местом.

Для удовлетворения строгих требований RTO рекомендуется распространять файлы контрольных точек по нескольким дискам, добавляя несколько контейнеров в файловую группу MEMORY_OPTIMIZED_DATA. SQL Server поддерживает параллельную загрузку файлов контрольных точек с нескольких дисков — восстановление происходит на суммарной скорости дисков.

С точки зрения емкости диска рекомендуется использовать 2–3 раза больше доступных таблиц, оптимизированных для памяти.

Связанный контент

• Пример базы данных для In-Memory OLTP