[Sammelthread] ZFS Stammtisch

Wesumat schrieb:
@gea
Hätte noch mal ne Frage zu napp-it und den Jobs, gibt es eine Möglichkeit einzelne Jobs (z.B. replication) zu verknüpfen, so dass diese sequentiell ausgeführt werden? Konnte in den Dokus so ad hoc nichts in die Richtung finden.
Zum Vergrößern anklicken....

Man könnte mit postjob scripts "jobid.post" jobs sequentiell starten. Am Einfachsten aber die Jobs mit Verzögerung starten. Eine leichte Überlappung kann kaum ein Last Problem sein.

Wesumat schrieb:
Eine weitere Verständnisfrage zu den push Alert Jobs, worauf sollten diese reagieren? Auf jegliche Fehler wie bei der Email Alarmierung (sprich Disc, Cap und Jobs)? Konnte zwar test Pushs per webapi erhalten, bei einem testweise fehlerhaft endenden other job kam aber keine Alarmierung per push, obwohl dieser mit error in der job Liste stand. Auto-Job ist aktiv (1min).
Zum Vergrößern anklicken....

Alert Mails und Push Alerts sind von der Auslösung identisch. Wird jedoch ein Alert oder Push getriggert, so wird am gleichen Tag kein weiterer Alert (Push oder Mail) mit gleicher Ursache verschickt.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Danke für die Rückmeldung gea,

das mit den .postjobs gucke ich mir mal an.

Das Verhalten beim alert schaue ich mir auch noch mal an, ob es eventuell an der Aktivierung von email und push alert liegt.
 
Hm,

habe den email Job komplett weggeschmissen. Ändert aber nichts, laut auto.log wird der job fleissig jede Minute aktiviert?
Zum Testen habe ich den Push Job auch noch mal komplett neu angelegt.

root@NAS02:/var/web-gui/_log# more auto.log
2025.01.22.21.56.00: job 1737577018: start auto push
2025.01.22.21.55.01: job 1737577018: start auto push
2025.01.22.21.54.00: job 1737577018: start auto push

....

Interessanterweise scheint aber schon gar kein zugehöriges log zu der JobID des push alerts geschrieben zu werden.

1737579264606.png


1737579308095.png


Ich habe hier allerdings die webapi.pl unter _my/
-rw-r--r-- 1 napp-it root 7414 Jan 19 14:16 /var/web-gui/_my/scripts/webapi/webapi.pl
abgelegt und etwas angepasst, um einen lokalen gotify Server anzutriggern.

Ein Test aus der gui klappt, ein Aufruf der oben liegenden webapi.pl ohne Parameter löst ebenfalls
einen Test-Push aus. Nur wenn jetzt theoretisch ein Abbruch eines Jobs aufgetreten ist, passiert einfach
nichts, wird bei einem echten Alarm noch irgendetwas an anderer Stelle berücksichtigt?

1737579808290.png
 
Nicht so einfach zu beantworten vor allem bei einer so speziellen und selten genutzten Funktion

1. man könnte debuggen und den job manuell starten mit run_jobid
perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/job-push.pl run_173780874

Dann im Script mit print Anweisungen den Ablauf anzeigen lassen

2. Einen "other job" anlegen der sich am push-test orientiert und eigene Ereignisse auswertet

3. Job > Report anlegen mit Alert only und webapi
und schauen ob das geht. Report kann man mit eigenen Reports erweitern.
 
Bin jetzt etwas weiter gekommen,

erster Stolperstein, bei manuellen Jobs wird anscheinend nichts gemacht,
1737635460606.png


zweiter Stolperstein, nur einmal pro Tag, aber kann man ja zu Testzwecken mal auf immer ändern.
1737635541011.png


dritter Stolperstein, Job werden nicht in .par Datei aufgenommen, auch wenn sie bei der Anlage in der GUI angehakt sind.
1737635681709.png

neu angelegt
1737635743362.png


root@NAS02:/var/web-gui/_log/jobs# cat 1737635700.par | grep trigger
trigger=Disk,Low,

Fügt man dann dort auch ein , Job hinzu, dann wird letztlich auch ein Push beim Alarm für einen Job gemacht.
 
Push > Alert als Alternative zu Email > Alert war vor Jahren eine Idee die ich seither nicht mehr angefasst und stattdessen selbst erweiterbare Report Scripts eingebaut habe, bei denen man beliebig viele per job selektierbare Trigger haben kann. Da kann man dann auch per Reportjob Mail, TLS oder Push/webapi als Sendmethode wählen. Spricht aber nichts dagegen, die Scripte anzupassen.

