VPSలో CPU steal time, noisy neighbourను ఎలా గుర్తించాలి

CPU steal time కొలిచేది ఏమిటి

CPU steal time అనేది మీ virtual CPU అమలు కావడానికి సిద్ధంగా ఉండి, వేచి ఉండాల్సిన పని ఏదీ లేకపోయినా, hypervisor physical core ను వేరే guest కు ఇచ్చిన సమయంలోని వాటా. ఆ పని queue లో వేచి ఉంది. ఆ core వేరే చోట ఉపయోగించబడుతోంది. Linux ఈ cycles ను విడిగా లెక్కించి stగా నివేదిస్తుంది. దీనివల్ల “నా server busy గా ఉంది” అనే పరిస్థితిని “నా server తన వంతు కోసం వేచి ఉంది” అనే పరిస్థితి నుంచి వేరు చేయవచ్చు.

ఈ తేడా కోసమే ఈ counter ఉంటుంది. మీ స్వంత processes CPUపై గడిపిన సమయం us (user) లేదా sy (system)గా నివేదించబడుతుంది. ఒక task storage పై blocked గా గడిపిన సమయం wa (I/O wait)గా నివేదించబడుతుంది. అమలు కావడానికి సిద్ధంగా ఉండి, run queueలో ఉండి, I/O pending ఏదీ లేకపోయినా ఇంకా అమలు కాకుండా ఉన్న vCPU (virtual CPU) stగా నివేదించబడుతుంది. మీ server లోని ఏదీ ఈ స్థితిని తొలగించలేరు. ఎందుకంటే scheduling నిర్ణయం మీ స్థాయికి ఒక layer దిగువన, hostపై తీసుకోబడుతుంది.

ఇది అనేక guests మధ్య ఒకే physical machine ను ఒక VPS ఎలా పంచుకుంటుందో నేరుగా అనుసరిస్తుంది. సాధారణ కారణం ఒక neighbour. అదే nodeపై ఉన్న మరో guest అధిక CPU వినియోగంతో నడుస్తుండటంతో, host cores ను మీ మధ్య పంచుతుంది. తరచుగా గుర్తించకుండా పోయే రెండో కారణం కూడా ఉంది. అనేక providers shared vCPU ను physical coreలోని కొంత భాగానికి పరిమితం చేస్తారు. కొన్ని hypervisorsలో అమలు చేసిన ఈ పరిమితి guestలో stealగా లెక్కించబడుతుంది. కాబట్టి అధిక st reading ఆ core మీకు ఇవ్వలేదని చెబుతుంది. కానీ దాన్ని ఎవరు ఉపయోగించుకున్నారో మాత్రం ఎల్లప్పుడూ చెప్పదు.

Steal విలువ ఎక్కడి నుంచి వస్తుంది

మీ kernel స్వయంగా steal ను కొలవలేదు, ఎందుకంటే దానికి host కనిపించదు. ఆ విలువను hypervisor అందిస్తుంది. KVMలో host, guestతో పంచుకున్న ఒక pageలో ప్రతి vCPUకి సంబంధించిన counterను రాస్తుంది. kernelను CONFIG_PARAVIRT_TIME_ACCOUNTING తో build చేసినప్పుడు guest ఆ విలువలను మొత్తం చేస్తుంది. ప్రతి distribution kernelలో ఇది ఉంటుంది. Xen తన runstate area ద్వారా ఇదే సమాచారాన్ని అందిస్తుంది. మొత్తం విలువ userspaceకు కచ్చితంగా ఒకే చోట అందుతుంది:

head -1 /proc/stat

ఆ cpu lineలో boot అయినప్పటి నుంచి USER_HZ ticksలో పది counters ఉంటాయి. వాటి క్రమం: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. label తర్వాత steal ఎనిమిదో విలువ. దిగువన ఉన్న ప్రతి tool, vmstat, top, mpstat మరియు ఏదైనా Prometheus exporter కూడా ఇదే fieldను చదివి, రెండు samples ఆధారంగా శాతాన్ని లెక్కిస్తాయి.

