Kamusta! Gusto kong sabihin sa iyo sa mga simpleng termino ang tungkol sa mga mekanika ng pagnanakaw sa loob ng mga virtual machine at tungkol sa ilang hindi halatang artifact na nagawa naming malaman sa panahon ng pagsasaliksik nito, na kailangan kong sumisid bilang isang teknikal na direktor ng isang cloud platform . Ang platform ay tumatakbo sa KVM.
Ang oras ng pagnanakaw ng CPU ay ang oras kung kailan hindi tumatanggap ang virtual machine ng mga mapagkukunan ng processor para sa pagpapatupad nito. Ang oras na ito ay binibilang lamang sa mga operating system ng bisita sa mga virtualization environment. Ang mga dahilan kung saan napupunta ang pinaka-inilalaang mapagkukunang ito, tulad ng sa buhay, ay napakalabo. Ngunit nagpasya kaming malaman ito, at kahit na nagsagawa ng ilang mga eksperimento. Hindi sa alam na namin ngayon ang lahat tungkol sa pagnanakaw, ngunit sasabihin namin sa iyo ang isang bagay na kawili-wili ngayon.
1. Ano ang magnakaw
Kaya, ang magnakaw ay isang sukatan na nagpapahiwatig ng kakulangan ng oras ng processor para sa mga proseso sa loob ng isang virtual machine. Gaya ng inilarawan Ang stealth ay ang oras kung saan ang hypervisor ay nagsasagawa ng iba pang mga proseso sa host OS kahit na ito ay nakapila sa proseso ng virtual machine para sa pagpapatupad. Ibig sabihin, ang pagnanakaw ay kinakalkula bilang pagkakaiba sa pagitan ng oras kung kailan ang proseso ay handa nang isakatuparan at ang oras kung kailan ang proseso ay inilalaan ng oras ng processor.
Natatanggap ng virtual machine kernel ang steal metric mula sa hypervisor. Kasabay nito, hindi eksaktong tinukoy ng hypervisor kung ano ang iba pang mga proseso na pinapatakbo nito, sinasabi lang nito na "habang abala ako, hindi kita mabibigyan ng oras." Sa KVM, idinagdag ang suporta para sa pagkalkula ng pagnanakaw . Mayroong dalawang pangunahing punto dito:
- Natututo ang virtual machine tungkol sa pagnanakaw mula sa hypervisor. Iyon ay, mula sa punto ng view ng mga pagkalugi, para sa mga proseso sa virtual machine mismo ito ay isang hindi direktang pagsukat na maaaring sumailalim sa iba't ibang mga pagbaluktot.
- Ang hypervisor ay hindi nagbabahagi ng impormasyon sa virtual machine tungkol sa kung ano pa ang ginagawa nito - ang pangunahing bagay ay hindi ito naglalaan ng oras dito. Dahil dito, ang virtual machine mismo ay hindi makaka-detect ng mga distortion sa steal indicator, na maaaring masuri sa pamamagitan ng likas na katangian ng mga prosesong nakikipagkumpitensya.
2. Ano ang nakakaapekto sa pagnanakaw
2.1. Magnakaw ng pagkalkula
Sa esensya, ang pagnanakaw ay kinakalkula nang humigit-kumulang kapareho ng normal na oras ng paggamit ng CPU. Walang gaanong impormasyon tungkol sa kung paano isinasaalang-alang ang pag-recycle. Marahil dahil itinuturing ng karamihan sa mga tao na malinaw ang tanong na ito. Ngunit mayroon ding mga pitfalls dito. Upang maging pamilyar sa prosesong ito, maaari mong basahin : matututunan mo ang tungkol sa maraming mga nuances kapag kinakalkula ang paggamit at tungkol sa mga sitwasyon kung saan ang pagkalkula na ito ay magiging mali para sa mga sumusunod na dahilan:
- Nag-overheat ang processor, na nagiging sanhi ng paglaktaw ng mga cycle.
- I-enable/i-disable ang turbo boost, na nagbabago sa bilis ng orasan ng processor.
- Isang pagbabago sa haba ng time slice na nangyayari kapag gumagamit ng processor power-saving na mga teknolohiya gaya ng SpeedStep.
- Ang problema sa pagkalkula ng average: ang pagtatantya ng isang minutong paggamit sa 80% ay maaaring magtago ng panandaliang pagsabog ng 100%.
- Ang isang spin lock ay nagiging sanhi ng pag-reclaim ng processor, ngunit ang proseso ng user ay hindi nakakakita ng anumang pag-unlad sa pagpapatupad nito. Bilang resulta, ang kinakalkula na paggamit ng processor sa pamamagitan ng proseso ay magiging isang daang porsyento, kahit na ang proseso ay hindi pisikal na ubusin ang oras ng processor.
Wala akong nakitang artikulo na naglalarawan ng katulad na kalkulasyon para sa pagnanakaw (kung alam mo, ibahagi ito sa mga komento). Ngunit, sa paghusga sa source code, ang mekanismo ng pagkalkula ay kapareho ng para sa pag-recycle. Sa simple, isa pang counter ang idinagdag sa kernel, direkta para sa proseso ng KVM (proseso ng virtual machine), na binibilang ang tagal ng proseso ng KVM na naghihintay para sa oras ng CPU. Kinukuha ng counter ang impormasyon tungkol sa processor mula sa detalye nito at sinusuri kung ang lahat ng mga tik nito ay ginagamit ng proseso ng virtual machine. Kung iyon lang, ipinapalagay namin na ang processor ay abala lamang sa proseso ng virtual machine. Kung hindi, ipinapaalam namin na ang processor ay gumagawa ng iba, lumitaw ang pagnanakaw.
Ang proseso ng pagbibilang ng pagnanakaw ay napapailalim sa parehong mga problema gaya ng regular na pagbibilang ng pag-recycle. Hindi para sabihing madalas lumilitaw ang mga ganitong problema, ngunit mukhang nakapanghihina ng loob.
2.2. Mga uri ng virtualization sa KVM
Sa pangkalahatan, mayroong tatlong uri ng virtualization, na lahat ay sinusuportahan ng KVM. Ang mekanismo ng paglitaw ng pagnanakaw ay maaaring depende sa uri ng virtualization.
Broadcast. Sa kasong ito, ang pagpapatakbo ng virtual machine operating system na may mga pisikal na hypervisor device ay nangyayari tulad nito:
- Ang guest operating system ay nagpapadala ng command sa guest device nito.
- Ang driver ng guest device ay tumatanggap ng command, bumubuo ng isang kahilingan para sa BIOS ng device at ipinapadala ito sa hypervisor.
- Ang proseso ng hypervisor ay nagsasalin ng command sa command para sa pisikal na device, na ginagawa itong, bukod sa iba pang mga bagay, ay mas secure.
- Tinatanggap ng driver ng pisikal na device ang binagong utos at ipinapadala ito sa mismong pisikal na device.
- Ang mga resulta ng pagpapatupad ng mga utos ay bumalik sa parehong landas.
Ang bentahe ng pagsasalin ay pinapayagan ka nitong tularan ang anumang aparato at hindi nangangailangan ng espesyal na paghahanda ng kernel ng operating system. Ngunit kailangan mong magbayad para dito, una sa lahat, sa bilis.
Virtualization ng hardware. Sa kasong ito, naiintindihan ng device sa antas ng hardware ang mga utos mula sa operating system. Ito ang pinakamabilis at pinakamahusay na paraan. Ngunit, sa kasamaang-palad, hindi ito sinusuportahan ng lahat ng pisikal na device, hypervisors at guest operating system. Sa kasalukuyan, ang mga pangunahing device na sumusuporta sa virtualization ng hardware ay mga processor.
Paravirtualization. Ang pinakakaraniwang opsyon para sa virtualization ng device sa KVM at sa pangkalahatan ang pinakakaraniwang virtualization mode para sa mga operating system ng bisita. Ang kakaiba nito ay ang pagtatrabaho sa ilang hypervisor subsystem (halimbawa, sa network o disk stack) o ang paglalaan ng mga memory page ay nangyayari gamit ang hypervisor API, nang hindi nagsasalin ng mga low-level na command. Ang disbentaha ng paraan ng virtualization na ito ay ang kernel ng operating system ng bisita ay dapat mabago upang maaari itong makipag-ugnayan sa hypervisor gamit ang API na ito. Ngunit ito ay karaniwang nalutas sa pamamagitan ng pag-install ng mga espesyal na driver sa guest operating system. Sa KVM ang API na ito ay tinatawag .
Sa paravirtualization, kumpara sa pagsasahimpapawid, ang landas patungo sa pisikal na aparato ay makabuluhang nababawasan sa pamamagitan ng direktang pagpapadala ng mga command mula sa virtual machine patungo sa proseso ng hypervisor sa host. Binibigyang-daan ka nitong pabilisin ang pagpapatupad ng lahat ng mga tagubilin sa loob ng virtual machine. Sa KVM, ginagawa ito ng virtio API, na gumagana lang para sa ilang partikular na device, gaya ng network o disk adapter. Ito ang dahilan kung bakit naka-install ang mga virtio driver sa loob ng mga virtual machine.
Ang downside ng acceleration na ito ay hindi lahat ng proseso na tumatakbo sa loob ng virtual machine ay nananatili sa loob nito. Lumilikha ito ng ilang mga espesyal na epekto na maaaring magresulta sa pangingitlog sa pagnanakaw. Inirerekomenda kong simulan ang isang detalyadong pag-aaral ng isyung ito sa .
2.3. "Patas" na pag-iiskedyul
Ang isang virtual machine sa isang hypervisor ay, sa katunayan, isang ordinaryong proseso na sumusunod sa mga batas ng pag-iskedyul (pamamahagi ng mapagkukunan sa pagitan ng mga proseso) sa Linux kernel, kaya tingnan natin ito nang mas malapitan.
Ginagamit ng Linux ang tinatawag na CFS, Completely Fair Scheduler, na naging default na scheduler mula noong kernel 2.6.23. Upang maunawaan ang algorithm na ito, maaari mong basahin ang Linux Kernel Architecture o ang source code. Ang kakanyahan ng CFS ay upang ipamahagi ang oras ng processor sa pagitan ng mga proseso depende sa tagal ng kanilang pagpapatupad. Ang mas maraming oras ng CPU na kailangan ng isang proseso, mas kaunting oras ng CPU ang natatanggap nito. Tinitiyak nito na ang lahat ng mga proseso ay naisakatuparan ng "patas" - upang ang isang proseso ay hindi patuloy na sumasakop sa lahat ng mga processor, at ang iba pang mga proseso ay maaari ding isagawa.
Minsan ang paradigm na ito ay humahantong sa mga kagiliw-giliw na artifact. Malamang na naaalala ng mga matagal nang gumagamit ng Linux ang pagyeyelo ng isang regular na editor ng teksto sa isang desktop habang nagpapatakbo ng mga application na masinsinang mapagkukunan tulad ng isang compiler. Nangyari ito dahil ang mga gawaing hindi masinsinang mapagkukunan sa mga desktop application ay nakikipagkumpitensya sa mga gawaing masinsinang mapagkukunan, gaya ng compiler. Iniisip ng CFS na ito ay hindi patas, kaya pana-panahon nitong itinitigil ang text editor at hinahayaan ang processor na pangasiwaan ang mga gawain ng compiler. Ito ay naitama gamit ang isang mekanismo , ngunit maraming iba pang mga tampok ng pamamahagi ng oras ng processor sa pagitan ng mga gawain ay nanatili. Sa totoo lang, hindi ito isang kuwento tungkol sa kung gaano masama ang lahat ng bagay sa CFS, ngunit isang pagtatangka upang maakit ang pansin sa katotohanan na ang "patas" na pamamahagi ng oras ng processor ay hindi ang pinaka walang kuwentang gawain.
Ang isa pang mahalagang punto sa scheduler ay ang preemption. Ito ay kinakailangan upang maalis ang proseso ng pagngisi mula sa processor at hayaan ang iba na gumana. Ang proseso ng ejection ay tinatawag na context switching. Sa kasong ito, ang buong konteksto ng gawain ay napanatili: ang estado ng stack, mga rehistro, atbp., Pagkatapos kung saan ang proseso ay ipinadala upang maghintay, at isa pa ang pumalit sa lugar nito. Ito ay isang mamahaling operasyon para sa OS at bihirang ginagamit, ngunit walang likas na mali dito. Ang madalas na paglipat ng konteksto ay maaaring magpahiwatig ng isang problema sa OS, ngunit kadalasan ito ay tuluy-tuloy at hindi nagpapahiwatig ng anumang partikular na bagay.
Ang ganoong mahabang kuwento ay kinakailangan upang ipaliwanag ang isang katotohanan: mas maraming mapagkukunan ng processor ang sinusubukang kumonsumo ng isang proseso sa isang matapat na scheduler ng Linux, mas mabilis itong ititigil upang ang ibang mga proseso ay gumana din. Kung ito ay tama o hindi ay isang kumplikadong tanong na maaaring malutas sa ibang paraan sa ilalim ng iba't ibang mga pagkarga. Sa Windows, hanggang kamakailan, ang scheduler ay nakatuon sa priyoridad na pagproseso ng mga desktop application, na maaaring magdulot ng pag-freeze ng mga proseso sa background. Ang Sun Solaris ay mayroong limang magkakaibang klase ng mga scheduler. Noong naglunsad kami ng virtualization, nagdagdag kami ng pang-anim, , dahil ang nakaraang limang ay hindi gumana nang sapat sa virtualization ng Solaris Zones. Inirerekomenda kong simulan ang isang detalyadong pag-aaral ng isyung ito sa mga aklat na tulad ng o .
2.4. Paano masubaybayan ang pagnanakaw?
Ang pagsubaybay sa pagnanakaw sa loob ng isang virtual machine, tulad ng anumang iba pang sukatan ng processor, ay simple: maaari mong gamitin ang anumang tool sa sukatan ng processor. Ang pangunahing bagay ay ang virtual machine ay nasa Linux. Para sa ilang kadahilanan, hindi ibinibigay ng Windows ang impormasyong ito sa mga gumagamit nito. π
Output ng nangungunang command: mga detalye ng pag-load ng processor, sa pinakakanang column - magnakaw
Ang kahirapan ay lumitaw kapag sinusubukang makuha ang impormasyong ito mula sa hypervisor. Maaari mong subukang hulaan ang pagnanakaw sa host machine, halimbawa, gamit ang Load Average (LA) na parameter - ang average na halaga ng bilang ng mga prosesong naghihintay sa execution queue. Ang pamamaraan para sa pagkalkula ng parameter na ito ay hindi simple, ngunit sa pangkalahatan, kung ang LA ay na-normalize ng bilang ng mga thread ng processor ay higit sa 1, ito ay nagpapahiwatig na ang Linux server ay na-overload ng isang bagay.
Ano pa ang hinihintay ng lahat ng mga prosesong ito? Ang malinaw na sagot ay ang processor. Ngunit ang sagot ay hindi ganap na tama, dahil kung minsan ang processor ay libre, ngunit ang LA ay lumalabas sa sukat. Tandaan . Ang parehong ay maaaring mangyari sa isang disk at iba pang mga input/output device. Ngunit sa katunayan, ang mga proseso ay maaaring maghintay para sa pagtatapos ng anumang lock, alinman sa pisikal, na nauugnay sa isang I/O device, o lohikal, tulad ng isang mutex. Kasama rin dito ang pag-lock sa antas ng hardware (kaparehong tugon mula sa disk), o lohika (ang tinatawag na locking primitives, na kinabibilangan ng grupo ng mga entity, mutex adaptive at spin, semaphores, condition variables, rw lock, ipc lock ...).
Ang isa pang tampok ng LA ay na ito ay itinuturing bilang isang average ng operating system. Halimbawa, 100 proseso ang nakikipagkumpitensya para sa isang file, at pagkatapos ay LA=50. Ang ganitong malaking halaga ay tila nagpapahiwatig na ang operating system ay masama. Ngunit para sa iba pang baluktot na nakasulat na code, ito ay maaaring isang normal na estado, sa kabila ng katotohanan na ito lamang ang masama, at ang iba pang mga proseso sa operating system ay hindi nagdurusa.
Dahil sa pag-average na ito (at hindi bababa sa isang minuto), ang pagtukoy ng anuman sa pamamagitan ng tagapagpahiwatig ng LA ay hindi ang pinakakapaki-pakinabang na gawain, na may napakawalang katiyakan na mga resulta sa mga partikular na kaso. Kung susubukan mong malaman ito, makikita mo na ang mga artikulo sa Wikipedia at iba pang magagamit na mapagkukunan ay naglalarawan lamang ng mga pinakasimpleng kaso, nang walang malalim na paliwanag sa proseso. Ipinapadala ko muli ang lahat na interesado, - sundan ang mga link sa ibaba. Sino ang tamad magsalita ng Ingles - .
3. Mga espesyal na epekto
Ngayon tingnan natin ang mga pangunahing kaso ng pagnanakaw na nakatagpo natin. Sasabihin ko sa iyo kung paano sila sumusunod mula sa lahat ng nasa itaas at kung paano nauugnay ang mga ito sa mga indicator sa hypervisor.
Nire-recycle. Ang pinakasimple at pinakakaraniwan: ang hypervisor ay muling ginamit. Sa katunayan, maraming nagpapatakbo ng mga virtual machine, mataas na pagkonsumo ng processor sa loob ng mga ito, maraming kumpetisyon, ang paggamit ng LA ay higit sa 1 (na-normalize ng mga thread ng processor). Bumabagal ang lahat sa loob ng lahat ng virtual machine. Ang pagnanakaw na ipinadala mula sa hypervisor ay lumalaki din, kinakailangan na muling ipamahagi ang pagkarga o patayin ang isang tao. Sa pangkalahatan, ang lahat ay lohikal at naiintindihan.
Paravirtualization vs. Single Instance. Mayroon lamang isang virtual machine sa hypervisor; kumokonsumo ito ng maliit na bahagi nito, ngunit gumagawa ng malaking I/O load, halimbawa sa disk. At mula sa isang lugar ay lumilitaw dito ang isang maliit na pagnanakaw, hanggang sa 10% (tulad ng ipinapakita ng ilang mga eksperimento).
Ang kaso ay kawili-wili. Ang Steal ay lilitaw dito dahil mismo sa pagharang sa antas ng mga paravirtualized na driver. Ang isang interrupt ay nilikha sa loob ng virtual machine, na pinoproseso ng driver at ipinadala sa hypervisor. Dahil sa interrupt na paghawak sa hypervisor, para sa virtual machine ito ay mukhang isang ipinadalang kahilingan, ito ay handa na para sa pagpapatupad at naghihintay para sa processor, ngunit hindi ito binibigyan ng oras ng processor. Iniisip ng virtual na batang babae na ang oras na ito ay ninakaw.
Nangyayari ito sa sandaling ipinadala ang buffer, napupunta ito sa espasyo ng kernel ng hypervisor, at nagsisimula kaming maghintay para dito. Bagaman, mula sa punto ng view ng virtual machine, dapat siyang bumalik kaagad. Samakatuwid, ayon sa algorithm ng pagkalkula ng pagnanakaw, ang oras na ito ay itinuturing na ninakaw. Malamang, sa sitwasyong ito ay maaaring mayroong iba pang mga mekanismo (halimbawa, pagproseso ng ilang iba pang mga tawag sa sys), ngunit hindi sila dapat magkaiba.
Scheduler kumpara sa mataas na load na virtual machine. Kapag ang isang virtual machine ay naghihirap mula sa pagnanakaw ng higit sa iba, ito ay dahil sa scheduler. Kung mas maraming proseso ang naglo-load sa processor, mas maaga itong sipain ng scheduler para gumana rin ang iba. Kung ang virtual machine ay kumonsumo ng kaunti, halos hindi ito makakita ng magnakaw: ang proseso nito ay tapat na nakaupo at naghintay, kailangan nating bigyan ito ng mas maraming oras. Kung ang isang virtual machine ay gumagawa ng pinakamataas na load sa lahat ng mga core nito, ito ay madalas na kick out sa processor at sinusubukan nilang huwag bigyan ito ng maraming oras.
Mas malala pa kapag ang mga proseso sa loob ng virtual machine ay sumusubok na makakuha ng mas maraming processor dahil hindi nila makayanan ang pagproseso ng data. Pagkatapos ang operating system sa hypervisor, dahil sa matapat na pag-optimize, ay magbibigay ng mas kaunting oras ng processor. Ang prosesong ito ay nangyayari tulad ng isang avalanche, at nagnakaw ng mga pagtalon sa kalangitan, kahit na ang ibang mga virtual machine ay maaaring halos hindi ito mapansin. At mas maraming core, mas malala ang apektadong makina. Sa madaling salita, ang mga virtual machine na may mataas na load na maraming core ang pinakamahirap.
Low LA, pero may steal. Kung ang LA ay humigit-kumulang 0,7 (iyon ay, ang hypervisor ay tila kulang sa karga), ngunit ang pagnanakaw ay sinusunod sa loob ng mga indibidwal na virtual machine:
- Ang opsyon na may paravirtualization na inilarawan na sa itaas. Ang virtual machine ay maaaring makatanggap ng mga sukatan na nagpapahiwatig ng pagnanakaw, bagaman ang hypervisor ay maayos. Ayon sa mga resulta ng aming mga eksperimento, ang opsyong ito sa pagnanakaw ay hindi lalampas sa 10% at hindi dapat magkaroon ng malaking epekto sa pagganap ng mga application sa loob ng virtual machine.
- Ang parameter ng LA ay hindi nakalkula nang tama. Mas tiyak, sa bawat tiyak na sandali ito ay kinakalkula nang tama, ngunit kapag na-average sa loob ng isang minuto ito ay lumalabas na minamaliit. Halimbawa, kung ang isang virtual machine sa bawat ikatlong bahagi ng hypervisor ay kumonsumo ng lahat ng mga processor nito nang eksaktong kalahating minuto, ang LA bawat minuto sa hypervisor ay magiging 0,15; apat na tulad ng mga virtual machine na gumagana nang sabay-sabay ay magbibigay ng 0,6. At ang katotohanan na sa loob ng kalahating minuto sa bawat isa sa kanila ay mayroong isang ligaw na pagnanakaw sa 25% ayon sa tagapagpahiwatig ng LA ay hindi na maaaring makuha.
- Muli, dahil sa scheduler na nagpasya na ang isang tao ay kumakain ng labis at hayaan na may maghintay. Pansamantala, lilipat ako ng konteksto, hahawakan ang mga interrupt at aasikasuhin ang iba pang mahahalagang bagay sa system. Bilang resulta, ang ilang mga virtual machine ay hindi nakakakita ng anumang mga problema, habang ang iba ay nakakaranas ng malubhang pagkasira ng pagganap.
4. Iba pang mga pagbaluktot
Mayroong isang milyong higit pang mga dahilan para sa pagbaluktot sa patas na pagbabalik ng oras ng processor sa isang virtual machine. Halimbawa, ang hyperthreading at NUMA ay nagpapakilala ng mga kahirapan sa mga kalkulasyon. Ganap nilang nalilito ang pagpili ng kernel para sa pagpapatupad ng proseso, dahil ang scheduler ay gumagamit ng mga coefficients - mga timbang, na ginagawang mas mahirap ang pagkalkula kapag inililipat ang konteksto.
May mga pagbaluktot dahil sa mga teknolohiya tulad ng turbo boost o, sa kabaligtaran, mode ng pag-save ng enerhiya, na, kapag kinakalkula ang paggamit, ay maaaring artipisyal na pataasin o bawasan ang dalas o kahit na ang time slice sa server. Ang pagpapagana ng turbo boost ay nakakabawas sa performance ng isang processor thread dahil sa pagtaas ng performance ng isa pa. Sa sandaling ito, ang impormasyon tungkol sa kasalukuyang dalas ng processor ay hindi ipinadala sa virtual machine, at naniniwala ito na may nagnanakaw ng oras nito (halimbawa, humiling ito ng 2 GHz, ngunit natanggap ang kalahati nito).
Sa pangkalahatan, maaaring maraming dahilan para sa pagbaluktot. Maaari kang makakita ng ibang bagay sa isang partikular na sistema. Mas mainam na magsimula sa mga aklat na binigyan ko ng mga link sa itaas, at pagkuha ng mga istatistika mula sa hypervisor gamit ang mga utility tulad ng perf, sysdig, systemtap, kung saan .
5. Konklusyon
- Ang ilang halaga ng pagnanakaw ay maaaring mangyari dahil sa paravirtualization, at maaari itong ituring na normal. Sumulat sila sa Internet na ang halagang ito ay maaaring 5-10%. Depende sa mga application sa loob ng virtual machine at sa load na inilalagay nito sa mga pisikal na device nito. Dito mahalagang bigyang-pansin kung ano ang pakiramdam ng mga application sa loob ng mga virtual machine.
- Ang ratio ng load sa hypervisor at steal sa loob ng virtual machine ay hindi palaging malinaw na magkakaugnay; ang parehong pagtatantya ng steal ay maaaring mali sa mga partikular na sitwasyon sa ilalim ng iba't ibang load.
- Ang scheduler ay may masamang ugali sa mga prosesong nagtatanong ng marami. Sinisikap niyang magbigay ng mas kaunti sa mga humihingi ng higit pa. Ang malalaking virtual machine ay masama.
- Ang isang maliit na pagnanakaw ay maaaring maging pamantayan kahit na walang paravirtualization (isinasaalang-alang ang pag-load sa loob ng virtual machine, ang mga katangian ng pag-load ng mga kapitbahay, pamamahagi ng pag-load sa mga thread at iba pang mga kadahilanan).
- Kung gusto mong malaman ang pagnanakaw sa isang partikular na sistema, kailangan mong galugarin ang iba't ibang mga opsyon, mangolekta ng mga sukatan, maingat na pag-aralan ang mga ito at isipin kung paano pantay na ipamahagi ang load. Ang mga paglihis mula sa anumang mga kaso ay posible, na dapat kumpirmahin sa eksperimento o tingnan sa kernel debugger.
Pinagmulan: www.habr.com