VPS లో CPU steal time అంటే ఏమిటి? ఎలా గుర్తించాలి?

CPU steal time వాస్తవానికి దేనిని కొలుస్తుంది

CPU steal time అనేది మీ వర్చువల్ CPU రన్ అవ్వడానికి సిద్ధంగా ఉండి, వేచి ఉండాల్సిన పని ఏమీ లేనప్పుడు, హైపర్‌వైజర్ ఆ ఫిజికల్ కోర్‌ను మరొక గెస్ట్‌కు కేటాయించిన సమయం. ఆ పని క్యూలో ఉండిపోయింది. ఆ కోర్ వేరే చోట బిజీగా ఉంది. Linux ఆ సైకిళ్లను విడిగా లెక్కించి st గా చూపిస్తుంది. దీని ద్వారానే "నా సర్వర్ బిజీగా ఉంది" అని మరియు "నా సర్వర్ తన వంతు కోసం వేచి ఉంది" అని మీరు గుర్తించగలరు.

ఈ వ్యత్యాసాన్ని గుర్తించడమే ఈ కౌంటర్ ఉనికికి ప్రధాన కారణం. మీ సొంత ప్రాసెస్‌లు CPUపై గడిపే సమయాన్ని us (user) లేదా sy (system) గా రిపోర్ట్ చేస్తారు. ఒక టాస్క్ స్టోరేజ్ కోసం వేచి ఉంటూ బ్లాక్ అయిన సమయాన్ని wa (I/O wait) గా చూపిస్తారు. ఒక vCPU (virtual CPU) రన్ అవ్వడానికి సిద్ధంగా ఉండి, రన్ క్యూలో కూర్చుని, ఎటువంటి I/O పెండింగ్‌లో లేకపోయినా, ఇంకా ఎగ్జిక్యూట్ అవ్వకపోతే, దానిని st గా రిపోర్ట్ చేస్తారు. మీ సర్వర్ లోపల ఏదీ ఈ స్థితిని మార్చలేదు, ఎందుకంటే షెడ్యూలింగ్ నిర్ణయం మీ కంటే ఒక పొర కింద, హోస్ట్ స్థాయిలో జరుగుతుంది.

ఇది ఒక VPS ఒక ఫిజికల్ మెషీన్‌ను అనేక గెస్ట్‌ల మధ్య ఎలా పంచుకుంటుంది అనే అంశం నుండి నేరుగా వస్తుంది. దీనికి సాధారణ కారణం పొరుగున ఉన్న మరొక గెస్ట్: అదే నోడ్‌లో ఉన్న మరొక గెస్ట్ అధిక లోడ్‌తో నడుస్తుంటే, హోస్ట్ కోర్లను మీ మధ్య పంచుతుంది. దీనికి మరొక కారణం కూడా ఉంది, అది తరచుగా గమనించబడదు. చాలా మంది ప్రొవైడర్లు షేర్డ్ vCPUని ఫిజికల్ కోర్‌లో కొంత భాగానికి పరిమితం చేస్తారు (cap). అనేక హైపర్‌వైజర్లలో, ఆ విధంగా విధించిన పరిమితిని గెస్ట్ లోపల steal గా పరిగణిస్తారు. కాబట్టి, అధిక st రీడింగ్ కనిపిస్తే, ఆ కోర్ మీకు కేటాయించబడలేదని అర్థం. కానీ అది ఎవరి వల్ల జరిగిందో అది ఎల్లప్పుడూ చెప్పదు.

steal సంఖ్య ఎక్కడి నుండి వస్తుంది

మీ kernel స్వయంగా steal ను కొలవలేదు, ఎందుకంటే అది host ను చూడలేదు. hypervisor దీనిని తెలియజేస్తుంది. KVM లో, host ప్రతి vCPU కౌంటర్‌ను guest తో పంచుకున్న ఒక పేజీలో రాస్తుంది. kernel ను CONFIG_PARAVIRT_TIME_ACCOUNTING తో నిర్మించినప్పుడు guest దీనిని లెక్కిస్తుంది; ప్రతి distribution kernel ఇలాగే ఉంటుంది. Xen కూడా తన runstate ప్రాంతం ద్వారా ఇదే విషయాన్ని తెలియజేస్తుంది. ఈ మొత్తం విలువ userspace కు ఒకే ఒక చోట చేరుతుంది:

head -1 /proc/stat

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

