ZFS Schreiben langsam

[Haithabu84]

Hallo,

ich habe zwar schon einige Themen durchforstet, aber bisher nichts passendes gefunden für mein Problem: Mir ist aufgefallen, dass beim erstellen eines Dumps mit vzdump ohne compress oder irgendetwas die Schreibrate im Vergleich zu einem Node mit ext4 um mehr als die Hälfte langsamer war.

Während ich beim ext4-Node bei der Erstellung eines Dumps als Schreibrate ~235MB/s hatte, war beim ZFS-Node maximal 92MB/s möglich.

Beide Nodes haben die gleiche Hardware-Ausstattung:

Xeon E5-2620 V3
32Gb Ram
2x 1Tb Samsung SM863

Beim ZFS-Node sind die SSDs in einem Mirror und beim ext4 in einem Raid1 mit mdadm.

Woran kann dies liegen? Komprimierung? Wie kann ich am besten den Flaschenhals finden?

Gruß

 

[LnxBil]

Komprimierung?

Könnte ja. Wenn du die Standard PVE Installation gewählt hast, dann wird automatisch das ZFS komprimiert.

Ist deine Aussage

Node mit ext4 um mehr als die Hälfte langsamer war.

auf den Durchsatz oder die Zeit bezogen? Falls ersteres, wie sind die Backupzeiten im Vergleich?

 

[Haithabu84]

Sowohl als auch. Für einen 10Gb Container mit vzdump braucht der ext4-Node maximal 1 Minute und hatte jetzt etwa 160Mb/s, während beim ZFS-Node der selbe Container fast 3 Minuten brauchte und der Durchsatz bei etwa 80MB/s lag.


Ja, habe Standardinstallation verwendet, weil ich root auf ZFS wollte.

 

[Haithabu84]

Wenn ich das richtig verstanden habe, kann man mit...

zfs set compression=off pool

... die Compression ohne Gefahr im laufenden Betrieb abschalten?!

Zumindest wird das hier erwähnt:
https://forum.proxmox.com/threads/disable-zfs-compression.36693/

Da könnte ich das ja bei Gelegenheit mal testen und schauen wie sich die Performance verhält. Denn ich habe ein weiteres Problem: In einem Container habe ich mehrere alte cisam-Datenbanken laufen und bei einigen Abfragen brauch er länger als vorher.

Kann dies ebenfalls an der Compression liegen? Die CPU langweilt sich irgendwie, RAM liegt im normalen Bereich. Im oben geposteten Link wird meist davon gesprochen das die Compression normalerweise keinen spürbaren Performance-Verlust bringt...

Die Container wurden alle aus Backups auf diesen Node migriert, mit:

pct restore 100 vzdump-lxc-100.tar.lzo --rootfs local-zfs:100

 

[LnxBil]

Da könnte ich das ja bei Gelegenheit mal testen und schauen wie sich die Performance verhält.

Statistisch gesehen wird sie schlechter, da normalerweise fast alle Daten mit Ausnahmen von Bild, Audio und Video komprimierbar sind und somit die Datenmenge, die auf die Platten geschrieben wird reduziert wird, was den Durchsatz auf den gesamten Schreibvorgang verbessert.

ZFS ist generell langsamer als ein nicht-ZFS, wenn man ein solch einfaches Setup von 2 Disks annimmt. Die Frage ist immer wieviel langsamer.
Da du ja schon Enterprise SSDs verwendest sollte das schon etwas schneller sein.

Was für eine PVE-Version hast du?

 

[Haithabu84]

Statistisch gesehen wird sie schlechter, da normalerweise fast alle Daten mit Ausnahmen von Bild, Audio und Video komprimierbar sind und somit die Datenmenge, die auf die Platten geschrieben wird reduziert wird, was den Durchsatz auf den gesamten Schreibvorgang verbessert.

ZFS ist generell langsamer als ein nicht-ZFS, wenn man ein solch einfaches Setup von 2 Disks annimmt. Die Frage ist immer wieviel langsamer.
Da du ja schon Enterprise SSDs verwendest sollte das schon etwas schneller sein.

Was für eine PVE-Version hast du?

Das ganz frische und aktuelle 6.0-6.

Beim kopieren mit scp von einem NAS auf diesen Node, hatte ich über 10Gbit NIC auch einen Durchsatz von etwa 450Mb/s. Wobei ich mir da nicht sicher bin ob hier Linux generell über den RAM zwischenspeichert und somit dies nicht wirklich aussagekräftig ist.

Oder ich werde doch mal mit fio und iostat nachsehen müssen.