ఇందులో మిగతావాటికన్నా ముఖ్యమైన ఒక పరిణామం ఉంది. hypervisor ఈ counterను ఎప్పుడూ export చేయకపోతే field శాశ్వతంగా zeroగానే ఉంటుంది. అప్పుడు దానిపై ఆధారపడిన ప్రతి tool host అధిక loadలో ఉన్నప్పటికీ ప్రశాంతమైన 0.0 ను చూపిస్తుంది. KVM మరియు Xen ఈ counterను export చేస్తాయి. VMware మరియు Hyper-Vపై నడిచే guests సాధారణంగా మార్పులేని zeroను report చేస్తాయి. zeroను నమ్మే ముందు platformను తనిఖీ చేయండి:

systemd-detect-virt

ఇది platform పేరును print చేస్తుంది. ఉదాహరణకు kvm, xen, vmware లేదా microsoft. Bare metalపై ఇది none ను చూపిస్తుంది. Containerలో ఇది runtimeను చూపిస్తుంది. ఉదాహరణకు lxc, docker లేదా podman. ఇది container గురించి సమాచారం ఇస్తుంది, దాని కింద ఉన్న machine గురించి కాదు. kvmపై zero కనిపిస్తే, host మీకు తగిన వనరులను అందిస్తోందనడానికి అది నిజమైన ఆధారం. Fieldను ఎప్పుడూ నింపని platformపై zeroకు ఎలాంటి ఆధారం ఉండదు. అప్పుడు నిజమైన పనిని కొలిచే timing ఆధారంగా contentionను అంచనా వేయాలి.

VPSలో CPU steal time ను ఎలా తనిఖీ చేయాలి?

vmstat అనేది procps package నుంచి వస్తుంది. ఇది దాదాపు ప్రతి Ubuntu మరియు Debian VPS image లో ఉంటుంది. కొన్ని minimal container image లలో ఇది ఉండకపోవచ్చు. అందువల్ల దానిపై ఆధారపడే ముందు దీన్ని install చేయండి.

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

vmstat --version, vmstat from procps-ng 4.0.4 వంటి ఒక line ను print చేస్తుంది. అది print అయితే tool install అయి ఉందని, మీరు నిజమైన kernel counters చదువుతున్నారని అర్థం. vmstat 1 5 ప్రతి సెకనుకు ఒక sample చొప్పున మొత్తం ఐదు samples తీసుకుంటుంది.

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 block లో st column ను కనుగొనండి. ప్రస్తుత procps-ng builds దాని తర్వాత KVM guest time కోసం gu column ను print చేస్తాయి. అందువల్ల st చివరి column కాకుండా కుడి నుంచి రెండవది అవుతుంది. ఆ column స్థానాన్ని కాకుండా header name ఆధారంగా చదవండి. ఎందుకంటే releases మధ్య ఆ స్థానం మారింది.

చదివిన విలువను సరిగ్గా అర్థం చేసుకోవడానికి రెండు విషయాలు గుర్తుంచుకోండి. మొదటి data line boot అయినప్పటి నుంచి ఉన్న average, కాబట్టి దాన్ని విస్మరించి దాని తర్వాతి lines చదవండి. అలాగే ఒక sample measurement కాదు. Steal time విరామాలుగా వస్తుంది. అందువల్ల vmstat 1 60 ను అమలు చేసి, నిర్ణయం తీసుకునే ముందు పూర్తి ఒక నిమిషం monitor చేయండి.

top తన %Cpu(s) summary line లో అదే సంఖ్యను st గుర్తించిన field లో చూపిస్తుంది:

%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కి ఒక row ను print చేస్తుంది. అందులోని %steal column ప్రతి vCPU ప్రభావితమైందా లేదా ఒక్కదానిపైనే సమస్య ఉందా చూపిస్తుంది. Support ticket కోసం అవసరమైన history కావాలంటే, samples ను screen నుంచి చదవడం బదులు వాటిని save చేయండి:

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

