cim vic jader CPU, tim pomalejsi

[David Pasek]

Ahoj.

Tak jedeme dal, mozna se v nekterych vecech budu opakovat, ale jelikoz
v dalsim mailu vidim, ze sis udelal pekne domaci cviceni, takze uz mas
i praktickou zkusenost a pekne pozorovani chovani systemu s
VIRTUALIZACNIM PARADOXem, tak ti to zacne davat smysl. A treba se i ja
dozvim neco noveho a nebo mi vysvetlite, ze neco chapu spatne ja,
protoze i ja jsem v tomto oboru vlastne samouk, jen jsem na tom
ztravil dost let pokusu a badani ;-)

Navic se do budoucna (nevim kdy) chystam otestovat BHYVE, ve kterem
bude uplne stejna problematika ... viz
http://freebsd.1045724.x6.nabble.com/Overcommitting-CPUs-with-BHyve-td6270889.html
... takze proc to tema tady nezacit rozpytvavat uz ted ;-)

On Thu, Apr 1, 2021 at 5:07 PM Miroslav Lachman <000.fbsd at quip.cz> wrote:
>
> Ten virtualizacni paradox bych porad chapal, kdybych od toho VM
> pozadoval s pridavanim vCPU i vetsi vykon, ale to se nedeje, jenom tim,
> ze nastavim vic vCPU a zatez vseho okolo je porad stejna, spadne vykon
> toho VM o desitky procent dolu.

No to je prave ten VIRTUALIZACNI PARADOX. Mene vCPU ti da paradoxne vetsi vykon.
Zasadni otazkou je, co to vlastne je ten vykon, ktery ladis?
Je to co chces opravdu hruby vypocetni CPU vykon mereny v Hz?
Nebude do toho potreba zapocitat i context switching overhead?

K tomu aby si dostal vyuziti veskere taktovaci frekvence ze vsech CPU
coru bez overheadu (ztratoveho vykonu diky cekani v ramci context
switchingu), tak by bylo idealni mit single-user/single-app operacni
system jakym byl MS-DOS, ale musel by umoznovat SMP a musel bys mit
jednu jedinou aplikaci, ktera dokaze spustit tolik threadu, kolik mas
pCPU nebo jeste lepe CPU threadu a nebude moc cekat na I/O operace.
Asi uznas, ze to je celkem synteticky workload neodpovidajici realnym
workloadum a tve opravdove potrebe :-)

Nicmene tim se zase dostavame k CPU Schedulingu.
Ja bohuzel nevim jak funguje scheduling ve VirtualBoxu a vychazim z
toho co znam z jineho virtualizacniho scheduleru.

Jestli te zajima tato problematika a chces to pochopit, tak doporucuju
si precist a pochopit
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmw_vsphere41_cpu_schedule_esx-white-paper.pdf
a
https://kloudkonnect.wordpress.com/2019/08/23/understanding-esxi-cpu-scheduling/

vCPU : pCPU pomer je jen o schedulovani jednotlivych vCPU (procesu
resp. threadu) do scheduleru a je jasne, ze to nejde do nekonecna.
VIRTUALIZACNI PARADOX neni primarne o pomeru vCPU a pCPU, ale o
implementaci virtual SMP (vSMP), to znamena o tom, jak se scheduluji
do scheduleru skupiny vCPU, ktere patri k jednomu virtualnimu pocitaci
(VM). Rika se tomu CO-SCHEDULING. V tom technical paperu na vyse
uvedenem odkazu je porovnani dvou scheduler algoritmu
1/ strict co-scheduling algorithm
2/ relaxed co-scheduling algorithm

Snazil jsem se vygooglit jaky algoritmus pouziva VirtualBox, ale nic
jsem nenasel.
Stejna nezodpovezena otazka je tady
https://superuser.com/questions/712339/how-do-different-virtual-machines-handle-cpu-scheduling

Co ja vim, tak VMware ESXi pouzival strict co-scheduling nekdy pred
rokem 2006 ve verzi pred ESX 3. Od ESX 3 se pouziva algoritmus relaxed
co-scheduling a budes se divit, ale porad se to ladi a optimalizuje,
protoze i CPU hardware vendori (Intel, AMD, ARM) uz dneska vedi, ze to
je o serverove virtualizaci, takze se spolecne vymysli co a jak
vylepsit.

