cim vic jader CPU, tim pomalejsi

[David Pasek]

Ahoj,
pripojim se do teto diskuse, protoze doufam, ze k tomu mam co rict, i
kdyz predesilam, ze s virtualizaci na FreeBSD jsem zatim
neexperimentoval a to ani s VirtualBoxem, ani s bhyve, ktere mi
pripada z pohledu vykonu a provozu produkcnich workloadu zajimavejsi,
jelikoz se jedna o virtualizaci Typu 1 a nikoliv Typu 2, jako je
VirtualBox.

<snip>
There are two main hypervisor types, referred to as “Type 1” (or “bare
metal”) and “Type 2” (or “hosted”). A type 1 hypervisor acts like a
lightweight operating system and runs directly on the host’s hardware,
while a type 2 hypervisor runs as a software layer on an operating
system, like other computer programs.
</snip>

Duvodem, proc jsem zatim neexperimentoval s virtualizaci na FreeBSD je
to, ze se od roku 2006 intenzivne venuji virtualizaci pomoci
technologii VMware a zivim se tim :-)
DISCLAIMER: jsem zamestnancem VMware, takze muj nazor tim muze byt
ovlivnen. Na druhou stranu jsem dlouletym uzivatelem FreeBSD a
povazuji ho za jeden z nejlepsich OS se skvelou minulosti i
budoucnosti.

Musim otevrene rict, ze mam pocit, ze pomalu nastava cas zacit
testovat bhyve, protoze i kdyz je porad velky rozdil v detailech mezi
ruznymi hypervizory, tak na spoustu veci uz dnes bohate staci i
open-source technologie. Na testovani bhyve se chystam ve verzi
FreeBSD 13.

Nicmene zpatky k tematu. Pozorovany symptom subjektivne lepsiho vykonu
s mene vCPU nez s vice vCPU neni nic neobvykleho ani na jinych
virtualizacnich platformach, a dokonce i na roky vyladenem VMware
hypervizoru (ESXi), ktery se dnes pouziva i pro business critical
workloady.

Rikam tomu "VIRTUALIZATION PARADOX".

Problematiku jsem pred 7-mi lety popisoval zde
https://www.vcdx200.com/2013/10/two-2-or-four-4-socket-servers-for.html

Upozornuji, ze v te dobe byly 8-mi vCPU virtualni servery brany jako
"monster" VM, coz je z dnesniho pohledu usmevne, ale princip je porad
stejny. V dnesni dobe ja osobne povazuji za "monster" VM virtualni
servery od 32 vCPU a 256 GB RAM vyse, ale takove virtualni servery
typicky bezi na hardwaru, ktery je popsan zde
https://www.vcdx200.com/2021/01/server-rack-design-and-capacity-planning.html

Takze co je to tedy "VIRTUALIZATION PARADOX"?
"VIRTUALIZATION PARADOX" je situace, kdy konkretni vypocetni workload
bezi lepe na virtualnim serveru s mene vCPU nez na stroji s vice vCPU.

<snip from="https://www.vcdx200.com/2013/10/two-2-or-four-4-socket-servers-for.html">
In our example we are planning to have monster VMs with 8 vCPUs so 64
logical CPUs in 4S-SERVER offers potentially more scheduling
opportunities against 32 logical CPUs in 2S-SERVER. As far as I know
virtualization benchmarks tiles (tiles are a group of VMs) usually
have up to 2 vCPUs so I think the co-scheduling issue is not covered
by these benchmarks.

So the final decision depends on the expected number of  monster VMs
which can affect real performance of workloads inside these monster
VMs. CPU performance overloading can be monitored by ESX metric %RDY
(vCPU READY but pCPU not) and co-scheduling execution delays by metric
%CSTP (vCPU stopped because of co-scheduling). Recommended thresholds
are discussed here but every environment has different quality
requirements so your thresholds can be different and it depends what
quality SLA you want to offer and what type of application you want to
run on top of virtual infrastructure.

Anyway, co-scheduling of monster VMs is a serious issue for IaaS Cloud
Providers because it is really hard to explain to customers that less
vCPUs can give them paradoxically better CPU performance. I call this
phenomenon "VIRTUALIZATION PARADOX".
</snip>

Nechci jit do uplneho detailu, ale problematika je spojena s CPU schedulingem.
V tom je totiz rozdil mezi General Purpose OS (FreeBSD, Linux, etc.) a
bare metal hypervizor (VMware ESXi).
Hypervizor je samozrejme take Operacni System, ale ma jednotlive
schedulery (CPU, RAM, Storage, Network) vyladeny pro specificky ucel,
a tim je provoz virtualnich serveru. Jinymi slovy scheduling.