మీరు అనుమానిస్తున్న గంటలలో cron ద్వారా దీన్ని run చేయండి. అప్పుడు ఆ file, provider కు "నిన్న రాత్రి slow గా అనిపించింది" అని చెప్పడం మరియు ఖచ్చితమైన పది నిమిషాల ఆధారాలను చూపించడం మధ్య ఉన్న తేడాగా మారుతుంది.

steal సంఖ్యల అర్థం ఏమిటి?

• స్థిరంగా ఉండే 0.0. ఇది ఆరోగ్యకరమైన పరిస్థితి. లేదా platform steal ను అసలు report చేయకపోవచ్చు. సంతోషించే ముందు systemd-detect-virt తో నిర్ధారించండి.
• కొన్ని seconds పాటు ఉండే కొన్ని శాతం spikes. ఏ shared node లోనైనా ఇది సాధారణమే. పొరుగు tenant యొక్క build ప్రారంభమై ఉండవచ్చు, లేదా host తన backups నడుపుతూ ఉండవచ్చు.
• shared plan లో నిరంతరం 1 నుంచి 5 శాతం. ఇది ఊహించదగినదే. ధరలో shared CPU వినియోగం ప్రతిబింబిస్తుంది.
• నిరంతరం 5 నుంచి 10 శాతం. కొలవగల slowdown ఇది. ఆధారాలను నమోదు చేయడం ప్రారంభించి, అనేక రోజులలో ఒకే సమయాలను పరస్పరం పోల్చండి.
• ఒకసారి గంటలపాటు 10 శాతానికి మించి. మీ workload కు node లోని వనరుల కేటాయింపు అధికంగా ఉంది. Support ticket నమోదు చేయడానికి లేదా మరో node కు మారడానికి ఇది సరైన స్థాయి.

ఈ పరిధులను specification గా కాకుండా, అర్థం చేసుకునే మార్గదర్శకంగా పరిగణించండి. ఎందుకంటే shared plan కోసం ఏ provider కూడా steal కు హామీ ఇవ్వదు. మీరు నడుపుతున్న workload ను బట్టి వీటిని అంచనా వేయండి. ఒక overnight batch job 15 శాతం steal ను తట్టుకోగలదు; ఎవరూ గమనించకపోవచ్చు. latency-sensitive service లో average ఆందోళనకరంగా కనిపించకముందే p99 లో ప్రభావం కనిపిస్తుంది. అందుకే trading bots వంటి latency-sensitive workloads ను dedicated cores పై నడపాలి.

మీకు steal time వల్ల ఎంత ఖర్చు అవుతోంది?

లెక్క చాలా చిన్నది. మీ CPU సమయానికి s భాగం తీసుకోబడితే, స్థిరమైన CPU సమయం అవసరమయ్యే job గడియార సమయంపై 1 / (1 - s) రెట్లు ఎక్కువ సమయం తీసుకుంటుంది. 60 seconds CPU సమయం అవసరమయ్యే job కోసం:

[
  {
    "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"
  }
]

3 percent వద్ద, ఇది సాధారణ shared-plan విలువ. ఆ job 61.9 seconds పడుతుంది; సాధారణంగా అవసరమయ్యే 60.0 seconds కాదు. దీనిపై ఎవరూ ticket తెరవరు. 8 percent వద్ద ఇది 65.2 seconds అవుతుంది. 40 percent వద్ద అదే job కు 100.0 seconds అవసరం అవుతుంది. గతంలో ఖాళీ అయ్యే queue అప్పటి నుంచి పెరగడం ప్రారంభిస్తుంది.

అవి కొలతలు కావు; లెక్కించిన విలువలు. ఈ model ఒక runnable thread మాత్రమే ఉందని, interval అంతటా steal సమానంగా విస్తరించి ఉందని ఊహిస్తుంది. వాస్తవ సేవలు ఈ curve కంటే అధ్వాన్నంగా అనిపించవచ్చు. కారణం, stolen slice ఒక request మధ్యలో పడితే, ఆ request పై వేచి ఉన్న ప్రతి పనికి ఆ ఆలస్యం మళ్లీ వస్తుంది. Formula బదులుగా మీ స్వంత విలువ తెలుసుకోవాలంటే, నిశ్శబ్ద సమయంలో VPS ను benchmark చేయండి మరియు busy సమయంలో మళ్లీ benchmark చేయండి. రెండు windows కోసం st ను నమోదు చేయండి.

