VMware vSphere માં વર્ચ્યુઅલ મશીન પ્રદર્શનનું વિશ્લેષણ. ભાગ 1: CPU

જો તમે VMware vSphere (અથવા કોઈપણ અન્ય ટેક્નોલોજી સ્ટેક) પર આધારિત વર્ચ્યુઅલ ઈન્ફ્રાસ્ટ્રક્ચરનું સંચાલન કરો છો, તો તમે કદાચ વારંવાર વપરાશકર્તાઓ તરફથી ફરિયાદો સાંભળો છો: "વર્ચ્યુઅલ મશીન ધીમું છે!" લેખોની આ શ્રેણીમાં હું પ્રદર્શન મેટ્રિક્સનું વિશ્લેષણ કરીશ અને તમને કહીશ કે તે શું અને શા માટે ધીમું થાય છે અને તે કેવી રીતે ધીમું ન થાય તેની ખાતરી કેવી રીતે કરવી.

હું વર્ચ્યુઅલ મશીન પ્રદર્શનના નીચેના પાસાઓને ધ્યાનમાં લઈશ:

• સીપીયુ,
• ફ્રેમ,
• ડિસ્ક,
• નેટવર્ક.

હું CPU થી શરૂઆત કરીશ.

પ્રદર્શનનું વિશ્લેષણ કરવા માટે અમને જરૂર પડશે:

• vCenter પ્રદર્શન કાઉન્ટર્સ - પરફોર્મન્સ કાઉન્ટર્સ, જેના ગ્રાફ vSphere ક્લાયંટ દ્વારા જોઈ શકાય છે. આ કાઉન્ટર્સ પરની માહિતી ક્લાયંટના કોઈપણ સંસ્કરણમાં ઉપલબ્ધ છે (C# માં "જાડા" ક્લાયંટ, ફ્લેક્સમાં વેબ ક્લાયંટ અને HTML5 માં વેબ ક્લાયંટ). આ લેખોમાં અમે C# ક્લાયન્ટના સ્ક્રીનશૉટ્સનો ઉપયોગ કરીશું, માત્ર એટલા માટે કે તેઓ લઘુચિત્રમાં વધુ સારા દેખાય છે :)
• ESXTOP - એક ઉપયોગિતા જે ESXi કમાન્ડ લાઇનથી ચાલે છે. તેની મદદથી, તમે રીઅલ ટાઇમમાં પરફોર્મન્સ કાઉન્ટર્સના મૂલ્યો મેળવી શકો છો અથવા વધુ વિશ્લેષણ માટે આ મૂલ્યોને ચોક્કસ સમયગાળા માટે .csv ફાઇલમાં અપલોડ કરી શકો છો. આગળ, હું તમને આ ટૂલ વિશે વધુ કહીશ અને વિષય પરના દસ્તાવેજો અને લેખોની કેટલીક ઉપયોગી લિંક્સ પ્રદાન કરીશ.

સિદ્ધાંત એક બીટ

ESXi માં, એક અલગ પ્રક્રિયા - VMware પરિભાષામાં વિશ્વ - દરેક vCPU (વર્ચ્યુઅલ મશીન કોર) ના સંચાલન માટે જવાબદાર છે. ત્યાં સેવા પ્રક્રિયાઓ પણ છે, પરંતુ VM પ્રદર્શનનું વિશ્લેષણ કરવાના દૃષ્ટિકોણથી તે ઓછા રસપ્રદ છે.

ESXi માં પ્રક્રિયા ચારમાંથી એક સ્થિતિમાં હોઈ શકે છે:

• ચલાવો - પ્રક્રિયા કેટલાક ઉપયોગી કાર્ય કરે છે.
• રાહ જુઓ - પ્રક્રિયા કોઈપણ કાર્ય (નિષ્ક્રિય) કરી રહી નથી અથવા ઇનપુટ/આઉટપુટની રાહ જોઈ રહી છે.
• કોસ્ટોપ – એવી સ્થિતિ જે મલ્ટી-કોર વર્ચ્યુઅલ મશીનોમાં થાય છે. તે ત્યારે થાય છે જ્યારે હાઇપરવાઇઝર CPU શેડ્યૂલર (ESXi CPU શેડ્યૂલર) ભૌતિક સર્વર કોરો પર તમામ સક્રિય વર્ચ્યુઅલ મશીન કોરોના એક સાથે એક્ઝેક્યુશનને શેડ્યૂલ કરી શકતું નથી. ભૌતિક વિશ્વમાં, બધા પ્રોસેસર કોરો સમાંતર રીતે કામ કરે છે, VM ની અંદર ગેસ્ટ OS સમાન વર્તનની અપેક્ષા રાખે છે, તેથી હાઇપરવાઇઝરને VM કોરોને ધીમું કરવું પડે છે જે તેમની ઘડિયાળ ચક્રને ઝડપથી સમાપ્ત કરવાની ક્ષમતા ધરાવે છે. ESXi ના આધુનિક સંસ્કરણોમાં, CPU શેડ્યૂલર રિલેક્સ્ડ કો-શેડ્યુલિંગ નામની પદ્ધતિનો ઉપયોગ કરે છે: હાઇપરવાઇઝર "સૌથી ઝડપી" અને "ધીમી" વર્ચ્યુઅલ મશીન કોર (સ્ક્યુ) વચ્ચેના અંતરને ધ્યાનમાં લે છે. જો ગેપ ચોક્કસ થ્રેશોલ્ડ કરતાં વધી જાય, તો ફાસ્ટ કોર કોસ્ટોપ સ્ટેટમાં પ્રવેશે છે. જો VM કોરો આ સ્થિતિમાં ઘણો સમય વિતાવે છે, તો તે પ્રદર્શન સમસ્યાઓનું કારણ બની શકે છે.
• તૈયાર - પ્રક્રિયા આ સ્થિતિમાં પ્રવેશે છે જ્યારે હાઇપરવાઇઝર તેના અમલ માટે સંસાધનો ફાળવવામાં અસમર્થ હોય છે. ઉચ્ચ તૈયાર મૂલ્યો VM પ્રદર્શન સમસ્યાઓનું કારણ બની શકે છે.

મૂળભૂત વર્ચ્યુઅલ મશીન CPU પ્રદર્શન કાઉન્ટર્સ

CPU વપરાશ, %. આપેલ સમયગાળા માટે CPU વપરાશની ટકાવારી બતાવે છે.

કેવી રીતે વિશ્લેષણ કરવું? જો VM સતત 90% પર CPU નો ઉપયોગ કરે છે અથવા 100% સુધીના શિખરો છે, તો અમને સમસ્યાઓ છે. સમસ્યાઓ ફક્ત VM ની અંદર એપ્લિકેશનના "ધીમી" કામગીરીમાં જ નહીં, પણ નેટવર્ક પર VM ની અપ્રાપ્યતામાં પણ વ્યક્ત કરી શકાય છે. જો મોનિટરિંગ સિસ્ટમ બતાવે છે કે VM સમયાંતરે બંધ થાય છે, તો CPU વપરાશ ગ્રાફમાં શિખરો પર ધ્યાન આપો.

ત્યાં એક પ્રમાણભૂત એલાર્મ છે જે વર્ચ્યુઅલ મશીનનો CPU લોડ દર્શાવે છે:

મારે શું કરવું જોઈએ? જો VM નો CPU વપરાશ સતત છતમાંથી પસાર થઈ રહ્યો છે, તો પછી તમે vCPU ની સંખ્યા વધારવા વિશે વિચારી શકો છો (કમનસીબે, આ હંમેશા મદદ કરતું નથી) અથવા VM ને વધુ શક્તિશાળી પ્રોસેસર્સવાળા સર્વર પર ખસેડવાનું.

MHz માં CPU વપરાશ

% માં vCenter વપરાશ પરના ગ્રાફમાં તમે ફક્ત સમગ્ર વર્ચ્યુઅલ મશીન માટે જ જોઈ શકો છો; વ્યક્તિગત કોરો માટે કોઈ આલેખ નથી (Extop માં કોરો માટે % મૂલ્યો છે). દરેક કોર માટે તમે MHz માં ઉપયોગ જોઈ શકો છો.

કેવી રીતે વિશ્લેષણ કરવું? એવું બને છે કે એપ્લિકેશન મલ્ટિ-કોર આર્કિટેક્ચર માટે ઑપ્ટિમાઇઝ નથી: તે ફક્ત એક કોર 100% વાપરે છે, અને બાકીના લોડ વિના નિષ્ક્રિય છે. ઉદાહરણ તરીકે, ડિફોલ્ટ બેકઅપ સેટિંગ્સ સાથે, MS SQL માત્ર એક કોર પર પ્રક્રિયા શરૂ કરે છે. પરિણામે, ડિસ્કની ધીમી ગતિને કારણે બેકઅપ ધીમો પડી જાય છે (આ તે છે જેના વિશે વપરાશકર્તાએ શરૂઆતમાં ફરિયાદ કરી હતી), પરંતુ પ્રોસેસર તેનો સામનો કરી શકતું નથી. પરિમાણો બદલીને સમસ્યા હલ કરવામાં આવી હતી: બેકઅપ ઘણી ફાઇલોમાં સમાંતર ચાલવાનું શરૂ કર્યું (અનુક્રમે, ઘણી પ્રક્રિયાઓમાં).

કોરો પર અસમાન ભારનું ઉદાહરણ.

એવી સ્થિતિ પણ છે (ઉપરના ગ્રાફની જેમ) જ્યારે કોરો અસમાન રીતે લોડ થાય છે અને તેમાંના કેટલાકમાં 100% ની ટોચ હોય છે. જેમ કે માત્ર એક કોર લોડ કરવા સાથે, CPU વપરાશ માટેનું એલાર્મ કામ કરશે નહીં (તે સમગ્ર VM માટે છે), પરંતુ પ્રદર્શન સમસ્યાઓ હશે.

મારે શું કરવું જોઈએ? જો વર્ચ્યુઅલ મશીનમાં સોફ્ટવેર અસમાન રીતે કોરોને લોડ કરે છે (માત્ર એક કોર અથવા કોરોનો ભાગ વાપરે છે), તો તેમની સંખ્યા વધારવાનો કોઈ અર્થ નથી. આ કિસ્સામાં, VM ને વધુ શક્તિશાળી પ્રોસેસર્સવાળા સર્વર પર ખસેડવું વધુ સારું છે.

તમે સર્વર BIOS માં પાવર વપરાશ સેટિંગ્સને તપાસવાનો પણ પ્રયાસ કરી શકો છો. ઘણા એડમિનિસ્ટ્રેટરો BIOS માં ઉચ્ચ પ્રદર્શન મોડને સક્ષમ કરે છે અને ત્યાંથી C-સ્ટેટ્સ અને P-સ્ટેટ્સ ઊર્જા બચત તકનીકોને અક્ષમ કરે છે. આધુનિક ઇન્ટેલ પ્રોસેસર્સ ટર્બો બૂસ્ટ ટેક્નોલોજીનો ઉપયોગ કરે છે, જે અન્ય કોરોના ખર્ચે વ્યક્તિગત પ્રોસેસર કોરોની આવૃત્તિમાં વધારો કરે છે. પરંતુ તે ત્યારે જ કાર્ય કરે છે જ્યારે ઊર્જા બચત તકનીકો ચાલુ હોય. જો આપણે તેમને અક્ષમ કરીએ, તો પ્રોસેસર લોડ ન હોય તેવા કોરોના પાવર વપરાશને ઘટાડી શકશે નહીં.

VMware સર્વર પર પાવર-સેવિંગ ટેક્નોલોજીઓને અક્ષમ ન કરવાની ભલામણ કરે છે, પરંતુ શક્ય તેટલું શક્ય તેટલું હાઇપરવાઇઝરને પાવર મેનેજમેન્ટ છોડતા મોડ્સ પસંદ કરવાની ભલામણ કરે છે. આ કિસ્સામાં, હાઇપરવાઇઝર પાવર વપરાશ સેટિંગ્સમાં, તમારે ઉચ્ચ પ્રદર્શન પસંદ કરવાની જરૂર છે.

જો તમારી પાસે તમારા ઈન્ફ્રાસ્ટ્રક્ચરમાં વ્યક્તિગત VM (અથવા VM કોરો) છે જેને CPU આવર્તન વધારવાની જરૂર છે, તો પાવર વપરાશને યોગ્ય રીતે સમાયોજિત કરવાથી તેમની કામગીરીમાં નોંધપાત્ર સુધારો થઈ શકે છે.

CPU તૈયાર

જો VM કોર (vCPU) તૈયાર સ્થિતિમાં હોય, તો તે ઉપયોગી કાર્ય કરતું નથી. આ સ્થિતિ ત્યારે થાય છે જ્યારે હાઇપરવાઇઝરને મફત ભૌતિક કોર ન મળે કે જેમાં વર્ચ્યુઅલ મશીનની vCPU પ્રક્રિયા સોંપી શકાય.

કેવી રીતે વિશ્લેષણ કરવું? સામાન્ય રીતે, જો વર્ચ્યુઅલ મશીનના કોરો 10% કરતા વધુ સમય તૈયાર સ્થિતિમાં હોય, તો તમે પ્રદર્શન સમસ્યાઓ જોશો. સરળ શબ્દોમાં કહીએ તો, VM ભૌતિક સંસાધનો ઉપલબ્ધ થવાની રાહ જુએ છે તે સમયના 10% કરતા વધુ.

vCenter માં તમે CPU તૈયાર થી સંબંધિત 2 કાઉન્ટર્સ જોઈ શકો છો:

• તત્પરતા
• તૈયાર છે.

બંને કાઉન્ટર્સના મૂલ્યો સમગ્ર VM અને વ્યક્તિગત કોરો માટે બંને જોઈ શકાય છે.
તત્પરતા ટકાવારી તરીકે તરત જ મૂલ્ય બતાવે છે, પરંતુ માત્ર રીઅલ-ટાઇમમાં (છેલ્લા કલાકનો ડેટા, માપન અંતરાલ 20 સેકન્ડ). "હીલ્સ પર ગરમ" સમસ્યાઓ શોધવા માટે જ આ કાઉન્ટરનો ઉપયોગ કરવો વધુ સારું છે.

તૈયાર કાઉન્ટર મૂલ્યોને ઐતિહાસિક દ્રષ્ટિકોણથી પણ જોઈ શકાય છે. પેટર્ન સ્થાપિત કરવા અને સમસ્યાના ઊંડા વિશ્લેષણ માટે આ ઉપયોગી છે. ઉદાહરણ તરીકે, જો વર્ચ્યુઅલ મશીન ચોક્કસ સમયે કામગીરીની સમસ્યાઓ અનુભવવાનું શરૂ કરે છે, તો તમે CPU રેડી મૂલ્યના અંતરાલોની તુલના સર્વર પરના કુલ લોડ સાથે કરી શકો છો જ્યાં આ VM ચાલી રહ્યું છે, અને લોડ ઘટાડવા માટે પગલાં લઈ શકો છો (જો DRS નિષ્ફળ).

તૈયાર, રેડીનેસથી વિપરીત, ટકાવારીમાં નહીં, પરંતુ મિલિસેકન્ડ્સમાં બતાવવામાં આવે છે. આ એક સમેશન પ્રકાર કાઉન્ટર છે, એટલે કે, તે દર્શાવે છે કે માપન સમયગાળા દરમિયાન VM કોર તૈયાર સ્થિતિમાં કેટલો સમય હતો. તમે એક સરળ સૂત્રનો ઉપયોગ કરીને આ મૂલ્યને ટકાવારીમાં રૂપાંતરિત કરી શકો છો:

(CPU તૈયાર સમેશન મૂલ્ય / (ચાર્ટ ડિફોલ્ટ અપડેટ અંતરાલ સેકન્ડમાં * 1000)) * 100 = CPU તૈયાર %

ઉદાહરણ તરીકે, નીચેના ગ્રાફમાં VM માટે, સમગ્ર વર્ચ્યુઅલ મશીન માટે પીક રેડી મૂલ્ય નીચે મુજબ હશે:

તૈયાર ટકાવારીની ગણતરી કરતી વખતે, તમારે બે મુદ્દાઓ પર ધ્યાન આપવું જોઈએ:

• સમગ્ર VM માટે તૈયાર મૂલ્ય એ સમગ્ર કોરોમાં તૈયારનો સરવાળો છે.
• માપન અંતરાલ. રીઅલ-ટાઇમ માટે તે 20 સેકન્ડ છે, અને, ઉદાહરણ તરીકે, દૈનિક ચાર્ટ પર તે 300 સેકન્ડ છે.

સક્રિય મુશ્કેલીનિવારણ સાથે, આ સરળ મુદ્દાઓ સરળતાથી ચૂકી શકાય છે અને અસ્તિત્વમાં ન હોય તેવી સમસ્યાઓ હલ કરવામાં મૂલ્યવાન સમય વેડફાય છે.

ચાલો નીચે આપેલા ગ્રાફના ડેટાના આધારે તૈયારની ગણતરી કરીએ. (324474/(20*1000))*100 = 1622% સમગ્ર VM માટે. જો તમે કોરો જુઓ તો તે એટલું ડરામણું નથી: 1622/64 = 25% પ્રતિ કોર. આ કિસ્સામાં, કેચ જોવા માટે એકદમ સરળ છે: તૈયાર મૂલ્ય અવાસ્તવિક છે. પરંતુ જો આપણે ઘણા કોરો સાથે સમગ્ર VM માટે 10-20% વિશે વાત કરી રહ્યા છીએ, તો દરેક કોર માટે મૂલ્ય સામાન્ય શ્રેણીમાં હોઈ શકે છે.

મારે શું કરવું જોઈએ? ઉચ્ચ તૈયાર મૂલ્ય સૂચવે છે કે વર્ચ્યુઅલ મશીનોની સામાન્ય કામગીરી માટે સર્વર પાસે પૂરતા પ્રોસેસર સંસાધનો નથી. આવી સ્થિતિમાં, પ્રોસેસર (vCPU:pCPU) દ્વારા ઓવરસબ્સ્ક્રિપ્શન ઘટાડવાનું બાકી છે. દેખીતી રીતે, આ હાલના VM ના પરિમાણોને ઘટાડીને અથવા VM ના ભાગને અન્ય સર્વર પર સ્થાનાંતરિત કરીને પ્રાપ્ત કરી શકાય છે.

કો-સ્ટોપ

કેવી રીતે વિશ્લેષણ કરવું? આ કાઉન્ટર પણ સમેશન પ્રકારનું છે અને તે તૈયારની જેમ ટકાવારીમાં રૂપાંતરિત થાય છે:

(CPU કો-સ્ટોપ સમેશન મૂલ્ય / (ચાર્ટ ડિફોલ્ટ અપડેટ અંતરાલ સેકન્ડમાં * 1000)) * 100 = CPU કો-સ્ટોપ %

અહીં તમારે VM પરના કોરોની સંખ્યા અને માપન અંતરાલ પર પણ ધ્યાન આપવાની જરૂર છે.
કોસ્ટોપ સ્થિતિમાં, કર્નલ ઉપયોગી કાર્ય કરતી નથી. VM કદની યોગ્ય પસંદગી અને સર્વર પર સામાન્ય લોડ સાથે, કો-સ્ટોપ કાઉન્ટર શૂન્યની નજીક હોવું જોઈએ.

આ કિસ્સામાં, ભાર સ્પષ્ટપણે અસામાન્ય છે :)

