Производительность базы данных Oracle в отдельных томах Azure NetApp Files

  • Статья

В этой статье рассматриваются следующие темы об Oracle в облаке. Эти темы могут представлять особый интерес для администратора базы данных, облачного архитектора или архитектора хранилища:

  • Когда вы управляете рабочей нагрузкой оперативной обработки транзакций (OLTP) (в основном случайным вводом-выводом) или рабочей нагрузкой интерактивной аналитической обработки (OLAP) (в основном последовательным вводом-выводом), как выглядит производительность?
  • В чем разница в производительности между обычным клиентом NFS ядра Linux (kNFS) и собственным клиентом Direct NFS Oracle?
  • Что касается пропускной способности, достаточно ли производительности одного тома Azure NetApp Files?

Важно!

Для правильного и оптимального развертывания Orace dNFS следуйте инструкциям по исправлению, описанным здесь.

Среда тестирования и компоненты

На следующей диаграмме показана среда, используемая для тестирования. Для единообразия и простоты для развертывания всех элементов тестового стенда использовались сценарии Ansible.

Oracle testing environment

Конфигурация виртуальной машины

В тестах использовалась следующая настройка виртуальной машины:

  • Операционная система:
    RedHat Enterprise Linux 7.8 (wle-ora01)
  • Типы экземпляров:
    При тестировании использовались две модели — D32s_v3 и D64s_v3
  • Количество сетевых интерфейсов:
    Один (1) помещен в подсеть 3
  • Диски:
    Бинарные файлы Oracle и ОС были помещены на один премиум-диск

Конфигурация Azure NetApp Files

В тестах использовалась следующая конфигурация Azure NetApp Files:

  • Размер пула емкости:
    Были настроены различные размеры пула: 4 ТиБ, 8 ТиБ, 16 ТиБ, 32 ТиБ
  • Уровень обслуживания:
    Ультра (128 МиБ/с пропускной способности на 1 ТиБ выделенной емкости тома)
  • Тома:
    Были оценены одно- и двухтомные тесты

Генератор рабочей нагрузки

В тестах использовалась рабочая нагрузка, созданная SLOB 2.5.4.2. SLOB (Silly Little Oracle Benchmark) — это хорошо известный генератор рабочей нагрузки в пространстве Oracle, предназначенный для нагрузки и тестирования подсистемы ввода-вывода с помощью физической нагрузки ввода-вывода с SGA-буферизацией.

SLOB 2.5.4.2 не поддерживает подключаемую базу данных (PDB). Таким образом, в сценарии setup.sh и runit.sh было внесено изменение, чтобы добавить к ним поддержку PDB.

Переменные SLOB, используемые в тестах, описаны в следующих разделах.

Рабочая нагрузка 80 % ВЫБРАТЬ, 20 % ОБНОВИТЬ | Случайный ввод/вывод — переменные slob.conf

UPDATE_PCT=20
SCAN_PCT=0
RUN_TIME=600
WORK_LOOP=0
SCALE=75G
SCAN_TABLE_SZ=50G
WORK_UNIT=64
REDO_STRESS=LITE
LOAD_PARALLEL_DEGREE=12

Рабочая нагрузка 100 % ВЫБРАТЬ | Последовательный ввод/вывод — переменные slob.conf

UPDATE_PCT=0
SCAN_PCT=100
RUN_TIME=600
WORK_LOOP=0
SCALE=75G
SCAN_TABLE_SZ=50G
WORK_UNIT=64
REDO_STRESS=LITE
LOAD_PARALLEL_DEGREE=12

База данных

Версия Oracle, используемая для тестов, — Oracle Database Enterprise Edition 19.3.0.0.

Параметры Oracle следующие:

  • sga_max_size: 4096M
  • sga_target: 4096
  • db_writer_processes: 12
  • awr_pdb_autoflush_enabled: true
  • filesystemio_options: SETALL
  • log_buffer: 134217728

PDB была создана для базы данных SLOB.

На следующей диаграмме показано табличное пространство с именем PERFIO размером 600 ГБ (20 файлов данных по 30 ГБ каждый), созданное для размещения четырех пользовательских схем SLOB. Каждая пользовательская схема имела размер 125 ГБ.

Oracle database

Метрики производительности

Цель состояла в том, чтобы сообщить о производительности ввода-вывода, испытанной приложением. Поэтому все диаграммы в этой статье используют метрики, сообщаемые базой данных Oracle через отчеты автоматического репозитория рабочих нагрузок (AWR). На диаграммах используются следующие метрики:

  • Среднее количество запросов ввода-вывода/с
    Соответствует сумме среднего числа запросов ввода-вывода на чтение в секунду и среднего числа запросов ввода-вывода на запись в секунду из раздела профиля нагрузки
  • Средний объем операций ввода-вывода, МБ/с
    Соответствует сумме среднего числа операций ввода-вывода при чтении, МБ/с, и среднего числа операций ввода-вывода при записи, МБ/с, из раздела профиля нагрузки
  • Средняя задержка чтения
    Соответствует средней задержке события ожидания Oracle "последовательное чтение файла базы данных" в микросекундах
  • Количество потоков/схема
    Соответствует количеству потоков SLOB на схему пользователя

