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-களில், அந்த enforced cap-ஆனது guest-க்குள் steal ஆகக் கணக்கிடப்படுகிறது. எனவே, அதிகப்படியான st வாசிப்பு, core உங்களுக்கு வழங்கப்படவில்லை என்பதை மட்டுமே உணர்த்துகிறது. அது யார் அந்த core-ஐ எடுத்துக்கொண்டார்கள் என்பதை எப்போதும் சொல்வதில்லை.

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

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

head -1 /proc/stat

அந்த cpu வரியானது, boot ஆனதிலிருந்து USER_HZ ticks-ல் பத்து counter-களைக் கொண்டுள்ளது. அவை: 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-க்குள் இது lxc, docker அல்லது podman போன்ற runtime தகவலைக் காட்டும்; இது உங்களுக்குக் கீழே உள்ள machine-ஐப் பற்றி அல்லாமல், container-ஐப் பற்றிய தகவலை மட்டுமே தரும். kvm-ல் பூஜ்ஜியம் என்பது host உங்களைச் சரியாக நடத்துகிறது என்பதற்கான உண்மையான சான்று. இந்த field-ஐ நிரப்பாத platform-களில், பூஜ்ஜியம் என்பது எந்தச் சான்றும் அல்ல; அங்கு உண்மையான பணிகளைச் செய்து முடிக்கும் நேரத்தை (timing) வைத்தே நெரிசலை (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 கட்டளை ஒரு வினாடிக்கு ஒரு மாதிரி வீதம், ஐந்து முறை தரவுகளைச் சேகரிக்கும்.

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 time-க்காக 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 அதன் backups-ஐ இயக்கலாம்.
• பகிரப்பட்ட திட்டத்தில் 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 சதவீதத்தில், அந்தப் பணி 61.9 வினாடிகள் எடுக்கும், இது 60.0 வினாடிகளுக்குப் பதிலாக நடப்பது. இதற்காக யாரும் ticket திறப்பதில்லை. 8 சதவீதத்தில் இது 65.2 வினாடிகளாகிறது. 40 சதவீதத்தில் அதே பணிக்கு 100.0 வினாடிகள் தேவைப்படுகிறது, மேலும் வழக்கமாக காலியாகும் வரிசை (queue) வளரத் தொடங்குகிறது.

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

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

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

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

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

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

Steal என்பது virtual machine-ன் ஒரு பண்பு, அதற்குள் இயங்கும் container-ன் பண்பு அல்ல. உங்கள் VPS-ல் இயங்கும் ஒரு Docker container, அந்த host-ன் /proc-ஐப் பகிர்ந்து கொள்கிறது. எனவே, அதற்குள் வாசிக்கப்படும் ஒரு st மதிப்பு என்பது அந்த VPS-ன் steal ஆகும்; இதுவே நீங்கள் அறிய வேண்டியது. VPS என விற்கப்படும் container-அடிப்படையிலான virtualization வேறுவிதமாகச் செயல்படுகிறது. 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-ஐக் குறை கூறுவதற்கு முன் உங்கள் சொந்த வரம்புகளைச் சரிபார்க்கவும், குறிப்பாக நீங்கள் உங்கள் சேவைகளை Docker-ல் ஒரு VPS-ல் CPU வரம்புகளுடன் compose file-ல் இயக்கும்போது இதை கவனிக்கவும். Layered virtualization நேரத்தை இழக்க மற்றொரு இடத்தைச் சேர்க்கிறது, ஏனெனில் உங்கள் VPS-க்குள் இருக்கும் ஒரு VM, உங்கள் steal மற்றும் அதன் சொந்த scheduling தாமதம் ஆகிய இரண்டையும் எதிர்கொள்கிறது. நீங்கள் ஒரு VPS-ல் nested virtualization-ஐ இயக்கும்போது இதை நினைவில் கொள்ளுங்கள்.

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

Guest-க்குள் எந்த அமைப்பையும் மாற்றினாலும் steal-ஐச் சரிசெய்ய முடியாது, ஏனெனில் இந்த முடிவை எடுக்கும் scheduler, guest-க்கு வெளியே இயங்குகிறது. Kernel-ஐ upgrade செய்வதாலும் இது மாறாது: Linux kernel 7.2-ல் சேர்க்கப்பட்ட cache aware scheduling, உங்களுக்கு வழங்கப்பட்ட cores-க்குள் பணிகளை மறுசீரமைக்குமே தவிர, அண்டை virtual machine எடுத்துக்கொண்ட cycles-ஐ மீட்டெடுக்க முடியாது. நான்கு நடவடிக்கைகள் மட்டுமே நடைமுறைக்குச் சாத்தியமானவை.

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

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

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

Contention-ஐத் தவிர்க்க பணம் செலுத்துங்கள். Dedicated vCPU திட்டம் உங்கள் instance-க்காக physical cores-ஐ ஒதுக்குகிறது, எனவே 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-ஐ பல guest-களுக்குப் பிரித்து வழங்குகிறது. பல மணிநேரங்களாக steal time இரண்டு இலக்கங்களில் நீடித்தால், அது சாதாரணமானது அல்ல; அது குறித்து support ticket பதிவு செய்ய வேண்டும். Dedicated vCPU plan-ல், எதிர்பார்க்கப்படும் அளவு 0.0 ஆகும்; எனவே, அதைத் தாண்டி வேறு எந்த மதிப்பும் இருந்தால் அது ஒரு பிழையாகக் கருதப்பட்டு தெரிவிக்கப்பட வேண்டும். உங்கள் workload-க்கு ஏற்ப இந்த மதிப்பை மதிப்பிடுங்கள்: ஒரு overnight batch job-ஆல் தாங்கிக்கொள்ளக்கூடிய steal time, latency-sensitive API-க்கு பாதிப்பை ஏற்படுத்தும்.

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

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

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

இதற்கு இரண்டு பொதுவான காரணங்கள் உள்ளன. Hypervisor இந்த counter-ஐ வெளிப்படுத்தாமல் இருக்கலாம்; இது VMware மற்றும் Hyper-V தளங்களில் வழக்கமானது, எனவே host என்ன செய்தாலும் இந்த மதிப்பு பூஜ்ஜியமாகவே இருக்கும். நீங்கள் எந்தத் தளத்தில் இருக்கிறீர்கள் என்பதை அறிய systemd-detect-virt கட்டளையை இயக்கவும். மற்றபடி, bottleneck வேறு எங்காவது இருக்கலாம்: 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-ன் கட்டுப்பாட்டில் உள்ளவை.