મારે શું કરવું જોઈએ? જો એક હાઇપરવાઇઝર પર મોટી સંખ્યામાં કોરો સાથેના ઘણા VM ચાલી રહ્યા હોય અને CPU પર ઓવરસબ્સ્ક્રિપ્શન હોય, તો કો-સ્ટોપ કાઉન્ટર વધી શકે છે, જે આ VM ની કામગીરીમાં સમસ્યાઓ તરફ દોરી જશે.

ઉપરાંત, જો એક VM ના સક્રિય કોરો હાયપર-ટ્રેડીંગ સક્ષમ સાથે એક ભૌતિક સર્વર કોર પર થ્રેડોનો ઉપયોગ કરે તો સહ-સ્ટોપ વધશે. આ પરિસ્થિતિ ઊભી થઈ શકે છે, ઉદાહરણ તરીકે, જો VM જ્યાં તે ચાલી રહ્યું છે તે સર્વર પર ભૌતિક રીતે ઉપલબ્ધ કરતાં વધુ કોરો ધરાવે છે, અથવા જો VM માટે "preferHT" સેટિંગ સક્ષમ છે. તમે આ સેટિંગ વિશે વાંચી શકો છો અહીં.

ઉચ્ચ કો-સ્ટોપને કારણે VM પ્રદર્શનમાં સમસ્યાઓ ટાળવા માટે, આ VM પર ચાલતા સૉફ્ટવેરના ઉત્પાદકની ભલામણો અને જ્યાં VM ચાલે છે ત્યાં ભૌતિક સર્વરની ક્ષમતાઓ અનુસાર VM કદ પસંદ કરો.

