cim vic jader CPU, tim pomalejsi - bhyve

[Miroslav Lachman]

On 15/04/2021 12:58, Miroslav Lachman wrote:

> K tomu muzu rict u jen "pekne me stve, ze jsem jedinej, kdo ma s tou 
> virtualizaci takovy problemy". A fakt nechapu, cim to muze byt, kdyz 
> jsem to zkousel na 3 strojich s 2 ruznymi CPU s 2 ruznymi typy 
> hypervisoru na dvou ruznych verzich FreeBSD a vzdy tam pozoruju velmi 
> zasadni zpomaleni, ktere nikdo z vas nepozoruje :(

Tak mam dalsi smutne pokracovani pribehu s VirtualBoxem a FreeBSD.

I kdyz se na testovacim stroji po upgrade na FreeBSD 12.2 a VirtualBox 
6.1 dosahlo jen nepatrneho zlepseni, tak jsem v pulce tydne udelal 
stejne upgrade na produkcnim stroji. (a pak se dve noci nevyspal)

Po upgrade na 12.2 a reinstalaci vsech portu (VirtualBox stale ve verzi 
5.2.44) doslo pri restartu VirtualBoxu na kernel panic a okamzity reboot 
systemu. Neco takoveho jsem uz dlouho nevidel, ale budiz. Nevim, co se 
ve 12.2 oproti 11.4 zmenilo, ale filesystem to odnesl dost osklive 
(stovky poskozenych / ztraceny [lost+found] souboru), neslo spustit 
background fsck, musel jsem to nabootovat do single user rezimu atd.
Kdyz byl FS opraveny a rebootoval jsem do multiuser rezimu, v okamziku 
spusteni VirtualBoxu opet instantni panic a ten samy problem s FS, dalsi 
skoro hodina vypadku.
Udelal jsem upgrade VirtualBoxu z 5.2.44 (legacy) na 6.1.18. S touhle 
verzi to nabehlo bez padu a pfctl "benchmark" probehne okamzite.

# time pfctl -t czech_net -T add -f /etc/pf.czech_net.table
2535/2535 addresses added.

Usr: 0.000s  Krnl: 0.007s  Totl: 0:00.00s  CPU: 0.0%  swppd: 0  I/O: 0+0

Realny workload s Apachem a PHP je ale porad strasne pomaly. Daleko 
pomalejsi, nez by na tomhle typu CPU a poctu jader mel byt. K dalsimu 
testovani jsem se ale nedostal, protoze Guru Meditation:

VBox.log.1:03:13:11.811807 Changing the VM state from 'RUNNING' to 
'GURU_MEDITATION'
VBox.log.1:03:13:11.831083 Console: Machine state changed to 
'GuruMeditation'
VBox.log.1:03:13:11.957231 !!         VCPU2: Guru Meditation -8 
(VERR_NO_MEMORY)

Proces vboxheadless se pak musi rucne killnout, nejde ani restartovat.

Ta sama situace se pak behem jednoho dne zopakovala asi 4x.

Neco se tedy u FreeBSD 12.2 nebo VirtualBoxu 6.1 zmenilo v oblasti 
pameti a konfigurace, ktera pred tim bezela normalne, ma ted patrne malo 
pameti, takze jsem tomu nejvetsimu VM sebral 2GB a zkusil upgrade 
VirtualBoxu na nejnovejsi 6.1.22 = snad to bude stabilnejsi.

A nic nemohlo byt vzdalenejsi pravde. S 6.1.22 se okamzite vratil 
syndrom okamzite paniky. Jakmile se spusti libovolny jeden virtual, tak 
to shodi cely server a ja pak opravuju rucne FS.

Samozrejme temi panicy doslo i k poskozeni FS uvnitr virtualu a ja pak 
dalsi noc resil opravy, opakovane panicy a fsck, abych se vratil zasek 
verzi 6.1.18, ktera tam bezi do ted a s tim mensim mnozstvim pridelene 
pameti to zatim nezatuhlo.

Z celeho toho laborovani mam ale z kombinace FreeBSD a VirtualBox velmi 
horkou pachut v puse a mam pocit, ze to byla posledni kapka a zadne 
dalsi projekty na tehle kombinaci stavet nebudu. Spis ty soucasne zkusim 
premigrovat do Bhyve. Krome toho nejvetsiho, protoze tam se stejne 
klient rozhodl odejit jinam. A vzhledem k tem vypadkum a nedostatecnemu 
vykonu se mu ani nemuzu moc divit.

VirtualBox jsem pouzival dlouha leta a nikdy jsem s nim nezazil takove 
problemy, jako ted. Ale aby mi celkem jednoduchy upgrade minoritni verze 
shazoval cely server, za to mi to nestoji.

Co si ale nedokazu moc vysvetlit je to, proc na testovacim serveru je to 
ve stejne konfiguraci FreeBSD 12.2 a VirtualBox 6.1.18 porad pomale v 
tom pfctl testu, kdyz na produkcnim se to zlepsilo do ocekavanych norem. 
Zarovn proc na testovacim serveru nedoslo k zadnym padum systemu a na 
produkcnim ano... Kdyz sjou oba stroje Intel Xeon z podobne doby, oba s 
UFS, oba s GENERIC kernelem atd. Vsechny aktualizace tma probihaji 
stejnym zpusobem ze stejneho privatniho repozitare.

No nic, je to jen takovy povzdech. Ani nemam moc chut se v tom vic 
stourat, kdyz ten hlavni duvod - velky produkcni virtual - uz je pase.

Mirek