Одной из самых важных новостей компании 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)

На рисунке приведены сравнительные результаты, полученные на серверах 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)

Параллельно тестированию сервера 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 (см. Аппаратное ускорение корпоративных вычислений).

Upd. Коллеги, при размещении перепутали местами изображения, ошибка устранена.