ps
Im aktuellen napp-it 25.x wird jetzt Jobs in die Push Parameterdatei übernommen (Leerzeichen nach Komma im Formular war das Problem) und ein Hinweis angezeigt das Push Alertjob auf active stehen muss.
 
Sollte eigentlich nicht so sein.
Der Report /var/web-gui/data/napp-it/zfsos/_lib/scripts/report/r03#joberror#parse_job_results#SIL#AS.pl prüft in sub my_report ob ein Job in id.par aktiv ist und dann ob die id.log am Anfang (letzter Logeintrag) ein error stehen hat.

ps
Wenn Themen zu speziell werden, diese bitte im napp-it Thread oder besser einem eigenen Thread auslagern
 
Uhm, mein zil/l2arc device hat irgendwas, wie entfern ich das (ist ein Truenas, allerdings manuell hinzugefügt) richtig?

Hinzugefügt per:
zpool add apps cache gptid/00bd58e3-7efa-a046-85d6-...
zpool add apps log gptid/aa6d566f-ab06-2a4a-a35b-...

mit remove statt add gehts irgendwie nicht...
 
Für alle, die sich schon mal mit dem "Aufräumen" von ZFS Snapshots rumschlagen mussten: Ich habe kürzlich ein kleines Kommandozeilen-Tool geschrieben, dass das ganze etwas vereinfachen soll. Das Tool ist noch in der Alpha-Phase - also empfehle ich es, erstmal auf Testsystemen einzusetzen (Haftung schließe ich aus). Ich persönlich setze es auf meinem Homeserver ein und bin mit den Ergebnissen ganz zufrieden bisher:

github.com

GitHub - sandreas/zfs-tool: zfs-tool to help with various zfs tasks, e.g. cleanup snapshots

zfs-tool to help with various zfs tasks, e.g. cleanup snapshots - sandreas/zfs-tool
github.com github.com

Features:
  • Filtern, Limitieren und Sortieren von snapshots anhand mehrerer Kriterien
  • Templatebasierte Ausgabe der Eigenschaften von Snapshots, um eigene Übersichten zu realisieren
  • Ermitteln des "Reclaimed"-Space - der Platz den man frei macht, wenn man einen Snapshot löscht (auch kumuliert)
Mehr Doku und Beispiele auf der Projektseite.

Bissel Feedback würde mich freuen - vielleicht erfinde ich auch hier das Rad neu, man könnte das sicher auch mit Shell-Scripten lösen, ich fand ein geschlossenes Tool nur etwas handlicher als das gescripte.
 
Servus,

heute kam mir mein Storage total lahm vor.
Blick ins Dashnoard (Napp-it) führt beide NIC auf.
e1000g0 net1 Ethernet up 1000 full BOUND 10.0.1.x 255.255.255.0 0:e0:81:d6:f2:aa 1500 ok
mcxe0 net2 Ethernet up 10000 full BOUND 10.0.1.x 255.255.255.0 0:2:c9:57:18:e0 1500 ok

Allerdings geht alles über die e100O NIC und nicht über die Mellanox.
Host ist ein Solaris 11.3 System.
Interessant ist, dass die e1000 ein IP hat, ich diese aber nicht ansprechen kann.
Wenn ich das Kabel an der e1000 abziehe, komme ich nicht mehr auf das Webinterface, was aber auf der IP der Mellanox läuft.
Bin verwirrt ;)
Ich habe die zweite NIC als Fallback, weil es vorkam, dass die Mellanox kein Link hatte.

Was passiert, wenn ich die Intel "ausschalte" ?
Könnte mir jetzt n´boot Snap machen, aber dachte, ich frage mal vorweg :)
 
Mit zwei Netzwerkkarten im gleichen Subnet gibts gerne Routing oder Broadcastprobleme. Ich würde das nur machen wenn man etwas spezielles erreichen will, ansonst unterschiedliche subnets nehmen z.B. 10.0.1.x und 10.0.2.x mit 255.255.255.0

Zum Testen dem Desktop je eine ip im entsprechendem Subnetz geben.
 
