fio Tests innerhalb der VM langsamer

[Trust9]

Hallo Leute,
ich teste mich gerade durch Proxmox durch und habe eine Verständnisfrage.

Aktuell betreibe ich ein ZFS Raid 10 mit 4x Samsung 990 pro
ashift 12 und Blocksize 8k (soll mal ne SQL Datenbank rauf), compression lz4
Es läuft eine nackte ubuntu VM auf dem Host.

Wenn ich einen CPU Sysbench auf dem Host und innerhalb der VM mache, habe ich fast identische Werte.
Mache ich einen Memory Test, ebenfalls fast identisch.

Jetzt mein Problem bzw. Verständnisfrage

Führe ich einen fio Test auf dem Host durch ... Vollgas.
Innerhalb der VM ist allerdings der Schnarchmodus aktiviert und der Benchmark spuckt viel niedrigere Werte aus. Vermutlich habe ich irgendwas falsch konfiguriert.
Gerade zfs ist ja ein Monster, was die Möglichkeiten angeht.

Beides mit

fio --rw=readwrite --name=test --size=50M --direct=1 --bs=8k --numjobs=6 --group_reporting --runtime=10 --time_based

Host:

Jobs: 6 (f=6): [M(6)][100.0%][r=7533MiB/s,w=7519MiB/s][r=964k,w=962k IOPS][eta 00m:00s]
test: (groupid=0, jobs=6): err= 0: pid=83840: Wed Aug  7 15:59:21 2024
  read: IOPS=965k, BW=7542MiB/s (7909MB/s)(73.7GiB/10001msec)
    clat (nsec): min=643, max=14968k, avg=1854.71, stdev=19198.28
     lat (nsec): min=654, max=14968k, avg=1873.02, stdev=19371.51
    clat percentiles (nsec):
     |  1.00th=[  836],  5.00th=[ 1112], 10.00th=[ 1256], 20.00th=[ 1368],
     | 30.00th=[ 1448], 40.00th=[ 1544], 50.00th=[ 1656], 60.00th=[ 1800],
     | 70.00th=[ 1944], 80.00th=[ 2096], 90.00th=[ 2384], 95.00th=[ 2704],
     | 99.00th=[ 4128], 99.50th=[ 5280], 99.90th=[ 6624], 99.95th=[ 7840],
     | 99.99th=[28800]
   bw (  MiB/s): min= 7050, max= 8237, per=99.98%, avg=7540.72, stdev=53.62, samples=114
   iops        : min=902447, max=1054368, avg=965211.42, stdev=6863.73, samples=114
  write: IOPS=965k, BW=7541MiB/s (7907MB/s)(73.6GiB/10001msec); 0 zone resets
    clat (nsec): min=1498, max=19789k, avg=4023.10, stdev=37821.54
     lat (nsec): min=1523, max=19789k, avg=4053.21, stdev=37831.72
    clat percentiles (nsec):
     |  1.00th=[  1944],  5.00th=[  2256], 10.00th=[  2384], 20.00th=[  2544],
     | 30.00th=[  2704], 40.00th=[  2928], 50.00th=[  3344], 60.00th=[  3792],
     | 70.00th=[  4256], 80.00th=[  4896], 90.00th=[  5728], 95.00th=[  6496],
     | 99.00th=[  8256], 99.50th=[  8896], 99.90th=[ 11328], 99.95th=[ 18304],
     | 99.99th=[284672]
   bw (  MiB/s): min= 7060, max= 8234, per=99.97%, avg=7538.42, stdev=53.69, samples=114
   iops        : min=903768, max=1054075, avg=964916.11, stdev=6872.45, samples=114
  lat (nsec)   : 750=0.15%, 1000=1.33%
  lat (usec)   : 2=35.97%, 4=44.46%, 10=17.97%, 20=0.08%, 50=0.02%
  lat (usec)   : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%
  cpu          : usr=7.63%, sys=86.50%, ctx=11232, majf=0, minf=91
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=9654960,9653022,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=7542MiB/s (7909MB/s), 7542MiB/s-7542MiB/s (7909MB/s-7909MB/s), io=73.7GiB (79.1GB), run=10001-10001msec
  WRITE: bw=7541MiB/s (7907MB/s), 7541MiB/s-7541MiB/s (7907MB/s-7907MB/s), io=73.6GiB (79.1GB), run=10001-10001msec

VM:

Jobs: 6 (f=6): [M(6)][100.0%][r=1201MiB/s,w=1207MiB/s][r=154k,w=154k IOPS][eta 00m:00s]
test: (groupid=0, jobs=6): err= 0: pid=2371: Wed Aug  7 13:59:39 2024
  read: IOPS=148k, BW=1159MiB/s (1215MB/s)(11.3GiB/10001msec)
    clat (usec): min=10, max=8291, avg=19.84, stdev=17.70
     lat (usec): min=10, max=8291, avg=19.86, stdev=17.70
    clat percentiles (usec):
     |  1.00th=[   15],  5.00th=[   16], 10.00th=[   17], 20.00th=[   18],
     | 30.00th=[   19], 40.00th=[   20], 50.00th=[   20], 60.00th=[   20],
     | 70.00th=[   21], 80.00th=[   21], 90.00th=[   24], 95.00th=[   26],
     | 99.00th=[   29], 99.50th=[   34], 99.90th=[   61], 99.95th=[   75],
     | 99.99th=[  200]
   bw (  MiB/s): min=  958, max= 1290, per=99.87%, avg=1157.13, stdev=14.76, samples=114
   iops        : min=122696, max=165208, avg=148112.53, stdev=1889.35, samples=114
  write: IOPS=148k, BW=1160MiB/s (1216MB/s)(11.3GiB/10001msec); 0 zone resets
    clat (usec): min=10, max=8245, avg=20.23, stdev=11.18
     lat (usec): min=10, max=8245, avg=20.28, stdev=11.18
    clat percentiles (usec):
     |  1.00th=[   15],  5.00th=[   16], 10.00th=[   17], 20.00th=[   19],
     | 30.00th=[   20], 40.00th=[   20], 50.00th=[   20], 60.00th=[   21],
     | 70.00th=[   21], 80.00th=[   22], 90.00th=[   25], 95.00th=[   26],
     | 99.00th=[   30], 99.50th=[   35], 99.90th=[   61], 99.95th=[   76],
     | 99.99th=[  155]
   bw (  MiB/s): min=  955, max= 1298, per=99.85%, avg=1158.39, stdev=14.93, samples=114
   iops        : min=122366, max=166238, avg=148274.00, stdev=1911.54, samples=114
  lat (usec)   : 20=62.73%, 50=37.10%, 100=0.15%, 250=0.02%, 500=0.01%
  lat (usec)   : 750=0.01%, 1000=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01%
  cpu          : usr=3.44%, sys=18.46%, ctx=2968248, majf=0, minf=80
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=1483171,1485098,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=1159MiB/s (1215MB/s), 1159MiB/s-1159MiB/s (1215MB/s-1215MB/s), io=11.3GiB (12.1GB), run=10001-10001msec
  WRITE: bw=1160MiB/s (1216MB/s), 1160MiB/s-1160MiB/s (1216MB/s-1216MB/s), io=11.3GiB (12.2GB), run=10001-10001msec

Habt Ihr eine Idee wo mein Fehler liegt?

Danke euch

 

[Falk R.]

Wie ist denn die VM konfiguriert?

 

[meyergru]

Zum einen betreibst Du möglicherweise ein ZFS-Dateisystem als Datei bzw. ZFS-Volume auf einem ZFS-Raid. ZFS in ZFS funktioniert nicht sonderlich gut, weil die Verwaltungsstrukturen dupliziert werden. Normalerweise ist auch Kompression eingeschaltet, doppelt komprimieren wird wohl fruchtlos bleiben, braucht aber Rechenzeit. Zumindest für das ZFS-Dataset, wo die Disk-Images liegen, sollte man das abschalten. Die Doppelverarbeitung gilt auch für Checksumming und ggf. Verschlüsselung.

Es gibt daneben noch weitere Einstellungen, die ZFS langsam machen können, z.B. atime statt relatime.

Dann nutzt Du fio mit eine Blockgröße von 8K, was viel kleiner ist als die realen Write Blocks einer typischen Prosumer-SSD wie Deiner Samsung. Und dann wird je das VM-Blockdevice durch eine Emulation gejagt, um es auf die Datei im ZFS des Proxmox-Hosts abzubilden. Eventuell kann die Emulation nicht effektiv puffern und committed immer nach jedem Block.

Viele Übersetzungsschichten.

Eine Möglichkeit wäre, die Block Devices per passthrough an die VM durchzureichen, damit dort das ZFS verwaltet werden kann. Dazu gibt es zwei Möglichkeiten: 1. PCIe-Passthrough (dann funktioniert auch smartctl usw.) oder 2. Block-Device-Passthrough. Solche Lösungen werden oft verwendet, wenn man z.B. TrueNAS Scale o.ä. als VM laufen lassen will.

