VMware vSphere-ലെ വെർച്വൽ മെഷീൻ പ്രകടനത്തിന്റെ വിശകലനം. ഭാഗം 1: സിപിയു

നിങ്ങൾ VMware vSphere (അല്ലെങ്കിൽ മറ്റേതെങ്കിലും ടെക്നോളജി സ്റ്റാക്ക്) അടിസ്ഥാനമാക്കിയുള്ള ഒരു വെർച്വൽ ഇൻഫ്രാസ്ട്രക്ചർ നിയന്ത്രിക്കുകയാണെങ്കിൽ, ഉപയോക്താക്കളിൽ നിന്ന് നിങ്ങൾ പലപ്പോഴും പരാതികൾ കേൾക്കാറുണ്ട്: "വെർച്വൽ മെഷീൻ മന്ദഗതിയിലാണ്!" ഈ ലേഖന പരമ്പരയിൽ, ഞാൻ പ്രകടന അളവുകൾ വിശകലനം ചെയ്യുകയും എന്താണ്, എന്തുകൊണ്ട് ഇത് മന്ദഗതിയിലാക്കുന്നുവെന്നും അത് മന്ദഗതിയിലാകുന്നില്ലെന്ന് എങ്ങനെ ഉറപ്പാക്കാമെന്നും നിങ്ങളോട് പറയും.

വെർച്വൽ മെഷീൻ പ്രകടനത്തിൻ്റെ ഇനിപ്പറയുന്ന വശങ്ങൾ ഞാൻ പരിഗണിക്കും:

• സിപിയു,
• ഫ്രെയിം,
• ഡിസ്ക്,
• നെറ്റ്വർക്ക്.

ഞാൻ സിപിയുവിൽ നിന്ന് തുടങ്ങാം.

പ്രകടനം വിശകലനം ചെയ്യുന്നതിന് ഞങ്ങൾക്ക് ഇത് ആവശ്യമാണ്:

• vCenter പെർഫോമൻസ് കൗണ്ടറുകൾ - പ്രകടന കൗണ്ടറുകൾ, അതിൻ്റെ ഗ്രാഫുകൾ vSphere ക്ലയൻ്റിലൂടെ കാണാൻ കഴിയും. ഈ കൗണ്ടറുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ ക്ലയൻ്റിൻറെ ഏത് പതിപ്പിലും ലഭ്യമാണ് (C# ലെ "കട്ടിയുള്ള" ക്ലയൻ്റ്, ഫ്ലെക്സിലെ വെബ് ക്ലയൻ്റ്, HTML5 ലെ വെബ് ക്ലയൻ്റ്). ഈ ലേഖനങ്ങളിൽ ഞങ്ങൾ C# ക്ലയൻ്റിൽ നിന്നുള്ള സ്ക്രീൻഷോട്ടുകൾ ഉപയോഗിക്കും, കാരണം അവ മിനിയേച്ചറിൽ മികച്ചതായി കാണപ്പെടുന്നു :)
• ESXTOP - ESXi കമാൻഡ് ലൈനിൽ നിന്ന് പ്രവർത്തിക്കുന്ന ഒരു യൂട്ടിലിറ്റി. അതിൻ്റെ സഹായത്തോടെ, നിങ്ങൾക്ക് പെർഫോമൻസ് കൗണ്ടറുകളുടെ മൂല്യങ്ങൾ തത്സമയം ലഭിക്കും അല്ലെങ്കിൽ കൂടുതൽ വിശകലനത്തിനായി ഒരു നിശ്ചിത കാലയളവിലേക്ക് ഈ മൂല്യങ്ങൾ ഒരു .csv ഫയലിലേക്ക് അപ്‌ലോഡ് ചെയ്യാം. അടുത്തതായി, ഈ ടൂളിനെക്കുറിച്ച് ഞാൻ നിങ്ങളോട് കൂടുതൽ പറയുകയും വിഷയത്തെക്കുറിച്ചുള്ള ഡോക്യുമെൻ്റേഷനിലേക്കും ലേഖനങ്ങളിലേക്കും ഉപയോഗപ്രദമായ നിരവധി ലിങ്കുകൾ നൽകുകയും ചെയ്യും.

ഒരു സിദ്ധാന്തം

ESXi-യിൽ, ഒരു പ്രത്യേക പ്രക്രിയ - VMware ടെർമിനോളജിയിലെ ലോകം - ഓരോ vCPU- യുടെയും (വെർച്വൽ മെഷീൻ കോർ) പ്രവർത്തനത്തിന് ഉത്തരവാദിയാണ്. സേവന പ്രക്രിയകളും ഉണ്ട്, എന്നാൽ VM പ്രകടനം വിശകലനം ചെയ്യുന്നതിൻ്റെ കാഴ്ചപ്പാടിൽ അവ രസകരമല്ല.

ESXi-യിലെ ഒരു പ്രക്രിയ നാല് സംസ്ഥാനങ്ങളിൽ ഒന്നിൽ ആകാം:

• പ്രവർത്തിപ്പിക്കുക - പ്രക്രിയ ചില ഉപയോഗപ്രദമായ ജോലികൾ ചെയ്യുന്നു.
• കാക്കുക - പ്രക്രിയ ഒരു ജോലിയും ചെയ്യുന്നില്ല (നിഷ്ക്രിയം) അല്ലെങ്കിൽ ഇൻപുട്ട്/ഔട്ട്പുട്ടിനായി കാത്തിരിക്കുകയാണ്.
• കോസ്റ്റോപ്പ് - മൾട്ടി-കോർ വെർച്വൽ മെഷീനുകളിൽ സംഭവിക്കുന്ന ഒരു അവസ്ഥ. ഹൈപ്പർവൈസർ സിപിയു ഷെഡ്യൂളറിന് (ESXi CPU ഷെഡ്യൂളർ) ഫിസിക്കൽ സെർവർ കോറുകളിലെ എല്ലാ സജീവ വെർച്വൽ മെഷീൻ കോറുകളുടെയും ഒരേസമയം നിർവ്വഹണം ഷെഡ്യൂൾ ചെയ്യാൻ കഴിയാത്തപ്പോൾ ഇത് സംഭവിക്കുന്നു. ഭൗതിക ലോകത്ത്, എല്ലാ പ്രോസസർ കോറുകളും സമാന്തരമായി പ്രവർത്തിക്കുന്നു, VM-നുള്ളിലെ ഗസ്റ്റ് OS സമാന സ്വഭാവം പ്രതീക്ഷിക്കുന്നു, അതിനാൽ ഹൈപ്പർവൈസർ അവരുടെ ക്ലോക്ക് സൈക്കിൾ വേഗത്തിൽ പൂർത്തിയാക്കാൻ കഴിവുള്ള VM കോറുകളുടെ വേഗത കുറയ്ക്കേണ്ടതുണ്ട്. ESXi-യുടെ ആധുനിക പതിപ്പുകളിൽ, സിപിയു ഷെഡ്യൂളർ റിലാക്സ്ഡ് കോ-ഷെഡ്യൂളിംഗ് എന്ന് വിളിക്കുന്ന ഒരു സംവിധാനം ഉപയോഗിക്കുന്നു: ഹൈപ്പർവൈസർ "വേഗത", "ഏറ്റവും വേഗത കുറഞ്ഞ" വെർച്വൽ മെഷീൻ കോർ (സ്‌ക്യൂ) എന്നിവ തമ്മിലുള്ള വിടവ് പരിഗണിക്കുന്നു. വിടവ് ഒരു നിശ്ചിത പരിധി കവിയുന്നുവെങ്കിൽ, ഫാസ്റ്റ് കോർ കോസ്റ്റോപ്പ് അവസ്ഥയിലേക്ക് പ്രവേശിക്കുന്നു. VM കോറുകൾ ഈ അവസ്ഥയിൽ ധാരാളം സമയം ചെലവഴിക്കുകയാണെങ്കിൽ, അത് പ്രകടന പ്രശ്നങ്ങൾക്ക് കാരണമാകും.
• തയ്യാറായ - ഹൈപ്പർവൈസറിന് അതിൻ്റെ നിർവ്വഹണത്തിനായി വിഭവങ്ങൾ അനുവദിക്കാൻ കഴിയാതെ വരുമ്പോൾ പ്രക്രിയ ഈ അവസ്ഥയിലേക്ക് പ്രവേശിക്കുന്നു. ഉയർന്ന റെഡി മൂല്യങ്ങൾ VM പ്രകടന പ്രശ്നങ്ങൾക്ക് കാരണമാകും.

അടിസ്ഥാന വെർച്വൽ മെഷീൻ സിപിയു പ്രകടന കൗണ്ടറുകൾ

സി പി യു ഉപയോഗം, %. ഒരു നിശ്ചിത കാലയളവിലെ CPU ഉപയോഗത്തിൻ്റെ ശതമാനം കാണിക്കുന്നു.

എങ്ങനെ വിശകലനം ചെയ്യാം? ഒരു VM സ്ഥിരമായി 90% CPU ഉപയോഗിക്കുന്നുവെങ്കിൽ അല്ലെങ്കിൽ 100% വരെ പീക്കുകൾ ഉണ്ടെങ്കിൽ, ഞങ്ങൾക്ക് പ്രശ്‌നങ്ങളുണ്ട്. VM-നുള്ളിലെ ആപ്ലിക്കേഷൻ്റെ "സ്ലോ" പ്രവർത്തനത്തിൽ മാത്രമല്ല, നെറ്റ്വർക്കിലൂടെ VM-ൻ്റെ അപ്രാപ്യതയിലും പ്രശ്നങ്ങൾ പ്രകടിപ്പിക്കാം. മോണിറ്ററിംഗ് സിസ്റ്റം VM ഇടയ്ക്കിടെ വീഴുന്നതായി കാണിക്കുന്നുവെങ്കിൽ, CPU ഉപയോഗ ഗ്രാഫിലെ കൊടുമുടികൾ ശ്രദ്ധിക്കുക.

വെർച്വൽ മെഷീൻ്റെ സിപിയു ലോഡ് കാണിക്കുന്ന ഒരു സാധാരണ അലാറം ഉണ്ട്:

ഞാൻ എന്തു ചെയ്യണം? ഒരു VM-ൻ്റെ CPU ഉപയോഗം നിരന്തരം മേൽക്കൂരയിലൂടെ കടന്നുപോകുന്നുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് vCPU-കളുടെ എണ്ണം വർദ്ധിപ്പിക്കുന്നതിനെക്കുറിച്ചോ (നിർഭാഗ്യവശാൽ, ഇത് എല്ലായ്പ്പോഴും സഹായിക്കില്ല) അല്ലെങ്കിൽ കൂടുതൽ ശക്തമായ പ്രോസസ്സറുകളുള്ള സെർവറിലേക്ക് VM മാറ്റുന്നതിനെക്കുറിച്ചോ ചിന്തിക്കാം.

MHz-ൽ CPU ഉപയോഗം

% ലെ vCenter ഉപയോഗത്തിലെ ഗ്രാഫുകളിൽ നിങ്ങൾക്ക് മുഴുവൻ വെർച്വൽ മെഷീനും മാത്രമേ കാണാൻ കഴിയൂ (Esxtop ൽ കോറുകൾക്ക് % മൂല്യങ്ങളുണ്ട്). ഓരോ കോറിനും നിങ്ങൾക്ക് MHz-ൽ ഉപയോഗം കാണാം.

എങ്ങനെ വിശകലനം ചെയ്യാം? ഒരു മൾട്ടി-കോർ ആർക്കിടെക്ചറിനായി ഒരു ആപ്ലിക്കേഷൻ ഒപ്റ്റിമൈസ് ചെയ്തിട്ടില്ല എന്നത് സംഭവിക്കുന്നു: ഇത് ഒരു കോർ 100% മാത്രം ഉപയോഗിക്കുന്നു, ബാക്കിയുള്ളവ ലോഡ് കൂടാതെ നിഷ്ക്രിയമാണ്. ഉദാഹരണത്തിന്, ഡിഫോൾട്ട് ബാക്കപ്പ് ക്രമീകരണങ്ങൾ ഉപയോഗിച്ച്, MS SQL ഒരു കോറിൽ മാത്രം പ്രക്രിയ ആരംഭിക്കുന്നു. തൽഫലമായി, ബാക്കപ്പ് മന്ദഗതിയിലാകുന്നത് ഡിസ്കുകളുടെ വേഗത കുറവായതുകൊണ്ടല്ല (ഇതാണ് ഉപയോക്താവ് ആദ്യം പരാതിപ്പെട്ടത്), മറിച്ച് പ്രോസസ്സറിന് നേരിടാൻ കഴിയാത്തതിനാലാണ്. പാരാമീറ്ററുകൾ മാറ്റുന്നതിലൂടെ പ്രശ്നം പരിഹരിച്ചു: ബാക്കപ്പ് നിരവധി ഫയലുകളിൽ സമാന്തരമായി പ്രവർത്തിക്കാൻ തുടങ്ങി (യഥാക്രമം, നിരവധി പ്രക്രിയകളിൽ).

കോറുകളിൽ അസമമായ ലോഡിൻ്റെ ഒരു ഉദാഹരണം.

കോറുകൾ അസമമായി ലോഡുചെയ്യുമ്പോൾ (മുകളിലുള്ള ഗ്രാഫിലെന്നപോലെ) ഒരു സാഹചര്യവുമുണ്ട്, അവയിൽ ചിലതിന് 100% കൊടുമുടിയുണ്ട്. ഒരു കോർ മാത്രം ലോഡുചെയ്യുന്നത് പോലെ, CPU ഉപയോഗത്തിനുള്ള അലാറം പ്രവർത്തിക്കില്ല (ഇത് മുഴുവൻ VM-നും വേണ്ടിയുള്ളതാണ്), എന്നാൽ പ്രകടന പ്രശ്നങ്ങൾ ഉണ്ടാകും.

ഞാൻ എന്തു ചെയ്യണം? ഒരു വെർച്വൽ മെഷീനിലെ സോഫ്‌റ്റ്‌വെയർ കോറുകൾ അസമമായി ലോഡുചെയ്യുകയാണെങ്കിൽ (ഒരു കോർ അല്ലെങ്കിൽ കോറുകളുടെ ഒരു ഭാഗം മാത്രമേ ഉപയോഗിക്കുന്നുള്ളൂ), അവയുടെ എണ്ണം വർദ്ധിപ്പിക്കുന്നതിൽ അർത്ഥമില്ല. ഈ സാഹചര്യത്തിൽ, കൂടുതൽ ശക്തമായ പ്രോസസ്സറുകൾ ഉള്ള ഒരു സെർവറിലേക്ക് VM നീക്കുന്നതാണ് നല്ലത്.

സെർവർ ബയോസിലെ പവർ ഉപഭോഗ ക്രമീകരണങ്ങൾ പരിശോധിക്കാനും നിങ്ങൾക്ക് ശ്രമിക്കാം. പല അഡ്മിനിസ്ട്രേറ്റർമാരും BIOS-ൽ ഹൈ പെർഫോമൻസ് മോഡ് പ്രവർത്തനക്ഷമമാക്കുകയും അതുവഴി സി-സ്റ്റേറ്റുകളും പി-സ്റ്റേറ്റുകളും ഊർജ്ജ സംരക്ഷണ സാങ്കേതികവിദ്യകൾ പ്രവർത്തനരഹിതമാക്കുകയും ചെയ്യുന്നു. ആധുനിക ഇൻ്റൽ പ്രോസസ്സറുകൾ ടർബോ ബൂസ്റ്റ് സാങ്കേതികവിദ്യ ഉപയോഗിക്കുന്നു, ഇത് മറ്റ് കോറുകളുടെ ചെലവിൽ വ്യക്തിഗത പ്രോസസ്സർ കോറുകളുടെ ആവൃത്തി വർദ്ധിപ്പിക്കുന്നു. എന്നാൽ ഊർജ്ജ സംരക്ഷണ സാങ്കേതികവിദ്യകൾ ഓണായിരിക്കുമ്പോൾ മാത്രമേ ഇത് പ്രവർത്തിക്കൂ. ഞങ്ങൾ അവ പ്രവർത്തനരഹിതമാക്കുകയാണെങ്കിൽ, ലോഡ് ചെയ്യാത്ത കോറുകളുടെ വൈദ്യുതി ഉപഭോഗം പ്രോസസറിന് കുറയ്ക്കാൻ കഴിയില്ല.

സെർവറുകളിൽ പവർ-സേവിംഗ് ടെക്നോളജികൾ പ്രവർത്തനരഹിതമാക്കരുതെന്ന് വിഎംവെയർ ശുപാർശ ചെയ്യുന്നു, പക്ഷേ പവർ മാനേജ്മെൻ്റ് കഴിയുന്നത്ര ഹൈപ്പർവൈസറിന് വിട്ടുകൊടുക്കുന്ന മോഡുകൾ തിരഞ്ഞെടുക്കുക. ഈ സാഹചര്യത്തിൽ, ഹൈപ്പർവൈസർ വൈദ്യുതി ഉപഭോഗ ക്രമീകരണങ്ങളിൽ, നിങ്ങൾ ഉയർന്ന പ്രകടനം തിരഞ്ഞെടുക്കേണ്ടതുണ്ട്.

നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചറിൽ വ്യക്തിഗത VM-കൾ (അല്ലെങ്കിൽ VM കോറുകൾ) ഉണ്ടെങ്കിൽ, അതിന് വർദ്ധിച്ച CPU ഫ്രീക്വൻസി ആവശ്യമാണ്, വൈദ്യുതി ഉപഭോഗം ശരിയായി ക്രമീകരിക്കുന്നത് അവയുടെ പ്രകടനത്തെ ഗണ്യമായി മെച്ചപ്പെടുത്തും.

സിപിയു തയ്യാറാണ്

VM കോർ (vCPU) റെഡി സ്റ്റേറ്റിലാണെങ്കിൽ, അത് ഉപയോഗപ്രദമായ പ്രവർത്തനം നടത്തുന്നില്ല. വെർച്വൽ മെഷീൻ്റെ vCPU പ്രോസസ്സ് നൽകാനാകുന്ന ഒരു സ്വതന്ത്ര ഫിസിക്കൽ കോർ ഹൈപ്പർവൈസർ കണ്ടെത്താത്തപ്പോൾ ഈ അവസ്ഥ സംഭവിക്കുന്നു.

എങ്ങനെ വിശകലനം ചെയ്യാം? സാധാരണഗതിയിൽ, ഒരു വെർച്വൽ മെഷീൻ്റെ കോറുകൾ 10%-ൽ കൂടുതൽ സമയം റെഡി സ്റ്റേറ്റിലാണെങ്കിൽ, പ്രകടന പ്രശ്നങ്ങൾ നിങ്ങൾ ശ്രദ്ധിക്കും. ലളിതമായി പറഞ്ഞാൽ, ഭൗതിക വിഭവങ്ങൾ ലഭ്യമാകുന്നതിനായി VM കാത്തിരിക്കുന്ന സമയത്തിൻ്റെ 10%-ത്തിലധികം.

vCenter-ൽ നിങ്ങൾക്ക് CPU റെഡിയുമായി ബന്ധപ്പെട്ട 2 കൗണ്ടറുകൾ കാണാൻ കഴിയും:

• സന്നദ്ധത,
• തയ്യാറാണ്.

രണ്ട് കൗണ്ടറുകളുടെയും മൂല്യങ്ങൾ മുഴുവൻ വിഎമ്മിനും വ്യക്തിഗത കോറുകൾക്കും കാണാൻ കഴിയും.
സന്നദ്ധത മൂല്യത്തെ ഒരു ശതമാനമായി ഉടനടി കാണിക്കുന്നു, പക്ഷേ തത്സമയത്തിൽ മാത്രം (അവസാന മണിക്കൂറിലെ ഡാറ്റ, അളക്കൽ ഇടവേള 20 സെക്കൻഡ്). "കുതികാൽ ചൂടുള്ള" പ്രശ്നങ്ങൾ തിരയാൻ മാത്രം ഈ കൌണ്ടർ ഉപയോഗിക്കുന്നതാണ് നല്ലത്.

റെഡി കൌണ്ടർ മൂല്യങ്ങൾ ചരിത്രപരമായ വീക്ഷണകോണിൽ നിന്നും വീക്ഷിക്കാവുന്നതാണ്. പാറ്റേണുകൾ സ്ഥാപിക്കുന്നതിനും പ്രശ്നത്തിൻ്റെ ആഴത്തിലുള്ള വിശകലനത്തിനും ഇത് ഉപയോഗപ്രദമാണ്. ഉദാഹരണത്തിന്, ഒരു വെർച്വൽ മെഷീൻ ഒരു നിശ്ചിത സമയത്ത് പ്രകടന പ്രശ്നങ്ങൾ അനുഭവിക്കാൻ തുടങ്ങിയാൽ, നിങ്ങൾക്ക് CPU റെഡി മൂല്യത്തിൻ്റെ ഇടവേളകൾ ഈ VM പ്രവർത്തിക്കുന്ന സെർവറിലെ മൊത്തം ലോഡുമായി താരതമ്യം ചെയ്യാം, കൂടാതെ ലോഡ് കുറയ്ക്കാൻ നടപടികൾ കൈക്കൊള്ളുക (DRS ആണെങ്കിൽ പരാജയപ്പെടുന്നു).

റെഡി, റെഡിനെസ് പോലെയല്ല, ശതമാനത്തിലല്ല, മില്ലിസെക്കൻഡിലാണ് കാണിക്കുന്നത്. ഇതൊരു സമ്മേഷൻ ടൈപ്പ് കൗണ്ടറാണ്, അതായത്, അളക്കൽ കാലയളവിൽ VM കോർ എത്രത്തോളം റെഡി സ്റ്റേറ്റിൽ ഉണ്ടായിരുന്നുവെന്ന് ഇത് കാണിക്കുന്നു. ഒരു ലളിതമായ ഫോർമുല ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഈ മൂല്യം ശതമാനമാക്കി മാറ്റാം:

(സിപിയു റെഡി സമ്മേഷൻ മൂല്യം / (സെക്കൻഡിൽ ചാർട്ട് ഡിഫോൾട്ട് അപ്ഡേറ്റ് ഇടവേള * 1000)) * 100 = സിപിയു തയ്യാറാണ് %

ഉദാഹരണത്തിന്, ചുവടെയുള്ള ഗ്രാഫിലെ VM-ന്, മുഴുവൻ വെർച്വൽ മെഷീൻ്റെയും പീക്ക് റെഡി മൂല്യം ഇനിപ്പറയുന്നതായിരിക്കും:

റെഡി ശതമാനം കണക്കാക്കുമ്പോൾ, നിങ്ങൾ രണ്ട് പോയിൻ്റുകൾ ശ്രദ്ധിക്കണം:

• മുഴുവൻ വിഎമ്മിനുമുള്ള റെഡി മൂല്യം കോറിലുടനീളം റെഡിയുടെ ആകെത്തുകയാണ്.
• അളക്കൽ ഇടവേള. തത്സമയം ഇത് 20 സെക്കൻഡ് ആണ്, ഉദാഹരണത്തിന്, പ്രതിദിന ചാർട്ടുകളിൽ ഇത് 300 സെക്കൻഡ് ആണ്.

സജീവമായ ട്രബിൾഷൂട്ടിംഗ് ഉപയോഗിച്ച്, ഈ ലളിതമായ പോയിൻ്റുകൾ എളുപ്പത്തിൽ നഷ്‌ടപ്പെടുത്താനും നിലവിലില്ലാത്ത പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന് വിലപ്പെട്ട സമയം പാഴാക്കാനും കഴിയും.

ചുവടെയുള്ള ഗ്രാഫിൽ നിന്നുള്ള ഡാറ്റയെ അടിസ്ഥാനമാക്കി റെഡി എന്ന് കണക്കാക്കാം. മുഴുവൻ വിഎമ്മിനും (324474/(20*1000))*100 = 1622%. നിങ്ങൾ കോറുകൾ നോക്കുകയാണെങ്കിൽ അത് അത്ര ഭയാനകമല്ല: 1622/64 = ഓരോ കോറിനും 25%. ഈ സാഹചര്യത്തിൽ, ക്യാച്ച് കണ്ടെത്തുന്നത് വളരെ എളുപ്പമാണ്: റെഡി മൂല്യം അയഥാർത്ഥമാണ്. നിരവധി കോറുകളുള്ള മുഴുവൻ വിഎമ്മിനും 10-20% ആണ് നമ്മൾ സംസാരിക്കുന്നതെങ്കിൽ, ഓരോ കോറിനും മൂല്യം സാധാരണ പരിധിക്കുള്ളിലായിരിക്കാം.

ഞാൻ എന്തു ചെയ്യണം? വെർച്വൽ മെഷീനുകളുടെ സാധാരണ പ്രവർത്തനത്തിന് ആവശ്യമായ പ്രോസസർ ഉറവിടങ്ങൾ സെർവറിന് ഇല്ലെന്ന് ഉയർന്ന റെഡി മൂല്യം സൂചിപ്പിക്കുന്നു. അത്തരമൊരു സാഹചര്യത്തിൽ, പ്രോസസ്സർ (vCPU:pCPU) വഴിയുള്ള ഓവർസബ്സ്ക്രിപ്ഷൻ കുറയ്ക്കുക മാത്രമാണ് അവശേഷിക്കുന്നത്. വ്യക്തമായും, നിലവിലുള്ള VM-കളുടെ പാരാമീറ്ററുകൾ കുറയ്ക്കുന്നതിലൂടെയോ VM-കളുടെ ഒരു ഭാഗം മറ്റ് സെർവറുകളിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുന്നതിലൂടെയോ ഇത് നേടാനാകും.

കോ-സ്റ്റോപ്പ്

എങ്ങനെ വിശകലനം ചെയ്യാം? ഈ കൌണ്ടറും സമ്മേഷൻ തരത്തിലുള്ളതാണ്, അത് തയ്യാറായത് പോലെ തന്നെ ശതമാനത്തിലേക്ക് പരിവർത്തനം ചെയ്യപ്പെടുന്നു:

(സിപിയു കോ-സ്റ്റോപ്പ് സമ്മേഷൻ മൂല്യം / (സെക്കൻഡുകളിൽ ചാർട്ട് ഡിഫോൾട്ട് അപ്ഡേറ്റ് ഇടവേള * 1000)) * 100 = സിപിയു കോ-സ്റ്റോപ്പ് %

വിഎമ്മിലെ കോറുകളുടെ എണ്ണവും അളക്കൽ ഇടവേളയും ഇവിടെ നിങ്ങൾ ശ്രദ്ധിക്കേണ്ടതുണ്ട്.
കോസ്റ്റോപ്പ് അവസ്ഥയിൽ, കേർണൽ ഉപയോഗപ്രദമായ ജോലി ചെയ്യുന്നില്ല. സെർവറിലെ VM വലുപ്പവും സാധാരണ ലോഡും ശരിയായി തിരഞ്ഞെടുത്താൽ, കോ-സ്റ്റോപ്പ് കൗണ്ടർ പൂജ്യത്തിനടുത്തായിരിക്കണം.

ഈ സാഹചര്യത്തിൽ, ലോഡ് വ്യക്തമായും അസാധാരണമാണ് :)