રિઝર્વમાં કોરો ઉમેરશો નહીં; આ ફક્ત VM માટે જ નહીં, પણ સર્વર પરના તેના પડોશીઓ માટે પણ કામગીરીની સમસ્યાઓનું કારણ બની શકે છે.

અન્ય ઉપયોગી CPU મેટ્રિક્સ

ચલાવો - માપન સમયગાળા દરમિયાન vCPU એ RUN સ્થિતિમાં કેટલો સમય (ms) હતો, એટલે કે, તે ખરેખર ઉપયોગી કાર્ય કરી રહ્યું હતું.

નિષ્ક્રિય - માપન સમયગાળા દરમિયાન કેટલા સમય સુધી (ms) vCPU નિષ્ક્રિય સ્થિતિમાં હતું. ઉચ્ચ નિષ્ક્રિય મૂલ્યો કોઈ સમસ્યા નથી, vCPU પાસે ફક્ત "કરવાનું કંઈ નથી."

રાહ જુઓ - માપન સમયગાળા દરમિયાન કેટલા સમય સુધી (ms) vCPU પ્રતીક્ષા સ્થિતિમાં હતું. આ કાઉન્ટરમાં IDLE સમાવવામાં આવેલ હોવાથી, ઉચ્ચ પ્રતીક્ષા મૂલ્યો પણ સમસ્યા દર્શાવતા નથી. પરંતુ જો Wait ઊંચુ હોય ત્યારે જો Wait IDLE ઓછું હોય, તો તેનો અર્થ એ છે કે VM I/O ઑપરેશન્સ પૂર્ણ થવાની રાહ જોઈ રહ્યું હતું, અને આ બદલામાં, હાર્ડ ડ્રાઇવ અથવા VM ના કોઈપણ વર્ચ્યુઅલ ઉપકરણોના પ્રદર્શનમાં સમસ્યા સૂચવી શકે છે.

