[SOLVED] ZFS zu langsam

[Michl]

Guten Abend,

ich sitze gerade vor "meinem" ersten Proxmox-Produktivserver und bin der Meinung, dass ZFS nicht in die Pötte kommt.

Gerade getestet mit CrystalDiskmark sind es etwa 30 MB/s 4K QD32 Read.


Ein paar Eckdaten zum Server und der Installation:
CPU: Xeon E5-1620
RAM: 64GB, ZFS Max ARC=6GB
Controller: Broadcom SAS 9300-8i im IT-Mode
HDDs: 4x Consumer Samsung 850 Pro striped mirror, secure erase durchgeführt, 20% für spare freigelassen
ZIL: Intel 750 NVMe PCIe

ZPOOL manuell erstellt mit ashift=13
zfs set atime=off pool1
zfs set compression=lz4 pool1
zfs set recordsize=32K pool1
zfs set sync=always pool1

Die ZFS-Datasets sind pro VM als als Verzeichnis eingebunden.

betroffene VM: Windows 2016 Standard, 32 GB RAM, 6 vCPUs, Cache=writethrough, Virtio 0.1.141

Mir kommt's vor, als läge es am Gast bzw. KVM. Der Durchsatz auf dem Host scheint mir ok:

root@proxmox:~# pveperf /pool1/
CPU BOGOMIPS:      57601.92
REGEX/SECOND:      1484395
HD SIZE:           461.52 GB (pool1)
FSYNCS/SECOND:     4885.31
DNS EXT:           32.49 ms

root@proxmox:~# dd if=/pool1/vm200/images/200/vm-200-disk-1.raw bs=4K | pv | dd of=/dev/null
^C66GiB 0:00:18 [ 318MiB/s] [                                                                         <=>                                                                                                                                   ]
1546134+0 records in
1546133+0 records out
12369048+0 records in
12369048+0 records out
6332960768 bytes (6.3 GB, 5.9 GiB) copied, 18.7575 s, 338 MB/s6332952576 bytes (6.3 GB, 5.9 GiB) copied, 18.7575 s, 338 MB/s

root@proxmox:~# dd if=/pool1/vm200/images/200/vm-200-disk-1.raw bs=32K | pv | dd of=/dev/null
^C.6GiB 0:00:55 [ 923MiB/s] [                                                                                                                                                                                       <=>                     ]
92924636+0 records in
92924635+0 records out
1451952+0 records in
1451951+0 records out
47577413120 bytes (48 GB, 44 GiB) copied, 55.7338 s, 854 MB/s

  pool: pool1
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
        still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
        the pool may no longer be accessible by software that does not support
        the features. See zpool-features(5) for details.
  scan: scrub repaired 0B in 0h8m with 0 errors on Sat Dec  9 02:30:31 2017
config:

        NAME                                                 STATE     READ WRITE CKSUM
        pool1                                                ONLINE       0     0     0
          mirror-0                                           ONLINE       0     0     0
            scsi-350025388701934c1-part1                     ONLINE       0     0     0
            scsi-350025388401cc58b-part1                     ONLINE       0     0     0
          mirror-1                                           ONLINE       0     0     0
            scsi-350025388701934a4-part1                     ONLINE       0     0     0
            scsi-350025388401cc5a0-part1                     ONLINE       0     0     0
        logs
          nvme-INTEL_SSDPEDMW400G4_CVCQ64310020400AGN-part1  ONLINE       0     0     0

errors: No known data errors

root@proxmox:~# zpool list
NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
pool1   760G   274G   486G         -    43%    36%  1.00x  ONLINE  -

Das System erreichte bei der Grundinstallation (PVE 5.0) mit oben genannter Konfig schon mal gute Werte. Irgendwann mit dem Updates kamen die Windows 2016 Bluescreens. Nach viel Trial and Error und dem neusten Kernel, läufts wieder stabil, aber eben mit relativ bescheidenem Durchsatz.

Ab wann die Performance einbrach, kann ich nicht sagen.

Ich habe nun schon an allen Werten herumgedreht und auch ältere VirtIO-Treiber installiert... alles ohne Erfolg. Sync disable oder always bringt keine Veränderung. Lesen ist ja schon das Problem.

Habe testweise einen Pool auf der NVMe erstellt und ein zusätzliches Laufwerk an die VM gehängt und getestet -> exakt gleich schlechte Werte.

Hat jemand eine Idee?

Danke.

 

[HBO]

Hier kannste dich mal durch wurschteln, hatte soweit auch das gleiche Problem. Am besten diese ganzen kuriosen Tuning Sachen ausm Netz fast sein lassen, es gibt im englischen Bereich (hier im Proxmox Vorum) irgendwo noch einen recht guten Post (gerade nicht zur Hand).