Koncepcne je "VIRTUALIZATION PARADOX" o tom, ze hypervizor scheduler
ma k dispozici napr. 24 CPU Cores (pCPU), ktere se pomoci
hyperthreadingu mohou zdvojnásobit na 48 CPU Threads - logickych CPU
(lCPU). Cilem serverove virtualizace je partitioning a sharing
resourcu, takze se zavadi pojem vCPU (virtualni CPU), coz neni nic
jineho nez proces emulujici CPU. Tyto vCPU jsou pak schedulovany na
logicke CPU (lCPU).

Mam-li tedy scheduler k dispozici 48 logickych CPU, tak se na tom
celkem v pohode uprovozuje 6x 4vCPU Virtual Machine, protoze se
scheduluje 24 vCPU na 24 pCPU a hyperthreding dava systemu k dispozici
az 48 lCPU, ktere davaji prostor schedulovat i systemovy overhead
spojeny s virtualizaci (overhead). V takovemto pripade bych tedy
neocekaval vykonnostni problemy a User eXperience by nemela byt
virtualizaci vubec postizena.

Jelikoz je virtualizace nejen o partitioningu, ale i o sharingu, tak
toto vetsinou uzivatelum nestaci a chteji vic, takze se pokracuje k
tzv. overbookingu. Ve vyse uvedenem scenari s 24 pCPU systemem, si
dokazu predstavit, a v praxi se realne pouziva, provoz 18-ti 4vCPU
Virtual Machine, jelikoz pri provozu 72 vCPU na 48 lCPU dochazi k
akceptovatelnemu frontovani (queueingu) vCPU v ramci CPU scheduleru
(logical CPU).

Akceptovatelne frontovani vCPU versus pCPU je velmi subjektivni a
relativni pojem. Kazda aplikace je jinak nachylna na CPU latency, a je
logicke, ze vyssi vCPU / pCPU pomery vedou k vetsi pravdepodobnosti
toho, ze vCPU bude cekat delsi dobu v CPU scheduler queue, a tim se
muze zvysit CPU latence uvnitr virtualizovaneho serveru.

Ve virtualizacnim svete se provozuji nasledujici typicke virtualizacni
pomery vCPU : pCPU
1 : 1 - mission critical aplikacni workloady (CPU latency sensitive)
3 : 1 - business critical aplikacni workloady
5 : 1 - general aplikacni workloady
10 : 1 - testovaci nebo nekriticke workloady (CPU latency nonsensitive)

pCPU je ve vyse uvedenych pomerech CPU Core, nikoliv CPU thread (logicke CPU).

Pozor! Ve vsech vyse uvedeny uvahach vychazim z virtualizace Typu 1,
coz VirtualBox neni. Pri pouziti VirtualBoxu je potreba pocitat s
vetsim overheadem virtualizace a navic i s workloadem, ktery musi
uprovozovat podkladovy Operacni System pro nevirtualizovany aplikacni
workload.

A dalsi pozor! Zatim jsem naznacil jen frontovani vCPU na CPU
Scheduleru, ale jelikoz se bavime o schedulingu virtualnich serveru s
vice vCPU, tak tam je jeste dalsi slozitost, protoze hypervisor musi
mit implementovane vSMP (virtualni symetricky multiprocesing) a tam je
zasadni jestli se scheduluji vsechny VM vCPU do CPU scheduleru
najednou (a pri takovemto pristupu se muze vCPU latence dost zvysit) a
nebo je umoznen scheduling vCPU i jednotlive (tak to delaji moderni
hypervizory). Nicmene, kdyz hypervizor  vSMP umoznuje scheduling
jednotlivych vCPU, tak se muze stat, ze se jednotlive vCPU v ramci
jedne VM casove rozjedou, a kdyz uz je to moc, tak je potreba aby ty
vCPU, ktere jsou moc v prestihu, pockaly na vCPU, ktere jsou casove
pozadu. A tomu se rika CO-STOP (co-scheduling stop). Viz.
https://vmware2112.wordpress.com/2012/07/05/what-does-the-cpu-co-stop-counter-measure-cstp/

Takze jak vidite, tak velmi zalezi na implementaci jednotlivych
hypervizoru, ale na to uzivatele vetsinou prijdou az tehdy, kdyz
pozoruji vykonnostni problemy.

Vitejte ve svete serverove virtualizace, kde se snazime oklamat fyziku
a ono to nekdy trosku funguje a nekdy uz proste ne ;-)

David.
-- 
David Pasek
david.pasek at gmail.com, +420 602 525 736