VPS-ல் CPU Steal Time என்றால் என்ன? அதை கண்டறிவது எப்படி?

CPU steal time எதை அளவிடுகிறது

CPU steal time என்பது உங்கள் virtual CPU இயங்குவதற்குத் தயாராக இருந்தும், எதற்கும் காத்திருக்க வேண்டிய அவசியம் இல்லாதபோதும், hypervisor அந்த physical core-ஐ வேறொரு guest-க்கு ஒதுக்கிய நேரத்தைக் குறிக்கிறது. உங்கள் பணி வரிசையில் (queued) இருந்தது. அந்த core வேறொரு இடத்தில் இருந்தது. Linux இந்தச் சுழற்சிகளைத் தனியாகக் கணக்கிட்டு st எனப் பதிவு செய்கிறது. இதன் மூலமே "எனது server பிஸியாக உள்ளது" என்பதற்கும் "எனது server தனது முறைக்காகக் காத்திருக்கிறது" என்பதற்கும் உள்ள வித்தியாசத்தை நீங்கள் அறிய முடியும்.

இந்த வித்தியாசத்தைக் கண்டறிவதுதான் இந்தக் கணக்கீட்டின் முக்கிய நோக்கமே. உங்கள் சொந்த process-கள் CPU-வில் செலவிடும் நேரம் us (user) அல்லது sy (system) எனப் பதிவு செய்யப்படுகிறது. ஒரு பணி storage-க்காகக் காத்திருக்கும் நேரம் wa (I/O wait) எனப் பதிவு செய்யப்படுகிறது. ஒரு vCPU (virtual CPU) இயங்கத் தயாராக இருந்து, run queue-வில் அமர்ந்து, I/O நிலுவையில் இல்லாதபோதும் இயங்கவில்லை என்றால், அது st எனப் பதிவு செய்யப்படுகிறது. உங்கள் server-க்குள் இருக்கும் எதனாலும் இந்த நிலையை மாற்ற முடியாது, ஏனெனில் scheduling முடிவுகள் உங்களுக்குக் கீழே உள்ள host மட்டத்திலேயே எடுக்கப்படுகின்றன.

இது ஒரு VPS பல guest-களுக்கு இடையே ஒரு physical machine-ஐ எவ்வாறு பகிர்ந்து கொள்கிறது என்பதிலிருந்து நேரடியாகத் தொடர்கிறது. இதற்குச் சாதாரணமான காரணம் ஒரு அண்டை guest ஆகும்: அதே node-ல் உள்ள மற்றொரு guest அதிகச் சுமையுடன் இயங்கும்போது, host அந்த core-களை உங்களுக்கும் அவர்களுக்கும் இடையில் பகிர்ந்து கொள்கிறது. கவனிக்கப்படாத இரண்டாவது காரணமும் ஒன்று உள்ளது. பல providers ஒரு shared vCPU-வை ஒரு physical core-ன் ஒரு பகுதியாக மட்டுமே கட்டுப்படுத்துகிறார்கள் (cap). பல hypervisor-களில், அவ்வாறு அமல்படுத்தப்பட்ட கட்டுப்பாடு guest-க்குள் steal ஆகக் கணக்கிடப்படுகிறது. எனவே, அதிக st அளவீடு என்பது அந்த core உங்களுக்கு வழங்கப்படவில்லை என்பதை மட்டுமே உணர்த்துகிறது. அதை யார் எடுத்துக்கொண்டார்கள் என்பதை அது எப்போதும் சொல்வதில்லை.

steal எண் எங்கிருந்து வருகிறது

உங்கள் kernel-ஆல் steal-ஐ தானாகவே அளவிட முடியாது, ஏனெனில் அதற்கு host-ஐப் பார்க்க முடியாது. hypervisor தான் அதைத் தெரிவிக்கிறது. KVM-ல், host ஒரு per-vCPU counter-ஐ guest-உடன் பகிரப்பட்ட ஒரு பக்கத்தில் (page) எழுதுகிறது. kernel CONFIG_PARAVIRT_TIME_ACCOUNTING உடன் கட்டமைக்கப்பட்டிருந்தால், guest அதைச் சேர்த்துக் கொள்கிறது; அனைத்து distribution kernel-களும் இவ்வாறுதான் கட்டமைக்கப்பட்டுள்ளன. Xen அதன் runstate பகுதி வழியாக இதையே தெரிவிக்கிறது. இந்த மொத்த மதிப்பு userspace-க்கு ஒரே ஒரு இடத்தில் மட்டுமே கிடைக்கிறது:

