ZFS Schreiben langsam

[Haithabu84]

Nächstes Problem: Gerade eben festgestellt, dass in einem meiner Routine-Container, Fragmente von Daten sich ansammeln... sieht nach Daten Korruption aus. Wie zum Teufel ist das nur möglich?

Hatte über zwei Wochen getestet und da war nie ein solches Problem sichtbar. Woher kommt das plötzlich? Komprimierung? Hat ZFS 64bit iNodes standardmäßig aktiv?

 

[LnxBil]

Fragmente von Daten sich ansammeln... sieht nach Daten Korruption aus.

Was genau siehst du da?

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.

Ich hab auch mal bei meinen MZ7WD960HMHP-00003 geschaut und da ist auch von 512 Bytes die Rede. Das ist meistens aber schon falsch, denn oft haben die SSDs intern eine viel höhere Blockgröße von 8 KB bei Enterprise bis zu 1 MB für Consumer-Billigware. Sehr gut zu sehen wenn du ein Byte auf die sonst unbenutze Platte schreibst und dir dann den "total LBAs written" Wert anschaust und siehst wieviel der dann gestiegen ist. Aber allgemein ist das natürlich total schwer zu sehen.

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
...

Ich hab leider kein PVE5, noch 4 und kein DIRECT_IO Support for ZFS, sodass ich hier leider auf einem zvol testen muss. Mein Pool hat auch 4K (ashift=12) und besteht aus 6x MZ7WD960HMHP-00003, die an SATA2 hängen (Server ist so alt, der kann noch kein SATA3) im RAID10 (3 mirrored vdevs):

root@proxmox4 ~ > fio --name=/dev/rpool/testfile --ioengine=libaio --iodepth=32 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=1 --group_reporting
/dev/rpool/testfile: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio-2.16
Starting 1 process
Jobs: 1 (f=1): [w(1)] [100.0% done] [0KB/115.2MB/0KB /s] [0/29.5K/0 iops] [eta 00m:00s]
/dev/rpool/testfile: (groupid=0, jobs=1): err= 0: pid=4930: Sat Sep  7 09:09:40 2019
  write: io=1024.0MB, bw=119837KB/s, iops=29959, runt=  8750msec
    slat (usec): min=3, max=3983, avg= 9.03, stdev=11.81
    clat (usec): min=33, max=57709, avg=1057.42, stdev=3672.02
     lat (usec): min=41, max=57754, avg=1066.45, stdev=3672.79
    clat percentiles (usec):
     |  1.00th=[  175],  5.00th=[  262], 10.00th=[  294], 20.00th=[  318],
     | 30.00th=[  326], 40.00th=[  334], 50.00th=[  342], 60.00th=[  350],
     | 70.00th=[  362], 80.00th=[  378], 90.00th=[  532], 95.00th=[ 1704],
     | 99.00th=[21376], 99.50th=[26496], 99.90th=[38656], 99.95th=[43776],
     | 99.99th=[50944]
    lat (usec) : 50=0.01%, 100=0.13%, 250=3.90%, 500=85.35%, 750=3.15%
    lat (usec) : 1000=1.48%
    lat (msec) : 2=1.05%, 4=0.43%, 10=1.42%, 20=1.86%, 50=1.19%
    lat (msec) : 100=0.02%
  cpu          : usr=7.82%, sys=26.86%, ctx=10672, majf=3, minf=67
  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    : total=r=0/w=262144/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=32

Run status group 0 (all jobs):
  WRITE: io=1024.0MB, aggrb=119837KB/s, minb=119837KB/s, maxb=119837KB/s, mint=8750msec, maxt=8750msec

Da die SSDs schon 6 Jahre alt sind, der Rechner knapp 10 ist es wirklich erstaunlich, dass meine Werte hier um ein vielfaches (also mehr als 3x) höher sind als deine.

 

[Haithabu84]

Ja, das verstehe ich auch nicht. Das mit der "Data Corruption" ist scheinbar ein Fehlalarm. Hängt wohl eher an den alten Datenbanken.

