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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