head -1 /proc/stat

அந்த cpu வரியில் பத்து counter-கள் உள்ளன. இவை boot ஆனதிலிருந்து USER_HZ ticks-ல் கணக்கிடப்படுகின்றன. அவற்றின் வரிசை: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. label-க்கு அடுத்துள்ள எட்டாவது மதிப்புதான் steal ஆகும். கீழே உள்ள அனைத்து கருவிகளும், அதாவது vmstat, top, mpstat மற்றும் எந்தவொரு Prometheus exporter-ம், அதே field-ஐப் படித்து, இரண்டு மாதிரிகளை (samples) சதவீதமாக மாற்றுகின்றன.

இதன் விளைவுகளில் ஒன்று மற்றவற்றை விட முக்கியமானது. hypervisor இந்த counter-ஐ ஒருபோதும் export செய்யவில்லை என்றால், அந்த field எப்போதும் பூஜ்ஜியமாகவே இருக்கும். host அதிக சுமையுடன் (overloaded) இருந்தாலும், அதை அடிப்படையாகக் கொண்ட அனைத்து கருவிகளும் 0.0 என்று அமைதியான நிலையைக் காட்டும். KVM மற்றும் Xen இதை export செய்கின்றன. VMware மற்றும் Hyper-V-ல் இயங்கும் guest-கள் பொதுவாக பூஜ்ஜியத்தையே காட்டுகின்றன. பூஜ்ஜியத்தை நம்புவதற்கு முன் platform-ஐச் சரிபார்க்கவும்:

systemd-detect-virt

இது kvm, xen, vmware அல்லது microsoft போன்ற platform பெயரை அச்சிடும்; bare metal-ல் none என்று காட்டும். container-க்குள் இது runtime-ஐ மட்டுமே காட்டும், உதாரணமாக lxc, docker அல்லது podman. இது உங்களுக்கு machine-ஐப் பற்றித் தெரிவிக்காமல், container-ஐப் பற்றி மட்டுமே தெரிவிக்கும். kvm-ல் பூஜ்ஜியம் என்பது host உங்களைச் சரியாக நடத்துகிறது என்பதற்கான உண்மையான சான்றாகும். இந்த field-ஐ ஒருபோதும் நிரப்பாத platform-ல், பூஜ்ஜியம் என்பது எந்தச் சான்றும் அல்ல; அங்கு உண்மையான பணிகளைச் செய்து முடிக்கும் நேரத்தை வைத்தே நெரிசலை (contention) மதிப்பிட வேண்டும்.

VPS-ல் CPU steal time-ஐ எவ்வாறு சரிபார்ப்பது?

vmstat என்பது procps தொகுப்பிலிருந்து (package) கிடைக்கிறது. இது பெரும்பாலான Ubuntu மற்றும் Debian VPS பிம்பங்களில் (images) ஏற்கனவே இருக்கும். சில மிகச்சிறிய (minimal) container பிம்பங்களில் இது இருக்காது, எனவே இதைச் சார்ந்திருக்கும் முன் நிறுவிக்கொள்ளவும்.

sudo apt-get update
sudo apt-get install -y procps
vmstat --version
vmstat 1 5

vmstat --version கட்டளை vmstat from procps-ng 4.0.4 போன்ற ஒரு வரியை வெளியிடும். இது திரையில் தோன்றினால், கருவி நிறுவப்பட்டுள்ளது மற்றும் நீங்கள் உண்மையான kernel counters-ஐ வாசிக்கிறீர்கள் என்று அர்த்தம். vmstat 1 5 கட்டளை ஒரு வினாடிக்கு ஒரு மாதிரி (sample) வீதம், ஐந்து முறை தரவுகளைச் சேகரிக்கும்.

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 3216484  98304 1284360    0    0     4    18   62  110  3  1 96  0  0  0
 2  0      0 3216232  98304 1284360    0    0     0     0  248  431  6  2 84  0  8  0