దీని వల్ల ఒక ముఖ్యమైన పరిణామం ఉంది. hypervisor ఎప్పుడూ కౌంటర్‌ను ఎగుమతి చేయకపోతే, ఆ ఫీల్డ్ ఎప్పటికీ సున్నాగానే ఉంటుంది. host ఓవర్‌లోడ్ అయినప్పటికీ, దానిపై ఆధారపడిన ప్రతి సాధనం ప్రశాంతమైన 0.0 అని చూపిస్తుంది. KVM మరియు Xen దీనిని ఎగుమతి చేస్తాయి. VMware మరియు Hyper-V లోని guests సాధారణంగా సున్నానే చూపిస్తాయి. సున్నాను నమ్మే ముందు ప్లాట్‌ఫారమ్‌ను తనిఖీ చేయండి:

systemd-detect-virt

ఇది ప్లాట్‌ఫారమ్ పేరును ముద్రిస్తుంది, ఉదాహరణకు kvm, xen, vmware లేదా microsoft, మరియు bare metal పై అయితే none అని చూపిస్తుంది. container లోపల ఇది runtime ను చూపిస్తుంది, ఉదాహరణకు lxc, docker లేదా podman. ఇది మీకు container గురించి చెబుతుంది కానీ దాని కింద ఉన్న యంత్రం గురించి కాదు. kvm పై సున్నా ఉంటే, host మిమ్మల్ని బాగా చూసుకుంటుందని అర్థం. ఈ ఫీల్డ్‌ను ఎప్పుడూ నింపని ప్లాట్‌ఫారమ్‌పై, సున్నా అనేది ఎటువంటి ఆధారం కాదు. అటువంటి సందర్భాల్లో, అసలైన పని పూర్తి కావడానికి పట్టే సమయాన్ని బట్టి ఒత్తిడిని అంచనా వేయాలి.

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

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

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

vmstat --version కమాండ్ vmstat from procps-ng 4.0.4 వంటి ఒక లైన్‌ను ప్రింట్ చేస్తుంది. అది ప్రింట్ అయితే, టూల్ ఇన్‌స్టాల్ చేయబడిందని మరియు మీరు నిజమైన కెర్నల్ కౌంటర్లను చూస్తున్నారని అర్థం. 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 కాలమ్‌ను వెతకండి. ప్రస్తుత procps-ng బిల్డ్‌లు KVM గెస్ట్ టైమ్ కోసం దాని తర్వాత gu కాలమ్‌ను ప్రింట్ చేస్తాయి, కాబట్టి st అనేది చివరిది కాకుండా కుడి నుండి రెండవదిగా ఉంటుంది. కాలమ్ స్థానం వెర్షన్ల మధ్య మారుతూ ఉంటుంది కాబట్టి, దాని హెడర్ పేరును బట్టి గుర్తించండి.

ఖచ్చితమైన రీడింగ్ కోసం రెండు అలవాట్లు పాటించాలి. మొదటి డేటా లైన్ బూట్ అయినప్పటి నుండి సగటును సూచిస్తుంది, కాబట్టి దాన్ని విస్మరించి తర్వాతి లైన్లను చూడండి. అలాగే, ఒకే శాంపిల్ కొలత కాదు, ఎందుకంటే 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

ప్రతి కోర్ (per-core) వివరాల కోసం, sysstatని జోడించండి:

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

mpstat కమాండ్ ప్రతి CPUకి ఒక వరుసను ప్రింట్ చేస్తుంది, ఇందులో %steal కాలమ్ ఉంటుంది. ఇది ప్రతి vCPU ప్రభావితమైందో లేదో లేదా ఒకటి మాత్రమే ప్రభావితమైందో చూపిస్తుంది. సపోర్ట్ టికెట్ కోసం అవసరమైన హిస్టరీని పొందడానికి, స్క్రీన్ మీద చూసి వదిలేయకుండా శాంపిల్స్‌ను సేవ్ చేయండి:

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

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

Steal సంఖ్యలు దేనిని సూచిస్తాయి?