ഞാൻ എന്തു ചെയ്യണം? ഒരു ഹൈപ്പർവൈസറിൽ ധാരാളം കോറുകളുള്ള നിരവധി വിഎമ്മുകൾ പ്രവർത്തിക്കുകയും സിപിയുവിൽ ഓവർസബ്‌സ്‌ക്രിപ്‌ഷൻ ഉണ്ടെങ്കിൽ, കോ-സ്റ്റോപ്പ് കൗണ്ടർ വർദ്ധിച്ചേക്കാം, ഇത് ഈ വിഎമ്മുകളുടെ പ്രകടനത്തിൽ പ്രശ്‌നങ്ങൾക്ക് ഇടയാക്കും.

കൂടാതെ, ഒരു VM-ൻ്റെ സജീവ കോറുകൾ ഒരു ഫിസിക്കൽ സെർവർ കോറിൽ ഹൈപ്പർ-ട്രെഡിംഗ് പ്രവർത്തനക്ഷമമാക്കിയ ത്രെഡുകൾ ഉപയോഗിക്കുകയാണെങ്കിൽ കോ-സ്റ്റോപ്പ് വർദ്ധിക്കും. ഉദാഹരണത്തിന്, VM-ന് അത് പ്രവർത്തിക്കുന്ന സെർവറിൽ ഭൗതികമായി ലഭ്യമാവുന്നതിനേക്കാൾ കൂടുതൽ കോറുകൾ ഉണ്ടെങ്കിൽ അല്ലെങ്കിൽ VM-നായി "preferHT" ക്രമീകരണം പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടെങ്കിൽ ഈ സാഹചര്യം ഉണ്ടാകാം. ഈ ക്രമീകരണത്തെക്കുറിച്ച് നിങ്ങൾക്ക് വായിക്കാം ഇവിടെ.