வலதுபுறம் உள்ள cpu தொகுதியில் st நெடுவரிசையைக் (column) கண்டறியவும். தற்போதைய procps-ng உருவாக்கங்களில், KVM guest நேரத்திற்காக gu நெடுவரிசை அதற்குப் பிறகு அச்சிடப்படுகிறது. எனவே, st என்பது கடைசி நெடுவரிசையாக இல்லாமல், வலமிருந்து இரண்டாவதாக இருக்கும். நெடுவரிசையின் தலைப்புப் பெயரை வைத்து அதைக் கண்டறியவும், ஏனெனில் வெளியீட்டு பதிப்புகளுக்கிடையே அதன் இடம் மாறியிருக்கலாம்.

துல்லியமான வாசிப்பிற்கு இரண்டு பழக்கங்களைக் கடைப்பிடிக்கவும். முதல் தரவு வரி என்பது கணினி தொடங்கியதிலிருந்து (boot) உள்ள சராசரி, எனவே அதைத் தவிர்த்துவிட்டு அதற்குப் பின் வரும் வரிகளை வாசிக்கவும். ஒரு மாதிரி (sample) என்பது முழுமையான அளவீடு அல்ல, ஏனெனில் steal time திடீரென ஏற்படும்: vmstat 1 60 கட்டளையை இயக்கி, ஒரு நிமிடம் முழுமையாகக் கவனித்த பிறகே ஒரு முடிவுக்கு வரவும்.

top கட்டளை அதன் %Cpu(s) சுருக்க வரியில், st எனக் குறிக்கப்பட்ட புலத்தில் அதே எண்ணைக் காட்டும்:

%Cpu(s):  6.2 us,  2.1 sy,  0.0 ni, 83.9 id,  0.0 wa,  0.0 hi,  0.3 si,  7.5 st

ஒவ்வொரு core-க்கான விரிவான தகவலுக்கு, sysstat-ஐச் சேர்க்கவும்:

sudo apt-get install -y sysstat
mpstat -P ALL 1 5

mpstat ஒவ்வொரு CPU-க்கும் ஒரு வரிசையை அச்சிடும், அதில் %steal நெடுவரிசை இருக்கும். இது அனைத்து vCPU-களும் பாதிக்கப்பட்டுள்ளதா அல்லது ஒன்று மட்டும் பாதிக்கப்பட்டுள்ளதா என்பதைக் காட்டும். ஆதரவு கோரும் (support ticket) தேவைக்காக, திரையில் பார்ப்பதை விட மாதிரிகளைச் சேமித்து வைக்கவும்:

date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.log

நீங்கள் சந்தேகப்படும் நேரங்களில் இதை cron மூலம் இயக்கவும். அப்போதுதான், "நேற்று இரவு வேகம் குறைவாக இருந்தது" என்று சொல்வதற்கும், அந்த பத்து நிமிடங்களுக்கான துல்லியமான தரவைக் காட்டுவதற்கும் உள்ள வித்தியாசத்தை நீங்கள் நிரூபிக்க முடியும்.

Steal எண்கள் எதைக் குறிக்கின்றன?