Im Grunde habe ich nur noch min und max ARC Size genommen und mit ashift 12 (wieso nutzt du 13?) sowie einer Subvol Blocksize von 4k nichts geändert, seitdem keine Probleme und im Grunde bis auf CPU das gleiche Setup.

PS: Teste mit FIO, ist am aussagekräftigsten in Kombination mit iostat.

 

[LnxBil]

Hat jemand eine Idee?

Warum hast du blocksize=32K? Erstelle dir einfach mal ein neues Volume (gleiche Größe) mit 4K Blocksize und kopiere die Daten via dd rüber (VM vorher natürlich aus), danach einfach das alte Volume umbenennen und das neue so benennen wie das alte. Dann mal nochmal testen.

 

[Michl]

@HBO

Deinen Thread hatte ich vor ein paar Wochen schonmal durchgelesen. Ich glaube mein Problem ist ein anderes. Vielleicht kannst Du was mit dem FIO-Output anfangen?

root@proxmox:~# fio --filename=/pool1/test.dat --sync=1 --rw=read --bs=4k --numjobs=1 --iodepth=1 --runtime=120 --time_based --group_reporting --name=journal-test
journal-test: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=psync, iodepth=1
fio-2.16
Starting 1 process
Jobs: 1 (f=1): [R(1)] [100.0% done] [275.1MB/0KB/0KB /s] [70.7K/0/0 iops] [eta 00m:00s]
journal-test: (groupid=0, jobs=1): err= 0: pid=19922: Sat Dec  9 22:35:32 2017
  read : io=34089MB, bw=290889KB/s, iops=72722, runt=120001msec
    clat (usec): min=3, max=100172, avg=10.64, stdev=34.81
     lat (usec): min=3, max=100173, avg=11.34, stdev=34.81
    clat percentiles (usec):
     |  1.00th=[    5],  5.00th=[    6], 10.00th=[    6], 20.00th=[    8],
     | 30.00th=[    8], 40.00th=[    8], 50.00th=[    8], 60.00th=[    8],
     | 70.00th=[    8], 80.00th=[    9], 90.00th=[   29], 95.00th=[   30],
     | 99.00th=[   34], 99.50th=[   39], 99.90th=[   47], 99.95th=[   49],
     | 99.99th=[   91]
    lat (usec) : 4=0.02%, 10=84.27%, 20=3.17%, 50=12.50%, 100=0.04%
    lat (usec) : 250=0.01%, 500=0.01%, 750=0.01%
    lat (msec) : 250=0.01%
  cpu          : usr=5.62%, sys=94.27%, ctx=948, majf=0, minf=7
  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    : total=r=8726751/w=0/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: io=34089MB, aggrb=290889KB/s, minb=290889KB/s, maxb=290889KB/s, mint=120001msec, maxt=120001msec

70K IOPS sieht für mich gut aus. Allerdings kommt in der Windows VM nichts davon an !?

cat /etc/modprobe.d/zfs.conf
options zfs zfs_arc_min=1073741824
options zfs zfs_arc_max=6442450944

min ist bei mir auch gesetzt.

ashift 12 (wieso nutzt du 13?)

Weil ...ich weiss nicht. Soweit ich weiß, arbeitet die SSD mit 8K NAND. Irgendwo las ich damals, man solle den Wert deswegen auf 13 setzen. Bei der Einrichtung hatte ich intensiv mit ashift=9, 12 und 13 getestet.

Die besten Ergebnisse (Dateikopieren und DB) hatte ich mit ahsift=13 und recordsize=32K. Aber egal wie, es war alles schneller als es momentan läuft.

@LnxBil
Hab ich gemacht. Leider kaum nen Unterschied.
Selbst ein Benchmark auf einem leeren Volume läuft nicht gut.

Dazu kommt, dass ich im Prinzip nichts verändert habe ausser ein paar Updates.
Hier die Werte bei der Einrichtung von CrystalDiskmark (habe nur mit diesem Programm einen Vergleichswert):

Seq Q32T1     Read: 7822    Write: 5564    Write sync: 729
4K Q32T1      Read: 321.4   Write: 289.8

Jetzt sieht das so aus:

Seq Q32T1     Read: 1407    Write sync: 334
4K Q32T1      Read: 31.7   Write: 44.15

Achja, das Dateiformat der VM ist RAW.
Ein kopieren dieser Datei mit cp auf den gleichen Pool zeigt durchschnittliche 700 MB write auf dem Pool und 150 MB/s auf dem ZIL.

Windows läuft auch einigermaßen fix, wenn die Transfer-Blocksize mindestens 16K beträgt. Fast unabhängig von ashift und recordsize. Dies testete ich mit weiteren Pools auf dem freien Speicher der NVMe.

