Аналізуємо продуктивність сервера Oracle SPARC T7-2

Однією з найбільш важливих новин компанії 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 (див. Апаратне прискорення корпоративних обчислень).
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.