xymos schrieb:
Interessant ist, dass die e1000 ein IP hat, ich diese aber nicht ansprechen kann.
Zum Vergrößern anklicken....
Die e1000 ist bei mir sehr problematisch. Die schmiert regelmäßig einfach ab und ist nicht mehr ansprechbar (Debian 12 / Proxmox 8). Mit folgendem habe ich es halbwegs in den Griff bekommen:
Code: 
# /etc/network/interfaces

iface eth0 inet manual
    post-up /usr/sbin/ethtool -K $IFACE tso off gso off 2> /dev/null

Aber stabil ist es nicht, alle paar Monate mal ist die Kiste einfach offline, dann muss ich an die Hardware (Monitor anschließen) und das Netzwerk neustarten.

Meine Vermutung ist, dass es bei mir ein Kernel / Treiberproblem ist, denn mit Proxmox 7 hatte ich das nicht.
 
So, vorheriges Problem gelöst.

Jetzt bin ich grad bissl am runeiern wegen meinem special vdev.
Also, special small block muss immer unter der recordsize sein, soweit versteh ich, wie das funktioniert (dass es eben nicht um die Dateigröße selbst geht sondern um den Record).
Das svdev ist nun eine Sache am pool, das Dataset dann die andere.

1) Heisst also, ich kann auf einem Pool durchaus mehrere Datasets mit unterschiedlicher recordsize und special small blocks anlegen, wenn ich das richtig vestehe?
Ich kann also fürs jeweilige Dataset steuern, wie das mit den special small blocks laufen soll?
1a) Ich könnte z.B. das ganze Dataset aufs svdev "zwingen" indem ich special small = recordsize mach (bzw. mit =0 deaktivieren)?
1b) Ich könnte z.B. für andere Datasets auf dem Pool mir eine mir passende special small zur recordsize aussuchen... für Medien z.B. 1M record und 256k special small... und fürn anderes Dataset eben z.B. die standardwerte lassen...

2) Ich hab zwar gesucht, aber leider keine aussagekräftigen Benchmarks (Erfahrungswerte reichen mir auch) gefunden zum Einfluss der Recordsize. Wenn ich z.B. ein Pool hab, das hauptsächlich ein Medienarchiv ist (zumindest ein Dataset auf dem Pool), bestehend aus 4x (evtl. 5x) 20tb Ultrastar, hauptsächlich Videos, macht die Recordsize >128k in der Realität vor allem beim Lesen (aber auch beim Schreiben) einen Einfluss? Also wenn man da jetzt z.B. 512k oder 1M einstellt, ist da merklich ein Unterschied zu den 128k default, oder "konvergiert" die Geschwindigkeit bei den 128k schon?
 
Ja.
Recsize und small blocksize sind Eigenschaften eines ZFS Dateisystems, können also jeweils unterschiedlich sein.
Setzt man smallblocksize z.B. auf 64K so landen alle Datenblöcke bis zu dieser Größe auf dem special vdev also Metadaten und komprimierte Dateien bis 64K (wegen dynamischer recsize)

Setzt man recsize auf einen Wert > 64K, so landen größere Dateien als 64K auf hd.

Setzt man recsize auf 64K so gibt es keine größeren Datenblöcke als 64K, also landet das ganze Dateisystem auf dem special vdev.

Recsize hat Auswirkung auf die Effizienz vieler ZFS Eigenschaften, auf Fragmentierung, read ahead und write amplification. Die Default 128K ist ein guter Kompromiss. Kleine Werte 16-64K können mit SSD/NVMe Mirrors und Datenbanken Sinn machen, weniger mit HD und Raid-Z. Da eher große Werte wählen wie 1M.
 
Zuletzt bearbeitet:
Ja, so allgemein hab ich das schon in Erfahrung gebracht und gelernt.

Aber ich tu mir schwer einzuschätzen, wie groß der Effekt zwischen 128k und 1M ist für große Daten, also für ein Dataset, wo eben hauptsächlich Videomaterial und so liegt.
Mit einem extra Dataset für diesen Datentypen könne ich gut leben, siehe oben.

=> Die Frage ist, was man sich gefühlt erwarten kann von 128k zu 1M, ob das +3% sind, +10%, +50% oder +200% sind?
Ich weiss, dass man das "so allgemein" nicht sagen kann, aber ich hab ja den Aufbau (Z1 4-5 20tb Platten + svdev Metadata, Dateien 10mb-2000mb) ja halbwegs geschildert, gibts da irgend einen Erfahrungswert?
Die "Platzverschwendung" ist wegen LZ4 ja nicht so das Thema, write amplification auch nicht so weil hauptsächlich gelesen wird vom "Medienarchiv"...

