Овим кратким постом желео бих да отклоним један неспоразум у вези са анализом АВР база података које раде на Орацле Екадата. Већ скоро 10 година стално се суочавам са питањем: какав је допринос Екадата софтвера продуктивности? Или користећи новостворене речи: колико је „стручан“ рад одређене базе података?
Често се на ово тачно питање, по мом мишљењу, даје нетачан одговор у односу на АВР статистику. Представља метод системског чекања, који време одговора третира као збир радног времена процесора (ДБ ЦПУ) и времена чекања различитих класа.
Са појавом Екадата, специфична системска очекивања у вези са радом Екадата софтвера појавила су се у АВР статистици. По правилу, називи таквих чекања почињу речју „ћелија“ (Екадата Стораге сервер се назива ћелија), од којих су најчешћа чекања са изговореним називима „целл смарт табле сцан“, „целл мултиблоцк пхисицал реад“ и „физичко читање једног блока ћелије“.
У већини случајева, удео таквих Екадата чекања у укупном времену одговора је мали, па стога они чак ни не спадају у одељак Топ10 Форегроунд Евентс према укупном времену чекања (у овом случају, морате да их потражите у Форегроунд Ваит Одељак Догађаји). Са великом муком смо пронашли пример дневног АВР-а од наших купаца, у којем су очекивања Екадата укључена у Топ10 одељак и укупно су износила око 5%:
догађај
Чека
Укупно време чекања (сек.)
Авг Ваит
%ДБ време
Сачекајте разред
ДБ ЦПУ
КСНУМКСК
70.4
СКЛ*Нет више података од дблинк-а
670,196
5471.5
КСНУМКСмс
3.3
мрежа
физичко читање једног блока ћелије
5,661,452
3827.6
КСНУМКСус
2.3
Кориснички И/О
Синц АСМ ребаланс
4,350,012
3481.3
КСНУМКСус
2.1
други
физичко читање више блокова ћелија
759,885
2252
КСНУМКСмс
1.4
Кориснички И/О
директан пут прочитан
374,368
1811.3
КСНУМКСмс
1.1
Кориснички И/О
СКЛ*Нет порука од дблинк-а
7,983
1725
КСНУМКСмс
1.1
мрежа
скенирање паметног стола ћелије
1,007,520
1260.7
КСНУМКСмс
0.8
Кориснички И/О
директан пут очитавање темп
520,211
808.4
КСНУМКСмс
0.5
Кориснички И/О
енк: ТМ - препирка
652
795.8
КСНУМКСмс
0.5
апликација
Следећи закључци се често извлаче из такве АВР статистике:
1. Допринос Екадата магије перформансама базе података није висок – не прелази 5%, а база података се слабо „ексадатизира“.
2. Ако се таква база података пренесе са Екадата на класичну архитектуру „сервер + низ“, онда се перформансе неће много променити. Јер чак и ако се испостави да је овај низ три пута спорији од Екадата система за складиштење (што је тешко могуће за модерне Алл Фласх низове), онда множењем 5% са три добијамо повећање удела И/О чекања на 15% - база података ће ово сигурно преживети!
Оба ова закључка су нетачна, штавише, искривљују разумевање идеје која стоји иза Екадата софтвера. Екадата не пружа само брз И/О, већ функционише фундаментално другачије у поређењу са класичном архитектуром сервер + низ. Ако је операција базе података заиста „прилагођена“, онда се СКЛ логика преноси у систем складиштења. Сервери за складиштење, захваљујући низу посебних механизама (првенствено Екадата Стораге Индекес, али не само), сами проналазе потребне податке и шаљу ДБ серверима. Они то раде прилично ефикасно, тако да је удео типичних Екадата чекања у укупном времену одговора мали.
Како ће се ово удео променити ван Екадата? Како ће то утицати на перформансе базе података у целини? Тестирање ће најбоље одговорити на ова питања. На пример, чекање на „скенирање паметне табеле ћелије“ изван Екадата може да се претвори у тако тешко скенирање целе табеле да И/О заузима целокупно време одговора и перформансе се драстично смањују. Због тога је погрешно, када се анализира АВР, сматрати укупан проценат очекивања Екадата као допринос његове магије перформансама, а још више користити овај проценат за предвиђање перформанси ван Екадата. Да бисте разумели колико је „тачан“ рад базе података, потребно је да проучите АВР статистику одељка „Статистике активности инстанце“ (постоји много статистика са називима који су сами по себи разумљиви) и упоредите их међусобно.
А да бисте разумели како ће се осећати база података изван Екадата, најбоље је направити клон базе података из резервне копије на циљној архитектури и анализирати перформансе овог клона под оптерећењем. Власници Екадата, по правилу, имају ову прилику.
Аутор: Алексеј Струченко, шеф одељења базе података Јет Инфосистема
Извор: ввв.хабр.цом