Das Problem bei der Performance von der Datenbankabfrage konnte ich herausfinden: Die VM hat einfach zu wenig Ressourcen, bei jeder Abfrage sind beide zugewiesene CPUs voll ausgelastet. Ich werde das mal auf 4 hochsetzen und dann erstmal beobachten. Eventuell werde ich mit cpuunits dann zum späteren Zeitpunkt etwas nachjustieren. Derzeit haben alle Container cpuunits=1024, würde ich dann bei dieser auf 2048 hochdrehen.

 

[LnxBil]

Beim kopieren mit scp von einem NAS auf diesen Node, hatte ich über 10Gbit NIC auch einen Durchsatz von etwa 450Mb/s. Wobei ich mir da nicht sicher bin ob hier Linux generell über den RAM zwischenspeichert und somit dies nicht wirklich aussagekräftig ist.

Das ist ja dann schonmal OK.

Oder ich werde doch mal mit fio und iostat nachsehen müssen.

Das ist eh immer eine gute Idee. Schau auch mal wieviel sync IO du hast, das wird oft bei einer Datenbank verwendet.

 

[Haithabu84]

Habe jetzt nochmal mit fio direkt auf den rpool random geschrieben, dass Ergebnis ist etwas enttäuschend:

fio --name=randfile --ioengine=libaio --iodepth=32 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=8 --group_reporting
randfile: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
...
fio-3.12
Starting 8 processes
randfile: Laying out IO file (1 file / 1024MiB)
randfile: Laying out IO file (1 file / 1024MiB)
randfile: Laying out IO file (1 file / 1024MiB)
randfile: Laying out IO file (1 file / 1024MiB)
randfile: Laying out IO file (1 file / 1024MiB)
randfile: Laying out IO file (1 file / 1024MiB)
randfile: Laying out IO file (1 file / 1024MiB)
randfile: Laying out IO file (1 file / 1024MiB)
Jobs: 2 (f=1): [_(2),f(1),_(1),w(1),_(3)][99.5%][w=60.6MiB/s][w=15.5k IOPS][eta 00m:01s]
randfile: (groupid=0, jobs=8): err= 0: pid=5939: Wed Sep  4 21:41:16 2019
  write: IOPS=10.4k, BW=40.6MiB/s (42.5MB/s)(8192MiB/202003msec); 0 zone resets
    slat (usec): min=6, max=642588, avg=762.76, stdev=1589.98
    clat (usec): min=2, max=648677, avg=23820.55, stdev=14546.04
     lat (usec): min=67, max=648783, avg=24584.02, stdev=14915.15
    clat percentiles (usec):
     |  1.00th=[  1827],  5.00th=[  3163], 10.00th=[  6325], 20.00th=[ 11731],
     | 30.00th=[ 16450], 40.00th=[ 21103], 50.00th=[ 25297], 60.00th=[ 28705],
     | 70.00th=[ 31589], 80.00th=[ 34341], 90.00th=[ 38536], 95.00th=[ 40633],
     | 99.00th=[ 44303], 99.50th=[ 47449], 99.90th=[ 68682], 99.95th=[104334],
     | 99.99th=[574620]
   bw (  KiB/s): min= 1648, max=36544, per=12.48%, avg=5181.32, stdev=3362.58, samples=3217
   iops        : min=  412, max= 9136, avg=1295.30, stdev=840.64, samples=3217
  lat (usec)   : 4=0.01%, 10=0.01%, 100=0.01%, 250=0.01%, 500=0.01%
  lat (usec)   : 750=0.01%, 1000=0.02%
  lat (msec)   : 2=1.49%, 4=5.06%, 10=9.86%, 20=21.17%, 50=62.02%
  lat (msec)   : 100=0.30%, 250=0.03%, 500=0.01%, 750=0.02%
  cpu          : usr=0.71%, sys=8.77%, ctx=1910803, majf=7, minf=133
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.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.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,2097152,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=40.6MiB/s (42.5MB/s), 40.6MiB/s-40.6MiB/s (42.5MB/s-42.5MB/s), io=8192MiB (8590MB), run=202003-202003msec

Das kann doch nicht alles sein? Gut, vielleicht erwarte ich auch zuviel bei 8x1Gb Files... kann jemand diese Werte bestätigen oder habe ich hier ein Perfomance-Problem?

 

[LnxBil]

Das kann doch nicht alles sein? Gut, vielleicht erwarte ich auch zuviel bei 8x1Gb Files... kann jemand diese Werte bestätigen oder habe ich hier ein Perfomance-Problem?

Teste mal auf einem zvol, das sollte eher der Performance einer VM entsprechen.