Wie ist das denn mit dem Schreiben, ich überleg gerade, ob neben Änderunsdatum der letzte zugriff hinterlegt wird? Ist sowas dann in den Metadatas oder im File selbst hinterlegt? Ist aber eigentlich eher am Rand.
 
Videodaten lassen sich praktisch nicht mehr weiter komprimieren. Wenn es hauptsächlich Videodaten sind würde ich einfach ohne viel nachdenken 1M recsize nehmen, mit mechanischen Festplatten und Raid-Zn sowieso. Änderungsdatum und Zugriff sind File Attribute, letztlich Metadaten. Zugriff darauf bekommt man mit svdev schnell.

Wenn man Bedenken mit der Performance hat, den Pool nicht so voll machen. Schon ab 50% läßt die Performance nach.
 
Hat jemand ein Fio File / CMDline für einen 24x2TB SSD Pool (256GB RAM) zur Hand?

Eben dieser Pool macht mir aktuell ein wenig Bauchschmerzen, er fühlt sich sehr langsam an.

Ich hab die Vermutung dass das wieder dieser verf..luchte Broadcom 9600 HBA ist. Zudem bin ich grade zu doof fio zu bedienen und der versucht anscheinend mir den ganzen Pool zu füllen.

(Wir hätten Sand niemals das Denken beibringen sollen)
 
Pool Layout: 24x Micron 5300 PRO 1.92TB @ Broadcom 9600-24i @ Direct Attach Backplane, 5x RAID-Z1 (4x á 5 disks, 1x á 4 disks), compression = on
Pool recordsize = 16k (ist ein download / temp-pool, recordsize = 16k war eine der Empfehlungen für bestimmte Download-Workloads laut zfs docs)

1. Test: Sequentiell mit ganz viel Hass, schauen was der Pool maximal so kann, also SEQ16k Q64T32
Code: 
fio --name=test1 --size=16G --ioengine=libaio --rw=read --bs=1M --numjobs=32 --iodepth=64 --group_reporting --direct=1
fio --name=test2 --size=16G --ioengine=libaio --rw=write --bs=1M --numjobs=32 --iodepth=64 --group_reporting --direct=1
Read:
bw ( MiB/s): min= 1296, max= 6062, per=100.00%, avg=2573.39, stdev=12.68, samples=12950
iops : min= 1296, max= 6062, avg=2573.34, stdev=12.68, samples=12950
Write:

Read:
Code: 
test1: (groupid=0, jobs=32): err= 0: pid=140989: Mon Feb 10 22:39:05 2025
  read: IOPS=2549, BW=2549MiB/s (2673MB/s)(512GiB/205672msec)
    slat (usec): min=491, max=40436, avg=12377.21, stdev=3410.65
    clat (usec): min=2, max=951070, avg=779256.52, stdev=91950.54
     lat (usec): min=503, max=964847, avg=791633.73, stdev=92985.03
    clat percentiles (msec):
     |  1.00th=[  271],  5.00th=[  651], 10.00th=[  709], 20.00th=[  751],
     | 30.00th=[  776], 40.00th=[  785], 50.00th=[  802], 60.00th=[  810],
     | 70.00th=[  818], 80.00th=[  835], 90.00th=[  852], 95.00th=[  860],
     | 99.00th=[  885], 99.50th=[  894], 99.90th=[  911], 99.95th=[  919],
     | 99.99th=[  927]
   bw (  MiB/s): min= 1296, max= 6062, per=100.00%, avg=2573.39, stdev=12.68, samples=12950
   iops        : min= 1296, max= 6062, avg=2573.34, stdev=12.68, samples=12950
  lat (usec)   : 4=0.01%, 10=0.01%, 750=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.02%, 50=0.06%
  lat (msec)   : 100=0.07%, 250=0.55%, 500=1.20%, 750=18.12%, 1000=79.95%
  cpu          : usr=0.03%, sys=19.77%, ctx=10900192, majf=0, minf=524693
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.2%, >=64=99.6%
     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.1%, >=64=0.0%
     issued rwts: total=524288,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=2549MiB/s (2673MB/s), 2549MiB/s-2549MiB/s (2673MB/s-2673MB/s), io=512GiB (550GB), run=205672-205672msec