Es handelt sich ja um die Standardinstallation und da sollten ja schon die optimalsten Einstellungen gesetzt sein. Da würde ich wesentlich bessere Ergebnisse erwarten. Irgendwie alles ziemlich enttäuschend, da ich so nicht mal eine 1Gbit Leitung auslasten kann.

Was mir auch auffällt: Auf einem Node mit root auf ext4 und zwei weiteren SSD in einem ZFS Mirror ist die Leistung ebenfalls viel besser. Eventuell liegt das ganze Problem eher bei root auf ZFS Variante. Dort ist ebenfalls ashift=12 gesetzt und es handelt sich nur um 860PRO von Samsung.

Ich werde das wohl mal umbauen. Mit der jetzigen Konfiguration komme ich jedenfalls nicht mehr weiter.

 

[LnxBil]

Ja, das verstehe ich auch nicht. Das mit der "Data Corruption" ist scheinbar ein Fehlalarm. Hängt wohl eher an den alten Datenbanken.

Naja ... es ist halt MySQL - auch wenn das jetzt Oracle gehört wird die "Datenbank" immer noch von DBAs belächelt - vor allem von Oracle DBAs

Was mir auch auffällt: Auf einem Node mit root auf ext4 und zwei weiteren SSD in einem ZFS Mirror ist die Leistung ebenfalls viel besser.

Wenn der baugleiche Server nichts "wichtiges" macht, wechsele doch jeden Server mal, d.h. ext4-System umstellen auf ZFS und andersherum und teste nochmal. Wenn es immer noch die gleichen Ergebnisse im Sinne von ZFS langsam und ext4 top ist, dann wissen wir, dass es an der speziellen ZFS-Version hängt. Wenn es nicht umgedreht ist weißt du, dass es an der Hardware liegt.

Generell lese ich auch den englischen Thread mit, sodass wir wahrscheinlich dort weiterschreiben werden ...

 

[Haithabu84]

Wenn der baugleiche Server nichts "wichtiges" macht, wechsele doch jeden Server mal, d.h. ext4-System umstellen auf ZFS und andersherum und teste nochmal. Wenn es immer noch die gleichen Ergebnisse im Sinne von ZFS langsam und ext4 top ist, dann wissen wir, dass es an der speziellen ZFS-Version hängt. Wenn es nicht umgedreht ist weißt du, dass es an der Hardware liegt.

So werd ich es machen. Habe jetzt zu nächster Woche noch paar SSDs bestellt und werde das mal entsprechend ausprobieren.

 

[Haithabu84]

Scheint wohl seit diesem Wochenende vermehrt Probleme mit dem ZFSonLinux zu geben.

Mir ist jetzt noch etwas anderes aufgefallen, wo ich nicht weiß wo das herkommt, vielleicht durch die Komprimierung... keine Ahnung: Ich habe meine Command History mit Datum versehen und mit 1000 Einträgen. Da fällt mir auf das teilweise die ersten Kommandos die ich abgesetzt habe, plötzlich das aktuelle Datum von Heute aufweisen.

Sollte sich das so durch das gesamte System ziehen, dürfte das auch für Linux nicht gesund sein.

    1  2019-09-09 09:08:12  zpool status
...
  248  2019-09-05 16:04:20  apt get install iotop

 

[Haithabu84]

Ich bin langsam mit meinem Latein am Ende. Habe jetzt auf zwei kleinere separate SSD mit Raid1 das Proxmox drauf und habe auf vier weiteren SSD ein ZFS Raid10 gebildet für die Container. Es handelt sich um Intel D3-4610 SSD.

Der Pool wurde über die GUI erstellt mit ashift=12 und es wurde manuell atime=off gesetzt. Ansonsten alles original.

NAME                      USED  AVAIL     REFER  MOUNTPOINT
rpool                    76.3G  1.61T      112K  /rpool
rpool/subvol-100-disk-0  6.30G  43.7G     6.30G  /rpool/subvol-100-disk-0
rpool/subvol-101-disk-0  49.4G  50.6G     49.4G  /rpool/subvol-101-disk-0
rpool/subvol-111-disk-0  20.6G  19.4G     20.6G  /rpool/subvol-111-disk-0

  pool: rpool