મહત્તમ મર્યાદિત - સેટ કરેલ સંસાધન મર્યાદાને કારણે માપન સમયગાળા દરમિયાન vCPU તૈયાર સ્થિતિમાં કેટલો સમય હતો. જો પ્રદર્શન અસ્પષ્ટ રીતે ઓછું હોય, તો આ કાઉન્ટરની કિંમત અને VM સેટિંગ્સમાં CPU મર્યાદા તપાસવી ઉપયોગી છે. VM ની ખરેખર મર્યાદાઓ હોઈ શકે છે જેના વિશે તમે જાણતા નથી. ઉદાહરણ તરીકે, આ ત્યારે થાય છે જ્યારે VM એ નમૂનામાંથી ક્લોન કરવામાં આવ્યું હતું જેના પર CPU મર્યાદા સેટ કરવામાં આવી હતી.

સ્વેપ રાહ જુઓ - માપન સમયગાળા દરમિયાન કેટલા સમય સુધી vCPU એ VMkernel સ્વેપ સાથે ઑપરેશન માટે રાહ જોઈ. જો આ કાઉન્ટરની કિંમતો શૂન્યથી ઉપર છે, તો VM માં ચોક્કસપણે પ્રભાવ સમસ્યાઓ છે. અમે RAM કાઉન્ટર્સ વિશેના લેખમાં સ્વેપ વિશે વધુ વાત કરીશું.