Für weitere Beispiele verweise ich mal auf den letzten Post von mir zu einem ähnlichen Thema.

 

[Haithabu84]

Teste mal auf einem zvol, das sollte eher der Performance einer VM entsprechen.

Das wäre dann aber nicht wirklich hilfreich, da ich ein zvol nur bei einer Qemu-VM zum Einsatz kommt. Bei einem LXc Container werden doch nur Datasets verwendet, oder nicht?

Habe jetzt einfach mal ein Dataset erstellt:

zfs create rpool/data/test

Erst fio mit write:

io --filename=/rpool/data/test/testus --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --runtime=120 --size=1G --time_based --group_reporting --name=journal-test
journal-test: (g=0): rw=write, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.12
Starting 1 process
journal-test: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [W(1)][100.0%][w=9.84MiB/s][w=2518 IOPS][eta 00m:00s]
journal-test: (groupid=0, jobs=1): err= 0: pid=25958: Thu Sep  5 13:55:14 2019
  write: IOPS=2563, BW=10.0MiB/s (10.5MB/s)(1202MiB/120001msec); 0 zone resets
    clat (usec): min=235, max=20752, avg=388.32, stdev=168.71
     lat (usec): min=235, max=20752, avg=388.58, stdev=168.74
    clat percentiles (usec):
     |  1.00th=[  314],  5.00th=[  330], 10.00th=[  334], 20.00th=[  343],
     | 30.00th=[  355], 40.00th=[  363], 50.00th=[  375], 60.00th=[  383],
     | 70.00th=[  396], 80.00th=[  416], 90.00th=[  474], 95.00th=[  502],
     | 99.00th=[  545], 99.50th=[  553], 99.90th=[  586], 99.95th=[  709],
     | 99.99th=[ 2409]
   bw (  KiB/s): min= 8528, max=11992, per=99.98%, avg=10252.11, stdev=644.11, samples=239
   iops        : min= 2132, max= 2998, avg=2563.01, stdev=161.03, samples=239
  lat (usec)   : 250=0.01%, 500=94.61%, 750=5.33%, 1000=0.02%
  lat (msec)   : 2=0.02%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%
  cpu          : usr=1.02%, sys=9.37%, ctx=615314, majf=0, minf=10
  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=0,307641,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):
  WRITE: bw=10.0MiB/s (10.5MB/s), 10.0MiB/s-10.0MiB/s (10.5MB/s-10.5MB/s), io=1202MiB (1260MB), run=120001-120001msec

Danach nochmal mit read:

fio --filename=/rpool/data/test/testus --sync=1 --rw=read --bs=4k --numjobs=1 --iodepth=1 --runtime=120 --size=1G --time_based --group_reporting --name=journal-test
journal-test: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [R(1)][100.0%][r=1257MiB/s][r=322k IOPS][eta 00m:00s]
journal-test: (groupid=0, jobs=1): err= 0: pid=9803: Thu Sep  5 13:58:26 2019
  read: IOPS=317k, BW=1238MiB/s (1298MB/s)(145GiB/120001msec)
    clat (nsec): min=1990, max=688829, avg=2932.38, stdev=4310.83
     lat (usec): min=2, max=688, avg= 2.96, stdev= 4.31
    clat percentiles (nsec):
     |  1.00th=[ 2064],  5.00th=[ 2064], 10.00th=[ 2064], 20.00th=[ 2064],
     | 30.00th=[ 2096], 40.00th=[ 2096], 50.00th=[ 2096], 60.00th=[ 2096],
     | 70.00th=[ 2128], 80.00th=[ 2288], 90.00th=[ 2416], 95.00th=[ 2576],
     | 99.00th=[26496], 99.50th=[27520], 99.90th=[30080], 99.95th=[32384],
     | 99.99th=[46336]
   bw (  MiB/s): min= 1081, max= 1303, per=99.98%, avg=1237.86, stdev=23.00, samples=239
   iops        : min=276812, max=333644, avg=316892.29, stdev=5886.78, samples=239
  lat (usec)   : 2=0.01%, 4=96.67%, 10=0.14%, 20=0.09%, 50=3.09%
  lat (usec)   : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%
  cpu          : usr=20.01%, sys=79.97%, ctx=848, majf=0, minf=10
  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=38034713,0,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=1238MiB/s (1298MB/s), 1238MiB/s-1238MiB/s (1298MB/s-1298MB/s), io=145GiB (156GB), run=120001-120001msec

Dasselbe nochmal mit randwrite:

fio --filename=/rpool/data/test/testus --sync=1 --rw=randwrite --bs=4k --numjobs=1 --iodepth=1 --runtime=120 --size=1G --time_based --group_reporting --name=journal-test
journal-test: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][w=9533KiB/s][w=2383 IOPS][eta 00m:00s]
journal-test: (groupid=0, jobs=1): err= 0: pid=17121: Thu Sep  5 14:01:25 2019
  write: IOPS=2298, BW=9194KiB/s (9415kB/s)(1077MiB/120001msec); 0 zone resets
    clat (usec): min=241, max=30338, avg=432.77, stdev=287.62
     lat (usec): min=241, max=30338, avg=433.08, stdev=287.65
    clat percentiles (usec):
     |  1.00th=[  326],  5.00th=[  338], 10.00th=[  343], 20.00th=[  359],
     | 30.00th=[  371], 40.00th=[  383], 50.00th=[  396], 60.00th=[  408],
     | 70.00th=[  441], 80.00th=[  482], 90.00th=[  523], 95.00th=[  553],
     | 99.00th=[ 1336], 99.50th=[ 1598], 99.90th=[ 2474], 99.95th=[ 3359],
     | 99.99th=[16450]
   bw (  KiB/s): min= 5560, max=11376, per=99.98%, avg=9192.06, stdev=1237.80, samples=239
   iops        : min= 1390, max= 2844, avg=2298.00, stdev=309.45, samples=239
  lat (usec)   : 250=0.01%, 500=85.26%, 750=13.29%, 1000=0.08%
  lat (msec)   : 2=1.15%, 4=0.17%, 10=0.02%, 20=0.01%, 50=0.01%
  cpu          : usr=1.01%, sys=12.84%, ctx=552955, majf=0, minf=9
  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=0,275832,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):
  WRITE: bw=9194KiB/s (9415kB/s), 9194KiB/s-9194KiB/s (9415kB/s-9415kB/s), io=1077MiB (1130MB), run=120001-120001msec

Als letztes dann nochmal mit randwrite ohne sync:

fio --name=/rpool/data/test/randfile --ioengine=libaio --iodepth=32 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=1 --group_reporting
/rpool/data/test/randfile: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.12
Starting 1 process
/rpool/data/test/randfile: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [w(1)][100.0%][w=143MiB/s][w=36.7k IOPS][eta 00m:00s]
/rpool/data/test/randfile: (groupid=0, jobs=1): err= 0: pid=28555: Thu Sep  5 14:03:01 2019
  write: IOPS=49.3k, BW=193MiB/s (202MB/s)(1024MiB/5312msec); 0 zone resets
    slat (usec): min=5, max=104127, avg=18.59, stdev=451.38
    clat (nsec): min=1854, max=105420k, avg=628986.43, stdev=2591309.26
     lat (usec): min=9, max=105432, avg=647.71, stdev=2634.70
    clat percentiles (usec):
     |  1.00th=[   273],  5.00th=[   285], 10.00th=[   289], 20.00th=[   302],
     | 30.00th=[   314], 40.00th=[   334], 50.00th=[   359], 60.00th=[   408],
     | 70.00th=[   498], 80.00th=[   685], 90.00th=[  1012], 95.00th=[  1369],
     | 99.00th=[  3326], 99.50th=[  5211], 99.90th=[ 13042], 99.95th=[101188],
     | 99.99th=[105382]
   bw (  KiB/s): min=35216, max=317072, per=93.23%, avg=184042.40, stdev=83970.31, samples=10
   iops        : min= 8804, max=79268, avg=46010.40, stdev=20992.39, samples=10
  lat (usec)   : 2=0.01%, 20=0.01%, 50=0.01%, 100=0.01%, 250=0.05%
  lat (usec)   : 500=70.08%, 750=12.31%, 1000=7.28%
  lat (msec)   : 2=8.17%, 4=1.33%, 10=0.62%, 20=0.09%, 250=0.06%
  cpu          : usr=8.92%, sys=67.78%, ctx=10759, majf=0, minf=10
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.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.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=193MiB/s (202MB/s), 193MiB/s-193MiB/s (202MB/s-202MB/s), io=1024MiB (1074MB), run=5312-5312msec

Bei allen Durchläufen war Basis eine einzige 1Gb-Datei die direkt auf dem Dataset Test lag. Was mir bis jetzt ebenfalls aufgefallen ist: Der ARC ist im Routine-Betrieb immer bis Anschlag gefüllt, er greift sich die vollen 50% wie im default gegeben... muss das so?