Nun gehts erst mal nach Hause. Vielen Dank euch beiden.

 

[dietmar]

Achja, das Dateiformat der VM ist RAW.

Hoffe du verwendest subvolumes für die ZFS disks? Kannst Du bitte die VM config posten?

 

[LnxBil]

Hoffe du verwendest subvolumes für die ZFS disks?

Mist, das hatte ich überlesen. Er hat RAW-Dateien auf dem ZFS liegen. Wahnsinn.

 

[Michl]

@dietmar

root@proxmox:~# cat /etc/pve/qemu-server/102.conf
agent: 1
balloon: 0
bios: ovmf
boot: c
bootdisk: virtio0
cores: 8
cpu: host
cpuunits: 512
efidisk0: vm102:102/vm-102-disk-2.qcow2,size=128K
memory: 32768
name: terminalserver
net0: virtio=5E:33:06:0E:7A:F3,bridge=vmbr2
numa: 0
onboot: 1
ostype: win10
protection: 1
sata0: none,media=cdrom
sata1: none,media=cdrom
scsihw: virtio-scsi-pci
smbios1: uuid=f43409e7-5d87-42ef-8d9d-413ed66bb886
sockets: 1
startup: up=30
usb0: host=064f:0bd8,usb3=1
virtio0: vm102:102/vm-102-disk-1.raw,backup=0,cache=writethrough,size=256G

Mist, das hatte ich überlesen. Er hat RAW-Dateien auf dem ZFS liegen. Wahnsinn.

Wieso? Sorry bin eben ein ZFS-Noob, wenn man das mal so sagen will.
Qcow2 auf ZFS scheint mir doppelt gemoppelt. Ich dachte RAW wäre von der Performance besser?

Mein Wissensstand: Proxmox erstellt, eingebunden als ZFS, pro VM ein ZFS-Volume. Ich hingegen erstelle mit zfs create ein ZFS-Recordset. Von der Datenhaltung, Geschwindigkeit und Sicherheit sollte das identisch sein. Korrekt?



Heute hab ich mit einer Windows 2008 VM (alter Server, ursprünglich bare metal) etwas getestet. Diese ist exakt gleich konfiguriert (ausser nur 4 GB RAM und 2 vCPUs), aber die Benchmarkergebnisse sind wesentlich besser bzw. auf dem Stand, mit dem ich "zufrieden" bin.

Wenn ich diese 2008er VM (ID 200) herunterfahre und die Platte an den Server 2016 (ID 102) hänge, sind die Ergebnisse auch auf diesem Laufwerk wieder schlecht.

für jede VM bin ich so vorgegangen:
- zfs create pool1/vm102
- im Storage als DIR eingebunden (wegen eigenem Backupscript, was mittlerweile um die 1500 Zeilen angewachsen ist, ist mir das so am liebsten)

Wie schon gesagt, die Ergebnisse waren im 2016er Windows anfangs auch gut. Im 2008er Server läufts nach wie vor gut, obwohl da sogar mehr Daten geschoben wurden. Deswegen tippe ich mittlerweile eher auf Windows 2016 bzw. Treiber/Kernel!? Habe natürlich im 2016er den Virenscanner deaktivert und geschaut, dass er im Leerlauf ist.



Was sagen euch eigentlich die pveperf-Werte bzw. FIO?

Was sind die Nachteile bei meinem Aufbau? Wie mach ich's besser? Omg, da steckt nun einiges an Lernaufwand und Trial&Error drin...

Danke.

 

[LnxBil]

Was sind die Nachteile bei meinem Aufbau? Wie mach ich's besser? Omg, da steckt nun einiges an Lernaufwand und Trial&Error drin...

ZFS als Dateisystem kann kein O_DIRECT, ZFS als Blockstorage aber schon, damit hast du bessere Performance, da nicht noch eine Ebene dazwischenhängt. Am Besten immer die Einstellungen verwenden, die PVE dir automatisch vorschlägt, dann das sind bereits die besten Einstellungen. QCOW2 auf ZFS hat nur einen Vorteil und der ist einfacher zwischen Snapshots hin und herspringen - sonst hat es nur Nachteile.

Kannst über das 'Move Disk' Feld deine RAW auch gleich auf "richtiges" ZFS Storage umstellen, dann klappt z.B. auch TRIM automatisch, wenn du es für die VM aktivierst und SCSI mit VirtIO-SCSI Controller verwendest.

Was genau hat dir an den Standard-Dingen wie ZFS-Volumes und PVE-Backup nicht gefallen, dass du alles neu erfinden willst?

 

[Michl]

ZFS on Linux unterstützt doch kein TRIM (?)