• நிலையான 0.0. இது ஆரோக்கியமானது, அல்லது அந்த தளம் steal அளவை அறிக்கையிடவில்லை என்று பொருள். நீங்கள் மகிழ்ச்சியடைவதற்கு முன் systemd-detect-virt மூலம் உறுதிப்படுத்தவும்.
• சில நொடிகள் நீடிக்கும் சில சதவீத அளவிலான திடீர் அதிகரிப்பு. பகிரப்பட்ட node-களில் இது இயல்பானது. அண்டை பயனரின் build செயல்முறை தொடங்குவது அல்லது host தனது backup-களை எடுப்பது இதற்குக் காரணமாக இருக்கலாம்.
• பகிரப்பட்ட திட்டத்தில் 1 முதல் 5 சதவீதம் வரை நீடித்திருக்கும் அளவு. இது எதிர்பார்க்கக்கூடியது. பகிரப்பட்ட CPU-விற்கான விலையே இதைக் குறிக்கிறது.
• 5 முதல் 10 சதவீதம் வரை நீடித்திருக்கும் அளவு. இது செயல்திறனில் மந்தநிலையை ஏற்படுத்தும். ஆதாரங்களைப் பதிவு செய்யத் தொடங்குங்கள், மேலும் பல நாட்களின் அதே நேரங்களுடன் ஒப்பிட்டுப் பாருங்கள்.
• மணிநேரக் கணக்கில் 10 சதவீதத்திற்கு மேல் இருப்பது. உங்கள் பணிச்சுமைக்கு அந்த node-ல் அதிகப்படியான பயனர்கள் உள்ளனர். இந்த நிலையில் நீங்கள் support ticket பதிவு செய்யலாம் அல்லது வேறு server-க்கு மாறலாம்.

எந்தவொரு சேவை வழங்குநரும் பகிரப்பட்ட திட்டத்தில் steal-க்கு உத்தரவாதம் அளிப்பதில்லை என்பதால், இந்த அளவீடுகளை ஒரு வழிகாட்டியாகக் கருதுங்கள், விதியாக அல்ல. நீங்கள் இயக்கும் பணிகளுடன் இவற்றை ஒப்பிட்டுப் பாருங்கள். இரவு நேர batch job-ல் 15 சதவீத steal இருந்தாலும் யாரும் அதைக் கவனிக்க மாட்டார்கள். ஆனால், latency-sensitive சேவைகளில் சராசரி அளவு கவலைக்குரியதாக மாறுவதற்கு முன்பே p99-ல் பாதிப்பு தெரியும். இதனால்தான் trading bots போன்ற latency-sensitive பணிகளுக்கு dedicated cores தேவைப்படுகின்றன.

Steal time உங்களுக்கு எவ்வளவு செலவை ஏற்படுத்துகிறது?

இதற்கான கணக்கீடு எளிதானது. உங்கள் CPU நேரத்தில் s பங்கு எடுக்கப்பட்டால், ஒரு குறிப்பிட்ட அளவு CPU தேவைப்படும் பணி, கடிகார நேரத்தில் 1 / (1 - s) மடங்கு அதிக நேரம் எடுக்கும். 60 வினாடிகள் CPU தேவைப்படும் ஒரு பணிக்கு:

[
  {
    "steal_percent": 0,
    "wall_clock_seconds": "60.0"
  },
  {
    "steal_percent": 3,
    "wall_clock_seconds": "61.9"
  },
  {
    "steal_percent": 8,
    "wall_clock_seconds": "65.2"
  },
  {
    "steal_percent": 15,
    "wall_clock_seconds": "70.6"
  },
  {
    "steal_percent": 25,
    "wall_clock_seconds": "80.0"
  },
  {
    "steal_percent": 40,
    "wall_clock_seconds": "100.0"
  }
]

பொதுவாக பகிரப்பட்ட திட்டங்களில் (shared-plan) காணப்படும் 3 சதவீதத்தில், அந்தப் பணி 60.0 வினாடிகளுக்குப் பதிலாக 61.9 வினாடிகள் எடுத்துக்கொள்ளும். இதற்காக யாரும் புகார் அளிப்பதில்லை. 8 சதவீதத்தில் இது 65.2 வினாடிகளாகிறது. 40 சதவீதத்தில் அதே பணிக்கு 100.0 வினாடிகள் தேவைப்படுகின்றன, இதனால் முன்பு சீராகச் செயல்பட்ட வரிசை (queue) தேங்கத் தொடங்குகிறது.

