System gerät ins stocken bei bhyve-startup

Andy_m4

Well-Known Member
Hallo Forumsfreunde,

wenn ich ein Gastsystem via bhyve starte, so habe ich das Problem das mein System ins stocken gerät und man Freezes hat die durchaus auch mal bis zu einigen Sekunden dauern können. Also insbesondere in der Startphase wenn das Gastsystem bootet und die VM sozusagen Last hat.
So ein ähnliches Phänomen habe ich auch manchmal, wenn ich z.B. auf externe Datenträger (USB-Sticks) zugreife.
Als ob eine (länger dauernde) I/O Operation global alle Tasks blockiert.

Kennt jemand das Phänomen? Hat jemand eine Erklärung dafür? Gibts möglicherweise sogar Lösungsansätze?

Vielen Dank schon mal im voraus
von m4
 
Moin,

hast du ein paar Eckdaten zu dem Host? Dateisystem, wo liegt die Gastfestplatte etc. Wie startest du den Gast?
 
hast du ein paar Eckdaten zu dem Host?
Modernes System. :-)
Oder anders gesagt: Ich glaube nicht, das CPU oder RAM ein limitierender Faktor ist. Beides ist weit im grünen Bereich.
Die Platte ist eine SSD.
Das Dateisystem ist ZFS.

Wie startest du den Gast?
Code:
bhyve -A -H -P -c 2 -m 2048M -w \
  -s 0,hostbridge \
  -s 1,lpc \
  -s 2,ahci-cd,linuxlivecd.iso \
  -s 3,fbuf,tcp=0.0.0.0:5900,wait \
  -s 4,xhci,tablet \
  -l com1,stdio \
  -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
 linux
 
Teste mal -c threads/cores/sockets=2

Laut freebsd-wiki heißt es:
There are currently some slot limitations with UEFI:

  • - AHCI devices must be in slots 3/4/5/6 - The PCI-ISA bus aka lpc must be in slot 31 - virtio-net devices can be in any slot

Dein lpc läuft aber auf -s 1. -A brauchst du eigentlich nur bei FreeBSD-Gästen. Teste auch mal ohne -P.

Weitere Ideen: Ist die SSD voll? Ist trim aktiv?

HTH
 
Weitere Ideen: Ist die SSD voll? Ist trim aktiv?
Nein.
Ja.

-A brauchst du eigentlich nur bei FreeBSD-Gästen. Teste auch mal ohne -P.
Kann ich machen.
Das Problem ist allerdings nicht immer so ganz einfach zu reproduzieren. Holprig ist meist nur der erste Startup.
Der Zweite dann nicht mehr. Als ob er eben hängt wenn er irgendwas auf der "Platte" macht. Sobald der Kram aus dem Cache kommt gibts auch keine Probleme.
Deswegen ja auch die Idee mit der blockierenden I/O. Mich wundert nur, das es sich halt so großflächig auswirkt und nicht nur auf den Prozess der die I/O-Operation durchführt.
Man hat so das Gefühl, man ist unter einer Programmiersprache die GarbageCollection hat. Und wenn der collected dann steht "die Welt" für den Augenblick still.

Jedenfalls dachte ich, jemand kennt vielleicht das Problem und kann dann aus den Stand heraus sagen "Jaja. Bekanntes Problem. Das liegt an demunddem und teste mal jenen Parameter dann müsste es besser sein" oder so.
 
Wie groß ist der ARC?
ARC hab ich via vfs.zfs.arc_max auf 4GB begrenzt.

tief in die Swap treiben kann
Tatsächlich sehe ich gerade, das ich 6 GB im Swap rumlungern er aber auch 5GB freien RAM meldet.

Vielleicht sollte ich da noch mal genauer hingucken. So Swap bzw. Memory-Management-Geschichten ... wenn da was klemmt würde das auch erklären, warum die (kurzzeitigen) Freezes sozusagen systemweit sind.
 
Zum reproduzieren kannst du bhvectl --destroy --vm=linux ausführen. Nach dem Herunterfahren verbleibt /dev/vmm/linux, was sich beim nächsten Start auswirkt.
 
So. Ich hab jetzt noch mal von einem frisch rebooteten System getestet. Hab auch extra ein paar Diagnosetools a-la vmstat etc. mitlaufen lassen. Ließ sich aber nicht reproduzieren.
Ich werde die Sache weiter beobachten. Die Idee mit dem "wird Swap benötigt" fand ich auf jeden Fall ein hilfreichen Hinweis. Wie gesagt. Von dem Symptomen her würde es gut passen und es war mir auch bis dato nicht aufgefallen das Swap überhaupt benutzt wird (meist ist der bei mir frei oder es sind höchstens mal ein paar hundert MB drin). Gut möglich das das mit einem anderen RAM-intensiven Prozess zusammengefallen ist der FreeBSD genötigt hat auszulagern und das musste er beim VM-Start erst mal einiges wieder reorganisieren.

So stellt es sich jedenfalls für mich so im nachhinein betrachtet da. Das ist zwar immer noch Spekulation. Aber wenigstens ist sie plausibel und ich weiß beim nächsten Mal wenn das Problem auftritt gleich, wo ich nachgucken sollte. Und dann ergibt sich ja vielleicht noch konkreteres Bild.
 
Bei vm-bhyve kann man wired_memory="no" bzw. yes setzen. Eventuell federt das ein wenig ab. Aber wie man das nativ setzt, weiß ich grade nicht auswendig.
Bauchgefühlig denke ich, dass die Begrenzung vom ARC schon ausreicht.

Davon abgesehen habe ich den Effekt auch im Sekundenbereich, aber ausschließlich beim Start oder Beenden von VMs. Es fühlt sich aber nicht abnorm/viel zu lange an, gerade mit PCI-passthrough.
Achja, AMD-System hier.
 
Zurück
Oben