Ako administrirate virtualnu infrastrukturu temeljenu na VMware vSphere (ili bilo kojem drugom tehnološkom nizu), vjerojatno često čujete pritužbe korisnika: "Virtualni stroj je spor!" U ovoj seriji članaka analizirat ću metriku performansi i reći vam što i zašto usporava i kako se pobrinuti da ne usporava.
Razmotrit ću sljedeće aspekte performansi virtualnog stroja:
- CPU,
- RADNA MEMORIJA,
- DISK,
- Mreža.
Počet ću s CPU-om.
Za analizu izvedbe trebat će nam:
- Brojači performansi vCenter – brojači performansi, čiji se grafikoni mogu vidjeti kroz vSphere Client. Informacije o ovim brojačima dostupne su u bilo kojoj verziji klijenta (“debeli” klijent u C#, web klijent u Flexu i web klijent u HTML5). U ovim člancima koristit ćemo snimke zaslona iz C# klijenta, samo zato što bolje izgledaju u minijaturi :)
- ESXTOP – uslužni program koji se pokreće iz ESXi naredbenog retka. Uz njegovu pomoć možete dobiti vrijednosti brojača performansi u stvarnom vremenu ili učitati te vrijednosti za određeno razdoblje u .csv datoteku za daljnju analizu. Zatim ću vam reći više o ovom alatu i dati nekoliko korisnih poveznica na dokumentaciju i članke o toj temi.
Malo teorije
U ESXi-ju, zaseban proces – svijet u VMware terminologiji – odgovoran je za rad svakog vCPU-a (jezgre virtualnog stroja). Postoje i servisni procesi, ali sa stajališta analize performansi VM-a oni su manje zanimljivi.
Proces u ESXi može biti u jednom od četiri stanja:
- trčanje – proces obavlja neki koristan rad.
- Čekaj – proces ne obavlja nikakav posao (miruje) ili čeka ulaz/izlaz.
- Costop – stanje koje se javlja u višejezgrenim virtualnim strojevima. To se događa kada hipervizor CPU planer (ESXi CPU Scheduler) ne može rasporediti istovremeno izvršavanje svih aktivnih jezgri virtualnog stroja na jezgrama fizičkog poslužitelja. U fizičkom svijetu sve procesorske jezgre rade paralelno, gostujući OS unutar VM-a očekuje slično ponašanje, tako da hipervizor mora usporiti VM jezgre koje imaju mogućnost bržeg završetka ciklusa takta. U modernim verzijama ESXi, CPU planer koristi mehanizam koji se zove opušteno zajedničko raspoređivanje: hipervizor uzima u obzir jaz između "najbrže" i "najsporije" jezgre virtualnog stroja (skew). Ako razmak prijeđe određeni prag, brza jezgra ulazi u costop stanje. Ako VM jezgre provode puno vremena u ovom stanju, to može uzrokovati probleme s performansama.
- Spreman – proces ulazi u ovo stanje kada hipervizor ne može dodijeliti resurse za njegovo izvršenje. Visoke vrijednosti spremnosti mogu uzrokovati probleme s performansama VM-a.
Brojači CPU performansi osnovnog virtualnog stroja
Korištenje CPU-a, %. Prikazuje postotak upotrebe CPU-a za određeno razdoblje.
Kako analizirati? Ako VM dosljedno koristi CPU na 90% ili ima vrhova do 100%, tada imamo problema. Problemi se mogu izraziti ne samo u “sporom” radu aplikacije unutar VM-a, već iu nedostupnosti VM-a preko mreže. Ako sustav nadzora pokazuje da VM povremeno pada, obratite pozornost na vrhove u grafikonu CPU Usage.
Postoji standardni alarm koji pokazuje opterećenje CPU-a virtualnog stroja:
Što učiniti? Ako korištenje CPU-a VM-a stalno raste, možete razmisliti o povećanju broja vCPU-a (nažalost, to ne pomaže uvijek) ili o premještanju VM-a na poslužitelj sa snažnijim procesorima.
Upotreba procesora u MHz
U grafovima o upotrebi vCenter-a u % možete vidjeti samo za cijeli virtualni stroj; nema grafova za pojedinačne jezgre (u Esxtopu postoje % vrijednosti za jezgre). Za svaku jezgru možete vidjeti korištenje u MHz.
Kako analizirati? Događa se da aplikacija nije optimizirana za višejezgrenu arhitekturu: koristi samo jednu jezgru 100%, a ostale su u stanju mirovanja bez opterećenja. Na primjer, sa zadanim postavkama sigurnosne kopije, MS SQL pokreće proces samo na jednoj jezgri. Kao rezultat toga, sigurnosna kopija usporava ne zbog spore brzine diskova (to je ono na što se korisnik u početku žalio), već zato što se procesor ne može nositi. Problem je riješen promjenom parametara: sigurnosna kopija počela se izvoditi paralelno u nekoliko datoteka (odnosno, u nekoliko procesa).
Primjer neravnomjernog opterećenja jezgri.
Postoji i situacija (kao na gornjem grafikonu) kada su jezgre neravnomjerno opterećene i neke od njih imaju vršne vrijednosti od 100%. Kao i kod učitavanja samo jedne jezgre, alarm za CPU Usage neće raditi (on je za cijeli VM), ali će biti problema s performansama.
Što učiniti? Ako softver u virtualnom stroju neravnomjerno opterećuje jezgre (koristi samo jednu jezgru ili dio jezgri), nema smisla povećavati njihov broj. U tom je slučaju bolje premjestiti VM na poslužitelj s jačim procesorima.
Također možete pokušati provjeriti postavke potrošnje energije u BIOS-u poslužitelja. Mnogi administratori omogućuju High Performance način rada u BIOS-u i time onemogućuju C-state i P-state tehnologije za uštedu energije. Moderni Intelovi procesori koriste Turbo Boost tehnologiju, koja povećava frekvenciju pojedinačnih procesorskih jezgri na račun drugih jezgri. Ali radi samo kada su uključene tehnologije za uštedu energije. Ako ih onemogućimo, procesor ne može smanjiti potrošnju energije jezgri koje nisu opterećene.
VMware preporučuje da se ne onemogućuju tehnologije za uštedu energije na poslužiteljima, već da se izaberu načini koji upravljanje napajanjem prepuštaju hipervizoru što je više moguće. U tom slučaju, u postavkama potrošnje energije hipervizora morate odabrati High Performance.
Ako imate pojedinačne VM-ove (ili VM jezgre) u svojoj infrastrukturi koji zahtijevaju povećanu frekvenciju CPU-a, ispravna prilagodba potrošnje energije može značajno poboljšati njihovu izvedbu.
CPU spreman
Ako je VM jezgra (vCPU) u stanju Ready, ona ne obavlja koristan posao. Ovo se stanje događa kada hipervizor ne pronađe slobodnu fizičku jezgru kojoj se može dodijeliti vCPU proces virtualnog stroja.
Kako analizirati? Obično, ako su jezgre virtualnog stroja u stanju Ready više od 10% vremena, primijetit ćete probleme s performansama. Jednostavno rečeno, više od 10% vremena VM čeka da fizički resursi postanu dostupni.
U vCenteru možete vidjeti 2 brojača koji se odnose na CPU Ready:
- spremnost,
- Spreman.
Vrijednosti oba brojača mogu se vidjeti i za cijeli VM i za pojedinačne jezgre.
Spremnost pokazuje vrijednost odmah kao postotak, ali samo u stvarnom vremenu (podaci za zadnji sat, interval mjerenja 20 sekundi). Bolje je koristiti ovaj brojač samo za traženje problema "za petama".
Vrijednosti spremnih brojača također se mogu promatrati iz povijesne perspektive. Ovo je korisno za utvrđivanje obrazaca i za dublju analizu problema. Na primjer, ako virtualno računalo počne imati problema s performansama u određeno vrijeme, možete usporediti intervale vrijednosti CPU Ready s ukupnim opterećenjem na poslužitelju na kojem se izvodi ovaj VM i poduzeti mjere za smanjenje opterećenja (ako DRS ne uspijeva).
Spremno, za razliku od Spremnosti, nije prikazano u postocima, već u milisekundama. Ovo je brojač tipa Summation, odnosno pokazuje koliko je dugo tijekom razdoblja mjerenja VM jezgra bila u stanju Ready. Ovu vrijednost možete pretvoriti u postotak pomoću jednostavne formule:
(Vrijednost zbroja spremnosti CPU-a / (zadani interval ažuriranja grafikona u sekundama * 1000)) * 100 = % spremnosti CPU-a
Na primjer, za VM na donjem grafikonu, vršna vrijednost Ready za cijeli virtualni stroj bit će sljedeća:
Prilikom izračunavanja postotka spremnosti obratite pozornost na dvije točke:
- Vrijednost Ready za cijeli VM zbroj je Ready svih jezgri.
- Interval mjerenja. Za Real-time to je 20 sekundi, a npr. na dnevnim grafikonima 300 sekundi.
Uz aktivno rješavanje problema, ove se jednostavne točke lako mogu propustiti i dragocjeno vrijeme može se izgubiti na rješavanje nepostojećih problema.
Izračunajmo Ready na temelju podataka iz donjeg grafikona. (324474/(20*1000))*100 = 1622% za cijeli VM. Ako pogledate jezgre, nije tako strašno: 1622/64 = 25% po jezgri. U ovom slučaju, caku je prilično lako uočiti: vrijednost Ready je nerealna. Ali ako govorimo o 10–20% za cijeli VM s nekoliko jezgri, onda za svaku jezgru vrijednost može biti unutar normalnog raspona.
Što učiniti? Visoka vrijednost Ready označava da poslužitelj nema dovoljno procesorskih resursa za normalan rad virtualnih strojeva. U takvoj situaciji preostaje samo smanjiti pretplatu po procesoru (vCPU:pCPU). Očito, to se može postići smanjenjem parametara postojećih VM-ova ili migracijom dijela VM-ova na druge poslužitelje.
Zaustavljanje
Kako analizirati? Ovaj brojač je također tipa zbrajanja i pretvara se u postotke na isti način kao Spreman:
(Vrijednost sumiranja CPU-a / (zadani interval ažuriranja grafikona u sekundama * 1000)) * 100 = % CPU-a co-stop
Ovdje također treba obratiti pozornost na broj jezgri na VM-u i interval mjerenja.
U stanju costop, kernel ne obavlja koristan posao. S točnim odabirom veličine VM-a i normalnim opterećenjem poslužitelja, brojač co-stop trebao bi biti blizu nule.
U ovom slučaju, opterećenje je očito nenormalno :)
Što učiniti? Ako nekoliko VM-ova s velikim brojem jezgri radi na jednom hipervizoru i postoji prekomjerna pretplata na CPU-u, tada se brojač za zaustavljanje može povećati, što će dovesti do problema s izvedbom tih VM-ova.
Također, co-stop će se povećati ako aktivne jezgre jednog VM-a koriste niti na jednoj jezgri fizičkog poslužitelja s omogućenim hiper-treadingom. Do ove situacije može doći, na primjer, ako VM ima više jezgri nego što je fizički dostupno na poslužitelju na kojem se izvodi ili ako je postavka "preferHT" omogućena za VM. Možete pročitati o ovoj postavci .
Kako biste izbjegli probleme s performansama VM-a zbog velikog co-stopa, odaberite veličinu VM-a u skladu s preporukama proizvođača softvera koji radi na ovom VM-u i mogućnostima fizičkog poslužitelja na kojem se VM izvodi.
Nemojte dodavati jezgre u rezervi; to može uzrokovati probleme s performansama ne samo za sam VM, već i za njegove susjede na poslužitelju.
Drugi korisni CPU pokazatelji
trčanje – koliko je vremena (ms) tijekom razdoblja mjerenja vCPU bio u RUN stanju, odnosno stvarno je obavljao koristan rad.
Idle – koliko je dugo (ms) tijekom perioda mjerenja vCPU bio u stanju neaktivnosti. Visoke Idle vrijednosti nisu problem, vCPU jednostavno nije imao "što raditi."
Čekaj – koliko je dugo (ms) tijekom razdoblja mjerenja vCPU bio u stanju čekanja. Budući da je IDLE uključen u ovaj brojač, visoke vrijednosti čekanja također ne ukazuju na problem. Ali ako je Wait IDLE nizak kada je Wait visok, to znači da je VM čekao završetak I/O operacija, a to zauzvrat može ukazivati na problem s performansama tvrdog diska ili bilo kojeg virtualnog uređaja VM-a.
Max ograničeno – koliko je dugo (ms) tijekom razdoblja mjerenja vCPU bio u stanju Ready zbog postavljenog ograničenja resursa. Ako je izvedba neobjašnjivo niska, tada je korisno provjeriti vrijednost ovog brojača i ograničenje CPU-a u postavkama VM-a. VM doista mogu imati ograničenja kojih niste svjesni. Na primjer, to se događa kada je VM kloniran iz predloška na kojem je postavljeno CPU ograničenje.
Zamjena čekanja – koliko je dugo tijekom razdoblja mjerenja vCPU čekao na operaciju s VMkernel Swap. Ako su vrijednosti ovog brojača iznad nule, tada VM definitivno ima problema s performansama. O SWAP-u ćemo više govoriti u članku o RAM brojačima.
ESXTOP
Ako su brojači performansi u vCenter-u dobri za analizu povijesnih podataka, onda je operativnu analizu problema bolje napraviti u ESXTOP-u. Ovdje su sve vrijednosti predstavljene u gotovom obliku (nema potrebe ništa prevoditi), a minimalno razdoblje mjerenja je 2 sekunde.
Zaslon ESXTOP za CPU poziva se tipkom "c" i izgleda ovako:
Radi praktičnosti, možete ostaviti samo procese virtualnog stroja pritiskom na Shift-V.
Da biste vidjeli metriku za pojedinačne VM jezgre, pritisnite "e" i unesite GID VM-a od interesa (30919 na snimci zaslona u nastavku):
Dopustite mi da ukratko prođem kroz stupce koji su prikazani prema zadanim postavkama. Dodatni stupci se mogu dodati pritiskom na "f".
NWLD (Broj svjetova) – broj procesa u grupi. Da biste proširili grupu i vidjeli metriku za svaki proces (na primjer, za svaku jezgru u višejezgrenom VM-u), pritisnite "e". Ako postoji više od jednog procesa u grupi, tada su metričke vrijednosti za grupu jednake zbroju metrika za pojedinačne procese.
% KORIŠTENO – koliko CPU ciklusa poslužitelja koristi proces ili grupa procesa.
%TRČANJE – koliko je dugo tijekom perioda mjerenja proces bio u RUN stanju, tj. obavio koristan posao. Razlikuje se od %USED po tome što ne uzima u obzir hiper-nitnost, frekvencijsko skaliranje i vrijeme potrošeno na sistemske zadatke (%SYS).
%SYS – vrijeme potrošeno na sistemske zadatke, na primjer: obrada prekida, I/O, mrežni rad itd. Vrijednost može biti visoka ako VM ima veliki I/O.
%OVRLP – koliko je vremena fizička jezgra na kojoj se izvodi VM proces potrošila na zadatke drugih procesa.
Ove metrike povezane su jedna s drugom na sljedeći način:
%USED = %RUN + %SYS - %OVRLP.
Obično je metrika %ISKORIŠTENO informativnija.
%ČEKATI – koliko je dugo tijekom perioda mjerenja proces bio u stanju čekanja. Omogućuje IDLE.
%BESPOSLEN – koliko je dugo tijekom razdoblja mjerenja proces bio u stanju mirovanja.
%SWPWT – koliko je dugo tijekom razdoblja mjerenja vCPU čekao na operaciju s VMkernel Swap.
%VMWAIT – koliko je dugo tijekom perioda mjerenja vCPU bio u stanju čekanja na događaj (obično I/O). Ne postoji sličan brojač u vCentru. Visoke vrijednosti ukazuju na probleme s I/O na VM-u.
%ČEKAJ = %VMČEKAJ + %IDLE + %SWPWT.
Ako VM ne koristi VMkernel Swap, tada je pri analizi problema s performansama preporučljivo pogledati %VMWAIT, jer ova metrika ne uzima u obzir vrijeme kada VM nije radio ništa (%IDLE).
%RDY – koliko je dugo tijekom razdoblja mjerenja proces bio u stanju Ready.
%CSTP – koliko je dugo tijekom razdoblja mjerenja proces bio u stanju costop.
%MLMTD – koliko je dugo tijekom razdoblja mjerenja vCPU bio u stanju Ready zbog postavljenog ograničenja resursa.
%WAIT + %RDY + %CSTP + %RUN = 100% – VM jezgra je uvijek u jednom od ova četiri stanja.
CPU na hipervizoru
vCenter također ima brojače CPU performansi za hipervizor, ali oni nisu ništa zanimljivo - oni su jednostavno zbroj brojača za sve VM-ove na poslužitelju.
Najprikladniji način za pregled statusa procesora na poslužitelju je na kartici Sažetak:
Za poslužitelj, kao i za virtualni stroj, postoji standardni alarm:
Kada je opterećenje CPU-a poslužitelja veliko, VM-ovi koji rade na njemu počinju imati problema s performansama.
U ESXTOP-u podaci o opterećenju procesora poslužitelja prikazani su na vrhu zaslona. Uz standardno opterećenje CPU-a, koje nije baš informativno za hipervizore, postoje još tri metrike:
CORE UTIL (%) – učitavanje jezgre fizičkog poslužitelja. Ovaj brojač pokazuje koliko je vremena jezgra radila tijekom perioda mjerenja.
PCPU UTIL (%) – ako je hiper-nitnost omogućena, tada postoje dvije niti (PCPU) po fizičkoj jezgri. Ova metrika pokazuje koliko je svakoj niti trebalo da dovrši posao.
KORIŠTENI PCPU (%) – isto kao i PCPU UTIL(%), ali uzima u obzir skaliranje frekvencije (bilo smanjenje frekvencije jezgre u svrhu uštede energije ili povećanje frekvencije jezgre zbog tehnologije Turbo Boost) i hiper-nitnost.
PCPU_USED% = PCPU_UTIL% * efektivna frekvencija jezgre / nominalna frekvencija jezgre.
Na ovoj snimci zaslona, za neke jezgre, zbog Turbo Boosta, USED vrijednost je veća od 100%, jer je frekvencija jezgre viša od nominalne.
Nekoliko riječi o tome kako se uzima u obzir hipernitnost. Ako se procesi izvode 100% vremena na obje niti fizičke jezgre poslužitelja, dok jezgra radi na nominalnoj frekvenciji, tada:
- CORE UTIL za jezgru bit će 100%,
- PCPU UTIL za obje niti će biti 100%,
- PCPU USED za obje niti bit će 50%.
Ako obje niti nisu radile 100% vremena tijekom razdoblja mjerenja, tada se tijekom tih razdoblja kada su niti radile paralelno, PCPU KORIŠTEN za jezgre dijeli na pola.
ESXTOP također ima ekran s parametrima potrošnje CPU-a poslužitelja. Ovdje možete vidjeti da li poslužitelj koristi tehnologije za uštedu energije: C-stanja i P-stanja. Poziva se tipkom "p":
Uobičajeni problemi s performansama procesora
Na kraju ću proći kroz tipične uzroke problema s performansama VM CPU-a i dati kratke savjete za njihovo rješavanje:
Takt jezgre nije dovoljan. Ako nije moguće nadograditi svoj VM na snažnije jezgre, možete pokušati promijeniti postavke napajanja kako bi Turbo Boost radio učinkovitije.
Neispravna veličina VM-a (previše/malo jezgri). Ako instalirate nekoliko jezgri, doći će do velikog opterećenja CPU-a na VM-u. Ako je puno, uhvatite visoki co-stop.
Velika prekomjerna pretplata CPU-a na poslužitelju. Ako VM ima visoku Ready, smanjite prekomjernu pretplatu na CPU.
Netočna NUMA topologija na velikim VM-ovima. NUMA topologija koju vidi VM (vNUMA) mora odgovarati NUMA topologiji poslužitelja (pNUMA). Dijagnostika i moguća rješenja ovog problema napisana je npr. u knjizi . Ako ne želite ići dublje i nemate ograničenja licenciranja za OS instaliran na VM-u, napravite mnogo virtualnih utičnica na VM-u, jednu jezgru po jednu. Nećete puno izgubiti :)
To je sve što se mene tiče CPU-a. Postavljati pitanja. U sljedećem dijelu govorit ću o RAM-u.
korisni linkovi
Izvor: www.habr.com