Ako administrirate virtuelnu infrastrukturu zasnovanu na VMware vSphere (ili bilo kom drugom tehnološkom steku), vjerovatno ćete često čuti pritužbe korisnika: „Virtuelna mašina je spora!“ U ovoj seriji članaka analizirat ću metriku performansi i reći vam šta i zašto usporava i kako osigurati da se ne usporava.
Razmotrit ću sljedeće aspekte performansi virtuelne mašine:
- procesor,
- FRAME,
- DISK,
- Mreža.
Počeću sa CPU-om.
Za analizu učinka trebat će nam:
- vCenter Performance Counters – brojači performansi, čiji se grafikoni mogu pogledati kroz vSphere klijent. 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 ćemo koristiti screenshotove sa C# klijenta, samo zato što izgledaju bolje u minijaturi :)
- ESXTOP – uslužni program koji se pokreće iz komandne linije ESXi. Uz njegovu pomoć možete dobiti vrijednosti brojača performansi u realnom vremenu ili prenijeti te vrijednosti za određeni period u .csv datoteku za dalju analizu. Zatim ću vam reći više o ovom alatu i pružiti nekoliko korisnih veza do dokumentacije i članaka na tu temu.
Malo teorije
U ESXi, poseban proces – svet u VMware terminologiji – odgovoran je za rad svakog vCPU-a (jezgra virtuelne mašine). Postoje i servisni procesi, ali sa stanoviš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 posao.
- čekajte – proces ne radi nikakav posao (u mirovanju) ili čeka na ulaz/izlaz.
- Costop – stanje koje se javlja u virtuelnim mašinama sa više jezgara. Događa se kada planer CPU hipervizora (ESXi CPU Scheduler) ne može zakazati istovremeno izvršavanje svih aktivnih jezgara virtuelne mašine na fizičkim jezgrama servera. 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 jezgre VM-a koje imaju mogućnost da brže završe svoj ciklus takta. U modernim verzijama ESXi-a, CPU planer koristi mehanizam koji se zove opušteno zajedničko planiranje: hipervizor razmatra jaz između „najbrže“ i „najsporije“ jezgre virtuelne mašine (iskrivljeno). Ako jaz pređe određeni prag, brzo jezgro ulazi u kostop stanje. Ako jezgre VM-a provode mnogo vremena u ovom stanju, to može uzrokovati probleme s performansama.
- spreman – proces ulazi u ovo stanje kada hipervizor nije u mogućnosti da dodijeli resurse za njegovo izvršenje. Visoke vrijednosti spremnosti mogu uzrokovati probleme s performansama VM-a.
Osnovni brojači CPU performansi virtuelne mašine
Upotreba CPU-a, %. Prikazuje postotak korištenja CPU-a za dati period.
Kako analizirati? Ako VM dosljedno koristi CPU na 90% ili ima vrhova do 100%, onda imamo problema. Problemi se mogu izraziti ne samo u “sporom” radu aplikacije unutar VM-a, već iu nedostupnosti VM-a preko mreže. Ako sistem za praćenje pokaže da VM periodično pada, obratite pažnju na vrhove u grafikonu upotrebe CPU-a.
Postoji standardni alarm koji pokazuje opterećenje CPU-a virtuelne mašine:
Što da radim? Ako korištenje CPU-a VM-a stalno ide preko krova, onda možete razmišljati o povećanju broja vCPU-ova (nažalost, to ne pomaže uvijek) ili premještanju VM-a na server sa moćnijim procesorima.
Upotreba CPU-a u MHz
Na grafikonima o korištenju vCenter u % možete vidjeti samo za cijelu virtualnu mašinu; nema grafikona za pojedinačna jezgra (u Esxtop-u postoje % vrijednosti za jezgre). Za svaku jezgru možete vidjeti korištenje u MHz.
Kako analizirati? Dešava se da aplikacija nije optimizirana za višejezgrenu arhitekturu: koristi samo jednu jezgru 100%, a ostale su neaktivne bez opterećenja. Na primjer, sa zadanim postavkama sigurnosne kopije, MS SQL pokreće proces na samo jednoj jezgri. Kao rezultat toga, sigurnosna kopija se usporava ne zbog male brzine diskova (na to se korisnik u početku žalio), već zato što se procesor ne može nositi. Problem je riješen promjenom parametara: backup je počeo paralelno raditi u nekoliko datoteka (odnosno u nekoliko procesa).
Primjer neravnomjernog opterećenja jezgara.
Postoji i situacija (kao na gornjem grafikonu) kada su jezgre neravnomjerno opterećene i neke od njih imaju vrhove od 100%. Kao i kod učitavanja samo jedne jezgre, alarm za korištenje CPU-a neće raditi (to je za cijeli VM), ali će biti problema s performansama.
Što da radim? Ako softver u virtuelnoj mašini neravnomerno učitava jezgra (koristi samo jedno jezgro ili deo jezgara), nema smisla povećavati njihov broj. U ovom slučaju, bolje je premjestiti VM na server sa snažnijim procesorima.
Također možete pokušati provjeriti postavke potrošnje energije u BIOS-u servera. Mnogi administratori omogućavaju režim visokih performansi u BIOS-u i na taj način onemogućavaju tehnologije za uštedu energije C-state i P-state. Moderni Intel procesori koriste Turbo Boost tehnologiju, koja povećava frekvenciju pojedinačnih procesorskih jezgara na račun ostalih jezgara. 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 serverima, već da se izaberu načini koji prepuštaju upravljanje napajanjem 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 (ili VM jezgre) u svojoj infrastrukturi koje zahtijevaju povećanu frekvenciju CPU-a, ispravno podešavanje potrošnje energije može značajno poboljšati njihove performanse.
CPU Ready
Ako je jezgro VM (vCPU) u stanju Ready, ono ne obavlja koristan rad. Ovaj uslov se javlja kada hipervizor ne pronađe slobodnu fizičku jezgru kojoj se može dodijeliti vCPU proces virtualne mašine.
Kako analizirati? Obično, ako su jezgra virtuelne mašine u stanju pripravnosti više od 10% vremena, primetićete probleme sa performansama. Jednostavno rečeno, više od 10% vremena VM čeka da fizički resursi postanu dostupni.
U vCenter možete pogledati 2 brojača vezana za CPU Ready:
- spremnost,
- Spreman.
Vrijednosti oba brojača mogu se vidjeti i za cijeli VM i za pojedinačna jezgra.
Spremnost prikazuje vrijednost odmah u postocima, ali samo u realnom vremenu (podaci za posljednji sat, interval mjerenja 20 sekundi). Bolje je koristiti ovaj brojač samo za traženje problema „vrućih za petama“.
Spremne vrijednosti brojača također se mogu posmatrati iz istorijske perspektive. Ovo je korisno za uspostavljanje obrazaca i za dublju analizu problema. Na primjer, ako virtuelna mašina počne da ima problema sa performansama u određenom trenutku, možete uporediti intervale vrednosti CPU Ready sa ukupnim opterećenjem na serveru na kome radi ovaj VM i preduzeti mere za smanjenje opterećenja (ako DRS ne uspije).
Spremnost, za razliku od Readiness, se ne prikazuje u procentima, već u milisekundama. Ovo je brojač tipa sumiranja, odnosno pokazuje koliko je dugo tokom perioda mjerenja jezgro VM bilo u stanju Ready. Ovu vrijednost možete pretvoriti u postotak koristeći jednostavnu formulu:
(Zbirna vrijednost CPU-a / (zadani interval ažuriranja grafikona u sekundama * 1000)) * 100 = CPU spreman %
Na primjer, za VM na grafikonu ispod, vršna vrijednost Ready za cijelu virtuelnu mašinu će biti sljedeća:
Prilikom izračunavanja postotka spremnosti obratite pažnju na dvije točke:
- Vrijednost Ready za cijeli VM je zbir Ready u svim jezgrama.
- Interval mjerenja. Za Real-time je 20 sekundi, a na primjer, na dnevnim grafikonima je 300 sekundi.
Uz aktivno rješavanje problema, ove jednostavne točke se lako mogu propustiti i vrijedno vrijeme se može izgubiti na rješavanje nepostojećih problema.
Izračunajmo Ready na osnovu podataka iz grafikona ispod. (324474/(20*1000))*100 = 1622% za cijeli VM. Ako pogledate jezgre nije tako strašno: 1622/64 = 25% po jezgru. U ovom slučaju, kvaku je prilično lako uočiti: vrijednost Ready je nerealna. Ali ako govorimo o 10-20% za cijeli VM s nekoliko jezgara, tada za svaku jezgru vrijednost može biti unutar normalnog raspona.
Što da radim? Visoka vrijednost Ready ukazuje da server nema dovoljno procesorskih resursa za normalan rad virtuelnih mašina. U takvoj situaciji, ostaje samo da se smanji pretplata po procesoru (vCPU:pCPU). Očigledno, ovo se može postići smanjenjem parametara postojećih VM-ova ili migracijom dijela VM-a na druge servere.
Co-stop
Kako analizirati? Ovaj brojač je takođe tipa sumiranja i pretvara se u procente na isti način kao i Ready:
(CPU co-stop vrijednost zbrajanja / (podrazumevani interval ažuriranja grafikona u sekundama * 1000)) * 100 = CPU co-stop %
Ovdje također morate obratiti pažnju na broj jezgara na VM-u i interval mjerenja.
U Costop stanju, kernel ne obavlja koristan rad. Sa ispravnim odabirom veličine VM-a i normalnim opterećenjem na serveru, brojač ko-stop bi trebao biti blizu nule.
U ovom slučaju, opterećenje je očito nenormalno :)
Što da radim? Ako nekoliko VM-ova sa velikim brojem jezgri radi na jednom hipervizoru i postoji prekomjerna pretplata na CPU-u, tada se brojač co-stop može povećati, što će dovesti do problema s performansama ovih VM-ova.
Takođe, ko-stop će se povećati ako aktivna jezgra jednog VM-a koriste niti na jednom fizičkom jezgru servera sa omogućenim hiper-treadingom. Ova situacija može nastati, na primjer, ako VM ima više jezgara nego što je fizički dostupno na serveru na kojem radi, ili ako je postavka „preferHT“ omogućena za VM. Možete pročitati o ovoj postavci .
Da biste izbjegli probleme s performansama VM-a zbog visokog zajedničkog zaustavljanja, odaberite veličinu VM-a u skladu s preporukama proizvođača softvera koji radi na ovom VM-u i mogućnostima fizičkog servera na kojem VM radi.
Nemojte dodavati jezgra u rezervi; to može uzrokovati probleme u performansama ne samo za sam VM, već i za njegove susjede na serveru.
Ostale korisne CPU metrike
trčanje – koliko je vremena (ms) tokom perioda mjerenja vCPU bio u stanju RUN, odnosno, zapravo je obavljao koristan posao.
Idle – koliko dugo (ms) tokom perioda mjerenja vCPU je bio u stanju neaktivnosti. Visoke vrijednosti u stanju mirovanja nisu problem, vCPU jednostavno nije imao „šta da radi“.
čekajte – koliko dugo (ms) tokom perioda mjerenja vCPU je 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 da se I/O operacije dovrše, a to, zauzvrat, može ukazivati na problem sa performansama čvrstog diska ili bilo kojeg virtuelnog uređaja VM.
Max ograničen – koliko dugo (ms) tokom perioda mjerenja vCPU je bio u stanju Ready zbog postavljenog ograničenja resursa. Ako su performanse neobjašnjivo niske, onda je korisno provjeriti vrijednost ovog brojača i CPU limit u postavkama VM-a. VM-ovi zaista mogu imati ograničenja kojih niste svjesni. Na primjer, ovo se dešava kada je VM kloniran iz šablona na kojem je postavljeno ograničenje CPU-a.
Zameni čekaj – koliko je dugo tokom perioda mjerenja vCPU čekao na operaciju sa VMkernel Swap. Ako su vrijednosti ovog brojača iznad nule, onda VM definitivno ima problema s performansama. Više o SWAP-u ćemo govoriti u članku o RAM brojačima.
ESXTOP
Ako su brojači performansi u vCenter-u dobri za analizu istorijskih podataka, onda je operativnu analizu problema bolje uraditi u ESXTOP-u. Ovdje su sve vrijednosti predstavljene u gotovom obliku (nema potrebe da se bilo šta prevodi), a minimalno vrijeme mjerenja je 2 sekunde.
ESXTOP ekran za CPU se poziva tipkom "c" i izgleda ovako:
Radi praktičnosti, možete ostaviti samo procese virtuelne mašine pritiskom na Shift-V.
Da vidite metriku za pojedinačna jezgra VM-a, pritisnite “e” i unesite GID VM-a od interesa (30919 na slici ispod):
Dozvolite mi da ukratko prođem kroz kolone koje su podrazumevano predstavljene. Dodatne kolone se mogu dodati pritiskom na "f".
NWLD (Broj svjetova) – broj procesa u grupi. Da proširite grupu i vidite 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.
%USED – koliko ciklusa CPU servera koristi proces ili grupa procesa.
%RUN – koliko je dugo tokom perioda mjerenja proces bio u RUN stanju, tj. obavio koristan posao. Razlikuje se od %USED po tome što ne uzima u obzir hiper-nitovanje, skaliranje frekvencije i vrijeme provedeno na sistemskim zadacima (%SYS).
%SYS – vrijeme provedeno na sistemskim zadacima, na primjer: obrada prekida, I/O, rad mreže, itd. Vrijednost može biti visoka ako VM ima veliki I/O.
%OVRLP – koliko je vremena fizičko jezgro na kojem se pokreće VM proces potrošilo na zadatke drugih procesa.
Ove metrike su međusobno povezane na sljedeći način:
%USED = %RUN + %SYS - %OVRLP.
Obično je metrika %USED informativnija.
%WAIT – koliko dugo je tokom perioda mjerenja proces bio u stanju čekanja. Omogućava IDLE.
%IDLE – koliko dugo je tokom perioda mjerenja proces bio u stanju mirovanja.
%SWPWT – koliko je dugo tokom perioda mjerenja vCPU čekao na operaciju sa VMkernel Swap.
%VMWAIT – koliko je dugo tokom perioda mjerenja vCPU bio u stanju čekanja na događaj (obično I/O). Ne postoji sličan brojač u vCenter-u. Visoke vrijednosti ukazuju na probleme sa I/O na VM-u.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Ako VM ne koristi VMkernel Swap, tada je pri analizi problema sa performansama preporučljivo pogledati %VMWAIT, pošto ova metrika ne uzima u obzir vrijeme kada VM nije radio ništa (%IDLE).
%RDY – koliko dugo je tokom perioda mjerenja proces bio u stanju pripravnosti.
%CSTP – koliko dugo je tokom perioda mjerenja proces bio u kostop stanju.
%MLMTD – koliko je dugo tokom perioda mjerenja vCPU bio u stanju Ready zbog postavljenog ograničenja resursa.
%WAIT + %RDY + %CSTP + %RUN = 100% – VM jezgro je uvijek u jednom od ova četiri stanja.
CPU na hipervizoru
vCenter takođe ima brojače CPU performansi za hipervizor, ali oni nisu ništa zanimljivi - oni su jednostavno zbir brojača za sve VM-ove na serveru.
Najpogodniji način da vidite status procesora na serveru je na kartici Sažetak:
Za server, kao i za virtuelnu mašinu, postoji standardni alarm:
Kada je opterećenje CPU-a servera veliko, VM-ovi koji rade na njemu počinju imati probleme s performansama.
U ESXTOP-u, podaci o učitavanju CPU servera su predstavljeni na vrhu ekrana. Pored standardnog opterećenja CPU-a, koje nije baš informativno za hipervizore, postoje još tri metrike:
CORE UTIL(%) – učitavanje fizičkog jezgra servera. Ovaj brojač pokazuje koliko je vremena jezgro obavljalo rad tokom perioda merenja.
PCPU UTIL(%) – ako je omogućeno hiper-nitiranje, tada postoje dvije niti (PCPU) po fizičkom jezgru. Ova metrika pokazuje koliko je vremena svakoj niti bilo potrebno da završi posao.
KORIŠTEN PCPU(%) – isto što i PCPU UTIL(%), ali uzima u obzir skaliranje frekvencije (bilo smanjenje frekvencije jezgre u svrhu uštede energije ili povećanje frekvencije jezgre zbog Turbo Boost tehnologije) i hiper-nitovanje.
PCPU_USED% = PCPU_UTIL% * efektivna frekvencija jezgra / nominalna frekvencija jezgra.
Na ovom snimku ekrana, za neke jezgre, zbog Turbo Boosta, USED vrijednost je veća od 100%, pošto je frekvencija jezgre viša od nominalne.
Nekoliko riječi o tome kako se uzima u obzir hyper-threading. Ako se procesi izvode 100% vremena na obje niti fizičkog jezgra servera, dok jezgro radi na nominalnoj frekvenciji, tada:
- CORE UTIL za jezgru će biti 100%,
- PCPU UTIL za obje niti će biti 100%,
- PCPU KORIŠTEN za obje niti će biti 50%.
Ako obe niti nisu radile 100% vremena tokom perioda merenja, tada se tokom perioda kada su niti radile paralelno, PCPU KORIŠTEN za jezgre deli na pola.
ESXTOP takođe ima ekran sa parametrima potrošnje CPU servera. Ovdje možete vidjeti da li server koristi tehnologije za uštedu energije: C-stanja i P-stanja. Poziva se tipkom "p":
Uobičajeni problemi sa performansama procesora
Konačno, proći ću preko tipičnih uzroka problema s performansama VM CPU-a i dati kratke savjete za njihovo rješavanje:
Brzina takta jezgre nije dovoljna. Ako nije moguće nadograditi svoj VM na snažnija jezgra, možete pokušati promijeniti postavke napajanja kako bi Turbo Boost radio efikasnije.
Netačna veličina VM-a (previše/malo jezgara). Ako instalirate nekoliko jezgara, na VM-u će biti veliko CPU opterećenje. Ako ima puno, uhvatite visoko zaustavljanje.
Velika pretplata CPU-a na serveru. Ako VM ima visoku Ready, smanjite pretplatu na CPU.
Neispravna NUMA topologija na velikim VM-ovima. NUMA topologija koju vidi VM (vNUMA) mora odgovarati NUMA topologiji servera (pNUMA). Dijagnostika i moguća rješenja ovog problema su, na primjer, napisana 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 po jezgru. Neces puno izgubiti :)
To je sve za mene o CPU-u. Postavljati pitanja. U sljedećem dijelu govorit ću o RAM-u.
korisni linkovi
izvor: www.habr.com