Treba tady
https://www.researchgate.net/publication/221351667_Is_co-scheduling_too_expensive_for_SMP_VMs
je reseach paper z roku 2011, ktery se problematikou zabyva a pisou
<snip>
Our experiments show that both of the widely used open source
hypervisors, Xen and KVM, with the default schedulers are susceptible
to the synchronization latency problem. To remediate this problem,
previous works propose a co-scheduling solution where virtual CPUs
(vCPUs) of a SMP VM are scheduled simultaneously.
</snip>

Jak to funguje ve VirtualBoxu by nam mozna mohl prozradit Honza
Pechanec, ktery myslim ze neco do VirtualBoxu programoval.

> Dale jsi v tom textu psal o "ve fronte 0.125% casu", to bych taky
> chapal, ze se budou ztracet treba i jednotky procent, coz ale neodpovida
> tomu, co ja na tom pozoruju.

Daval jsem to jen jako priklad frontovani vCPU. Ve VMware ESXi se
metrika, ktera to meri jmenuje CPURDY. Meri to cas v ms, jak dlouhou
vCPU ceka ve fronte, nez se dostane k pCPU. Nevim jak to monitorovat
na VirtualBoxu, takze ta uvedena cisla jsou z hypervisoru VMware ESXi,
ktery samozrejme pouziva jiny scheduler nez VirtualBox.
Nicmene uz pri  25 vCPU na 24 pCPU jsem videl v monitoringu cca 0.125%
frontovani per vCPU.

Vyznamnejsi metrika pro troubleshooting VIRTUALIZATION PARADOXu (aka
co-schedulingu) je metrika CO-STOP. Ta u kazdeho vCPU rika, jak dlouho
musel byt vCPU pozastaven v jine fronte, aby pockal na svoje kamarady,
ostatni vCPU ve stejnem virtualnim pocitaci.

> Ja zvednu pocet vCPU z 6 na 8 a boot
> (nacteni pravidel PF) se prodlouzi treba 20x oproti stavu pred navysenim
> poctu vCPU. Pritom ta fyzicka jadra jsou na hypervizoru porad k
> dispozici, nevytezujou je ty ostatni VM.

Vyuziti, ktere zminujes je vypocetni vykon v Hz?
Avsak vyznamne nakladnejsi CPU operace je context switch, coz je to co
se deje pri schedulingu vCPU na pCPU a vytvari ztratovou zatez CPU,
kterou nevidis v Hz (load), ale ma zasadni vliv na vykon uvnitr VM.

>
>
> Mozna ten tvuj predchozi text spatne chapu, tak se teda zeptam
> polopaticky: Je normalni, ze na nevytizenem stroji zvednutim poctu vCPU
> z 6 na 8 klesne vykon o desitky procent? Tedy ze uloha, ktera pred tim
> trvala do 10 sekund ted trva v radech minut?

Nic konketniho k VirtualBoxu ze me nedostanes.
Moje obecna zkusenost nejen se serverovou virtualizaci je takova, ze
vsechny pretizene systemy se chovaji velmi nepredikovatelne.
Otazkou je, kdy dochazi k pretizeni konkretniho hypervizoru.
Uz jsem ti psal, ze u VirtualBoxu se podle dokumentace nedoporucuje
overbookovat vCPU/pCPU, coz Ty delas.
U VMware hypervizoru (ESXi) se bezne overbookuje vCPU/pCPU 3:1. Stejne
obecne doporuceni overbooking 3:1 jsem nasel k hypervizoru KVM.
Co-Scheduling je dalsi faktor, v pripade VIRTUALIZACNIHO PARADOXu
jeste dulezitejsi, ktery ma vliv na vykon viceprocesorovych
virtualnich pocitacu.

Bylo by skvele, kdybys mel vizibilitu do VirtulBox scheduleru a umel z
nej vytahnout metriky CPURDY a CO-STOP, ktere by ti prozradily co se
ve scheduleru deje.

> A jeste vysvetleni k tomu, proc nastavuji "tak velky overbooking" -
> nedokazu zadnym zpusobem vytizit CPU na hypervisoru. Ten procesor ani v
> tom nejhorsim scenari nepracuje na vic, nez 50% (spis se to pohybuje
> mezi 15% - 30%), takze jsem si rikal, ze kdyz tomu VM pridam vic vCPU,
> tak to bude schopne vyuzit vic z potencialu HW CPU. Ale opak je pravdou.

