Анализируем производительность сервера Oracle SPARC T7-210.11.2016 07:03

Одной из самых важных новостей компании Oracle в 2015 году стал выход нового процессора SPARC M7 и линейки серверов на его основе. В эту линейку вошли серверы T-серии (T7–1, T7–2, T7–4) и серверы M-серии (M7–8, M7–16).

Помимо уникальных физических характеристик (частота 4,13 гГц, 32 ядра, до 256 потоков) на процессоре M7 заявлена возможность переноса части SQL-логики базы данных Oracle на специальные сопроцессоры DAX (Data Analytics Accelerator). Эта технология получила название «SQL in Silicon» — с ней новый процессор M7 позиционируется как первый процессор в истории ИТ, в том числе оптимизированный под задачи Oracle Database.

В начале 2016 года стало возможно тестирование серверов T-серии, и мы одними из первых в России параллельно протестировали сразу два тестовых сервера T7–2 (по два процессора M7 в каждом).

Тестирование было организовано в несколько этапов:

  1. анализ производительности нового сервера SPARC с помощью синтетических тестов, использующих Oracle Database,
  2. исследование новых возможностей виртуализации сервера T7–2 (см. Виртуализация на Oracle SPARC T7–2 — результаты наших тестов)
  3. изучение технологии «SQL in Silicon».

Цель данного поста — поделиться с сообществом результатами, полученными на первом и на четвертом этапах.

На рынке существует широкий набор синтетических тестов, использующих Oracle Database. Более того, как это ни пародоксально звучит, выбор синтетики может в значительной степени предопределить результат. Как и при тестировании предыдущего поколения SPARC (серверы линейки T5) мы задавались целью узнать, какую максимальную производительность можно выжать из сервера — определить момент, когда он «закипает» под нагрузкой Oracle Database.

Для такого исследования классическая GUI-синтетика типа SwingBench не годится — у тестового ПО должен быть открытый код, чтобы иметь возможность свести к минимуму влияние на результаты тестов как системы ввода-вывода, так и внутренних механизмов базы данных (в данном случае Oracle Database). В ходе решения этой задачи нами было выбрано и значительно доработано ПО с открытым кодом SLOB (Silly Little Oracle Benchmark, автор Kevin Closson). В процессе исследования мы фиксировали максимальные значения показателя Logical Reads Per Second (логическое чтение или чтение из памяти) экземпляра Oracle при полностью разогретом кэше и параллельной работе сессий SLOB практически без конкуренции за ресурсы экземпляра. Интенсивность логических чтений из памяти является важной характеристикой нового процессора, а само чтение данных из памяти является неотъемлемой частью функционирования Oracle Database.

Рис. 1. Результаты в доменах 32 ядра (T5 vs T7)

bb5ba9cc46ce4a9e91e8212c7edbb72e.jpg

На рисунке приведены сравнительные результаты, полученные на серверах T5–4 (предыдущее поколение процессоров SPARC) и T7–2 (новые процессоры SPARC M7). Результаты зафиксированы в одинаковых по процессорной мощности доменах (32 ядра) при одинаковых версиях Oracle Database и настройках экземпляра. По оси X отложено количество параллельных сессий доработанного SLOB, по оси Y –максимальное количество логических чтений в секунду согласно статистике AWR.

Из графика видно, что насыщение (когда сервер «закипает») наступает, когда количество сессий SLOB сравнивается с количеством потоков домена (32 ядра по восемь потоков — 256). Также видно, что при одинаковом числе ядер домен сервера T7 оказался в 1,15–1,2 раза производительнее домена сервера T5. Это означает, что новый процессор M7 (в котором вдвое больше ядер) в 2,3–2,4 раза производительнее процессоров предыдущего поколения от Oracle. Заметим, что этот результат зафиксирован на сервере T7 как в контрольном (control), так и в гостевом (guest) домене. При этом на большом количестве сессий (192 и более) в гостевом домене сервера T7 заметно влияние виртуализации: производительность оказывается на 3–5% ниже, чем в контрольном домене при тех же условиях.

Максимальное значение показателя Logical Reads Per Second под нагрузкой SLOB нами было зафиксировано на 512 потоках — когда контрольному домену были отданы все 64 ядра. Это значение составило 93–95 миллионов логических чтений в секунду — за все время тестирования серверов различной архитектуры под нагрузкой Oracle Database такие цифры мы получили впервые!

Рис. 2. Сравнительные результаты в доменах 16 ядер (T5/T7/P8/x86)

99495d1f259f46839ca68bddcae47a87.jpg

Параллельно тестированию сервера T7–2 по той же методике были протестированы актуальные серверы архитектуры IBM Power и x86. На рисунке показаны сравнительные результаты тестов SLOB, полученные в доменах с одинаковым числом ядер (16). Заметим при этом, что у x86 сервера на одно ядро приходится по 2 потока, а у Power и SPARC — по 8 потоков. На большом количестве сессий SLOB результат сервера T7–2 (около 24 млн логических чтений в секунду) оказался лучшим — при том что на малых количествах сессий наиболее производительно показала себя архитектура x86.