இவை கணக்கிடப்பட்ட மதிப்புகள், அளவீடுகள் அல்ல. இந்த மாதிரி, ஒரே ஒரு runnable thread இருப்பதையும், steal நேரம் இடைவெளியில் சமமாகப் பரவியிருப்பதையும் கருதுகிறது. நிஜமான சேவைகள் பெரும்பாலும் இந்த வரைபடத்தை விட மோசமாகச் செயல்படும். ஏனெனில், ஒரு stolen slice கோரிக்கையின் (request) நடுவில் நிகழும்போது, அந்தக் கோரிக்கையைச் சார்ந்திருக்கும் அனைத்துப் பணிகளும் மீண்டும் தாமதத்தைச் சந்திக்க நேரிடும். ஒரு சூத்திரத்தை மட்டும் நம்பியிருக்காமல், நீங்களே துல்லியமான மதிப்பைப் பெற, VPS-ஐ benchmark செய்யவும். இதைச் செய்ய, சர்வர் அமைதியாக இருக்கும் நேரத்திலும், அதிக வேலைப்பளு இருக்கும் நேரத்திலும் சோதனையை நடத்தி, இரண்டு கால இடைவெளிகளுக்கும் st மதிப்புகளைப் பதிவு செய்யவும்.

இது steal-ஆ அல்லது வேறு ஏதேனும் ஒன்றா?

Steal-ஐ மற்ற அறிகுறிகளுடன் குழப்பிக்கொள்வது எளிது. எனவே, vmstat வரியில் உள்ள counters-ஐ ஒன்றாகப் பார்க்கவும்.

• st அதிகமாக இருந்து, r மற்றும் us குறைவாக இருந்தால்: host உங்களுக்குத் தேவையான core-ஐ வழங்கவில்லை என்று அர்த்தம். இதுவே steal ஆகும்.
• r உங்கள் vCPU எண்ணிக்கையை விட அதிகமாக இருந்து, us அதிகமாகவும் st பூஜ்ஜியத்திற்கு அருகிலும் இருந்தால்: உங்கள் CPU-வின் திறனை விட அதிகமான வேலைகளை நீங்கள் செய்கிறீர்கள் என்று அர்த்தம். r-ஐ nproc-ன் வெளியீட்டுடன் ஒப்பிட்டுப் பார்க்கவும். இது உங்கள் சொந்த oversubscription-ஆல் ஏற்படுவது, பக்கத்து virtual machine-ஆல் அல்ல.
• wa அதிகமாக இருந்து st பூஜ்ஜியத்திற்கு அருகில் இருந்தால்: storage-ல் பணிகள் முடங்கியுள்ளன என்று அர்த்தம். இது ஒரு மாறுபட்ட சிக்கல், இதற்குத் தீர்வு வேறு.
• Load average அதிகமாக இருந்து st மற்றும் us ஆகிய இரண்டும் குறைவாக இருந்தால்: load என்பது uninterruptible பணிகளையும் கணக்கிடும். எனவே, இது பொதுவாக CPU சிக்கலைக் குறிக்காமல், ஏதேனும் ஒரு சாதனம் முடங்கியுள்ளதையோ அல்லது network mount சரியாகச் செயல்படாததையோ குறிக்கும்.

Burstable plans-க்குத் தனியாகக் கவனிக்க வேண்டியவை உள்ளன. இவை நீங்கள் idle-ஆக இருக்கும்போது credit balance-ஐச் சேர்த்து வைக்கும், நீங்கள் வேலையில் இருக்கும்போது அதைப் பயன்படுத்தும். அந்த balance தீர்ந்ததும், உங்கள் provider உங்களை baseline rate-ல் கட்டுப்படுத்தும். சில தளங்களில், இந்த throttling-ஐ steal என்று குறிப்பிடுவார்கள். மற்ற தளங்களில், இது உள்ளே இருந்து பார்க்கும்போது தெரியாது; உங்களுக்குக் கிடைக்கும் cycles-ன் எண்ணிக்கை மட்டும் குறையும். பக்கத்து virtual machine-தான் காரணம் என்று முடிவு செய்வதற்கு முன், உங்கள் plan-ன் விளக்கத்தைப் படிக்கவும்.

ஏன் ஒரு container steal time-ஐக் காட்டுவதில்லை