Ano, to je bezny pozadavek vsech IT manazeru a jeden z duvodu, proc je
serverova virtualizace tak popularni a dnes jiz vlastne majoritni
zpusob provozu serveru. Pozadavek na lepsi vyuziti nakoupenych zdroju,
v pripade serverove virtualizace jde o lepsi vyuziti CPU a RAM.

Velmi tezko se mi vysvetluje IT manazerum i IT administratorum, ze
malokdy uvidi 100% vyuziti CPU taktu (Hz), protoze je to prave i o
context switchingu, ktery je pro celkovy vykon dulezity, protoze CPU k
tomu, aby neco pocital, tak musi delat i I/O operace do RAM a do
STORAGE, a v te dobe ten konkretni vCPU je ve stavu WAIT a pCPU tudiz
muze delat neco jineho pro jine vCPU, ale vyzaduje to switch pCPU
contextu.

Jinymi slovy je to tak, ze se snazis vyuzit vice CPU Hz (vyssi CPU
load), ale context switching Ti to nedovoli a pretezuje system
natolik, ze je to horsi nez lepsi

> Takze tu ted zkratka mam stroj s vykonem 6x 2.53 GHz (kdyz nepocitam HT
> vlakna),

Hyperthreading rozhodne nemuzes zapocitavat do celkovych Hz.
Hyperthreading pouze umi vyuzit diry v CPU pipelingu a realne ti v
modernich CPU muze prinest zvyseni vykonu o nejakych 15 - 25%, ale je
to velmi zavisle na tom, co se dela. Pamatuji si na historicke
diskuse, ve kterych participoval Dan, jestli se vyplati hyperthreading
vubec zapinat. Kdyz Intel hyperthreading uvedl na trh, tak to bylo
naimplementovane tak, ze pro vypocetne intenzivni workloady se
docililo vice "vykonu" bez hyperthreadingu. Dnes uz je hyperthreading
vyladenejsi, tedy alespon do te doby, nez nekdo najde security bug v
implementaci. Viz. "Intel CPUs can be exploited unless you disable
hyper-threading"
https://www.techradar.com/news/intel-cpus-can-be-exploited-unless-you-disable-hyper-threading-linux-dev-claims

> ale nedokazu ten vykon vyuzit na vic, nez polovinu.

Vyuziti taktovaci frekvence na polovinu (50%) je slusna prace. Nemel
bys mit vetsi ocekavani. To co mi ve VMwaru pozorujeme jako bezny
prinos virtualizace u nasich zakazniku, je zvednuti prumerneho vyuziti
CPU taktovaci frekvence z nejakych 5% na fyzickych serverech na cca
15-30% na serverech s hypervizorem. Z tohoto pohledu je pozorovanych
50% taktovaci frekvence uspech. Nic to vsak nevypovida o realnych
aplikacnich/databazovych transakcich. Jinymy slovy o realne ucinnosti
versus ztratovy vykon. K takovemu posouzeni potrebujes monitorovat
vykon aplikace. Ve Tvem pripade je tou aplikaci firewall (PF), ale
mohou to byt treba DB transakce, aplikacni transakce, apod. Proto si
musis udelat aplikacni benchmarky, coz ted delas, a overit si, pri
jakych podminkach ti hardware infrastruktura dava nejlepsi aplikacni
vykon.

> Rozhodne ne tim zpusobem, ze bych mel jeden velky VM. Mozna, ze kdybych
> mel 6 malych s 2 vCPU, tak by to dokazalo vyuzit lip, nez 1 VM s 8 vCPU.

Ano. A to je jedno z reseni VIRTUALIZACNIho PARADOXu. Zmensit pocet
vCPU v ramci virtualnich pocitacu a pouzit jich vice. Tam pak ulevis
tomu vSMP v ramci hypervizor CPU schedulingu. K tomu ale potrebujes
umet rozlozit aplikaci do vice virtualek. Bohuzel ne kazda aplikace
umi fungovat v takoveto scale-out architekture, a proto takova appka
vyzaduje scale-up, tzn. vice vCPU a vice vRAM. Scale-out architektura
totiz vyzaduje paralelizaci a distribuci, coz jsou principialne
slozitejsi technologie. A o tom je dnesni trend v modernich
aplikacich, ktery nas ve skole ucili uz pred 25-ti lety, a az ted se
dostava do beznejsi praxe.

>
> Mirek

To jsem se zase rozepsal. Dejte mi prosim vedet, jestli uz toho neni
moc a jestli to neni off-topic.

David