Результаты измерения производительности

В этом разделе описаны результаты измерения производительности.

Клиент Linux kNFS против Oracle Direct NFS

Этот сценарий выполнялся на виртуальной машине Azure Standard_D32s_v3 (Intel E5-2673 v4 @ 2,30 ГГц). Рабочая нагрузка составляет 75 % SELECT и 25 % UPDATE, в основном случайный ввод-вывод, и с попаданием в буфер базы данных ~ 7,5 %.

Как показано на следующей диаграмме, клиент Oracle DNFS обеспечил в 2,8 раза большую пропускную способность, чем обычный клиент kNFS Linux:

Linux kNFS Client compared with Oracle Direct NFS

На следующей диаграмме показана кривая задержки для операций чтения. В этом контексте узким местом для клиента kNFS является соединение с одним сокетом NFS TCP, установленное между клиентом и сервером NFS (том Azure NetApp Files).

Linux kNFS Client compared with Oracle Direct NFS latency curve

Клиент DNFS смог отправить больше запросов ввода-вывода в секунду из-за его способности создавать сотни соединений сокетов TCP, таким образом используя преимущества параллелизма. Как описано в разделе Конфигурация Azure NetApp Files, каждый дополнительный выделенный ТиБ позволяет получить дополнительные 128 МБ/с полосы пропускания. Пропускная способность DNFS превысила 1 ГиБ/с, что является пределом, налагаемым выбором емкости 8 ТиБ. При большей емкости можно было бы добиться большей пропускной способности.

Пропускная способность — это только одно из соображений. Еще одним соображением является задержка, которая в первую очередь влияет на взаимодействие с пользователем. Как показано на следующей диаграмме, увеличение задержки можно ожидать гораздо быстрее с kNFS, чем с DNFS.

Linux kNFS Client compared with Oracle Direct NFS read latency

Гистограммы дают отличное представление о задержках в базе данных. Следующая диаграмма дает полное представление с точки зрения записанного "последовательного чтения файла db" при использовании DNFS в самой высокой точке данных параллелизма (32 потока/схема). Как показано на следующей диаграмме, 47 % всех операций чтения выполнялись между 512 микросекундами и 1000 микросекундами, в то время как 90 % всех операций чтения выполнялись с задержкой менее 2 мс.

Linux kNFS Client compared with Oracle Direct NFS histograms

Таким образом, очевидно, что DNFS является обязательной, когда дело доходит до повышения производительности экземпляра базы данных Oracle на NFS.

Ограничения производительности одного тома

В этом разделе описаны пределы производительности одного тома со случайным вводом-выводом и последовательным вводом-выводом.

Случайный ввод-вывод

DNFS может потреблять гораздо большую пропускную способность, чем предусмотрено квотой производительности файлов Azure NetApp Files размером 8 ТБ. При увеличении емкости тома Azure NetApp Files до 16 ТиБ, что является мгновенным изменением, пропускная способность тома увеличилась с 1024 МиБ/с в 2 раза до 2048 МиБ/с.

На следующей диаграмме показана конфигурация для рабочей нагрузки выбора 80 % и обновления 20 %, а также с коэффициентом попадания в буфер базы данных 8 %. SLOB смог обработать один том до 200 000 запросов ввода-вывода NFS в секунду. Учитывая, что каждая операция имеет размер 8 КиБ, тестируемая система смогла доставить ~ 200 000 запросов ввода-вывода в секунду или 1600 МиБ/с.

Oracle DNFS throughput

На следующей диаграмме кривой задержки чтения показано, что по мере увеличения пропускной способности чтения задержка плавно увеличивается ниже линии 1 мс и достигает изгиба кривой при ~ 165 000 средних запросов ввода-вывода чтения в секунду при средней задержке чтения ~ 1,3 мс. Это значение невероятной задержки для скорости ввода-вывода, недостижимой практически для любой другой технологии в облаке Azure.

Oracle DNFS latency curve

Последовательный ввод-вывод

Как показано на следующей диаграмме, не все операции ввода-вывода являются случайными по своей природе, учитывая, например, резервное копирование RMAN или полное сканирование таблицы как рабочие нагрузки, требующие максимальной пропускной способности. Используя ту же конфигурацию, что описана ранее, но с измененным размером тома до 32 ТиБ, на следующей диаграмме показано, что один экземпляр Oracle DB может обеспечить пропускную способность более 3900 МБ/с, что очень близко к квоте производительности тома Azure NetApp Files в 32 ТБ (128 МБ/с * 32 = 4096 МБ/с).

Oracle DNFS I/O

Таким образом, Azure NetApp Files помогают перенести базы данных Oracle в облако. Он обеспечивает производительность, когда этого требует база данных. Вы можете динамически и без прерывания работы изменить размер квоты объема в любое время.

Следующие шаги