ఇది stealనా, లేక మరేదైనా సమస్యనా?

steal ను ఇతర లక్షణాలతో సులభంగా గందరగోళపరచవచ్చు. అదే vmstat line లోని counters ను కలిపి పరిశీలించండి.

• st ఎక్కువగా ఉండి, r మరియు us తక్కువగా ఉంటే: host మీకు CPU core ను కేటాయించడం లేదు. ఇది steal.
• r మీ vCPU count కంటే గణనీయంగా ఎక్కువగా ఉండి, us ఎక్కువగా మరియు st దాదాపు zero గా ఉంటే: మీ స్వంత CPUs నిర్వహించగల సామర్థ్యానికి మించి మీరు పనిని నడుపుతున్నారు. r ను nproc output తో పోల్చండి. ఇది మీ స్వంత oversubscription; పక్క tenant వల్ల కాదు.
• wa ఎక్కువగా ఉండి, st దాదాపు zero గా ఉంటే: tasks storage పై block అయ్యాయి. ఇది వేరే సమస్య, దీనికి వేరే పరిష్కారం అవసరం.
• Load average ఎక్కువగా ఉండి, st మరియు us రెండూ తక్కువగా ఉంటే: load figure uninterruptible tasks ను కూడా లెక్కిస్తుంది. కాబట్టి ఇది సాధారణంగా CPU సమస్యను కాకుండా stuck device లేదా hung network mount ను సూచిస్తుంది.

Burstable plans కు ప్రత్యేకంగా గమనించాల్సిన విషయం ఉంది. మీరు idle గా ఉన్నప్పుడు credit balance పెరుగుతుంది, busy గా ఉన్నప్పుడు తగ్గుతుంది. అది పూర్తిగా ఖర్చయిన తర్వాత provider మిమ్మల్ని baseline rate వద్ద పరిమితం చేస్తుంది. కొన్ని platforms ఈ throttle ను steal గా report చేస్తాయి. మరికొన్నింటిలో ఇది host లోపల నుంచి కనిపించదు; ప్రతి సెకనుకు మీకు తక్కువ CPU cycles మాత్రమే లభిస్తాయి. పక్క tenant కారణమని నిర్ణయించే ముందు plan description చదవండి.

కంటైనర్ steal time లేదని ఎందుకు చూపిస్తుంది

Steal అనేది కంటైనర్‌కు కాదు, దాని లోపల నడుస్తున్న virtual machine కు సంబంధించిన లక్షణం. మీ స్వంత VPS పై నడుస్తున్న Docker container, host యొక్క /proc ను పంచుకుంటుంది. అందువల్ల దాని లోపల చదివిన st విలువ VPS యొక్క steal time అవుతుంది. మీకు అవసరమైన విలువ ఇదే. VPSగా అందించే container-based virtualisation భిన్నంగా పనిచేస్తుంది. lxcfs అమల్లో ఉన్నప్పుడు, కంటైనర్‌లోని /proc/stat cgroup accounting ఆధారంగా రూపొందించబడుతుంది. అందువల్ల steal విలువ నిర్మాణాత్మకంగానే zero అవుతుంది. లోపలి స్థాయి నుంచే metrics సేకరించే monitoring stack, కింద ఉన్న physical machine వనరుల కొరతతో ఇబ్బంది పడుతున్నప్పటికీ, మార్పులేని zero విలువను ప్రశాంత స్థితిగా చూపవచ్చు.

కంటైనర్‌లో ఇదే అర్థాన్ని కలిగిన counter CPU quota throttling ను సూచిస్తుంది. cgroup v2 లో:

cat /sys/fs/cgroup/cpu.stat