Eine andere Möglichkeit ist, anstelle einer VM einen LXC-Container zu verwenden, der direkt die logischen Dateisysteme des VM-Hosts mounten kann.

Die dritte Variante ist, auf dem Proxmox Host einen NFS-Server einzurichten (oder Samba) und die Storage dann per NFS zu mounten, aber auch da hat man dann zumindest Interprozess-Kommunikation.

 

[Trust9]

Hey Leute, vielen Dank für die Antworten. Ich werde leider erst heute Nachmittag zum Testen kommen, will aber wenigstens schon mal die VM Daten (wie gewünscht) mitteilen .

@Falk R.
Maschine: q35 mit UEFI
SCSI Controller: VirtIO Single
Bus/Device: SCSI
Cache Writeback
IO thread aktiviert
CPU: 15 Cores und Type: Host
Memory: 81920MiB
Helfen noch weitere Daten?

@meyergru
Also innerhalb der VM läuft ein Ubuntu auf Ext4.
In deine Vorschläge muss ich mich auch erstmal einlesen und testen, sobald ich vor der Maschine sitze.
Nur um mein Testsetup zu optimieren. Welche Blockgröße würdest du vorschlagen? Habe kurz google angeschmissen und ein paar Beiträge gefunden, in denen zwischen 16k und 64k getestet wurde.

Wenn ich den Speicher direkt per Passthrough durchreiche, oder per NFS Share mounte, gehen doch die Top ZFS Features, Replikation und Snapshots verloren, oder?

Ich wollte schon gerne die SQL Datenbank in einer echten VM betreiben und einen Container erstmal außen vor lassen.

Auf dem Host machen mich die gemessenen Werte wirklich, glücklich. Ich habe schon erwartet, dass eventuell so 10-15% durch die Virtualisierung verloren gehen, aber meine aktuellen Werte erschrecken mich schon . Ist erstmal nur ein Testsystem. Später würde ich auf Enterprise nvmes wechseln.

Danke nochmal.
Mir fehlt noch ein bisschen das technische Verständnis, aber ohne testen und fragen wird es nicht besser.

 

[Falk R.]

Hey Leute, vielen Dank für die Antworten. Ich werde leider erst heute Nachmittag zum Testen kommen, will aber wenigstens schon mal die VM Daten (wie gewünscht) mitteilen .

@Falk R.
Maschine: q35 mit UEFI
SCSI Controller: VirtIO Single
Bus/Device: SCSI
Cache Writeback

MAch den Cache bitte aus, Der zusätzliche Cache bringt keine echten Vorteile.

IO thread aktiviert
CPU: 15 Cores und Type: Host

Warum so viele Cores? In der Regel einer VM immer nur so viele Cores geben wie tatsächlich benötigt werden, dann läuft die einfach besser.
P.S. ich habe mit Ubuntu schon einige Benchmarks gemacht. Eine 8vCPU VM schafft locker über 1 Mio I/O (bei Server CPUs)
Für deine VM reichen vermutlich 2-4 Cores.
Auch beim RAM würde ich dem Host / ZFS ARC etwas Luft lassen.

Memory: 81920MiB
Helfen noch weitere Daten?

@meyergru
Also innerhalb der VM läuft ein Ubuntu auf Ext4.
In deine Vorschläge muss ich mich auch erstmal einlesen und testen, sobald ich vor der Maschine sitze.
Nur um mein Testsetup zu optimieren. Welche Blockgröße würdest du vorschlagen? Habe kurz google angeschmissen und ein paar Beiträge gefunden, in denen zwischen 16k und 64k getestet wurde.

Wenn ich den Speicher direkt per Passthrough durchreiche, oder per NFS Share mounte, gehen doch die Top ZFS Features, Replikation und Snapshots verloren, oder?

Ich wollte schon gerne die SQL Datenbank in einer echten VM betreiben und einen Container erstmal außen vor lassen.

Auf dem Host machen mich die gemessenen Werte wirklich, glücklich. Ich habe schon erwartet, dass eventuell so 10-15% durch die Virtualisierung verloren gehen, aber meine aktuellen Werte erschrecken mich schon . Ist erstmal nur ein Testsystem. Später würde ich auf Enterprise nvmes wechseln.

Danke nochmal.
Mir fehlt noch ein bisschen das technische Verständnis, aber ohne testen und fragen wird es nicht besser.

Die meisen SQL arbeiten in 64k Chunks, weshalb sich oft ein Tuning in diese Richtung etwas bringt, das sind dann aber nur kleine Tunings um 5-10 % mehr raus zu holen.

 