Write:
Code: 
test2: (groupid=0, jobs=32): err= 0: pid=143146: Mon Feb 10 22:47:52 2025
  write: IOPS=1429, BW=1429MiB/s (1499MB/s)(512GiB/366842msec); 0 zone resets
    slat (usec): min=553, max=28612, avg=22372.07, stdev=3954.23
    clat (usec): min=3, max=1657.1k, avg=1408855.41, stdev=145136.73
     lat (usec): min=1023, max=1679.2k, avg=1431227.47, stdev=145111.97
    clat percentiles (msec):
     |  1.00th=[  978],  5.00th=[ 1267], 10.00th=[ 1284], 20.00th=[ 1301],
     | 30.00th=[ 1334], 40.00th=[ 1368], 50.00th=[ 1401], 60.00th=[ 1452],
     | 70.00th=[ 1502], 80.00th=[ 1536], 90.00th=[ 1569], 95.00th=[ 1586],
     | 99.00th=[ 1636], 99.50th=[ 1636], 99.90th=[ 1653], 99.95th=[ 1653],
     | 99.99th=[ 1653]
   bw (  MiB/s): min=  666, max= 4230, per=99.67%, avg=1424.42, stdev= 7.54, samples=23451
   iops        : min=  666, max= 4230, avg=1424.05, stdev= 7.54, samples=23451
  lat (usec)   : 4=0.01%, 10=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.02%
  lat (msec)   : 100=0.04%, 250=0.05%, 500=0.56%, 750=0.18%, 1000=0.15%
  lat (msec)   : 2000=98.99%
  cpu          : usr=0.11%, sys=2.40%, ctx=863543, majf=0, minf=359
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.2%, >=64=99.6%
     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.1%, >=64=0.0%
     issued rwts: total=0,524288,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
  WRITE: bw=1429MiB/s (1499MB/s), 1429MiB/s-1429MiB/s (1499MB/s-1499MB/s), io=512GiB (550GB), run=366842-366842msec

2. Test: Standard SEQ1M Q8T1
Code: 
fio --name=test3 --size=32G --ioengine=libaio --rw=read --bs=1M --numjobs=1 --iodepth=8 --group_reporting --direct=1
fio --name=test4 --size=32G --ioengine=libaio --rw=write --bs=1M --numjobs=1 --iodepth=8 --group_reporting --direct=1
Read:
!!Achtung KiB/s!!
bw ( KiB/s): min=122880, max=656673, per=100.00%, avg=144126.92, stdev=34760.64, samples=465
iops : min= 120, max= 641, avg=140.74, stdev=33.94, samples=465
Write:
bw ( MiB/s): min= 390, max= 2268, per=100.00%, avg=1876.24, stdev=278.33, samples=34
iops : min= 390, max= 2268, avg=1876.24, stdev=278.33, samples=34
Read:
Code: 
Jobs: 1 (f=1): [R(1)][100.0%][r=355MiB/s][r=355 IOPS][eta 00m:00s]
test3: (groupid=0, jobs=1): err= 0: pid=145759: Mon Feb 10 22:53:03 2025
  read: IOPS=140, BW=140MiB/s (147MB/s)(32.0GiB/233285msec)
    slat (usec): min=384, max=37333, avg=7087.27, stdev=1666.91
    clat (usec): min=2, max=81854, avg=49636.56, stdev=10155.47
     lat (usec): min=475, max=90709, avg=56723.83, stdev=11523.38
    clat percentiles (usec):
     |  1.00th=[ 4359],  5.00th=[20579], 10.00th=[44827], 20.00th=[48497],
     | 30.00th=[50070], 40.00th=[51119], 50.00th=[52167], 60.00th=[53216],
     | 70.00th=[54264], 80.00th=[55313], 90.00th=[56886], 95.00th=[57934],
     | 99.00th=[60031], 99.50th=[61080], 99.90th=[63701], 99.95th=[65799],
     | 99.99th=[72877]
   bw (  KiB/s): min=122880, max=656673, per=100.00%, avg=144126.92, stdev=34760.64, samples=465
   iops        : min=  120, max=  641, avg=140.74, stdev=33.94, samples=465
  lat (usec)   : 4=0.01%, 500=0.01%, 1000=0.01%
  lat (msec)   : 2=0.01%, 4=0.68%, 10=0.73%, 20=2.45%, 50=27.18%
  lat (msec)   : 100=68.95%
  cpu          : usr=0.04%, sys=61.43%, ctx=21487896, majf=0, minf=2061
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=100.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.1%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=32768,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=8