Also Read ist in dem Bereich, in dem ich es erwarte... besser gesagt übertrifft es sogar meine Erwartungen. Aber Write mit sync ist total lahm, genauso wie randwrite. Im Endeffekt nehmen sich diese beiden Ergebnisse kaum etwas. Ohne Sync geht das schon eher in die Richtung die ich erwarte, aber mit dem Nachteil, dass eben bei bspw. Stromausfall ein Teil der Daten weg ist.

 

[LnxBil]

Das wäre dann aber nicht wirklich hilfreich, da ich ein zvol nur bei einer Qemu-VM zum Einsatz kommt. Bei einem LXc Container werden doch nur Datasets verwendet, oder nicht?

Da hast du natürlich recht. Ja, dann hat es schon Sinn ergeben das als Datei zu testen.

Was mir bis jetzt ebenfalls aufgefallen ist: Der ARC ist im Routine-Betrieb immer bis Anschlag gefüllt, er greift sich die vollen 50% wie im default gegeben... muss das so?

Das ist Standard. Es ist dir überlassen ob du das willst. ZFS wird - wie jedes Dateisystem - schneller mit mehr RAM.

Ohne Sync geht das schon eher in die Richtung die ich erwarte, aber mit dem Nachteil, dass eben bei bspw. Stromausfall ein Teil der Daten weg ist.

Genau. Im SYNC-Fall wäre ein dediziertes Enterprise-SSD-basiertes SLOG-Gerät vorteilhaft. Stromausfall kannst du nur durch USV kompensieren - oder durch einen Batteriegepufferten RAID-Controller, der aber wegen ZFS eher ausscheidet. Auch ist eine Einstiegs USV billiger als ein toller RAID-Controller.

 

[Haithabu84]

So toll ich ZFS und dessen Features finde, bin ich etwas von der Performance eines ZFS Mirrors enttäuscht. Aber scheinbar gibt es da gar nicht mehr Möglichkeiten, außer man rüstet mit Hardware auf:

• SLOG vor die SSDs, sowas wie Intel Optane oder eine M.2
• Mehr Arbeitsspeicher
• Raid-Z mit mehr Platten/SSDs

Sehe ich das richtig?

Sync will ich trotz USV und redundanter Netzteile, lieber anlassen. Vor allem den USV-System traue ich keinen Meter. Zu oft erlebt, teure USV von bekannten Hersteller gekauft und trotz regelmäßiger Wartung, reißt das Teil eines Tages alles mitsich... Kurzschluss. Mehrere angeschlossene Netzteile dahinter verbruzzelt. Wegen dem WriteOnDisk und Sync bin eigentlich zu ZFS gewechselt...

Ursprünglich bin ich eher ein Fan von Ceph, aber da mein Budget dies leider nicht hergibt => ZFS

Gerade auch nochmal auf einen File-Server LXC Container per SMB eine 1Gb-Datei hochgeladen, bestätigt auch das Ergebnis des vzdump, durchschnittlich 82MB/s. Eigenartig aber schon, dass ich mit scp teilweise an den 500MB/s gekratzt habe.

 

[LnxBil]

Raid-Z mit mehr Platten/SSDs

Generell mehr vdevs. Das gibt die Performance (also striping), nicht die Anzahl innerhalb eines vdevs.

Vor allem den USV-System traue ich keinen Meter. Zu oft erlebt, teure USV von bekannten Hersteller gekauft und trotz regelmäßiger Wartung, reißt das Teil eines Tages alles mitsich... Kurzschluss. Mehrere angeschlossene Netzteile dahinter verbruzzelt.

Wir haben hier pro Netzteilstrang eine USV, d.h. im Schrank eine USV für "links" und eine für "rechts", sodass wir immer den Ausfalle einer USV verkraften können.

Gerade auch nochmal auf einen File-Server LXC Container per SMB eine 1Gb-Datei hochgeladen, bestätigt auch das Ergebnis des vzdump, durchschnittlich 82MB/s. Eigenartig aber schon, dass ich mit scp teilweise an den 500MB/s gekratzt hab

Da muss was falsch laufen. Ich hab einen 10 Jahre alten IBM T60 Laptop als Server daheim rumstehen mit zwei 500 GB SATA Platten und ich kopiere dort via Samba mit 90-110 MB/sec hoch inkl. eingeschalteter Komprimierung ... also das, was die Leitung mit 1 GBE hergibt. Die Maschine hat nur 4 GB-RAM und da laufen noch einige LX(C) container.

Mal abgesehen, dass ich bei etwas größeren Systemen immer locker im 3-stelligen MB/sec Bereich arbeite auf das auf FESTPLATTEN mit ZFS.

Deduplizierung hattest du nicht - auch nur für eine Sekunde - eingeschaltet auf dem Pool? Kannst du mal noch ein zpool status -v absetzen?