ഉയർന്ന കോ-സ്റ്റോപ്പ് കാരണം VM പ്രകടനത്തിലെ പ്രശ്നങ്ങൾ ഒഴിവാക്കാൻ, ഈ VM-ൽ പ്രവർത്തിക്കുന്ന സോഫ്റ്റ്‌വെയറിൻ്റെ നിർമ്മാതാവിൻ്റെ ശുപാർശകൾക്കും VM പ്രവർത്തിക്കുന്ന ഫിസിക്കൽ സെർവറിൻ്റെ കഴിവുകൾക്കും അനുസൃതമായി VM വലുപ്പം തിരഞ്ഞെടുക്കുക.

കരുതലിൽ കോറുകൾ ചേർക്കരുത്; ഇത് VM-ന് മാത്രമല്ല, സെർവറിലെ അയൽക്കാർക്കും പ്രകടന പ്രശ്നങ്ങൾ ഉണ്ടാക്കിയേക്കാം.

മറ്റ് ഉപയോഗപ്രദമായ CPU മെട്രിക്കുകൾ

പ്രവർത്തിപ്പിക്കുക - അളക്കൽ കാലയളവിൽ എത്ര സമയം (മി.സെ.) vCPU RUN അവസ്ഥയിലായിരുന്നു, അതായത്, അത് യഥാർത്ഥത്തിൽ ഉപയോഗപ്രദമായ ജോലി ചെയ്യുന്നു.

