Рекомендации по использованию оборудования для выполняющейся в памяти OLTP в SQL Server
Выполняющаяся в памяти OLTP использует память и диск иначе, чем традиционные таблицы на диске. Улучшение производительности, которое вы видите при использовании OLTP в памяти, зависит от используемого оборудования. В этой статье мы обсудим несколько общих рекомендаций по оборудованию и укажите общие рекомендации по использованию оборудования с OLTP в памяти.
Примечание.
Эта статья была записью блога, опубликованной 1 августа 2013 г. командой разработчиков Microsoft SQL Server 2014. Сейчас веб-страница блога выводится из числа действующих.
ЦП
В памяти OLTP не требуется высокоуровневый сервер для поддержки рабочей нагрузки OLTP высокой пропускной способности. Рекомендуется использовать сервер среднего диапазона с двумя сокетами ЦП. Из-за повышенной пропускной способности, включенной OLTP в памяти, два сокета, скорее всего, будут достаточно для ваших бизнес-потребностей.
Рекомендуется включить одновременную многопоточность (SMT) с помощью OLTP в памяти. При использовании SMT некоторые рабочие нагрузки OLTP выросли на производительность до 40 %.
Память
Все оптимизированные для памяти таблицы полностью находятся в памяти. Таким образом, необходимо иметь достаточно физической памяти для таблиц и поддерживать рабочую нагрузку, выполняемую в базе данных, — сколько памяти на самом деле требуется на самом деле зависит от рабочей нагрузки, но в качестве начальной точки требуется достаточно доступной памяти примерно в два раза больше. Кроме того, требуется достаточно памяти для буферного пула, если рабочая нагрузка также работает в традиционных таблицах на основе дисков.
Чтобы определить объем памяти, используемый таблицей, оптимизированной для памяти, выполните следующий запрос:
select object_name(object_id), * from sys.dm_db_xtp_table_memory_stats;
Результаты показывают память, используемую для оптимизированных для памяти таблиц и их индексов. Данные таблицы включают данные пользователя и все старые версии строк, которые по-прежнему требуются при выполнении транзакций или еще не были удалены системой. Память, используемая хэш-индексами, является константой и не зависит от количества строк в таблице.
При использовании OLTP в памяти важно учитывать, что вся база данных не должна соответствовать памяти. У вас может быть база данных с несколькими терабайтами и по-прежнему использовать OLTP в памяти, если размер горячих данных (то есть оптимизированные для памяти таблицы) не превышает 256 ГБ. Максимальное количество файлов данных проверка point, которым SQL Server может управлять для одной базы данных, составляет 4000, при этом каждый файл составляет 128 МБ. Хотя это даст теоретический максимум 512 ГБ, чтобы гарантировать, что SQL Server может поддерживать слияние файлов проверка point и не достигнет предела 4000 файлов, мы поддерживаем до 256 ГБ. Это ограничение применяется только к таблицам, оптимизированным для памяти; Нет такого ограничения размера для традиционных дисковых таблиц в той же базе данных SQL Server.
Не устойчивые таблицы, оптимизированные для памяти (NDTs), то есть оптимизированные для памяти таблицы с помощью DURABILITY=SCHEMA_ONLY не сохраняются на диске. Хотя NDTs не ограничены количеством файлов проверка point, поддерживается только 256 ГБ. Рекомендации по использованию дисков журналов и данных в оставшейся части этой записи не применяются к не устойчивым таблицам, так как данные существуют только в памяти.
Диск журнала
Записи журнала, относящиеся к таблицам, оптимизированным для памяти, регистрируются в журнале транзакций базы данных вместе с другими записями журнала SQL Server.
Всегда важно поместить файл журнала на диск с низкой задержкой, таким образом, чтобы транзакции не должны ждать слишком долго, и предотвратить драку в журнале ввода-вывода. Система работает так быстро, как самый медленный компонент (закон Amdahl). Необходимо убедиться, что при запуске OLTP в памяти устройство ввода-вывода журнала не становится узким местом. Рекомендуется использовать устройство хранения с низкой задержкой — как минимум диск SSD.
Оптимизированные для памяти таблицы используют меньше пропускной способности журнала, чем таблицы на основе дисков, так как они не регистрируют операции индексов и не регистрируют записи UNDO. Это может помочь облегчить драку ввода-вывода журнала.
Диск данных
Сохраняемость оптимизированных для памяти таблиц с помощью файлов проверка point использует потоковую передачу ввода-вывода. Таким образом, эти файлы не нуждаются в диске с низкой задержкой или быстрым случайным вводом-выводом. Вместо этого основным фактором для этих дисков является скорость последовательного ввода-вывода и пропускной способности адаптера шины узла (HBA). Таким образом, для файлов проверка point не требуются диски SSD; их можно поместить на высокопроизводительные спиндели (например, SAS), если их скорость последовательного ввода-вывода соответствует вашим требованиям.
Важнейшим фактором определения требования к скорости является RTO [цель времени восстановления] при перезапуске сервера. Во время восстановления базы данных все данные в таблицах, оптимизированных для памяти, должны быть считаны с диска в память. Восстановление базы данных происходит на последовательной скорости чтения подсистемы ввода-вывода; диск является узким местом.
Для удовлетворения строгих требований RTO рекомендуется распространять файлы проверка point по нескольким дискам, добавив несколько контейнеров в файловую группу MEMORY_OPTIMIZED_DATA. SQL Server поддерживает параллельную загрузку файлов контрольных точек с нескольких дисков — восстановление выполняется с суммарной скоростью дисков.
С точки зрения емкости диска рекомендуется использовать 2–3 раза больше доступных таблиц, оптимизированных для памяти.