Generell würde ich jetzt an den Support verweisen und ihn fragen ob er noch was weiß. Sonst gibt es noch einige fähige ZFSler hier im Forum, aber das sind alles nicht-deutsch-Muttersprachler.

 

[Haithabu84]

Da muss was falsch laufen. Ich hab einen 10 Jahre alten IBM T60 Laptop als Server daheim rumstehen mit zwei 500 GB SATA Platten und ich kopiere dort via Samba mit 90-110 MB/sec hoch inkl. eingeschalteter Komprimierung ... also das, was die Leitung mit 1 GBE hergibt. Die Maschine hat nur 4 GB-RAM und da laufen noch einige LX(C) container.

Mal abgesehen, dass ich bei etwas größeren Systemen immer locker im 3-stelligen MB/sec Bereich arbeite auf das auf FESTPLATTEN mit ZFS.

Deduplizierung hattest du nicht - auch nur für eine Sekunde - eingeschaltet auf dem Pool? Kannst du mal noch ein zpool status -v absetzen?

Ja, dann kann ja irgendwas nicht stimmen.

Ich wüsste nicht wann ich Deduplizierung angehabt haben sollte, ansonsten ist der Pool mit den vorgegebenen Standardwerten von Proxmox installiert worden. ashift=12, Compression=on, usw. usf.

Hier zpool status:

zpool status -v
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 0 days 00:00:03 with 0 errors on Tue Aug 20 13:47:23 2019
config:

        NAME                                                      STATE     READ WRITE CKSUM
        rpool                                                     ONLINE       0     0     0
          mirror-0                                                ONLINE       0     0     0
            ata-SAMSUNG_sda-part3                                 ONLINE       0     0     0
            ata-SAMSUNG_sdb-part3                                 ONLINE       0     0     0

errors: No known data errors

Ich habe nur die Seriennummern der beiden SSD entfernt. Dann habe ich mit atop auch nochmal geschaut, wie sehr die Platten ausgelastet sind... liegen aber bei 0% die meiste Zeit.

Dann habe ich mal noch pveperf entdeckt:

pveperf
CPU BOGOMIPS:      57595.56
REGEX/SECOND:      3123298
HD SIZE:           760.00 GB (rpool/ROOT/pve-1)
FSYNCS/SECOND:     2071.76
DNS EXT:           50.04 ms
DNS INT:           35.46 ms

Verglichen mit meinem LVM-Node ist er um 40% bessere Fsync/second.

 

[Haithabu84]

Kann Verschlüsselung das Problem sein?

zpool get feature@encryption
NAME   PROPERTY            VALUE               SOURCE
rpool  feature@encryption  enabled             local

Kann man die zu Testzwecken einfach mal deaktivieren, ohne das Daten verloren gehen? Oder muss der Pool neuangelegt werden?

Aber irgendwie auch verwirrend:

zfs get encryption
NAME                          PROPERTY    VALUE        SOURCE
rpool                         encryption  off          default
rpool/ROOT                    encryption  off          default
rpool/ROOT/pve-1              encryption  off          default
rpool/data                    encryption  off          default
rpool/data/subvol-100-disk-0  encryption  off          default
rpool/data/subvol-101-disk-0  encryption  off          default
rpool/data/test               encryption  off          default

Hier sagt er wiederum das deaktiviert sei...

 

[LnxBil]

Aber irgendwie auch verwirrend:

Das Feature heißt nur, dass du es generell anschalten kannst. Standardmäßig ist es aus.

Mit geeigneter AES-NI Unterstützung deiner CPU sollte die Verschlüsselung keine nennenswerten Leistungseinbußen haben.

Beim ZFS-Node sind die SSDs in einem Mirror und beim ext4 in einem Raid1 mit mdadm.

War das der gleiche Rechner noch ein baugleicher anderer?

Ich muss aber sagen, dass mir so langsam die Ideen ausgehen, woran das liegen kann.

 

[Haithabu84]

War das der gleiche Rechner noch ein baugleicher anderer?

Sind beides baugleiche Maschinen. Die selben SSDs, selber Prozessor, selbes Mainboard mit HBA, gleich viel RAM. Nur das auf einem das root auf ZFS läuft und beim anderen für pve ein ext4 auf einem lvm liegt.

Ich habe auch schonmal wieder bisschen weitergeforscht... folgendes ist aufgefallen:

smartctl -a /dev/sda
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-5.0.21-1-pve] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Samsung based SSDs
Device Model:     SAMSUNG MZ7KM960HAHP-0E005
Serial Number:    XXX
LU WWN Device Id: 5 002538 c402e7397
Firmware Version: GXM1003Q
User Capacity:    960,197,124,096 bytes [960 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Fri Sep  6 08:16:28 2019 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Kann es sein das ich bei der Einrichtung des Pools eine falsche Sektorgröße verwendet habe? Es gibt da irgendwie widersprüchliche Informationen im Netz und ich hatte nach Best Practice einfach ashift=12 gesetzt...

Ich werde dann gleich mal ein Testsystem aufsetzen, bestehend aus einem 0815-Rechner und mal vergleichen.

 

[Haithabu84]

Ich glaube das ist der Schlüssel zum Erfolg... die Sektorgröße müsste falsch sein.

Das hier zeigt meine tatsächliche physische Sektorgröße:

lsblk -o NAME,MOUNTPOINT,PHY-SEC
NAME   MOUNTPOINT PHY-SEC
sda                   512
├─sda1                512
├─sda2                512
└─sda3                512
sdb                   512
├─sdb1                512
├─sdb2                512
└─sdb3                512

Eingestellt ist aber ashift=12 also 4k, ich bräuchte dann aber ashift=9 für 512... so verstehe ich das zumindest. Ich bin fälschlicherweise bei den Angaben zu den SSDs ausgegangen, dass wenn da steht kann so und soviel 4k-Blöcke schreiben, dass die Sektoren 4k groß sind.

 

[Haithabu84]

Irgendwie ist das alles eine komische Sache. Habe jetzt einen Rechner mit einem i7, 8Gb Ram und 2x Samsung 850 Pro zum Testen verwendet. Die Samsung 850 meldet per lsblk ebenfalls physisch 512er Sektoren.

Mir kommt es so vor als wäre in der Standardinstallation als Option irgendwie eine Limitation gesetzt. Als erstes habe ich ashift=12 ausprobiert und ansonsten alles so gelassen. Hier die Ergebnisse:

fio --name=/rpool/data/randfile --ioengine=libaio --iodepth=32 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=1 --group_reporting
/rpool/data/randfile: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.12
Starting 1 process
Jobs: 1 (f=1): [w(1)][100.0%][w=31.5MiB/s][w=8070 IOPS][eta 00m:00s]
/rpool/data/randfile: (groupid=0, jobs=1): err= 0: pid=21699: Fri Sep  6 12:59:41 2019
  write: IOPS=3450, BW=13.5MiB/s (14.1MB/s)(1024MiB/75978msec); 0 zone resets
    slat (usec): min=5, max=22039, avg=284.83, stdev=108.13
    clat (usec): min=2, max=30267, avg=8986.53, stdev=2408.44
     lat (usec): min=78, max=30535, avg=9271.95, stdev=2484.32
    clat percentiles (usec):
     |  1.00th=[ 1106],  5.00th=[ 2966], 10.00th=[ 5866], 20.00th=[ 7963],
     | 30.00th=[ 8586], 40.00th=[ 8979], 50.00th=[ 9503], 60.00th=[ 9896],
     | 70.00th=[10421], 80.00th=[10814], 90.00th=[11207], 95.00th=[11469],
     | 99.00th=[12256], 99.50th=[13304], 99.90th=[15795], 99.95th=[17433],
     | 99.99th=[30278]
   bw (  KiB/s): min= 9024, max=52008, per=98.06%, avg=13532.63, stdev=4545.20, samples=151
   iops        : min= 2256, max=13002, avg=3383.13, stdev=1136.28, samples=151
  lat (usec)   : 4=0.01%, 100=0.01%, 250=0.01%, 500=0.03%, 750=0.10%
  lat (usec)   : 1000=0.43%
  lat (msec)   : 2=3.16%, 4=2.15%, 10=55.52%, 20=38.59%, 50=0.01%
  cpu          : usr=1.73%, sys=18.12%, ctx=258366, majf=0, minf=10
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.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.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=13.5MiB/s (14.1MB/s), 13.5MiB/s-13.5MiB/s (14.1MB/s-14.1MB/s), io=1024MiB (1074MB), run=75978-75978msec

Im Durchschnitt schonmal 1-2MB/s schneller als der Server mit Enterprise-SSDs... ich lach mich weg. Danach 22Gb Container mit vzdump:

vzdump 121
INFO: starting new backup job: vzdump 121
INFO: filesystem type on dumpdir is 'zfs' -using /var/tmp/vzdumptmp21676 for temporary files
INFO: Starting Backup of VM 121 (lxc)
INFO: Backup started at 2019-09-06 13:18:55
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: CT Name: test.local
INFO: creating archive '/var/lib/vz/dump/vzdump-lxc-121-2019_09_06-13_18_55.tar'
INFO: Total bytes written: 22903879680 (22GiB, 108MiB/s)
INFO: archive file size: 21.33GB
INFO: delete old backup '/var/lib/vz/dump/vzdump-lxc-121-2019_09_06-10_13_06.tar'
INFO: Finished Backup of VM 121 (00:03:22)
INFO: Backup finished at 2019-09-06 13:22:17
INFO: Backup job finished successfully

Hier ebenfalls satte 20MB/s schneller als der Server... das soll mal einer verstehen.

Danach habe ich den Testrechner mit ashift=9 neuinstalliert und den selben Spaß nochmal:

fio --name=/rpool/data/randfile --ioengine=libaio --iodepth=32 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=1 --group_reporting
/rpool/data/randfile: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.12
Starting 1 process
/rpool/data/randfile: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [w(1)][97.4%][w=28.0MiB/s][w=7170 IOPS][eta 00m:01s]
/rpool/data/randfile: (groupid=0, jobs=1): err= 0: pid=2774: Fri Sep  6 13:42:58 2019
  write: IOPS=6934, BW=27.1MiB/s (28.4MB/s)(1024MiB/37805msec); 0 zone resets
    slat (usec): min=5, max=19159, avg=140.41, stdev=140.34
    clat (nsec): min=1887, max=27334k, avg=4471955.06, stdev=2357969.67
     lat (usec): min=51, max=27530, avg=4612.82, stdev=2429.36
    clat percentiles (usec):
     |  1.00th=[  693],  5.00th=[  996], 10.00th=[ 1221], 20.00th=[ 1958],
     | 30.00th=[ 2933], 40.00th=[ 3752], 50.00th=[ 4555], 60.00th=[ 5211],
     | 70.00th=[ 5932], 80.00th=[ 6718], 90.00th=[ 7504], 95.00th=[ 8029],
     | 99.00th=[ 8717], 99.50th=[10421], 99.90th=[13960], 99.95th=[16319],
     | 99.99th=[25035]
   bw (  KiB/s): min=15208, max=89748, per=97.63%, avg=27079.91, stdev=15866.92, samples=75
   iops        : min= 3802, max=22437, avg=6769.95, stdev=3966.74, samples=75
  lat (usec)   : 2=0.01%, 100=0.01%, 250=0.04%, 500=0.46%, 750=0.89%
  lat (usec)   : 1000=3.74%
  lat (msec)   : 2=15.35%, 4=22.43%, 10=56.47%, 20=0.58%, 50=0.04%
  cpu          : usr=2.66%, sys=29.97%, ctx=182408, majf=7, minf=10
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.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.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,262144,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
  WRITE: bw=27.1MiB/s (28.4MB/s), 27.1MiB/s-27.1MiB/s (28.4MB/s-28.4MB/s), io=1024MiB (1074MB), run=37805-37805msec

Hier ist er tatsächlich um fast Faktor 3 schneller also vorher. Fairer Weise muss ich sagen, dass umso öfter ich fio ausführte umso langsamer wurde es... ich geh mal davon aus das der RAM ein nicht ausreichend ist und der ARC nicht flexibel genug befüllt werden kann.

Danach wieder 22Gb Container dumpen:

INFO: starting new backup job: vzdump 121
INFO: filesystem type on dumpdir is 'zfs' -using /var/tmp/vzdumptmp8655 for temporary files
INFO: Starting Backup of VM 121 (lxc)
INFO: Backup started at 2019-09-06 14:00:34
INFO: status = stopped
INFO: backup mode: stop
INFO: ionice priority: 7
INFO: CT Name: test.local
INFO: creating archive '/var/lib/vz/dump/vzdump-lxc-121-2019_09_06-14_00_34.tar'
INFO: Total bytes written: 22906030080 (22GiB, 102MiB/s)
INFO: archive file size: 21.33GB
INFO: delete old backup '/var/lib/vz/dump/vzdump-lxc-121-2019_09_06-10_13_06.tar'
INFO: Finished Backup of VM 121 (00:03:35)
INFO: Backup finished at 2019-09-06 14:04:09
INFO: Backup job finished successfully

Keine Ahnung was ich davon halten soll. Irgendwie stimmt da was vorne und hinten nicht bei Proxmox und ich bin mir nicht sicher ob es sich vielleicht sogar um einen Bug handelt.

 

[Haithabu84]

Ich werde mein Problem nochmal im englischen Teil posten, vielleicht hat da noch jemand einen Einfall. Kann doch nicht sein, dass ein simpler ZFS Mirror so langsam ist. Ich bin etwas ratlos.