നിഷ്ക്രിയം - അളക്കൽ കാലയളവിൽ എത്ര സമയം (മി.സെ.) vCPU നിഷ്ക്രിയാവസ്ഥയിലായിരുന്നു. ഉയർന്ന നിഷ്‌ക്രിയ മൂല്യങ്ങൾ ഒരു പ്രശ്‌നമല്ല, വിസിപിയുവിന് “ഒന്നും ചെയ്യാനില്ല.”

കാക്കുക - അളക്കൽ കാലയളവിൽ എത്ര സമയം (മിസെ) vCPU വെയ്റ്റ് അവസ്ഥയിലായിരുന്നു. ഈ കൗണ്ടറിൽ IDLE ഉൾപ്പെടുത്തിയിരിക്കുന്നതിനാൽ, ഉയർന്ന കാത്തിരിപ്പ് മൂല്യങ്ങളും ഒരു പ്രശ്നത്തെ സൂചിപ്പിക്കുന്നില്ല. വെയ്റ്റ് കൂടുതലായിരിക്കുമ്പോൾ വെയ്റ്റ് ഐഡിഎൽ കുറവാണെങ്കിൽ, ഐ/ഒ ഓപ്പറേഷനുകൾ പൂർത്തിയാകുന്നതിനായി വിഎം കാത്തിരിക്കുകയായിരുന്നു എന്നാണ് ഇതിനർത്ഥം, ഇത് ഹാർഡ് ഡ്രൈവിൻ്റെ അല്ലെങ്കിൽ വിഎം-ൻ്റെ ഏതെങ്കിലും വെർച്വൽ ഉപകരണങ്ങളുടെ പ്രകടനത്തിലെ പ്രശ്‌നത്തെ സൂചിപ്പിക്കാം.