tl/dr


Gerade getestet:

- bestehenden Pool in Proxmox als ZFS eingebunden
- neuen Pool mit Standardwerten und ashift=12 auf der NVMe erstellt und eingebunden
- Harddisk in der VM erstellt und getestet mit Virtio Block, SCSI, Discard, IO-Thread, Cache None/Writeback, neuer Pool, alter Pool -> viele Kombinationen...

Die Performance ist leider genauso schlecht. Egal wie. Nochmal zur Erinnerung (leider erst nach meinem ersten Post bemerkt, sonst hätte ich wahrscheinlich diesen Thread nicht gestartet), betroffen ist nur Windows 2016, welches aber anfangs zufriedenstellende Werte lieferte.

Das alles hatte ich zuvor auf dem Testserver schon X mal durch. Wochenlanges gebenchmarke...

QCOW2 auf ZFS hat nur einen Vorteil und der ist einfacher zwischen Snapshots hin und herspringen - sonst hat es nur Nachteile

Wieso sagst du dann "Wahnsinn"?


Warum ich nicht Proxmox' Vorgaben verwende? Ich hatte die Ehre mir eine Firma ansehen zu dürfen, wo ZFS genau so eingerichtet ist. Und das bei mehr als 3000 VMs auf geschätzten 150 Hosts. Also schon etwas größere Umgebung. Mir wurden sehr viele Vor- und Nachteile diverser Konfigurationen mit auf den Weg gegeben. Da ich zuvor nie etwas mit KVM, Proxmox und ZFS zu tun hatte, und nur selten mit Linux, waren die ersten Gehversuche sowieso relativ hart und eigentlich hatte ich eh viel zu viel Input. Eingearbeitet hab ich mich gleichzeitig in shell und GUI.

Also weiterhin viel gelesen und ausprobiert. ZFS als "ZFS" eingebunden und weitere Tests gefahren. Die Leistung war mit meiner, ganz oben genannten, Konfig am besten. Wollte einen bestehenden Server mit der Proxmox GUI clonen. Nach 20 Minuten Laufdauer dann der Klick auf abbrechen... Ich dachte es wird ein "zfs clone" ausgeführt. Anscheinend wurde aber im Hintergrund ein neues ZVOL erstellt und die Daten dupliziert. Dafür reichte der Speicher auf dem Pool nicht. Die GUI reagierte zwar auf das Abbrechen, allerdings lief der Pool unbeirrt voll, auch der Prozess ließ sich nicht abschießen, und dann stürzte irgendwann das komplette System ab.

Auf der Console mit vi und zfs, hab ich nen Server in weniger als 1 Minute geklont, wenn es denn sein muss.

Weitere Tests dann mit Proxmox 5.0, installiert auf ZFS. Dann eine VM erstellt und mir gedacht, was würde passieren, wenn ich Proxmox aus irgendeinem Grund neu installieren muss. Kurzerhand einfach drüberinstalliert und der rpool war wieder leer.

Und weiter mit dem Backup... Für eine Offsite-Replikation auf eine NAS, ist das DSL vor Ort viel zu langsam. USB-Platten lagen aber sowieso in Mengen herum. Um Geld zu sparen, wollte ich diese benutzen. Leider funktionierte das automatische Mounten/Unmounten nicht, weil PVE alle paar Sekunden auf den Datenträger schreibt, sobald er in der GUI eingebunden ist. Irgendwann bin ich nicht mehr weiter gekommen und die Nachteile überwiegen (für mich).

Also musste was eigenes her. Mein script besteht mittlerweile aus einigen Teilen, zusammengesetzt etwa 1500 Zeilen. Es schaut sich stündlich die Hinterlassenschaften von zfs-auto-snapshot an, vergleicht die Snapshots mit dem Zieldatenträger, entscheidet ob inkrementell gesendet werden kann... Macht Vollbackups nur Nachts, verwaltet den Speicher, löscht Backup-Datensätze wenn nötig... gleicht die Menge der Datensätze verschiedener VMs an, sendet Mails zu bestimmten Intervallen oder wenn irgendwelche Fehler auftreten. Erkennt seine eigene Laufzeit und passt das Mailverhalten an... Puuh... führt fsfreeze aus und mailt auch hier über eventuelle Fehler... Löscht snapshots im Pool falls der Speicher voll rennt, und dafür kann man eine Hysterese definieren... ach und noch einiges mehr. Ich möchte das eigentlich nicht mehr missen.

Ansonsten ist Proxmox eine wirklich gute Software. Ich bin mir auch sicher, dass es für all meine Probleme auch "Werkslösungen" gibt, oder andere Leute diese Probleme schlicht und einfach nicht haben.