• స్థిరమైన 0.0. సర్వర్ ఆరోగ్యంగా ఉంది, లేదా ప్లాట్‌ఫారమ్ steal ను అసలు రిపోర్ట్ చేయడం లేదు. మీరు సంతోషించే ముందు systemd-detect-virt తో నిర్ధారించుకోండి.
• కొన్ని సెకన్ల పాటు ఉండే స్వల్ప స్పైక్స్ (Spikes). ఏదైనా shared node లో ఇది సాధారణం. పొరుగున ఉన్న సర్వర్‌లో ఏదైనా build ప్రారంభమైనా, లేదా హోస్ట్ బ్యాకప్‌లు రన్ చేస్తున్నా ఇలా జరుగుతుంది.
• Shared ప్లాన్‌పై 1 నుంచి 5 శాతం వరకు స్థిరంగా ఉండటం. ఇది ఆశించదగినదే. మీరు చెల్లించే ధర Shared CPU కే కాబట్టి ఇది సహజం.
• 5 నుంచి 10 శాతం వరకు స్థిరంగా ఉండటం. మీరు గమనించదగ్గ వేగ మందగమనం (slowdown). ఆధారాలను రికార్డ్ చేయడం ప్రారంభించండి మరియు కొన్ని రోజుల పాటు ఒకే సమయాల్లో వచ్చే గణాంకాలను పోల్చి చూడండి.
• గంటల తరబడి 10 శాతం కంటే ఎక్కువగా ఉండటం. మీ వర్క్‌లోడ్‌కు ఈ నోడ్ సరిపోవడం లేదు (oversubscribed). ఈ స్థాయిలో ఉన్నప్పుడు మీరు support ticket రైజ్ చేయడం లేదా సర్వర్‌ను మార్చడం సమంజసం.

ఈ శ్రేణులను ఒక మార్గదర్శిగా మాత్రమే చూడండి, ఇవి ఖచ్చితమైన నిబంధనలు కావు. ఎందుకంటే ఏ ప్రొవైడర్ కూడా shared ప్లాన్‌పై 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 సమయం అంతటా సమానంగా పంపిణీ చేయబడిందని భావిస్తుంది. వాస్తవ సేవలు ఈ వక్రరేఖ (curve) కంటే అధ్వాన్నంగా అనిపిస్తాయి, ఎందుకంటే ఒక stolen slice అభ్యర్థన మధ్యలో వస్తుంది, తద్వారా ఆ అభ్యర్థన కోసం వేచి ఉన్న ప్రతిదీ మళ్ళీ జాప్యాన్ని భరించాల్సి వస్తుంది. ఫార్ములాపై ఆధారపడకుండా మీ స్వంత గణాంకాలను పొందడానికి, తక్కువ రద్దీ ఉన్న సమయంలో మరియు ఎక్కువ రద్దీ ఉన్న సమయంలో benchmark the VPS చేయండి, ఆ రెండు సమయాల్లోనూ st ను రికార్డ్ చేయండి.

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

Steal ను ఇతర లక్షణాలతో పొరబడటం సులభం. కౌంటర్లను ఒకే vmstat లైనులో కలిపి చదవండి.

• st ఎక్కువగా ఉండి, r మరియు us తక్కువగా ఉంటే: హోస్ట్ మీకు కోర్ (core) కేటాయించడం లేదు. అదే steal.
• r మీ vCPU సంఖ్య కంటే చాలా ఎక్కువగా ఉండి, us ఎక్కువగా మరియు st సున్నాకి దగ్గరగా ఉంటే: మీ CPUs సామర్థ్యం కంటే ఎక్కువ పనిని మీరు చేస్తున్నారు. r ను nproc అవుట్‌పుట్‌తో పోల్చి చూడండి. ఇది మీ సొంత oversubscription, పక్కన ఉన్నవారు (neighbour) కాదు.
• wa ఎక్కువగా ఉండి st సున్నాకి దగ్గరగా ఉంటే: పనులు స్టోరేజ్ వద్ద నిలిచిపోయాయి (blocked), ఇది వేరే సమస్య మరియు దీనికి పరిష్కారం కూడా వేరుగా ఉంటుంది.
• Load average ఎక్కువగా ఉండి st మరియు us రెండూ తక్కువగా ఉంటే: లోడ్ గణాంకాలు uninterruptible పనులను కూడా లెక్కిస్తాయి, కాబట్టి ఇది సాధారణంగా CPU సమస్య కాకుండా, నిలిచిపోయిన పరికరం (stuck device) లేదా నెట్‌వర్క్ మౌంట్ సమస్యను సూచిస్తుంది.

Burstable ప్లాన్‌ల గురించి ప్రత్యేకంగా చెప్పుకోవాలి. ఇవి మీకు క్రెడిట్ బ్యాలెన్స్‌ను ఇస్తాయి; మీరు ఖాళీగా ఉన్నప్పుడు ఇది పెరుగుతుంది, బిజీగా ఉన్నప్పుడు తగ్గుతుంది. అది అయిపోయినప్పుడు, ప్రొవైడర్ మిమ్మల్ని బేస్‌లైన్ రేటు వద్ద ఉంచుతారు. కొన్ని ప్లాట్‌ఫారమ్‌లలో ఆ throttling ను steal గా చూపిస్తాయి. మరికొన్నింటిలో ఇది లోపలి నుండి కనిపించదు, మీకు సెకనుకు తక్కువ సైకిల్స్ మాత్రమే అందుతాయి. పక్కన ఉన్నవారే కారణమని నిర్ణయించుకునే ముందు ప్లాన్ వివరణను చదవండి.