state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
          mirror-1  ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0

errors: No known data errors

Ohne irgendwas drauf war ein bei fio randwrite schon besser, war ich bei 152MB/s. Aber vzdump 20Gb Restore 72MB/s oder kopieren einer 1Gb großen Datei auf einen Fileserver-Container wieder die magischen 82MB/s. Als würde irgendetwas abriegeln. Hört sich jetzt vielleicht komisch an, aber muss sich das erst "einlaufen"? Bei der alten Konfiguration lief es zum Schluss hin auch schon besser. Ich hatte bei abgeschalteten Container etwa 220MB/s.

 

[Haithabu84]

Ok. Habe gerade entdeckt das die Standard-Blocksize auf 128K eingestellt ist, egal ob man ashift=12 setzt. Also immer... das Problem was ich jetzt sehe ist, das man sich dann nicht wundern braucht warum es so lahm ist. Soll das wirklich so sein?

zfs get recordsize
NAME                     PROPERTY    VALUE    SOURCE
rpool                    recordsize  128K     default
rpool/subvol-100-disk-0  recordsize  128K     default
rpool/subvol-101-disk-0  recordsize  128K     default
rpool/subvol-111-disk-0  recordsize  128K     default

Habe des Spaßes wegen mal mit 128k getestet:

fio --name=/rpool/testfile --ioengine=libaio --iodepth=32 --rw=randwrite --bs=128k --direct=1 --size=1G --numjobs=1 --group_reporting
/rpool/testfile: (g=0): rw=randwrite, bs=(R) 128KiB-128KiB, (W) 128KiB-128KiB, (T) 128KiB-128KiB, ioengine=libaio, iodepth=32
fio-3.12
Starting 1 process

/rpool/testfile: (groupid=0, jobs=1): err= 0: pid=14293: Thu Sep 12 03:04:54 2019
  write: IOPS=28.2k, BW=3531MiB/s (3703MB/s)(1024MiB/290msec); 0 zone resets
    slat (usec): min=19, max=1372, avg=33.39, stdev=25.17
    clat (usec): min=3, max=2894, avg=1093.33, stdev=411.29
     lat (usec): min=111, max=2962, avg=1126.93, stdev=423.32
    clat percentiles (usec):
     |  1.00th=[  758],  5.00th=[  766], 10.00th=[  766], 20.00th=[  775],
     | 30.00th=[  775], 40.00th=[  783], 50.00th=[  816], 60.00th=[  865],
     | 70.00th=[ 1500], 80.00th=[ 1565], 90.00th=[ 1614], 95.00th=[ 1680],
     | 99.00th=[ 2057], 99.50th=[ 2114], 99.90th=[ 2900], 99.95th=[ 2900],
     | 99.99th=[ 2900]
  lat (usec)   : 4=0.01%, 250=0.05%, 500=0.06%, 750=0.48%, 1000=61.83%
  lat (msec)   : 2=35.79%, 4=1.78%
  cpu          : usr=8.65%, sys=85.47%, ctx=277, majf=0, minf=8
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.2%, 32=99.6%, >=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,8192,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=3531MiB/s (3703MB/s), 3531MiB/s-3531MiB/s (3703MB/s-3703MB/s), io=1024MiB (1074MB), run=290-290msec

Kann man das ändern? Ist das überhaupt zu empfehlen?

Wie kann man den bei einem Restore die recordsize für ein das Dataset mitgeben? Im Nachhinein wirkt eine Änderung nur für dazugekommene Dateien.

 

[LnxBil]

Kann man das ändern? Ist das überhaupt zu empfehlen?

Für Datasets, nein. Ergibt nur bei zvol Sinn und dort ist es eh kleiner ( 4 oder 8 KB, müsste man in PVE mal nachschauen). Bei zvol muss es angepasst sein auf die Blockgröße im Gast, sonst hat man read und write Amplification.