Größere Tests bzw. Änderungen werde ich wohl auf nächstes Jahr verschieben müssen.

Es läuft ja... irgendwie.
Danke.

 

[LnxBil]

Danke für die Ausführlichen Informationen.

ZFS on Linux unterstützt doch kein TRIM (?)

Daher ja in der VM, da dann entsprechend die freien Blöcke auch wieder freigemacht werden. Über RAW geht das nicht, nur über ZVOL (unter ZFS)

Wieso sagst du dann "Wahnsinn"?

Du hattest geschrieben, dass du RAW verwendest, nicht QCOW2 - weil es langsamer ist als ZVOL (mehr Software dazwischen) und du dich wegen Performanceproblemen hast. Zusätzlich kannst du kein TRIM in der VM verwenden, was auch nochmal einiges an Features kostet.

ZVOL hat auch eine andere Blockgröße als "normales" ZFS, was auch nochmal einiges ausmacht wenn man bedenkt, dass man dadurch ggf. Write-Amplification bekommt.

Auf der Console mit vi und zfs, hab ich nen Server in weniger als 1 Minute geklont, wenn es denn sein muss.

Ja, das ist auch normal. Die (PVE) Idee dahinter ist, dass du entweder ein Basisimage verwendest, von dem du einen Klon machst, oder aber einen 1:1-Klon erstellst, da du für einen ZFS-Klon immer einen Snapshot brauchst, den du dann auch nie wieder löschen kannst auf der Quelle - ist ein Nachteil der ZFS Snapshot-Methodik. Das Problem liegt hier in der Art, wie CoW in ZFS implementiert ist. Du hast CoW immer nur innerhalb einer Enität (ZFS Dateisystem oder ZVOL) und nicht übergreifend - es sei denn du schaltest Dedup ein, was dann aber nochmal andere Tore zur Hölle öffnet.

Und weiter mit dem Backup... Für eine Offsite-Replikation auf eine NAS, ist das DSL vor Ort viel zu langsam. USB-Platten lagen aber sowieso in Mengen herum. Um Geld zu sparen, wollte ich diese benutzen. Leider funktionierte das automatische Mounten/Unmounten nicht, weil PVE alle paar Sekunden auf den Datenträger schreibt, sobald er in der GUI eingebunden ist. Irgendwann bin ich nicht mehr weiter gekommen und die Nachteile überwiegen (für mich).

Also musste was eigenes her. Mein script besteht mittlerweile aus einigen Teilen, zusammengesetzt etwa 1500 Zeilen. Es schaut sich stündlich die Hinterlassenschaften von zfs-auto-snapshot an, vergleicht die Snapshots mit dem Zieldatenträger, entscheidet ob inkrementell gesendet werden kann... Macht Vollbackups nur Nachts, verwaltet den Speicher, löscht Backup-Datensätze wenn nötig... gleicht die Menge der Datensätze verschiedener VMs an, sendet Mails zu bestimmten Intervallen oder wenn irgendwelche Fehler auftreten. Erkennt seine eigene Laufzeit und passt das Mailverhalten an... Puuh... führt fsfreeze aus und mailt auch hier über eventuelle Fehler... Löscht snapshots im Pool falls der Speicher voll rennt, und dafür kann man eine Hysterese definieren... ach und noch einiges mehr. Ich möchte das eigentlich nicht mehr missen.

Nett! Sowas (vom Prinzip her) Ähnliches haben wir auch, aber auf Basis der PVE-Backups und nachgelagert, da dort gleich die Konfiguration mit dabei ist. Wir laden das in ZFS rein (Quelle ist kein ZFS) und haben dann send/receive usw. verfügbar. Rein nur die Snapshots des ZFS zu sichern ist ja kein vollständiges Backup, da die Konfiguration fehlt.

 

[Michl]

Daher ja in der VM, da dann entsprechend die freien Blöcke auch wieder freigemacht werden. Über RAW geht das nicht, nur über ZVOL (unter ZFS)

OK, das leuchtet ein.

Du hattest geschrieben, dass du RAW verwendest, nicht QCOW2 - weil es langsamer ist als ZVOL (mehr Software dazwischen) und du dich wegen Performanceproblemen hast. Zusätzlich kannst du kein TRIM in der VM verwenden, was auch nochmal einiges an Features kostet.

ZVOL hat auch eine andere Blockgröße als "normales" ZFS, was auch nochmal einiges ausmacht wenn man bedenkt, dass man dadurch ggf. Write-Amplification bekommt.