కంటైనర్ ఎందుకు steal time ను చూపదు

Steal అనేది వర్చువల్ మెషీన్ యొక్క లక్షణం, దాని లోపల నడుస్తున్న కంటైనర్ ది కాదు. మీ VPS లో నడుస్తున్న Docker కంటైనర్ హోస్ట్ యొక్క /proc ను పంచుకుంటుంది, కాబట్టి దాని లోపల కనిపించే st విలువ ఆ VPS యొక్క steal సమయమే, ఇది మీరు తెలుసుకోవలసినది. VPS గా విక్రయించబడే కంటైనర్-ఆధారిత వర్చువలైజేషన్ భిన్నంగా పనిచేస్తుంది. lxcfs అమల్లో ఉన్నప్పుడు, కంటైనర్ లోపల ఉండే /proc/stat అనేది cgroup అకౌంటింగ్ నుండి సేకరించబడుతుంది, మరియు డిజైన్ ప్రకారం steal విలువ సున్నాగా ఉంటుంది. కేవలం కంటైనర్ లోపలి నుంచే డేటాను సేకరించే మానిటరింగ్ స్టాక్, కింద ఉన్న ఫిజికల్ మెషీన్ వనరుల కొరతతో ఇబ్బంది పడుతున్నా, సున్నా అనే స్థిరమైన విలువను మాత్రమే చూపుతుంది.

కంటైనర్ లోపల, అదే అర్థాన్ని ఇచ్చే కౌంటర్ CPU quota throttling. cgroup v2 పై:

cat /sys/fs/cgroup/cpu.stat

nr_throttled అనేది గ్రూప్ తన CPU కోటాను దాటిన ఎన్‌ఫోర్స్‌మెంట్ పీరియడ్‌లను లెక్కిస్తుంది, మరియు throttled_usec అనేది అది నిలిపివేయబడిన (frozen) మొత్తం సమయాన్ని సూచిస్తుంది. nr_throttled పెరుగుతుందంటే మీ ప్రాసెస్ రన్ అవ్వడానికి సిద్ధంగా ఉన్నా రన్ అవ్వడం లేదని అర్థం; ఇది steal వంటి అనుభవమే, కానీ మీరు స్వయంగా విధించిన పరిమితి వల్ల ఇది జరుగుతుంది. హోస్ట్‌ను నిందించే ముందు మీ పరిమితులను తనిఖీ చేయండి, ముఖ్యంగా మీరు Docker compose ఫైల్‌లో CPU పరిమితులతో VPS పై సేవలను నడుపుతున్నప్పుడు ఇది ముఖ్యం. లేయర్డ్ వర్చువలైజేషన్ సమయం వృథా అవ్వడానికి మరొక కారణాన్ని జోడిస్తుంది, ఎందుకంటే మీ VPS లోపల ఉన్న VM మీ VPS యొక్క steal తో పాటు దాని స్వంత షెడ్యూలింగ్ జాప్యాన్ని కూడా భరిస్తుంది. మీరు VPS పై నెస్టెడ్ వర్చువలైజేషన్ నడుపుతున్నప్పుడు ఈ విషయాన్ని గుర్తుంచుకోండి.

నిరంతర steal సమయాల్లో ఏమి చేయాలి

Guest లోపల ఏ సెట్టింగ్ కూడా steal ను సరిచేయలేదు, ఎందుకంటే ఈ నిర్ణయం తీసుకునే scheduler guest వెలుపల నడుస్తుంది. Kernel ను upgrade చేయడం కూడా దీనిని మార్చదు: Linux kernel 7.2 లో చేర్చిన cache aware scheduling మీకు కేటాయించిన cores లోపల పనులను సర్దుబాటు చేస్తుంది, కానీ పక్కన ఉన్న ఇతర వినియోగదారులు తీసుకున్న cycles ను తిరిగి పొందలేదు. నాలుగు మార్గాలు వాస్తవమైనవి.

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

ఆ సమాచారంతో ఒక ticket తెరవండి. రెండు సూటి ప్రశ్నలు అడగండి: ఈ సమయాల్లో ఈ node oversubscribe చేయబడిందా, మరియు నా instance ను వేరే చోటికి మార్చగలరా? vmstat output ను మరియు ఖచ్చితమైన సమయాలను అందులో చేర్చండి. ప్రొవైడర్లు ఒక నిరూపించదగిన సమయ పరిధిని బట్టి స్పందిస్తారు; సర్వర్ నెమ్మదిగా ఉందని మాత్రమే చెబితే, వారు తిరిగి అదే అడుగుతారు. మీరు ఎంత పనిని వారిపై వదిలేయగలరు అనేది managed మరియు unmanaged VPS మధ్య ఉన్న ఆచరణాత్మక వ్యత్యాసాలలో ఒకటి.