പരമാവധി പരിമിതം - സെറ്റ് റിസോഴ്സ് പരിധി കാരണം അളക്കൽ കാലയളവിൽ എത്ര സമയം (മിസെ) vCPU തയ്യാറായ നിലയിലായിരുന്നു. പ്രകടനം വിശദീകരിക്കാനാകാത്തവിധം കുറവാണെങ്കിൽ, ഈ കൗണ്ടറിൻ്റെ മൂല്യവും വിഎം ക്രമീകരണങ്ങളിലെ സിപിയു പരിധിയും പരിശോധിക്കുന്നത് ഉപയോഗപ്രദമാണ്. VM-കൾക്ക് നിങ്ങൾക്ക് അറിയാത്ത പരിധികൾ ഉണ്ടായിരിക്കാം. ഉദാഹരണത്തിന്, CPU പരിധി സജ്ജീകരിച്ചിട്ടുള്ള ഒരു ടെംപ്ലേറ്റിൽ നിന്ന് ഒരു VM ക്ലോൺ ചെയ്യുമ്പോൾ ഇത് സംഭവിക്കുന്നു.

കാത്തിരിക്കുക - അളക്കൽ കാലയളവിൽ എത്ര സമയം vCPU VMkernel Swap ഉപയോഗിച്ച് ഒരു പ്രവർത്തനത്തിനായി കാത്തിരിക്കുന്നു. ഈ കൗണ്ടറിൻ്റെ മൂല്യങ്ങൾ പൂജ്യത്തിന് മുകളിലാണെങ്കിൽ, VM ന് തീർച്ചയായും പ്രകടന പ്രശ്‌നങ്ങളുണ്ട്. റാം കൗണ്ടറുകളെക്കുറിച്ചുള്ള ലേഖനത്തിൽ നമ്മൾ SWAP നെ കുറിച്ച് കൂടുതൽ സംസാരിക്കും.

ESXTOP

ചരിത്രപരമായ ഡാറ്റ വിശകലനം ചെയ്യുന്നതിന് vCenter-ലെ പ്രകടന കൗണ്ടറുകൾ നല്ലതാണെങ്കിൽ, പ്രശ്നത്തിൻ്റെ പ്രവർത്തന വിശകലനം ESXTOP-ൽ ചെയ്യുന്നതാണ് നല്ലത്. ഇവിടെ, എല്ലാ മൂല്യങ്ങളും റെഡിമെയ്ഡ് ഫോമിൽ അവതരിപ്പിച്ചിരിക്കുന്നു (ഒന്നും വിവർത്തനം ചെയ്യേണ്ട ആവശ്യമില്ല), ഏറ്റവും കുറഞ്ഞ അളവെടുപ്പ് കാലയളവ് 2 സെക്കൻഡാണ്.
CPU-നുള്ള ESXTOP സ്‌ക്രീൻ "c" കീ ഉപയോഗിച്ച് വിളിക്കുകയും ഇതുപോലെ കാണപ്പെടുന്നു:

സൗകര്യാർത്ഥം, Shift-V അമർത്തിക്കൊണ്ട് നിങ്ങൾക്ക് വെർച്വൽ മെഷീൻ പ്രോസസ്സുകൾ മാത്രം വിടാം.
വ്യക്തിഗത VM കോറുകൾക്കുള്ള മെട്രിക്‌സ് കാണുന്നതിന്, “e” അമർത്തി താൽപ്പര്യമുള്ള VM-ൻ്റെ GID നൽകുക (ചുവടെയുള്ള സ്‌ക്രീൻഷോട്ടിൽ 30919):

സ്ഥിരസ്ഥിതിയായി അവതരിപ്പിക്കുന്ന കോളങ്ങളിലൂടെ ഞാൻ ഹ്രസ്വമായി പോകട്ടെ. "f" അമർത്തി കൂടുതൽ നിരകൾ ചേർക്കാവുന്നതാണ്.

NWLD (ലോകങ്ങളുടെ എണ്ണം) - ഗ്രൂപ്പിലെ പ്രക്രിയകളുടെ എണ്ണം. ഗ്രൂപ്പ് വിപുലീകരിക്കുന്നതിനും ഓരോ പ്രോസസിനും മെട്രിക്‌സ് കാണുന്നതിനും (ഉദാഹരണത്തിന്, ഒരു മൾട്ടി-കോർ വിഎമ്മിലെ ഓരോ കോറിനും), “e” അമർത്തുക. ഒരു ഗ്രൂപ്പിൽ ഒന്നിൽ കൂടുതൽ പ്രക്രിയകൾ ഉണ്ടെങ്കിൽ, ഗ്രൂപ്പിനുള്ള മെട്രിക് മൂല്യങ്ങൾ വ്യക്തിഗത പ്രോസസ്സുകൾക്കുള്ള മെട്രിക്സിൻ്റെ ആകെത്തുകയ്ക്ക് തുല്യമാണ്.

%ഉപയോഗിച്ചു - എത്ര സെർവർ സിപിയു സൈക്കിളുകൾ ഒരു പ്രോസസ്സ് അല്ലെങ്കിൽ പ്രോസസ്സുകളുടെ ഗ്രൂപ്പ് ഉപയോഗിക്കുന്നു.

%RUN - അളക്കൽ കാലയളവിൽ പ്രക്രിയ എത്രത്തോളം RUN അവസ്ഥയിലായിരുന്നു, അതായത്. ഉപയോഗപ്രദമായ ജോലി ചെയ്തു. ഹൈപ്പർ-ത്രെഡിംഗ്, ഫ്രീക്വൻസി സ്കെയിലിംഗ്, സിസ്റ്റം ടാസ്‌ക്കുകൾക്കായി ചെലവഴിച്ച സമയം (%SYS) എന്നിവ കണക്കിലെടുക്കാത്തതിനാൽ ഇത് %USED-ൽ നിന്ന് വ്യത്യസ്തമാണ്.

%SYS – സിസ്റ്റം ടാസ്‌ക്കുകളിൽ ചെലവഴിച്ച സമയം, ഉദാഹരണത്തിന്: ഇൻ്ററപ്റ്റ് പ്രോസസ്സിംഗ്, I/O, നെറ്റ്‌വർക്ക് ഓപ്പറേഷൻ മുതലായവ. VM-ന് വലിയ I/O ഉണ്ടെങ്കിൽ മൂല്യം ഉയർന്നതായിരിക്കും.