[Trust9]

Hi,
ich habe gestern Abend noch folgendes gefunden:

Wichtige Details zur Blockgröße in PostgreSQL:​

1. Blockgröße (Page Size)
   1. Die Blockgröße von 8 KB ist die Grundeinheit, mit der PostgreSQL Daten speichert und abruft. Jede Tabelle und jeder Index ist in 8 KB große Blöcke unterteilt.
   2. Diese Blockgröße wird zur Compile-Zeit festgelegt und ist für die meisten PostgreSQL-Installationen standardmäßig auf 8 KB gesetzt. Es ist möglich, PostgreSQL mit einer anderen Blockgröße zu kompilieren (z.B. 4 KB oder 16 KB), aber das ist ungewöhnlich und erfordert eine Neu-Kompilierung des PostgreSQL-Quellcodes.
   3. Speicherverwaltung:
      • Die 8-KB-Blockgröße wirkt sich auch auf die Speicherverwaltung aus. PostgreSQL verwaltet den Speicher in Einheiten von 8 KB, was bedeutet, dass eine Tabelle, die kleiner als 8 KB ist, dennoch mindestens 8 KB Speicherplatz auf der Festplatte belegt.
   4. Indexe:
      • Indizes in PostgreSQL verwenden ebenfalls 8 KB große Blöcke, um Daten zu speichern. Der gleiche Mechanismus, der für Tabellen verwendet wird, gilt auch für Indexe.

Wenn ich das richtig verstehe, sollte ich mich doch auf 8K einschießen, oder?
recordsize: 8k

Jetzt habe ich gesehen, dass Ubuntu auf ext4 eine Blocksize von 4K verwendet.

sudo dumpe2fs /dev/ubuntu-vg/ubuntu-lv | grep 'Block size'
dumpe2fs 1.47.0 (5-Feb-2023)
Block size:               4096

Jetzt habe ich zfs auf 8k und die Partition innerhalb der VM auf 4k. Bin ich hier total auf dem Holzweg, oder versteckt sich hier noch Optimierungspotential?

Zu der Hardwarekonfiguration. War eine Anforderung vom Softwarehersteller. Du hast aber natürlich recht. Klein anfangen und hochskalieren.

 

[Falk R.]

Je nach Workload ist XFS performanter als EXT. In solches Tuning kann man unendlich Zeit investieren. Ob du jetzt 4K oder 8k FS für Postgre benutzt, macht höchstens 2-3 Prozent aus.

 

[Trust9]

Oh Mann ok. Dann verschwende ich keine Zeit mehr ins Tuning. Momentan benutze ich ja komplett Customer Hardware als Testsystem und ist vermutlich nicht als Referenz Benchmark anzusehen.

Eine 8vCPU VM schafft locker über 1 Mio I/O (bei Server CPUs)

Meinst du innerhalb einer VM auf ZFS? Das wäre ja mega gut.
Ich werde das als Nächstes mit einer Server-CPU und Enterprise SSDs testen. Ich bin gespannt, wie sich das Setup so schlägt.

Vielen Dank für deine Infos

 

[Falk R.]

Meinst du innerhalb einer VM auf ZFS? Das wäre ja mega gut.

Ich habe vor ein paar Jahren als VMware ESxi 7.0U3 heraus gebracht hatte das NVMe over TCP getestet. Da habe ich nach 2 Tagen Tuning aus einer vSphere VM mit Ubuntu 20.04 im Benchmark mit 4k I/O eine Million I/O herausgeholt.
Auf der Hardware hatte ich danach PVE7 installiert und die NVMe's in einen ZFS Mirror Pool gepackt. (6x 7,68 TB NVMe)
Dann habe ich eine Ubuntu VM nach Standard Best Practice (CPU=host, virtio Single) eingerichtet und mit dem gleichen Benchmark 1,2 Millionen I/O herausgeholt, mit 2 VMs hatte ich in Summe 2,4 Mio I/O. Also das Skaliert auch.

Datebank I/O hatte ich damals auch getestet, unter VMware 280-290k I/O und PVE 660k I/O. Alles mit Windows Server 2019 und SQL 2019 getestet.
Bei der PVE VM war aber die CPU zu 100% dicht, weshalb vermutlich noch mehr I/O theoretisch gehen müsste.

 

[Trust9]

Hab mir mal bei Hetzner einen Server bestellt. Bin schon gespannt, was am Ende dabei herauskommt.
Gebe schreibe hier dann mal meine Benchmark Ergebnisse.

Vielen Dank nochmal