LXC / VM Performance

[tomee]

Ich teste derzeit mit PVE 8.2 ein Projekt und beobachte einen eklatanten Unterschied zwischen der Performance einer VM (Rocky Linux 9.4) und einem Container. Die VM repliziert eine mySQL-Datenbank und aufgefallen ist das Problem, wiel diese VM "seconds_behind" nicht nahe 0 halten kann, sondern immer mal wieder (sprunghaft) 30, 60 oder mehr Sekunden zurückfiel. Im Container tritt dieses Problem nicht auf.

Um ein Gespür für den Performanceunterschied zu bekommen habe ich einen sysbench-Test mit mariaDB im Container und der VM durchgeführt (16 Kerne, 32GB):

Metrik	LXC	VM
Leseabfragen	1,020,390	432,614
Schreibabfragen	291,540	123,604
Andere Abfragen	145,770	61,802
Gesamtanzahl Abfragen	1,457,700	618,020
Transaktionen	72,885	30,901
Abfragen pro Sekunde	145,713.01	61,776.44

Das ist mehr als das doppelte. Ich ging bisher schon davon aus, dass ein LXC-Container ggü einer VM etwas flotter ist. Das der Unterschied zur VM jedoch so extrem ist.. ich frage mich, ob dieser Performanceunterschied wie beobachtet normal ist oder ich eine wichtige Stellschraube übersehe.

Der Flaschenhals wird hier vermutlich i/o sein und da habe ich einen ZFS-Mirror über zwei SSDs (Solidigm D7-P5520). Die VM verwendet als Dateisystem ext4. Im Benchmark oben Virtio Single, aio=threads, cache=none, iothread=1, ssd=1. Ich habe jedoch auch schon aio native und io_uring, sowie statt Virtio Single, Virtio Block probiert um die Performance der Datenbank in der VM zu steigern.

 

[Falk R.]

Zeig mal die VM Konfiguration.
Wenn ich mir die Werte anschaue, gehe ich davon aus, dass du nicht den CPU Typ host gewählt hast.

 

[tomee]

Korrekt, es war voreingestellt x86-64-v2-AES aber auch mit host gibt es keine allzugroße Änderung vom sysbench: 72k statt 62k queries/s

agent: 1
boot: order=scsi0;ide2;net0
cores: 16
cpu: host
ide2: none,media=cdrom
memory: 32768
meta: creation-qemu=9.0.0,ctime=1726738972
name: sonsari.db
net0: virtio=BC:24:11:77:99:88,bridge=vmbr0,firewall=1
net1: virtio=BC:24:11:8F:30:29,bridge=vmbr1,firewall=1
numa: 0
onboot: 1
ostype: l26
scsi0: local-datapool:vm-271-disk-0,aio=threads,discard=on,iothread=1,size=32G,ssd=1
scsi1: local-datapool:vm-271-disk-1,aio=threads,backup=0,cache=none,iothread=1,size=200G,ssd=1
scsi2: local-datapool:vm-271-disk-2,aio=threads,discard=on,iothread=1,size=450G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=05778b06-52c8-4a1b-bacb-a624a25158b7
sockets: 1
vmgenid: dd1c724b-a645-4b4e-8ea0-2b6cb497245f

 

[Falk R.]

Korrekt, es war voreingestellt x86-64-v2-AES aber auch mit host gibt es keine allzugroße Änderung vom sysbench: 72k statt 62k queries/s

Die Konfig sieht soweit gut aus, wie ist denn der Host ausgestattet? Falls der Host 8 Cores und 16 Threads pro CPU hat, geht die Performance auch runter. Beim LXC ist das alles kein Thema, da der Hostkernel genutzt wird.
Eventuell macht das Dateisystem in der VM auch noch etwas aus.

 

[tomee]