Результаты синтетических тестов SLOB позволяют сделать вывод о том, что даже без специальных возможностей «SQL in Silicon» сервер T7–2 показывает очень высокую производительность на задачах Oracle Database и его можно смело рекомендовать по крайней мере в качестве платформы консолидации Oracle Database. Таковы краткие итоги первого этапа нашего исследования процессора M7.

Что касается DAX (или «SQL in Silicon»), то исследовать его можно разными способами. Во-первых API к DAX открыт и его можно напрямую задействовать в приложении. Такой подход описан в нашей статье Аппаратное ускорение корпоративных вычислений — с помощью DAX удалось в 5–6 раз ускорить операции с математическими множествами.

Во-вторых, можно тестировать, насколько технология «SQL in Silicon» ускоряет запросы к базе данных. На сегодняшний день это возможно только в Oracle Database 12c и только при использовании опции In-Memory. Поэтому будет правильно напомнить, что собой представляет эта опция.
Большинство Database используют строковое хранение данных (Row Database) как на дисках, так и в памяти. При этом на рынке есть и активно развиваются Database, реализующие колоночное хранение (Columnar Database). Принято считать, что Row Database оптимально для транзакционных систем класса OLTP, а в хранилищах класса DWH определенные аналитические запросы могут работать гораздо быстрее с Columnar Database.

Появившаяся в Oracle Database 12c опция Database In-Memory реализует колоночное хранение данных в памяти дополнительно к традиционному строковому. Такое хранение возможно благодаря дополнительной области памяти (In-Memory кэш), в которой администратор Oracle Database может кэшировать данные как целых таблиц, так и отдельных колонок либо партиций в колоночном формате. Такое дополнительное колоночное хранение данных в памяти прозрачно для приложения, при этом у оптимизатора Oracle появляется возможность выбора из памяти нужных данных как в строчном, так и в колоночном представлении. Можно сказать, что с помощью In-Memory в Oracle реализовано уникальное сочетание строчного и колоночного хранения данных.

Мы неоднократно знакомили сообщество с результатами, полученными в наших тестированиях работы In-Memory, в частности мы разработали методику, эмулирующую работу систем класса DWH. В таблицу базы данных Oracle были сложены случайным образом сгенерированные данные о жителях Европы и их зарплатах (таблица persons, около 20 миллионов записей), в отдельную таблицу-справочник были сложены все европейские страны (таблица countries): 

create table persons ( 
  id not null number(38), 
  country_id number(38), 
  name varchar2(50), 
  salary number(36) 
); 

create table countries ( 
  id not null number(38), 
  name varchar2(20) 
);

Роль аналитического запроса играл SQL-расчет суммы всех зарплат жителей стран, начинающихся на R (это Россия и Румыния): 

select sum(salary) from persons where country_id in (select id from countries where name like 'R%');

При работе с In-Memory в In-Memory кэше «поднимались» две колонки таблицы persons — country_id и salary: 
alter table persons inmemory no inmemory (id, name) inmemory memcompress for query high (country_id, salary);

При использовании традиционного буфферного кэша (после прогревания) данный запрос отрабатывал на сервере T7–2 за 1.9 секунд (заметим, что механизм In-Memory отключался хинтом). При использовании кэша In-Memory на том же сервере — за 0.39 секунд или в 4.8 раза быстрее. Мониторинг работы DAX утилитой busstat показал, что во время исполнения запроса счетчики были не нулевыми — т.е. DAX работал:

5 dax0 DAX_SCH_query_cmd_sched 80 DAX_QRYO_input_valid 694586 DAX_QRYO_output_valid 1530256
5 dax1 DAX_SCH_query_cmd_sched 80 DAX_QRYO_input_valid 754450 DAX_QRYO_output_valid 2017088
5 dax2 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 522635 DAX_QRYO_output_valid 758496
5 dax3 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 672683 DAX_QRYO_output_valid 1529568
5 dax4 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 589392 DAX_QRYO_output_valid 1073248
5 dax5 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 635264 DAX_QRYO_output_valid 1502832
5 dax6 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 615433 DAX_QRYO_output_valid 1080257
5 dax7 DAX_SCH_query_cmd_sched 80 DAX_QRYO_input_valid 810452 DAX_QRYO_output_valid 2295872

Таким образом, данный аналитический запрос частично выполнялся на сопроцессорах DAX и мы зафиксировали почти 5-кратаное ускорение его работы за счет комплексной технологии In-Memory + DAX по сравнению с работой Oracle Database с использованием традиционного буфферного кэша. Заметим, что мы не подбирали специально запрос или размер таблицы persons — мы реализовали на T7–2 методику, с помощью которой изучали ранее работу опции In-Memory. Пятикратное ускорение в этом случае — более чем достойный результат, тем более что оно хорошо соответствует выводам, которые мы сделали ранее при тестировании DAX через API (см. Аппаратное ускорение корпоративных вычислений).

Комментарии (1)

  • 9 ноября 2016 в 22:18

    +1

    ↑

    ↓

    По стоимости так-же в 2,3–2,4 раза дороже, чем предыдущее поколение процессоров?

© Habrahabr.ru