2. Geneza problemu
Aplikacja o silnych wymaganiach zwizanych z bezpieczestwem
zostaje wdro甜ona na produkcje
Administratorzy obserwuj wysoki czas odpowiedzi aplikacji i
znaczne zu甜ycie zasob坦w CPU
Poniewa甜 aplikacja uruchomiona jest w chmurze, podjto decyzj o
zwikszeniu zasob坦w CPU (zapotrzebowanie na moc)
Zmniejsza to nieco wysoki czas odpowiedzi, ale zasoby nadal
konsumowane s w takim samym zakresie
3. Dlaczego pro
fi
lowanie na CPU jest wa甜ne?
Aplikacje w chmurach zu甜ywajc zasoby (CPU)
przyczyniaj si do znacznego zwikszenia koszt坦w
utrzymania (pacimy za moc CPU)
Aplikacje on-premise w przypadku znacznego zu甜ycia
zasob坦w CPU wymagaj skalowania (powieszenia iloci
instancji
Generowany jest wikszy lad wglowy :)
4. Objawy - podstawowy monitoring
Aplikacja uruchomiona jest
w kontenerze
Poniewa甜 do kontenera
przydzielone jest 2 CPU,
aplikacja utylizuje ponad
90% mocy
5. Flopsar - pierwsza ocena
Wstpny raport wydajnoci
aplikacji pokazuje do niski
redni czas odpowiedzi, ale
znacznie zu甜ycie zasob坦w CPU
(ponad 25%) i problem na
metodzie worker
Dalszy krok badania polega na
oszacowaniu gstoci rozkadu
甜da (link Grid z prawej strony
wykresu)
6. Gsto rozkadu 甜da
Grupa niewielkiej iloci wywoa
tworzcych skupienie w okolicy 20
sekund
Reszta operacji wykonywana w
czasie do 2 sekund. Zwraca uwag
du甜a ilo wywoa w jednostce
czasowej (okoo 50 tysicy na 30 sek)
7. Jakie operacje tworz skupienia?
Kliknicie w kwadrat w
skupieniu 20 sekundowym
daje nam odpowied添: S to
operacje (serwisy) typu
highcpu.HashingWorker
Pozostae operacje to
MathWorker oraz
SleepingWorker
11. Wnioski kocowe
Caa analiza trwaa poni甜ej jednej minuty. Czy dao by
si okreli przyczyn tego problemu bez Flopsar?
Oczywicie 甜e tak.
Pytanie otwarte - jakimi zasobami i w jakim czasie.