Run status group 0 (all jobs):
   READ: bw=140MiB/s (147MB/s), 140MiB/s-140MiB/s (147MB/s-147MB/s), io=32.0GiB (34.4GB), run=233285-233285msec
Code: 
test4: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=libaio, iodepth=8
fio-3.33
Starting 1 process
Jobs: 1 (f=1): [W(1)][94.7%][w=1808MiB/s][w=1808 IOPS][eta 00m:01s]
test4: (groupid=0, jobs=1): err= 0: pid=148467: Mon Feb 10 22:55:59 2025
  write: IOPS=1824, BW=1824MiB/s (1913MB/s)(32.0GiB/17961msec); 0 zone resets
    slat (usec): min=362, max=1606, avg=518.46, stdev=48.65
    clat (nsec): min=1810, max=5780.2k, avg=3640808.10, stdev=272630.20
     lat (usec): min=501, max=6320, avg=4159.26, stdev=307.97
    clat percentiles (usec):
     |  1.00th=[ 2704],  5.00th=[ 3294], 10.00th=[ 3359], 20.00th=[ 3458],
     | 30.00th=[ 3523], 40.00th=[ 3589], 50.00th=[ 3621], 60.00th=[ 3720],
     | 70.00th=[ 3785], 80.00th=[ 3851], 90.00th=[ 3949], 95.00th=[ 4047],
     | 99.00th=[ 4293], 99.50th=[ 4359], 99.90th=[ 4752], 99.95th=[ 4948],
     | 99.99th=[ 5735]
   bw (  MiB/s): min=  390, max= 2268, per=100.00%, avg=1876.24, stdev=278.33, samples=34
   iops        : min=  390, max= 2268, avg=1876.24, stdev=278.33, samples=34
  lat (usec)   : 2=0.01%, 750=0.01%
  lat (msec)   : 2=0.01%, 4=92.94%, 10=7.04%
  cpu          : usr=1.76%, sys=95.76%, ctx=101129, majf=0, minf=11
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=100.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.1%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=0,32768,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=8

Run status group 0 (all jobs):
  WRITE: bw=1824MiB/s (1913MB/s), 1824MiB/s-1824MiB/s (1913MB/s-1913MB/s), io=32.0GiB (34.4GB), run=17961-17961msec

3. Test: Dem Workload entsprechend, RND4K Q32T16 readwrite
Code: 
fio --name=test5 --size=16G --ioengine=libaio --rw=randrw --bs=16k --numjobs=16 --iodepth=32 --group_reporting --direct=1

Code: 
test5: (groupid=0, jobs=16): err= 0: pid=151826: Mon Feb 10 23:21:42 2025
  read: IOPS=7992, BW=125MiB/s (131MB/s)(128GiB/1049422msec)
    slat (usec): min=5, max=96135, avg=1924.07, stdev=2327.65
    clat (usec): min=2, max=231697, avg=30413.28, stdev=14279.02
     lat (usec): min=213, max=232229, avg=32337.35, stdev=14886.25
    clat percentiles (msec):
     |  1.00th=[    5],  5.00th=[   10], 10.00th=[   13], 20.00th=[   18],
     | 30.00th=[   22], 40.00th=[   26], 50.00th=[   30], 60.00th=[   33],
     | 70.00th=[   37], 80.00th=[   42], 90.00th=[   50], 95.00th=[   56],
     | 99.00th=[   70], 99.50th=[   75], 99.90th=[   87], 99.95th=[   91],
     | 99.99th=[  104]
   bw (  KiB/s): min=58669, max=487328, per=100.00%, avg=130505.10, stdev=2661.06, samples=32914
   iops        : min= 3666, max=30458, avg=8155.95, stdev=166.33, samples=32914
  write: IOPS=7994, BW=125MiB/s (131MB/s)(128GiB/1049422msec); 0 zone resets
    slat (usec): min=11, max=15747, avg=33.97, stdev=28.78
    clat (nsec): min=1800, max=230166k, avg=30429725.63, stdev=14289369.18
     lat (usec): min=18, max=230180, avg=30463.69, stdev=14290.53
    clat percentiles (msec):
     |  1.00th=[    5],  5.00th=[   10], 10.00th=[   13], 20.00th=[   18],
     | 30.00th=[   22], 40.00th=[   26], 50.00th=[   30], 60.00th=[   33],
     | 70.00th=[   37], 80.00th=[   42], 90.00th=[   50], 95.00th=[   56],
     | 99.00th=[   70], 99.50th=[   75], 99.90th=[   87], 99.95th=[   91],
     | 99.99th=[  105]
   bw (  KiB/s): min=51755, max=490944, per=100.00%, avg=130551.66, stdev=2745.03, samples=32914
   iops        : min= 3234, max=30684, avg=8158.87, stdev=171.58, samples=32914
  lat (usec)   : 2=0.01%, 4=0.01%, 20=0.01%, 50=0.01%, 100=0.01%
  lat (usec)   : 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
  lat (msec)   : 2=0.01%, 4=0.71%, 10=5.36%, 20=18.35%, 50=66.19%
  lat (msec)   : 100=9.36%, 250=0.02%
  cpu          : usr=0.25%, sys=5.58%, ctx=12445363, majf=0, minf=208
  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=8387154,8390062,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):
   READ: bw=125MiB/s (131MB/s), 125MiB/s-125MiB/s (131MB/s-131MB/s), io=128GiB (137GB), run=1049422-1049422msec
  WRITE: bw=125MiB/s (131MB/s), 125MiB/s-125MiB/s (131MB/s-131MB/s), io=128GiB (137GB), run=1049422-1049422msec