%OVRLP - VM പ്രോസസ്സ് പ്രവർത്തിക്കുന്ന ഫിസിക്കൽ കോർ മറ്റ് പ്രക്രിയകളുടെ ചുമതലകൾക്കായി എത്ര സമയം ചെലവഴിച്ചു.

ഈ അളവുകൾ പരസ്പരം ഇനിപ്പറയുന്ന രീതിയിൽ ബന്ധപ്പെട്ടിരിക്കുന്നു:

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

സാധാരണഗതിയിൽ %USED മെട്രിക് കൂടുതൽ വിവരദായകമാണ്.

% കാത്തിരിക്കുക - അളക്കൽ കാലയളവിൽ പ്രക്രിയ എത്രത്തോളം വെയ്റ്റ് അവസ്ഥയിലായിരുന്നു. IDLE പ്രവർത്തനക്ഷമമാക്കുന്നു.

%IDLE - അളക്കൽ കാലയളവിൽ പ്രക്രിയ IDLE അവസ്ഥയിൽ എത്രത്തോളം ഉണ്ടായിരുന്നു.

%SWPWT - അളക്കൽ കാലയളവിൽ എത്ര സമയം vCPU VMkernel Swap ഉപയോഗിച്ച് ഒരു പ്രവർത്തനത്തിനായി കാത്തിരിക്കുന്നു.

%VMWAIT - അളക്കൽ കാലയളവിൽ എത്രത്തോളം vCPU ഒരു ഇവൻ്റിനായി കാത്തിരിക്കുന്ന അവസ്ഥയിലായിരുന്നു (സാധാരണയായി I/O). vCenter-ൽ സമാനമായ കൗണ്ടർ ഒന്നുമില്ല. ഉയർന്ന മൂല്യങ്ങൾ VM-ൽ I/O-യിലെ പ്രശ്നങ്ങൾ സൂചിപ്പിക്കുന്നു.

%WAIT = %VMWAIT + %IDLE + %SWPWT.

VM VMkernel Swap ഉപയോഗിക്കുന്നില്ലെങ്കിൽ, പ്രകടന പ്രശ്നങ്ങൾ വിശകലനം ചെയ്യുമ്പോൾ %VMWAIT നോക്കുന്നത് ഉചിതമാണ്, കാരണം VM ഒന്നും ചെയ്യാതിരുന്ന സമയം (%IDLE) ഈ മെട്രിക് കണക്കിലെടുക്കുന്നില്ല.

%RDY - അളക്കൽ കാലയളവിൽ പ്രക്രിയ എത്രത്തോളം തയ്യാറായ നിലയിലായിരുന്നു.

%CSTP - അളക്കൽ കാലയളവിൽ എത്രത്തോളം പ്രക്രിയ കോസ്റ്റോപ്പ് അവസ്ഥയിലായിരുന്നു.

%MLMTD - സെറ്റ് റിസോഴ്സ് പരിധി കാരണം അളക്കൽ കാലയളവിൽ എത്ര സമയം vCPU തയ്യാറായ നിലയിലായിരുന്നു.

%WAIT + %RDY + %CSTP + %RUN = 100% - VM കോർ എല്ലായ്പ്പോഴും ഈ നാല് സംസ്ഥാനങ്ങളിൽ ഒന്നിലായിരിക്കും.

ഹൈപ്പർവൈസറിൽ സിപിയു

ഹൈപ്പർവൈസറിനായി vCenter-ന് CPU പ്രകടന കൗണ്ടറുകളും ഉണ്ട്, എന്നാൽ അവ രസകരമല്ല - അവ സെർവറിലെ എല്ലാ VM-കൾക്കുമുള്ള കൗണ്ടറുകളുടെ ആകെത്തുകയാണ്.
സെർവറിലെ സിപിയു നില കാണുന്നതിനുള്ള ഏറ്റവും സൗകര്യപ്രദമായ മാർഗം സംഗ്രഹ ടാബിലാണ്:

സെർവറിനും വെർച്വൽ മെഷീനിനും ഒരു സാധാരണ അലാറം ഉണ്ട്:

സെർവർ CPU ലോഡ് കൂടുതലായിരിക്കുമ്പോൾ, അതിൽ പ്രവർത്തിക്കുന്ന VM-കൾ പ്രകടന പ്രശ്നങ്ങൾ അനുഭവിക്കാൻ തുടങ്ങുന്നു.

ESXTOP-ൽ, സെർവർ CPU ലോഡ് ഡാറ്റ സ്ക്രീനിൻ്റെ മുകളിൽ അവതരിപ്പിക്കുന്നു. ഹൈപ്പർവൈസറുകൾക്ക് വളരെ വിവരദായകമല്ലാത്ത സ്റ്റാൻഡേർഡ് സിപിയു ലോഡിന് പുറമേ, മൂന്ന് മെട്രിക്കുകൾ കൂടി ഉണ്ട്:

കോർ UTIL(%) - ഫിസിക്കൽ സെർവർ കോർ ലോഡ് ചെയ്യുന്നു. അളക്കൽ കാലയളവിൽ കോർ എത്ര സമയം പ്രവർത്തിച്ചുവെന്ന് ഈ കൗണ്ടർ കാണിക്കുന്നു.

PCPU UTIL(%) - ഹൈപ്പർ-ത്രെഡിംഗ് പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടെങ്കിൽ, ഓരോ ഫിസിക്കൽ കോറിനും രണ്ട് ത്രെഡുകൾ (പിസിപിയു) ഉണ്ട്. ഓരോ ത്രെഡും ജോലി പൂർത്തിയാക്കാൻ എത്ര സമയമെടുത്തുവെന്ന് ഈ മെട്രിക് കാണിക്കുന്നു.

PCPU ഉപയോഗിച്ചു(%) – PCPU UTIL(%) പോലെ തന്നെ, എന്നാൽ ഫ്രീക്വൻസി സ്കെയിലിംഗ് (ഒന്നുകിൽ ഊർജ്ജ സംരക്ഷണ ആവശ്യങ്ങൾക്കായി കോർ ഫ്രീക്വൻസി കുറയ്ക്കുക, അല്ലെങ്കിൽ ടർബോ ബൂസ്റ്റ് സാങ്കേതികവിദ്യ കാരണം കോർ ഫ്രീക്വൻസി വർദ്ധിപ്പിക്കുക) കൂടാതെ ഹൈപ്പർ-ത്രെഡിംഗും കണക്കിലെടുക്കുന്നു.