Steal என்பது virtual machine-ன் பண்பு, அதற்குள் இயங்கும் container-ன் பண்பு அல்ல. உங்கள் சொந்த VPS-ல் உள்ள ஒரு Docker container, host-ன் /proc-ஐப் பகிர்ந்து கொள்கிறது. எனவே, அதற்குள் வாசிக்கப்படும் st மதிப்பு என்பது அந்த VPS-ன் steal ஆகும்; இதுவே நீங்கள் அறிய வேண்டியது. VPS என விற்கப்படும் container-அடிப்படையிலான virtualisation வேறுவிதமாகச் செயல்படுகிறது. lxcfs செயல்பாட்டில் இருக்கும்போது, container-க்குள் இருக்கும் /proc/stat என்பது cgroup கணக்கீட்டிலிருந்து தொகுக்கப்படுகிறது, மேலும் steal என்பது வடிவமைப்பிலேயே பூஜ்ஜியமாக இருக்கும். உள்ளே இருந்து மட்டும் தரவுகளைச் சேகரிக்கும் ஒரு monitoring stack, கீழே உள்ள physical machine தத்தளித்துக் கொண்டிருக்கும்போதும், எந்த மாற்றமும் இன்றி பூஜ்ஜியத்தையே காட்டும்.

ஒரு container-க்குள், அதே பொருளைக் கொண்ட counter என்பது CPU quota throttling ஆகும். cgroup v2-ல்:

cat /sys/fs/cgroup/cpu.stat

nr_throttled என்பது ஒரு group தனது CPU quota-வை எட்டிய அமலாக்க காலங்களைக் கணக்கிடுகிறது, மற்றும் throttled_usec என்பது அது முடக்கப்பட்டிருந்த மொத்த நேரத்தைக் குறிக்கிறது. nr_throttled அதிகரித்துக்கொண்டே இருந்தால், உங்கள் process இயங்கத் தயாராக இருந்தும் இயங்கவில்லை என்று அர்த்தம். இது steal போன்ற அனுபவமே, ஆனால் நீங்கள் அமைத்த வரம்பினால் இது நிகழ்கிறது. host-ஐக் குறை கூறுவதற்கு முன் உங்கள் சொந்த வரம்புகளைச் சரிபார்க்கவும். குறிப்பாக, compose file-ல் CPU வரம்புகளுடன் Docker-ல் உங்கள் சேவைகளை VPS-ல் இயக்கினால் இதை கவனிக்கவும். அடுக்கடுக்கான virtualisation (layered virtualisation) நேரத்தை இழக்க இன்னும் ஒரு இடத்தைச் சேர்க்கிறது, ஏனெனில் உங்கள் VPS-க்குள் இருக்கும் VM, உங்கள் steal மற்றும் அதன் சொந்த scheduling தாமதம் ஆகிய இரண்டையும் எதிர்கொள்கிறது. நீங்கள் VPS-ல் nested virtualisation-ஐ இயக்கினால் இதை நினைவில் கொள்ளுங்கள்.

தொடர்ச்சியான steal-ஐக் கையாளுதல்

Guest-க்குள் எந்த அமைப்பையும் மாற்றுவதன் மூலம் steal-ஐச் சரிசெய்ய முடியாது, ஏனெனில் இந்த முடிவை எடுக்கும் scheduler guest-க்கு வெளியில்தான் இயங்குகிறது. நான்கு நடவடிக்கைகள் மட்டுமே உண்மையான தீர்வைத் தரும்.

முதலில் ஆதாரங்களைச் சேகரிக்கவும். UTC நேரத்தின்படி timestamps-ஐக் குறித்துக்கொள்ளுங்கள். ஒவ்வொரு நிகழ்வின் கால அளவு, அது எவ்வளவு அடிக்கடி நிகழ்கிறது, மற்றும் mpstat-ல் ஒரு vCPU பாதிக்கப்படுகிறதா அல்லது அனைத்தும் பாதிக்கப்படுகின்றனவா என்பதைக் கவனியுங்கள். ஒரு வார கால log தரவுகள், ஒரு screenshot-ஐ விட அதிக மதிப்புடையவை.