Von dieser Performance merke ich aber nichts. Was mache ich falsch?
- zpool create pool1 mirror /dev/disk/by-id/xxx /dev/disk/by-id/xxx mirror /dev/disk/by-id/xxx /dev/disk/by-id/xxx -o ashift=13 (oder 12, macht keinen Unterschied)
Jeder von euch erwähnte subvols: fehlt an dieser Stelle etwas? Oder meint ihr diese, die Proxmox automatisch beim erstellen der Disk anlegt?
- pool1 als "ZFS" in Storage eingebunden
- VM-Disk auf pool1 erstellt (VirtIO Block) (ebenso eine mit SCSI und aktiviertem discard)

Ja, das ist auch normal. Die (PVE) Idee dahinter ist, dass du entweder ein Basisimage verwendest, von dem du einen Klon machst, oder aber einen 1:1-Klon erstellst, da du für einen ZFS-Klon immer einen Snapshot brauchst, den du dann auch nie wieder löschen kannst auf der Quelle - ist ein Nachteil der ZFS Snapshot-Methodik. Das Problem liegt hier in der Art, wie CoW in ZFS implementiert ist. Du hast CoW immer nur innerhalb einer Enität (ZFS Dateisystem oder ZVOL) und nicht übergreifend - es sei denn du schaltest Dedup ein, was dann aber nochmal andere Tore zur Hölle öffnet.

Dachte ich mir schon. Meine Idee bei meiner Variante ist, dass ich schnell mal was klonen kann und danach wieder verwerfen, wenn fertig.
Kann ich denn diese, von Proxmox erstellten volumes, genauso auf der Konsole klonen oder gibts da Probleme?

Bei meiner Methode sehe ich die "storages" bei mount und konnte diese auch immer mit "zfs mount" remounten. Zur Not vorher kurz aus der storage.cfg herausnehmen und rm -r auf das Verzeichnis im Pool. Oder overlay aktivieren...

Bei oben genannter Methode wird z.b. ein zd0 erstellt und die VM-Dateien liegen unter /dev/zvol/pool1. Ich verstehe einfach nicht was da im Hintergrund passiert und wie das ich im Ernstfall schnell wieder anbinden kann.

Ok, habe eben zwischendurch einfach mal folgendes gemacht:
zfs snap pool1/vm-102-disk-1@test
zfs clone pool1/vm-102-disk-1@test pool1/test

Jetzt habe ich so etwas:

zd0                230:0    0    32G  0 disk
zd16               230:16   0    32G  0 disk
├─zd16p1           230:17   0   128M  0 part
└─zd16p2           230:18   0  31.9G  0 part

Wieso auf einmal p1 und p2? Wie gesagt, erscheint mir rätselhalft. Deswegen scheue ich mich davor. Oder mache ich mir unnötige Gedanken darüber?

Nett! Sowas (vom Prinzip her) Ähnliches haben wir auch, aber auf Basis der PVE-Backups und nachgelagert, da dort gleich die Konfiguration mit dabei ist. Wir laden das in ZFS rein (Quelle ist kein ZFS) und haben dann send/receive usw. verfügbar. Rein nur die Snapshots des ZFS zu sichern ist ja kein vollständiges Backup, da die Konfiguration fehlt.

Bei der Konfig hab ich es mir relativ leicht gemacht: Wenn Backup fehlerfrei gelaufen, dann kopiert er anschließend alle, für mich relevanten, Konfigurationsdateien mit auf die Platte.

Im Worst-Case ist alles schnell wieder am Start...



Vorhin war ich via VPN auf der Kiste während etwa 10 Leute darauf angemeldet waren. Irgendwie ist die CPU-Last extrem hoch. Auf der Windows 2008-VM war das vor der Datenübernahme auch, bis ich den traceflag im SQL 2005 setzte.
Wie soll ich es am besten beschreiben? Im Taskmanager unter Details sieht man für alle Nutzer eine (selbst zusammenaddierte) Last von etwa 5%, jedoch im Leiter Leistung zeigt er kontinuierlich mehr als 30% an. Sobald etwas mehr damit gearbeitet wird, ist die Last bei mehr als 80%. Das ist laut meiner Erfahrung mit den Anwendungen viel, viel zu hoch.
Wegen einem Zeitproblem, hatte ich vor einiger Zeit bcdedit /set {default} useplatformclock true ausgeführt. Hat das eventuell damit zu tun?
https://ispire.me/windows-7820082012-causing-high-cpu-loads-on-kvm/

atop meldet etwa 200K context swtiches. Erscheint mir auch viel zu viel.

Mein Problem bei der ganzen Geschichte ist, der Server lief eigentlich schon mal von der Performance ganz gut. Allerdings war das, wie schon erwähnt, vor 5.1 und dann auch nicht lange. Und da dies mein erstes KVM-Produktivsystem ist, habe ich keine Referenz. Kurz darauf gings mit den Bluescreens wegen dem letzten PVE-Kernel los und somit wieder die Testerei. Ich weiss garnicht mehr, obs eventuell noch irgend einen Wert im BIOS gibt, den ich eventuell verstellt habe.