Je höher du bei fio die Größe wählst, desto schneller wird es aber du misst dann keine 4 KB random I/O Performance Bei 128K hast du das Limit beim Schreiben von ZFS erreicht und wenn du "en block" einen 128 KB Block schreibst wird der komprimiert und z.B. auf die Hälfte geschrumpft und dann packst du von deinem Backend her doppelt so viel Durchsatz wie vorher. Das macht natürlich nicht für alle Dateien Sinn, denn zum einen müssen sie komprimierbar und zum anderen größer als 128 KB sein. Das gilt z.B. für Logdateien, die sehr gut komprimierbar sind, wenn man sie als Datei z.B. beim entpacken draufkopier. Wenn Logdateien aber geschrieben werden wird dort meistens ja nur ein paar Zeilen hinzugefügt und das sind meistens keine großen KB-Werte. Somit werden die Daten dann nicht so gut komprimiert, da die Recordgröße in dem Fall einfach kleiner ist.

 

[Haithabu84]

Dachte nur das etwas komisch sei. Habe mich da auch etwas belesen und da wurde unter anderem empfohlen bei Datenbanken die recordsize auf 16k zu stellen, was wohl eine wesentlich bessere Performance bringen solle.

Ansonsten weiß ich jetzt auch fast nicht mehr weiter. Im Endeffekt alles durchprobiert, was in Frage kommt. Habe jetzt schon bessere SSDs mit besserer Write IO, aber davon ist überhaupt nichts zu spüren. Mit meinen 32Gb RAM liege ich eigentlich auch nicht schlecht. Ich sehe auch das der ARC ordentlich verwendet wird wenn viel los ist, da sind die ca. 16GB eben voll. Mit Raid10 habe ich jetzt auch zwei Vdevs, im Gegensatz zu vorher nur einer.

In den Container fühlt sich alles irgendwie lahm an. Egal ob da eine MySQL oder C-isam DB drin ist. Vor allem aber bei einem Samba-Server merkt man es, kopieren von einer einzigen 1GB File mit nur 82MB/s, als würde jemand auf der Bremse stehen.

Meine einzige Idee ist:

• Noch mehr RAM
• Problem mit dem BIOS von Supermicro (würde mich nicht wundern, aktuelles schon drauf)
• Die Container müssten vielleicht mal auf einen aktuelleren Stand gebracht werden, bzw. der Inhalt in einen neu angelegten Container umziehen

Zweiteres könnte ich testen, wenn ich den zweiten Server mit only LVM auf ZFS umbaue und dann mal gegenprüfe. Extra ZIL, L2ARC und SLOG macht, denke ich, nur bei HDDs Sinn.

 

[Haithabu84]

Habe jetzt durch Zufall herausgefunden, dass scheinbar vzdump eine Art Limitierung fest hinterlegt hat. Erst wenn man das bwlimit in der /etc/vzdump.conf manuell setzt, kann man das umgehen. Habe bwlimit=200000 gesetzt. Jetzt konnte ich zumindest mit 122MiB/s einen dump anlegen... Der Wert ist auch gut, denn:

Derzeit habe ich zwei 240Gb Intel D3 als OS-Platten im Raid1 mit LVM. Die haben nur 320MB/s schreiben und das Storage für Backups liegt ebenfalls dadrauf. Also ungefähr die Hälfte der Bandbreite geht für das Raid drauf... also alles in Ordnung.

Mittlerweile konnte ich auch verifizieren, woran das langsame Kopieren von Files auf einen SMB-Container gelegen hatte: Es lag am Linux-Client mit dem ich getestet habe, scheinbar sind da unterschiedliche Software-Versionen dran Schuld. Mit einem Windows-Client hatte ich dann etwa 117MB/s beim hochschieben.

Geprüft habe ich die Auslastung der Netzwerkkarte mit bmon. So konnte ich deutliche Unterschiede zwischen WIndows und Linux in der Performance feststellen.