PCPU_USED% = PCPU_UTIL% * ഫലപ്രദമായ കോർ ഫ്രീക്വൻസി / നോമിനൽ കോർ ഫ്രീക്വൻസി.

ഈ സ്ക്രീൻഷോട്ടിൽ, ചില കോറുകൾക്ക്, ടർബോ ബൂസ്റ്റ് കാരണം, USED മൂല്യം 100%-ൽ കൂടുതലാണ്, കാരണം കോർ ഫ്രീക്വൻസി നാമമാത്രമായതിനേക്കാൾ കൂടുതലാണ്.

ഹൈപ്പർ-ത്രെഡിംഗ് എങ്ങനെ കണക്കിലെടുക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള കുറച്ച് വാക്കുകൾ. സെർവറിൻ്റെ ഫിസിക്കൽ കോറിൻ്റെ രണ്ട് ത്രെഡുകളിലും 100% സമയവും പ്രക്രിയകൾ നടപ്പിലാക്കുകയാണെങ്കിൽ, കോർ നാമമാത്രമായ ആവൃത്തിയിലാണ് പ്രവർത്തിക്കുന്നത്, അപ്പോൾ:

• കോറിൻ്റെ CORE UTIL 100% ആയിരിക്കും,
• രണ്ട് ത്രെഡുകൾക്കുമുള്ള PCPU UTIL 100% ആയിരിക്കും,
• രണ്ട് ത്രെഡുകൾക്കും ഉപയോഗിക്കുന്ന PCPU 50% ആയിരിക്കും.

അളക്കൽ കാലയളവിൽ രണ്ട് ത്രെഡുകളും 100% സമയവും പ്രവർത്തിച്ചില്ലെങ്കിൽ, ത്രെഡുകൾ സമാന്തരമായി പ്രവർത്തിക്കുന്ന ആ കാലഘട്ടങ്ങളിൽ, കോറുകൾക്കായി ഉപയോഗിക്കുന്ന PCPU പകുതിയായി വിഭജിക്കപ്പെടുന്നു.

ESXTOP-ന് സെർവർ CPU പവർ ഉപഭോഗ പാരാമീറ്ററുകളുള്ള ഒരു സ്ക്രീനും ഉണ്ട്. സെർവർ ഊർജ്ജ സംരക്ഷണ സാങ്കേതികവിദ്യകൾ ഉപയോഗിക്കുന്നുണ്ടോ എന്ന് ഇവിടെ നിങ്ങൾക്ക് കാണാൻ കഴിയും: സി-സ്റ്റേറ്റുകളും പി-സ്റ്റേറ്റുകളും. "p" കീ ഉപയോഗിച്ച് വിളിക്കുന്നു:

സാധാരണ CPU പ്രകടന പ്രശ്നങ്ങൾ

അവസാനമായി, വിഎം സിപിയു പ്രകടനത്തിലെ പ്രശ്നങ്ങളുടെ സാധാരണ കാരണങ്ങൾ ഞാൻ പരിശോധിക്കുകയും അവ പരിഹരിക്കുന്നതിനുള്ള ചെറിയ നുറുങ്ങുകൾ നൽകുകയും ചെയ്യും:

കോർ ക്ലോക്ക് സ്പീഡ് പോരാ. നിങ്ങളുടെ VM കൂടുതൽ ശക്തമായ കോറുകളിലേക്ക് അപ്‌ഗ്രേഡ് ചെയ്യാൻ കഴിയുന്നില്ലെങ്കിൽ, ടർബോ ബൂസ്റ്റ് കൂടുതൽ കാര്യക്ഷമമായി പ്രവർത്തിക്കുന്നതിന് നിങ്ങൾക്ക് പവർ ക്രമീകരണങ്ങൾ മാറ്റാൻ ശ്രമിക്കാവുന്നതാണ്.

തെറ്റായ വിഎം വലുപ്പം (വളരെയധികം/കുറച്ച് കോറുകൾ). നിങ്ങൾ കുറച്ച് കോറുകൾ ഇൻസ്റ്റാൾ ചെയ്യുകയാണെങ്കിൽ, VM-ൽ ഉയർന്ന CPU ലോഡ് ഉണ്ടാകും. ധാരാളം ഉണ്ടെങ്കിൽ, ഉയർന്ന കോ-സ്റ്റോപ്പ് പിടിക്കുക.

സെർവറിൽ CPU-യുടെ വലിയ ഓവർസബ്‌സ്‌ക്രിപ്ഷൻ. VM-ന് ഉയർന്ന റെഡി ഉണ്ടെങ്കിൽ, CPU ഓവർസബ്സ്ക്രിപ്ഷൻ കുറയ്ക്കുക.

വലിയ VM-കളിൽ തെറ്റായ NUMA ടോപ്പോളജി. VM (vNUMA) കാണുന്ന NUMA ടോപ്പോളജി സെർവറിൻ്റെ (pNUMA) NUMA ടോപ്പോളജിയുമായി പൊരുത്തപ്പെടണം. ഈ പ്രശ്നത്തിനുള്ള ഡയഗ്നോസ്റ്റിക്സും സാധ്യമായ പരിഹാരങ്ങളും എഴുതിയിട്ടുണ്ട്, ഉദാഹരണത്തിന്, പുസ്തകത്തിൽ "VMware vSphere 6.5 ഹോസ്റ്റ് റിസോഴ്‌സ് ഡീപ് ഡൈവ്". നിങ്ങൾക്ക് കൂടുതൽ ആഴത്തിൽ പോകാൻ താൽപ്പര്യമില്ലെങ്കിൽ VM-ൽ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള OS-ന് നിങ്ങൾക്ക് ലൈസൻസിംഗ് നിയന്ത്രണങ്ങൾ ഇല്ലെങ്കിൽ, VM-ൽ നിരവധി വെർച്വൽ സോക്കറ്റുകൾ ഉണ്ടാക്കുക, ഒരു സമയം. നിങ്ങൾക്ക് വളരെയധികം നഷ്ടപ്പെടില്ല :)

സിപിയുവിനെക്കുറിച്ച് എനിക്ക് അത്രയേയുള്ളൂ. ചോദ്യങ്ങൾ ചോദിക്കാൻ. അടുത്ത ഭാഗത്തിൽ ഞാൻ റാമിനെക്കുറിച്ച് സംസാരിക്കും.

ഉപയോഗപ്രദമായ ലിങ്കുകൾ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