Was mich wirklich verwirrt:
Warum ist das Lesen beim 2. Test (Standard SEQ1M Q8T1) so viel langsamer als das Schreiben??

echo 1 >> /sys/module/zfs/parameters/zfs_vdev_async_read_max_active hilft auf jeden Fall, erhöht das Lesen auf ~500MByte/sec, alle Werte drüber lassen die Lesegeschwindigkeit einbrechen.
 
Zuletzt bearbeitet:
Interessant, hier scheint es Probleme mit libaio zu geben.

Baseline: compression=on, atime=on, relatime=on, ioengine=libaio
Code: 
bw (  KiB/s): min=81920, max=247808, per=100.00%, avg=110736.70, stdev=22750.26, samples=184
   iops        : min=   80, max=  242, avg=108.14, stdev=22.22, samples=184

compression=off
Code: 
   bw (  KiB/s): min=59392, max=247808, per=100.00%, avg=106658.54, stdev=28836.41, samples=189
   iops        : min=   58, max=  242, avg=104.16, stdev=28.16, samples=189

atime=off
Code: 
   bw (  KiB/s): min=73728, max=301056, per=100.00%, avg=115085.90, stdev=31898.49, samples=175
   iops        : min=   72, max=  294, avg=112.39, stdev=31.15, samples=175

autotrim=off
Code: 
   bw (  KiB/s): min=126976, max=247808, per=100.00%, avg=136171.38, stdev=11500.82, samples=149
   iops        : min=  124, max=  242, avg=132.98, stdev=11.23, samples=149

ioengine = io_uring
Code: 
   bw (  KiB/s): min=264192, max=2138112, per=100.00%, avg=820969.88, stdev=279639.15, samples=81
   iops        : min=  258, max= 2088, avg=801.73, stdev=273.09, samples=81

echo 1 >> /sys/module/zfs/parameters/zfs_vdev_async_read_max_active
Code: 
bw (  KiB/s): min=352256, max=1384448, per=99.60%, avg=568853.88, stdev=115593.87, samples=117
   iops        : min=  344, max= 1352, avg=555.52, stdev=112.88, samples=117

echo 1 >> /sys/module/zfs/parameters/zfs_vdev_async_read_max_active + io_uring
Code: 
bw (  MiB/s): min=  510, max= 1710, per=98.39%, avg=1028.42, stdev=242.57, samples=62
   iops        : min=  510, max= 1710, avg=1028.42, stdev=242.57, samples=62

Hach ja... Ich hasse Computer.
 
Anmelden, um zu antworten.

Ähnliche Themen

G
Wieviel ZFS steckt in Qnap ZFS ??
Antworten
5
Aufrufe
1K
gea
G
Shihatsu
ZFS Pool "verschicken"
Antworten
9
Aufrufe
710
sandreas
S
AG1M
[Kaufberatung] Neuer ZFS Homeserver
Antworten
20
Aufrufe
2K
AG1M
AG1M
thor17
Ceph Node auf bestehenden ZFS Pools
Antworten
3
Aufrufe
663
gea
G
AliManali
*erledigt* Perc H310 flashen
Antworten
2
Aufrufe
370
AliManali
AliManali
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh