С този малък пост се надявам да разясня едно недоразумение, свързано с анализа на AWR на бази данни, работещи на Oracle Exadata. Почти 10 години постоянно се сблъсквам с въпроса: какъв е приносът на Exadata Software за производителността? Или с новосформираните термини: до каква степен „екзадатизира“ работата на съответната база данни?
Често на този правилен въпрос, на мое мнение, се дава неверен отговор, свързан със статистиката AWR. В нея се представя метод на системните чакания, който интерпретира времето за отговор като сума от времето на работа на процесорите (DB CPU) и времето на чакания на различни класове.
С появата на Exadata в статистиката AWR се появиха специфични системни чакания, свързани с работата на Exadata Software. Обикновено имената на такива чакания започват с думата 'cell' (камерата е Exadata Storage сървър), като най-често срещаните чакания с говорещи имена са 'cell smart table scan', 'cell multiblock physical read' и 'cell single block physical read'.
В повечето случаи дялът на тези Exadata-чакања в общото време за отговор е малък и затова те дори не попадат в секцията Top10 Foreground Events by Total Wait Time (в този случай трябва да се търсят в раздела Foreground Wait Events). С големи усилия открихме пример на дневен AWR при нашите клиенти, в който Exadata-чакањата попаднаха в секцията Top10 и в общо съставиха около 5%:
Събитие
Чакания
Общо време на чакане (сек.)
Средно чакане
% DB време
Клас на чакане
DB CPU
115.2K
70.4
SQL*Net повече данни от dblink
670,196
5471.5
8.16ms
3.3
Мрежа
cell single block physical read
5,661,452
3827.6
676.07us
2.3
Потребител I/O
Синхронно ASM ребаланс
4,350,012
3481.3
800.30us
2.1
Други
cell multiblock physical read
759,885
2252
2.96ms
1.4
Потребител I/O
директно path read
374,368
1811.3
4.84ms
1.1
Потребител I/O
SQL*Net съобщение от dblink
7,983
1725
216.08ms
1.1
Мрежа
cell smart table scan
1,007,520
1260.7
1.25ms
0.8
Потребител I/O
директно path read temp
520,211
808.4
1.55ms
0.5
Потребител I/O
enq: TM — съдържание
652
795.8
1220.55ms
0.5
Приложение
От подобна AWR статистика често се правят следните изводи:
1. Приносът на магията Exadata към производителността на базата данни не е голям — не надвишава 5 %, а базата данни 'екзадатизира' лошо.
2. Ако такава база се прехвърли от Exadata на класическа архитектура 'сървър + масив', производителността няма да се промени значително. Защото дори ако този масив се окаже три пъти по-бавен от системата за съхранение Exadata (което едва ли е възможно за съвременни All Flash масиви), то като умножим 5% по три, ще получим увеличение на дела на чаканията за вход-изход до 15% — такова нещо базата данни със сигурност ще преживее!
И двата тези изхода не са точни, а освен това и из distort разбирате концепцията, заложена в Exadata Software. Exadata не само осигурява бърза входно-изходна работа, но работи принципно различно в сравнение с класическата архитектура „сървър + масив“. Ако работата на базата данни наистина „екзадатира“, то SQL логиката се прехвърля на системата за съхранение. сървъри благодарение на редица специални механизми (преди всичко Exadata Storage Indexes, но не само те) сами намират нужните данни и ги изпращат на сървърите на DB. Правят го доста ефективно, затова делът на характерните Exadata очаквания в общото времетраене на отговор е малък.
Как ще се промени този дял извън Exadata? Как ще се отрази на производителността на базата данни като цяло? Най-добре на тези въпроси ще отговори тестването. Например, очакването „cell smart table scan“ извън Exadata може да се превърне в толкова тежък Table Full Scan, че входно-изходната работа да заеме всичкото време за отговор и производителността да се влоши драстично. Именно затова е неправилно при анализа на AWR да се счита общият процент на очакванията Exadata за приносът на нейното магьосничество в производителността, и още по-малко да се използва този процент за прогнозиране на производителността извън Exadata. За да разберем колко „екзадатира“ работата на базата, е нужно да изучаваме статистиките AWR в секцията „Instance Activity Stats“ (там има много статистики с говорещи имена) и да ги сравняваме помежду им.
А за да разберем как ще се чувства базата данни извън Exadata, е най-добре да направим клон на базата от резервно копие на целевата архитектура и да анализираме производителността на този клон под натоварване. Такава възможност обикновено имат притежателите на Exadata.
Автор: Алексей Струченко, ръководител на отдела по БД в „Инфосистеми Джет“
Източник: habr.com