ESXTOP

જો vCenter માં પરફોર્મન્સ કાઉન્ટર્સ ઐતિહાસિક ડેટાનું વિશ્લેષણ કરવા માટે સારા છે, તો ESXTOP માં સમસ્યાનું ઓપરેશનલ વિશ્લેષણ વધુ સારી રીતે કરવામાં આવે છે. અહીં, તમામ મૂલ્યો તૈયાર સ્વરૂપમાં રજૂ કરવામાં આવે છે (કંઈપણ ભાષાંતર કરવાની જરૂર નથી), અને લઘુત્તમ માપન અવધિ 2 સેકન્ડ છે.
CPU માટે ESXTOP સ્ક્રીનને "c" કી સાથે બોલાવવામાં આવે છે અને તે આના જેવો દેખાય છે:

અનુકૂળતા માટે, તમે Shift-V દબાવીને માત્ર વર્ચ્યુઅલ મશીન પ્રક્રિયાઓ છોડી શકો છો.
વ્યક્તિગત VM કોરો માટે મેટ્રિક્સ જોવા માટે, "e" દબાવો અને રસ ધરાવતા VM નું GID દાખલ કરો (નીચેના સ્ક્રીનશોટમાં 30919):

મને સંક્ષિપ્તમાં કૉલમ્સમાંથી પસાર થવા દો જે મૂળભૂત રીતે પ્રસ્તુત છે. વધારાની કૉલમ "f" દબાવીને ઉમેરી શકાય છે.

NWLD (વિશ્વની સંખ્યા) - જૂથમાં પ્રક્રિયાઓની સંખ્યા. જૂથને વિસ્તૃત કરવા અને દરેક પ્રક્રિયા માટે મેટ્રિક્સ જોવા માટે (ઉદાહરણ તરીકે, મલ્ટી-કોર VMમાં દરેક કોર માટે), "e" દબાવો. જો કોઈ જૂથમાં એક કરતાં વધુ પ્રક્રિયાઓ હોય, તો જૂથ માટેના મેટ્રિક મૂલ્યો વ્યક્તિગત પ્રક્રિયાઓ માટેના મેટ્રિક્સના સરવાળા સમાન હોય છે.

% વપરાયેલ - પ્રક્રિયા અથવા પ્રક્રિયાઓના જૂથ દ્વારા કેટલા સર્વર CPU ચક્રોનો ઉપયોગ થાય છે.

%રન - માપન સમયગાળા દરમિયાન પ્રક્રિયા RUN રાજ્યમાં કેટલો સમય હતો, એટલે કે. ઉપયોગી કામ કર્યું. તે %USED થી અલગ છે કે તે હાઇપર-થ્રેડીંગ, ફ્રીક્વન્સી સ્કેલિંગ અને સિસ્ટમ કાર્યો (%SYS) પર ખર્ચવામાં આવેલ સમયને ધ્યાનમાં લેતું નથી.

%SYS - સિસ્ટમના કાર્યો પર વિતાવેલો સમય, ઉદાહરણ તરીકે: પ્રક્રિયામાં વિક્ષેપ, I/O, નેટવર્ક ઑપરેશન, વગેરે. જો VM પાસે મોટો I/O હોય તો મૂલ્ય વધારે હોઈ શકે છે.

% OVRLP - ભૌતિક કોર કે જેના પર VM પ્રક્રિયા ચાલી રહી છે તે અન્ય પ્રક્રિયાઓના કાર્યોમાં કેટલો સમય પસાર કરે છે.

આ મેટ્રિક્સ નીચે પ્રમાણે એકબીજા સાથે સંબંધિત છે:

%USED = %RUN + %SYS - %OVRLP.