Der Host ist ein Xeon Silver 4416+ mit 20 Kernen / 40 Threads bei max 5% Auslastung mit 500GB RAM.

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 46 bits physical, 57 bits virtual
Byte Order: Little Endian
CPU(s): 40
On-line CPU(s) list: 0-39
Vendor ID: GenuineIntel
BIOS Vendor ID: Intel(R) Corporation
Model name: Intel(R) Xeon(R) Silver 4416+
BIOS Model name: Intel(R) Xeon(R) Silver 4416+ CPU @ 2.0GHz
BIOS CPU family: 179
CPU family: 6
Model: 143
Thread(s) per core: 2
Core(s) per socket: 20
Socket(s): 1
Stepping: 8
CPU(s) scaling MHz: 73%
CPU max MHz: 3900.0000
CPU min MHz: 800.0000
BogoMIPS: 4000.00
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe sysca
ll nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known
_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe p
opcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cat_l2 cdp_l3 intel_ppin
cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2
erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512v
l xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local split_lock_detect user_shstk avx_vnni avx5
12_bf16 wbnoinvd dtherm ida arat pln pts vnmi avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni
avx512_bitalg tme avx512_vpopcntdq la57 rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm md_clear serialize tsxl
dtrk pconfig arch_lbr ibt amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities
Virtualization features:
Virtualization: VT-x
Caches (sum of all):
L1d: 960 KiB (20 instances)
L1i: 640 KiB (20 instances)
L2: 40 MiB (20 instances)
L3: 37.5 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-39
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS SW sequence; BHI BHI_DIS_S
Srbds: Not affected
Tsx async abort: Not affected

In der VM ist das Dateisystem ext4 und die einzige Anpassung der mount mit noatime.

 

[tomee]

fio --sync=1 --rw=randread --bs=16k --numjobs=1 --iodepth=4 --filesize=10G --runtime=300

Metrik	LXC	VM
IOPS	13.3k	6768
Durchsatz	207 MiB/s (217 MB/s)	106 MiB/s (111 MB/s)
Latenz	74.91 µs	146.94 µs
CPU-Auslastung	Benutzer 0.90%, System 29.90%	Benutzer 1.28%, System 10.05%

 

[Falk R.]

Wenn du 16k Benchmarkst, solltest du das XFS eventuell auch auf 16k Formatieren. Default ist da 4k.

 

[tomee]

Die VM hat ext4, nicht XFS. Hast Du hier einen Tip, was ich anpassen solle? Der Fio-Test war als grobe Einordnung gedacht, dass es definitiv ein i/o Problem ist.

 

[Falk R.]

Naja in der VM hast du den virtuellen Controller dazwischen und der LXC kann über den Hostkernel direkt auf die Disks zugreifen.
Man kann noch etwas rumspielen mit io_uring vs. threads und auch mal die alte Technik testen. Ich habe bei manchen VMs mit virtio statt scsi bessere Werte.

 

[tomee]

Ok, also kann man doch grob festhalten, dass der beobachtete Performanceunterschied (doppelt so schnell) normal ist? Bei hoher i/o Last müsste ich folglich LXC ggü einer VM den Vorzug geben.

 

[Falk R.]

Ok, also kann man doch grob festhalten, dass der beobachtete Performanceunterschied (doppelt so schnell) normal ist? Bei hoher i/o Last müsste ich folglich LXC ggü einer VM den Vorzug geben.

Doppelt so schnell ist nicht ganz normal, aber ein LXC hat immer Geschwindigkeitsvorteile. Dafür bist du immer vom Hostkernel abhängig und es gibt auch kein Live Migration.
Wenn das für dich OK ist, ist LXC die richtige Wahl.

 

[waltar]

Ich tausche in den Containern immer noch gerne das ext4 gegen xfs aus, rein aus Prinzip/Emotion ..., aber die Erkenntnis dieses doch großen Unterschiedes ist schon sehr interessant aus diesem lxc-vm-Vergleich, insbesondere wenn die HW schon altersschwach ist - gefällt mir !