அந்தத் தரவுகளுடன் ஒரு ticket-ஐத் திறக்கவும். இரண்டு நேரடியான கேள்விகளைக் கேளுங்கள்: இந்த நேரங்களில் node-ன் திறன் அளவுக்கு அதிகமாகப் பயன்படுத்தப்படுகிறதா (oversubscribed), மற்றும் எனது instance-ஐ வேறு இடத்திற்கு மாற்ற முடியுமா? vmstat-ன் வெளியீட்டையும், துல்லியமான நேரங்களையும் அதில் இணைக்கவும். நிரூபிக்கக்கூடிய தரவுகள் இருந்தால் மட்டுமே சேவை வழங்குநர்கள் நடவடிக்கை எடுப்பார்கள்; "server மெதுவாக உள்ளது" என்று மட்டும் அனுப்பினால், அவர்கள் மீண்டும் ஆதாரங்களைக் கேட்டுத்தான் பதில் அனுப்புவார்கள். இந்த வேலைகளில் எதை உங்களால் ஒப்படைக்க முடியும் என்பதுதான் நிர்வகிக்கப்படும் மற்றும் நிர்வகிக்கப்படாத VPS-க்கு இடையிலான நடைமுறை வேறுபாடுகளில் ஒன்று.

இடமாற்றம் (migration) கோரவும். ஒரு guest-ஐக் குறைந்த சுமை கொண்ட node-க்கு மாற்றுவது சேவை வழங்குநர்களுக்கு வழக்கமான பணியாகும், இதற்குச் சிறிய reboot மட்டுமே தேவைப்படும். இது செலவில்லாத தீர்வாகும், மேலும் ஒரே node-ல் பல அதிக சுமை கொண்ட அண்டை instance-கள் இருக்கும் பொதுவான சிக்கலை இது தீர்க்கிறது.

போட்டியைத் தவிர்க்க பணம் செலுத்துங்கள். ஒரு dedicated vCPU திட்டம் உங்கள் instance-க்காக physical core-களை ஒதுக்குகிறது, எனவே steal counter பூஜ்ஜியத்திலேயே இருக்கும். இதற்கு மாதந்தோறும் கூடுதல் செலவாகும், ஆனால் மாறுபாடுகளைத் தாங்க முடியாத workload-க்கு இதுவே சரியான தீர்வாகும். இதுவும் போதவில்லை என்றால், அல்லது memory bandwidth-ஐயும் முழுமையாக நீங்களே பயன்படுத்த விரும்பினால், அடுத்த கட்டம் VPS-க்கு பதிலாக dedicated server-க்கு மாறுவது ஆகும்.

இவற்றிற்காகக் காத்திருக்கும்போது, steal-ஆல் ஏற்படும் பாதிப்பைக் குறைக்கவும். உங்களிடம் உள்ள vCPU எண்ணிக்கையை விடக் குறைவான worker threads-ஐ இயக்குங்கள், ஏனெனில் core கிடைக்காத threads context switches-ஐ மட்டுமே அதிகரிக்கும். Batch வேலைகளை node-ன் சுமை குறைவாக இருக்கும் நேரத்திற்கு மாற்றுங்கள்; உங்கள் log தரவுகள் அந்த நேரத்தைக் காட்டும். பின்னர் அதே கட்டளையைப் பயன்படுத்தி அதே நேரங்களில் மீண்டும் அளவிடுங்கள்; அப்போதுதான் மாற்றம் பலனளித்ததா என்பதை ஊகிக்காமல் உறுதியாகச் சொல்ல முடியும்.

FAQ

VPS-ல் சாதாரண CPU steal time என்பது எவ்வளவு?