સામાન્ય રીતે %USED મેટ્રિક વધુ માહિતીપ્રદ છે.

રાહ જુઓ - માપન સમયગાળા દરમિયાન પ્રક્રિયા કેટલો સમય રાહ જુઓ સ્થિતિમાં હતી. IDLE ને સક્ષમ કરે છે.

% IDLE - માપન સમયગાળા દરમિયાન પ્રક્રિયા IDLE સ્થિતિમાં કેટલો સમય હતો.

%SWPWT - માપન સમયગાળા દરમિયાન કેટલા સમય સુધી vCPU એ VMkernel સ્વેપ સાથે ઑપરેશન માટે રાહ જોઈ.

% VMWAIT - માપન સમયગાળા દરમિયાન vCPU ઇવેન્ટની રાહ જોવાની સ્થિતિમાં કેટલો સમય હતો (સામાન્ય રીતે I/O). vCenter માં સમાન કાઉન્ટર નથી. ઉચ્ચ મૂલ્યો VM પર I/O સાથે સમસ્યાઓ સૂચવે છે.

% WAIT = % VMWAIT + % નિષ્ક્રિય + % SWPWT.

જો VM VMkernel સ્વેપનો ઉપયોગ કરતું નથી, તો પ્રદર્શન સમસ્યાઓનું વિશ્લેષણ કરતી વખતે %VMWAIT ને જોવાની સલાહ આપવામાં આવે છે, કારણ કે આ મેટ્રિક તે સમયને ધ્યાનમાં લેતું નથી જ્યારે VM કંઈ કરી રહ્યું ન હતું (%IDLE).

%RDY - માપન સમયગાળા દરમિયાન પ્રક્રિયા તૈયાર સ્થિતિમાં કેટલો સમય હતો.

%CSTP - માપન સમયગાળા દરમિયાન પ્રક્રિયા કોસ્ટોપ સ્થિતિમાં કેટલો સમય હતો.

%MLMTD - સેટ કરેલ સંસાધન મર્યાદાને કારણે માપન સમયગાળા દરમિયાન vCPU તૈયાર સ્થિતિમાં કેટલો સમય હતો.

% WAIT + % RDY + % CSTP + % RUN = 100% – VM કોર હંમેશા આ ચાર રાજ્યોમાંથી એકમાં હોય છે.

હાઇપરવાઇઝર પર CPU

vCenter પાસે હાઇપરવાઇઝર માટે CPU પર્ફોર્મન્સ કાઉન્ટર્સ પણ છે, પરંતુ તે કંઈ રસપ્રદ નથી - તે સર્વર પરના તમામ VM માટે કાઉન્ટર્સનો સરવાળો છે.
સર્વર પર CPU સ્થિતિ જોવાની સૌથી અનુકૂળ રીત સારાંશ ટેબ પર છે:

સર્વર માટે, તેમજ વર્ચ્યુઅલ મશીન માટે, ત્યાં પ્રમાણભૂત એલાર્મ છે:

જ્યારે સર્વર CPU લોડ વધારે હોય છે, ત્યારે તેના પર ચાલતા VM પરફોર્મન્સ સમસ્યાઓ અનુભવવાનું શરૂ કરે છે.

ESXTOP માં, સર્વર CPU લોડ ડેટા સ્ક્રીનની ટોચ પર પ્રસ્તુત થાય છે. પ્રમાણભૂત CPU લોડ ઉપરાંત, જે હાઇપરવાઇઝર માટે ખૂબ માહિતીપ્રદ નથી, ત્યાં વધુ ત્રણ મેટ્રિક્સ છે:

કોર UTIL(%) - ભૌતિક સર્વર કોર લોડ કરી રહ્યું છે. આ કાઉન્ટર દર્શાવે છે કે માપન સમયગાળા દરમિયાન કોરે કેટલો સમય કામ કર્યું.

PCPU UTIL(%) - જો હાયપર-થ્રેડીંગ સક્ષમ હોય, તો ભૌતિક કોર દીઠ બે થ્રેડો (PCPU) હોય છે. આ મેટ્રિક બતાવે છે કે દરેક થ્રેડને કાર્ય પૂર્ણ કરવામાં કેટલો સમય લાગ્યો.

PCPU વપરાયેલ(%) – PCPU UTIL(%) જેવું જ છે, પરંતુ ફ્રિક્વન્સી સ્કેલિંગ (ક્યાં તો ઉર્જા બચત હેતુઓ માટે કોર ફ્રિકવન્સી ઘટાડવી અથવા ટર્બો બૂસ્ટ ટેક્નોલોજીને કારણે કોર ફ્રીક્વન્સીમાં વધારો) અને હાઇપર-થ્રેડીંગને ધ્યાનમાં લે છે.