nr_throttled అనేది group తన CPU quota ను చేరుకున్న enforcement periods సంఖ్యను లెక్కిస్తుంది. throttled_usec quota కారణంగా group నిలిపివేయబడి ఉన్న మొత్తం సమయాన్ని లెక్కిస్తుంది. nr_throttled పెరుగుతుంటే, మీ process runnable స్థితిలో ఉండి కూడా అమలు కాలేదని అర్థం. ఇది steal time లాగే అనిపిస్తుంది. అయితే దీనికి కారణం మీరు స్వయంగా అమలు చేసిన limit. host ను నిందించే ముందు మీ స్వంత limits ను పరిశీలించండి. ముఖ్యంగా compose file లో CPU limits తో మీరు VPS పై Docker లో మీ సేవలను నడుపుతున్నప్పుడు ఇది అవసరం. Layered virtualisation లో సమయం అదృశ్యమయ్యే మరో స్థాయి ఏర్పడుతుంది. మీ VPS లోని VM, మీ steal time తో పాటు తన స్వంత scheduling delay ను కూడా భరిస్తుంది. మీరు VPS పై nested virtualisation నడుపుతున్నప్పుడు ఈ విషయాన్ని గుర్తుంచుకోండి.

steal నిరంతరంగా ఉండితే ఏమి చేయాలి

guest లోని ఏ setting కూడా steal సమస్యను పరిష్కరించదు, ఎందుకంటే ఆ నిర్ణయం తీసుకునే scheduler guest వెలుపల నడుస్తుంది. నాలుగు చర్యలు ఉపయోగకరంగా ఉంటాయి.

ముందుగా ఆధారాలను సేకరించండి. timestamps ను UTCలో నమోదు చేయండి. ప్రతి episode ఎంతసేపు కొనసాగిందో, అది ఎంత తరచుగా పునరావృతమవుతుందో, అలాగే mpstat ఒక vCPUపై ప్రభావం చూపుతోందా లేదా అన్నింటిపైనా చూపుతోందా నమోదు చేయండి. ఒక వారం పాటు log చేసిన samples, screenshot కంటే ఎక్కువ ఉపయోగకరం.

ఆ డేటాతో ticket తెరవండి. రెండు నేరుగా అడగాల్సిన ప్రశ్నలు ఇవి: ఈ సమయాల్లో ఈ node oversubscribed అవుతోందా, మరియు నా instance ను వేరే node కు తరలించగలరా? vmstat output మరియు ఖచ్చితమైన సమయాలను జతచేయండి. Providerలు పునరుత్పత్తి చేయగల సమయ పరిధిపై చర్య తీసుకుంటారు. Server slowగా ఉందని మాత్రమే చెప్పే ticketకు, సాధారణంగా ఆ సమయ పరిధిని అడిగే ప్రత్యుత్తరం వస్తుంది. ఈ పనిలో ఎంత భాగాన్ని providerకు అప్పగించగలరన్నది managed మరియు unmanaged VPS మధ్య ఉండే ఆచరణాత్మక తేడాలలో ఒకటి.

Migration కోరండి. guest ను తక్కువ load ఉన్న nodeకు తరలించడం providerకు సాధారణ పని. సాధారణంగా దీనికి చిన్న reboot మాత్రమే అవసరం. దీనికి అదనపు ఖర్చు ఉండదు. ఒకే nodeపై ఒకేసారి అనేక heavy neighbours ఉండే సాధారణ పరిస్థితిని ఇది పరిష్కరిస్తుంది.

Contention తగ్గించేందుకు మరింత చెల్లించండి. dedicated vCPU plan మీ instance కోసం physical cores ను reserve చేస్తుంది. అందువల్ల counter zero వద్ద ఉంటుంది. దీని నెలవారీ ఖర్చు ఎక్కువ. Variance ను తట్టుకోలేని workloadకు ఇది సరైన పరిష్కారం. ఇది కూడా సరిపోకపోతే, memory bandwidthను కూడా మీ instanceకే కేటాయించాలనుకుంటే, తదుపరి దశ VPSకు బదులుగా dedicated server.