migration కోసం అడగండి. Guest ను తక్కువ లోడ్ ఉన్న node కు మార్చడం ప్రొవైడర్లకు సాధారణ పని, మరియు దీనికి సాధారణంగా చిన్న reboot సరిపోతుంది. దీనికి ఎటువంటి ఖర్చు ఉండదు, మరియు ఒకే node లో అనేక భారీ పనులు ఒకేసారి జరుగుతున్నప్పుడు వచ్చే సాధారణ సమస్యను ఇది పరిష్కరిస్తుంది.

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

వీటిలో దేనికోసం వేచి చూస్తున్నా, steal వల్ల కలిగే నష్టాన్ని తగ్గించుకోండి. మీ వద్ద ఉన్న vCPUs కంటే తక్కువ worker threads ను నడపండి, ఎందుకంటే core దొరకని threads కేవలం context switches ను మాత్రమే పెంచుతాయి. Batch పనులను node ప్రశాంతంగా ఉన్న సమయాలకు మార్చండి, ఇది మీ logs ద్వారా మీకు తెలుస్తుంది. ఆ తర్వాత అదే సమయాల్లో అదే command తో మళ్ళీ కొలవండి, అప్పుడు మీరు ఊహించడం కాకుండా, మార్పు పనిచేసిందో లేదో ఖచ్చితంగా చెప్పగలరు.

FAQ

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

Shared ప్లాన్‌లో, స్వల్పకాలిక స్పైక్స్ మరియు 5 శాతం లోపు స్థిరమైన విలువ సాధారణమే, ఎందుకంటే shared CPU అంటే హోస్ట్ తన physical cores ను అతిథి (guest) సర్వర్ల మధ్య పంచుతుంది. గంటల తరబడి రెండంకెల విలువలు ఉండటం సాధారణం కాదు, దీనిపై మీరు support ticket రైజ్ చేయాలి. Dedicated vCPU ప్లాన్‌లో ఆశించే విలువ 0.0, కాబట్టి అక్కడ ఏ ఇతర విలువ కనిపించినా అది లోపంగా పరిగణించి రిపోర్ట్ చేయాలి. మీ workload ను బట్టి ఈ సంఖ్యను అంచనా వేయండి: రాత్రిపూట జరిగే batch job భరించే steal, latency-sensitive API భరించలేదు.

పెద్ద ప్లాన్‌కు మారితే high steal time సమస్య తీరుతుందా?

కేవలం ప్లాన్ మార్చడం వల్ల ఇది తగ్గదు. అదే shared node పై ఎక్కువ vCPUs ఉండటం అంటే, అవే physical cores కోసం మరిన్ని virtual CPUs పోటీ పడటం, కాబట్టి ఆ శాతం అలాగే ఉండవచ్చు. Steal ను తగ్గించేది dedicated CPU allocation మాత్రమే, లేదా తక్కువ లోడ్ ఉన్న node కు మారడం. బిజీగా ఉన్న మెషీన్‌లో ఎక్కువ వాటా పొందడం అంటే, ఇప్పటికీ బిజీగా ఉన్న మెషీన్‌లోనే వాటా కలిగి ఉండటమే.

నా VPS నెమ్మదిగా ఉన్నా, steal time ఎందుకు 0 అని చూపిస్తోంది?

దీనికి రెండు సాధారణ కారణాలు ఉన్నాయి. Hypervisor ఈ counter ను అసలు ఎగుమతి (export) చేయకపోవచ్చు, ఇది VMware మరియు Hyper-V ప్లాట్‌ఫారమ్‌లలో సాధారణం, కాబట్టి హోస్ట్ ఏమి చేసినా ఈ ఫీల్డ్ సున్నాగానే ఉంటుంది. మీరు ఏ ప్లాట్‌ఫారమ్‌లో ఉన్నారో తెలుసుకోవడానికి systemd-detect-virt రన్ చేయండి. ఒకవేళ అది కాకపోతే, bottleneck వేరే చోట ఉండవచ్చు: storage waits కోసం wa చెక్ చేయండి, మీ స్వంత overload కోసం r మరియు nproc లను పోల్చి చూడండి, మరియు quota throttling కోసం container లోపల /sys/fs/cgroup/cpu.stat ను చదవండి.

నా సర్వర్ లోపల నుండి steal time ను తగ్గించవచ్చా?

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