PCPU_USED% = PCPU_UTIL% * અસરકારક કોર આવર્તન / નામાંકિત કોર આવર્તન.

આ સ્ક્રીનશૉટમાં, કેટલાક કોરો માટે, ટર્બો બૂસ્ટને કારણે, USED મૂલ્ય 100% કરતાં વધારે છે, કારણ કે કોર આવર્તન નજીવા કરતાં વધારે છે.

હાયપર-થ્રેડીંગને કેવી રીતે ધ્યાનમાં લેવામાં આવે છે તે વિશે થોડાક શબ્દો. જો પ્રક્રિયાઓ સર્વરના ભૌતિક કોરના બંને થ્રેડો પર 100% સમય ચલાવવામાં આવે છે, જ્યારે કોર નજીવી આવર્તન પર કાર્ય કરે છે, તો પછી:

• કોર માટે CORE UTIL 100% હશે,
• બંને થ્રેડો માટે PCPU UTIL 100% હશે,
• બંને થ્રેડો માટે વપરાયેલ PCPU 50% હશે.

જો માપન સમયગાળા દરમિયાન બંને થ્રેડો 100% સમય કામ કરતા ન હોય, તો તે સમયગાળા દરમિયાન જ્યારે થ્રેડો સમાંતર રીતે કામ કરે છે, ત્યારે કોરો માટે વપરાયેલ PCPU અડધા ભાગમાં વહેંચાયેલું છે.

ESXTOP પાસે સર્વર CPU પાવર વપરાશ પરિમાણો સાથે સ્ક્રીન પણ છે. અહીં તમે જોઈ શકો છો કે શું સર્વર ઊર્જા બચત તકનીકોનો ઉપયોગ કરે છે: C-સ્ટેટ્સ અને P-સ્ટેટ્સ. "p" કી દ્વારા બોલાવવામાં આવે છે:

સામાન્ય CPU પ્રદર્શન સમસ્યાઓ

અંતે, હું VM CPU પ્રદર્શન સાથે સમસ્યાઓના લાક્ષણિક કારણો પર જઈશ અને તેમને ઉકેલવા માટે ટૂંકી ટીપ્સ આપીશ:

મુખ્ય ઘડિયાળ ઝડપ પૂરતી નથી. જો તમારા VM ને વધુ શક્તિશાળી કોરો પર અપગ્રેડ કરવું શક્ય ન હોય, તો તમે ટર્બો બૂસ્ટને વધુ કાર્યક્ષમ રીતે કાર્ય કરવા માટે પાવર સેટિંગ્સ બદલવાનો પ્રયાસ કરી શકો છો.

ખોટો VM માપન (ઘણા બધા/થોડા કોરો). જો તમે થોડા કોરો ઇન્સ્ટોલ કરો છો, તો VM પર CPU લોડ વધુ હશે. જો ત્યાં ઘણું હોય, તો ઉંચો કો-સ્ટોપ પકડો.

સર્વર પર CPU નું મોટું ઓવરસબ્સ્ક્રિપ્શન. જો VM વધારે તૈયાર હોય, તો CPU ઓવરસબ્સ્ક્રિપ્શન ઓછું કરો.

મોટા VM પર ખોટી NUMA ટોપોલોજી. VM (vNUMA) દ્વારા જોવામાં આવેલ NUMA ટોપોલોજી સર્વર (pNUMA) ની NUMA ટોપોલોજી સાથે મેળ ખાતી હોવી જોઈએ. ડાયગ્નોસ્ટિક્સ અને આ સમસ્યાના સંભવિત ઉકેલો લખેલા છે, ઉદાહરણ તરીકે, પુસ્તકમાં "VMware vSphere 6.5 હોસ્ટ રિસોર્સ ડીપ ડાઇવ". જો તમે વધુ ઊંડાણમાં જવા માંગતા નથી અને તમારી પાસે VM પર ઇન્સ્ટોલ કરેલ OS પર લાઇસેંસિંગ પ્રતિબંધો નથી, તો VM પર ઘણા વર્ચ્યુઅલ સોકેટ્સ બનાવો, એક સમયે એક કોર. તમે ઘણું ગુમાવશો નહીં :)

CPU વિશે મારા માટે એટલું જ છે. પ્રશ્નો પૂછો. આગળના ભાગમાં હું RAM વિશે વાત કરીશ.

ઉપયોગી લિંક્સhttp://virtual-red-dot.info/vm-cpu-counters-vsphere/
https://kb.vmware.com/kb/1017926
http://www.yellow-bricks.com/2012/07/17/why-is-wait-so-high/
https://communities.vmware.com/docs/DOC-9279
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere65-perf.pdf
https://pages.rubrik.com/host-resources-deep-dive_request.html

સોર્સ: www.habr.com