పై చర్యలలో ఏదైనా అమలయ్యే వరకు steal ప్రభావాన్ని తగ్గించండి. మీ వద్ద ఉన్న vCPUs కంటే తక్కువ worker threads నడపండి. Core పొందలేని threads context switches ను మాత్రమే పెంచుతాయి. Node తక్కువ busyగా ఉండే సమయాలకు batch workను మార్చండి. ఇప్పుడు మీ స్వంత log ఆ సమయాలను చూపిస్తుంది. తరువాత అదే గంటల్లో అదే commandతో మళ్లీ measure చేయండి. అప్పుడు మార్పు పనిచేసిందో లేదో ఊహించకుండా స్పష్టంగా చెప్పగలరు.

FAQ

VPSలో సాధారణ CPU steal time ఎంత?

Shared planలో కొద్దిసేపు కనిపించే spikes మరియు సుమారు 5 percent కంటే తక్కువగా నిరంతరం ఉండే విలువలు సాధారణమే. దీనికి కారణం shared CPUలో host భౌతిక coresను guests మధ్య విభజించడం. గంటలపాటు నిరంతరం double digitsగా ఉండటం సాధారణం కాదు; దీనిపై ticket నమోదు చేయడం సముచితం. Dedicated vCPU planలో అంచనా reading 0.0. కాబట్టి అక్కడ దీనికి భిన్నమైన ఏ విలువైనా report చేయాల్సిన లోపం. ఈ సంఖ్యను మీ స్వంత workloadతో పోల్చి అంచనా వేయండి: latency-sensitive API భరించలేని stealను overnight batch job భరించగలదు.

ఎక్కువ steal timeను పెద్ద plan పరిష్కరిస్తుందా?

అదొక్కటే సరిపోదు. అదే shared nodeలో ఎక్కువ vCPUs తీసుకున్నా, అదే పరిమితిలో ఉన్న భౌతిక cores కోసం పోటీ పడే virtual CPUs సంఖ్య పెరుగుతుంది. అందువల్ల percentage మారకపోవచ్చు. Dedicated CPU allocation లేదా తక్కువ load ఉన్న nodeకు migration మాత్రమే stealను తొలగిస్తుంది. Busy machineలో పెద్ద share తీసుకున్నా, అది busy machineలోని shareగానే ఉంటుంది.

VPS స్పష్టంగా slowగా ఉన్నప్పటికీ 0 steal time ఎందుకు చూపిస్తుంది?

దీనికి రెండు సాధారణ కారణాలు ఉన్నాయి. Hypervisor ఈ counterను అసలు export చేయకపోవచ్చు. VMware మరియు Hyper-V platformsలో ఇది సాధారణం. అందువల్ల hostలో ఏమి జరిగినా field zeroగానే ఉంటుంది. మీరు ఏ platformలో ఉన్నారో చూడటానికి systemd-detect-virt అమలు చేయండి. లేకపోతే bottleneck మరెక్కడో ఉంటుంది: storage waits కోసం waను పరిశీలించండి, మీ స్వంత overload కోసం rను nprocతో పోల్చండి, quota throttling కోసం containersలో /sys/fs/cgroup/cpu.statను చూడండి.

నా serverలో నుంచే steal timeను తగ్గించగలనా?

Guestలో నుంచే host schedulingను మార్చలేరు. అది కలిగించే ప్రభావాన్ని మాత్రమే తగ్గించగలరు. మీ వద్ద ఉన్న vCPUs కంటే తక్కువ worker threadsను అమలు చేయండి. అప్పుడు core కోసం వేచి run queueలో నిలిచే పని తగ్గుతుంది. Node తక్కువగా busyగా ఉండే సమయాలకు batch jobsను మార్చండి. మరిన్ని requestsకు CPU అవసరం లేకుండా resultsను cache చేయండి. Stealను నిజంగా తొలగించే మార్పులు, అంటే మరో nodeకు migration లేదా dedicated cores, provider పరిధిలో ఉంటాయి.