Shared plan-ல், அவ்வப்போது ஏற்படும் சிறிய அதிகரிப்புகளும், 5 சதவீதத்திற்கும் குறைவான நிலையான மதிப்பும் சாதாரணமானவை. ஏனெனில், shared CPU என்பது host தனது physical cores-ஐ பல விருந்தினர்களுக்கு (guests) பகிர்ந்து அளிப்பதைக் குறிக்கிறது. பல மணிநேரங்களாக steal time இரு இலக்க எண்களில் நீடித்தால், அது சாதாரணமானது அல்ல; அது குறித்து support ticket பதிவு செய்ய வேண்டும். Dedicated vCPU plan-ல், எதிர்பார்க்கப்படும் அளவு 0.0 ஆகும். எனவே, அதைத் தாண்டி வேறு எந்த மதிப்பும் இருந்தால், அது புகாரளிக்கப்பட வேண்டிய ஒரு பிழையாகும். உங்கள் பணிச்சுமைக்கு ஏற்ப இந்த எண்ணை மதிப்பிடுங்கள்: ஒரு overnight batch job-ஆல் தாங்கிக்கொள்ளக்கூடிய steal time, latency-sensitive API-ஆல் தாங்கிக்கொள்ள முடியாது.

பெரிய plan-க்கு மாறினால் அதிக steal time குறையுமா?

அதுவாக மட்டும் குறையாது. அதே shared node-ல் அதிக vCPU-களைப் பெறுவது என்பது, ஏற்கனவே நெரிசலில் உள்ள physical cores-க்காக அதிக virtual CPUs போட்டியிடுவதையே குறிக்கும். இதனால் steal time சதவீதம் மாறாமல் அப்படியே இருக்கலாம். Dedicated CPU ஒதுக்கீடு அல்லது குறைந்த சுமை கொண்ட node-க்கு மாறுவது மட்டுமே steal time-ஐ நீக்கும். நெரிசலான இயந்திரத்தில் அதிக பங்கு பெறுவது என்பது, நெரிசலான இயந்திரத்தில் அதிக சுமையைப் பெறுவதே ஆகும்.

எனது VPS மெதுவாக இயங்கினாலும், ஏன் steal time 0 என்று காட்டுகிறது?

இதற்கு இரண்டு பொதுவான காரணங்கள் உள்ளன. Hypervisor இந்த counter-ஐ வெளிப்படுத்தாமல் இருக்கலாம்; இது VMware மற்றும் Hyper-V தளங்களில் வழக்கமானது. எனவே, host என்ன செய்தாலும் இந்த மதிப்பு பூஜ்ஜியத்திலேயே இருக்கும். நீங்கள் எந்தத் தளத்தில் இருக்கிறீர்கள் என்பதை அறிய systemd-detect-virt-ஐ இயக்கவும். மற்றபடி, சிக்கல் வேறு எங்காவது இருக்கலாம்: storage waits-ஐக் கண்டறிய wa-ஐச் சரிபார்க்கவும், உங்கள் சொந்த overload-ஐக் கண்டறிய r மற்றும் nproc-ஐ ஒப்பிடவும், containers-க்குள் quota throttling-ஐக் கண்டறிய /sys/fs/cgroup/cpu.stat-ஐப் படிக்கவும்.

எனது server-க்குள் இருந்தபடியே steal time-ஐக் குறைக்க முடியுமா?

Guest-க்குள் இருந்தபடி host-ன் scheduling-ஐ உங்களால் மாற்ற முடியாது. அதன் பாதிப்பை மட்டுமே உங்களால் குறைக்க முடியும். உங்களிடம் உள்ள vCPU-களை விடக் குறைவான worker threads-ஐ இயக்கவும். இதனால், கிடைக்காத core-க்காக run queue-வில் காத்திருக்கும் வேலை குறையும். Node-ன் சுமை குறைவாக இருக்கும் நேரத்திற்கு batch jobs-ஐ மாற்றவும். முடிவுகளை cache செய்வதன் மூலம், CPU தேவைப்படும் கோரிக்கைகளைக் குறைக்கலாம். Steal time-ஐ முழுமையாக நீக்கும் மாற்றங்களான, மற்றொரு node-க்கு இடம்பெயர்தல் அல்லது dedicated cores-க்கு மாறுதல் போன்றவை provider-ன் கட்டுப்பாட்டில் உள்ளவை.