Vielen Dank für deine Geduld.

 

[Michl]

Auf dem System wird noch gearbeitet, jedoch konnte ich eben kurz rebooten.

Veränderungen:
- bcdedit /set {default} useplatformclock false
- 8 vCPUs auf 6 reduziert (die Host CPU hat 8 HT Cores)

Jetzt ist anscheinend der Overhead weg. Hat mein Problem damit überhaupt etwas zu tun, oder ist es wieder die reine Willkür des Systems? Mal sehen, wenn wieder mehr Benutzer drauf sind. Auch die Leistung ist etwas besser:


Server 2016, ZVOL auf bestehendem pool1 mit ashift=13, compression=lz4, sync=always, SCSI VirtIO



Server 2016, ZFS DIR auf bestehendem pool1 mit ashift=13, compression=lz4, sync=always, VirtIO Block



Server 2008, ZFS DIR auf bestehendem pool1 mit ashift=13, compression=lz4, sync=always, VirtIO Block
Damit könnte ich leben. Ob das gut oder schlecht ist für ein striped mirror pool aus consumer SSDs, weiß ich nicht. Die Ergebnisse sind natürlich reproduzierbar.

Der 2016er Server läuft ja nun anscheinend auch wieder etwas besser als die knapp 30 MB 4K Q32 read.
Anmerkung: Ich mag Windows 2016 überhaupt nicht. So etwas halbgares hab ich lange nicht gesehen. Bin sowieso kurz davor die Lizenzen zu verkaufen und auf 2012 downzugraden.

 

[Michl]

useplatformclock war das Problem.
Sorry, aber da war so vieles zwischendrin passiert, dass ich keinen Zusammenhang sah.

Warum ich ein zfs vol nicht mounten kann, ist mir nun auch klar
In den nächsten Tagen kommt ein neuer Server mit fast der gleichen Hardware. Da es etwas Zeit hat, bis der laufen muss, kann ich darauf in Ruhe ZVOLs testen.

Warum aber mit ZVOLs die Performance besser sein soll, aber nicht wird, ist mir immer noch ein Rätsel.
Letztenendes hab ich wieder was gelernt (bzw. ich weiss was ich noch lernen muss) und die Kiste läuft wieder.

Ich markiere den Thread als gelöst. Danke für die Mühen.

 

[fabian]

useplatformclock war das Problem.
Sorry, aber da war so vieles zwischendrin passiert, dass ich keinen Zusammenhang sah.

Warum ich ein zfs vol nicht mounten kann, ist mir nun auch klar
In den nächsten Tagen kommt ein neuer Server mit fast der gleichen Hardware. Da es etwas Zeit hat, bis der laufen muss, kann ich darauf in Ruhe ZVOLs testen.

Warum aber mit ZVOLs die Performance besser sein soll, aber nicht wird, ist mir immer noch ein Rätsel.
Letztenendes hab ich wieder was gelernt (bzw. ich weiss was ich noch lernen muss) und die Kiste läuft wieder.

Ich markiere den Thread als gelöst. Danke für die Mühen.

zvols sind nur der volume teil vom ZFS mit einem kleinen wrapper um direkt als block device ansprechbar zu sein, ohne den file system layer. weniger layer -> weniger overhead -> bessere performance zumindest in der theorie. in der praxis ist der gewinn leider (noch) nicht so groß wie er sein könnte, weil der block device wrapper (der großteils Linux spezifisch ist) weniger optimiert ist als der file system layer (der mit den anderen Open-ZFS varianten großteils gemeinsam ist).

ist in etwa vergleichbar mit raw/qcow2 auf einem ext4 formattierten logical volume, statt direkt logical volumes zu verwenden. nur dass die logical volumes weniger können als ZFS

 

[Michl]

Besten Dank.

 

[Michl]

Guten Morgen.

Ich muss den Thread nochmal aufgreifen. Mit den ZVOLs komme ich nun gut klar. Mir war wichtig, dass ich einen älteren ZFS-Snapshot klonen und an eine laufende VM anhängen kann. Und dass die Scripte funktionieren...

Neuer Server zum Testen:
Xeon E5-1620v4, 64GM RAM
Supermicro X10SRi, onboard SATA
SM Gehäuse mit Backplane
SSDs ebenfalls 850 Pro und Intel 750 für ZIL

Allerdings hapert es nun mit der Schreib- statt Lesegeschwindigkeit

ZVOL: mit sync=disabled: 500+ MB/s write
ZVOL: mit sync=always: 90 MB/s write

jedoch:
ZFS Dataset als DIR: mit sync=always: 700+ MB/s write

Bisher bestes Ergebnis mit SCSI Virtio, Cache writeback oder none.
Discard macht keinen Unterschied.

Das wäre dann das Achtfache! An den Platten kanns wohl nicht liegen, sonst würde es ja als DATASET auch nicht funktionieren.
Aber an was dann?

 

[LnxBil]

Ich würde auf die volblocksize tippen. Spiele damit mal etwas rum.

Wie testest du eigentlich in der VM oder von außerhalb?

 

[Michl]

Wie kann ich diese denn anpassen? In der GUI ist's ausgegraut und ZFS sagt readonly. Sind 8K...

Ich teste in verschiedenen Windows VMs, denn da muss es auch funktionieren. Anscheinend ist der Flaschenhals wohl die Intel NVMe. Dabei soll die doch eine gute Latenz haben?!

Mit sync=standard läufts etwas besser. Wie sicher ist denn überhaupt welche Einstellung? Derzeit verwende ich sync=always und Cache writethrough.

Die Anwendung nutzt SQL und Dateien. Mache mir sorgen, falls mal was abschmiert, dass es inkonsistent wird.

 

[LnxBil]

Wie kann ich diese denn anpassen? In der GUI ist's ausgegraut und ZFS sagt readonly. Sind 8K...

Du musst von Hand ein neues Volume anlegen mit einer entsprechenden Blockgröße (Parameter -b), d.h. wie folgt vorgehen:

Angenommen du hast rpool/vm-100-disk-1 und willst ein paar andere probieren:

root@proxmox:~# zfs list -o name,volsize,used,refer,volblocksize harddisk/data/vm-100-disk-1
NAME                         VOLSIZE   USED  REFER  VOLBLOCK
harddisk/data/vm-100-disk-1       4G    12K    12K      128K

root@proxmox:~# zfs create -s -b 64K -V 4G harddisk/data/vm-100-disk-2
root@proxmox:~# zfs create -s -b 32K -V 4G harddisk/data/vm-100-disk-3
root@proxmox:~# zfs create -s -b 16K -V 4G harddisk/data/vm-100-disk-4
root@proxmox:~# zfs create -s -b 8K -V 4G harddisk/data/vm-100-disk-5
root@proxmox:~# zfs create -s -b 4K -V 4G harddisk/data/vm-100-disk-6

root@proxmox:~# zfs list -r -o name,volsize,used,refer,volblocksize harddisk/data | grep -Ee '(vm-100-|^NAME)'
NAME                                  VOLSIZE   USED  REFER  VOLBLOCK
harddisk/data/vm-100-disk-1                4G    12K    12K      128K
harddisk/data/vm-100-disk-2                4G    12K    12K       64K
harddisk/data/vm-100-disk-3                4G    12K    12K       32K
harddisk/data/vm-100-disk-4                4G    12K    12K       16K
harddisk/data/vm-100-disk-5                4G    12K    12K        8K
harddisk/data/vm-100-disk-6                4G    12K    12K        4K

root@proxmox:~# for i in $(seq 2 6); do dd if=/dev/zvol/harddisk/data/vm-100-disk-1 of=/dev/zvol/harddisk/data/vm-100-disk-$i bs=4K; done
[...]

root@proxmox:~# for i in $(seq 2 6); do echo "unused$(($i-2)): harddisk:vm-100-disk-$i" >> /etc/pve/qemu-server/100.conf; done

In PVE solltest du dann diese Ansicht bekommen:



Und dann hänge einfach die neuen Volumes anstelle des aktuellen an die VM an (erst entfernen, dann hinzufügen).



Danach booten und testen. Vielleicht siehst du verschiedene Geschwindigkeiten und kannst ein optimales Gerät herausfinden.

Wichtig ist bei Virtualisierung immer, dass die Blockgrößen in der virtuellen Maschine ein Vielfaches (auch 1) der Host-Blockgröße ist und dass der Zugriff aligned ist. Wenn das nicht der Fall ist kommt es zu Write-Amplification und einem geringeren Durchsatz.

 

[Michl]

Wow, vielen Dank.

Hab nun einiges getestet:

SCSI Virtio, no cache, sync=standard
4k 407 MB/s
8k 612 MB/s
16k 728 MB/s
32k 905 MB/s
64k 1085 MB/s

SCSI Virtio, no cache, sync=always
4k 84 MB/s
8k 88 MB/s
16k 91 MB/s
32k 93 MB/s
64k 97 MB/s
VM reagiert nicht beim Schreiben

Virtio Block, no cache, sync=always
4k 83 MB/s
8k 88 MB/s
... wie oben