Kernel killt Programm

[manes]

Ich habe einen kleinen Server (Intel Pentium G4400), mit einem seit ~8 Jahren stetig wachsenden ZFS-Pool (gestartet mit ich glaube vier HDD zu je 4TB). Eine Reihe Festplatten, die bei Bedarf (Befüllung ~80%) immer wieder gegen mehr und größere Platten ersetzt wurden. Seit einigen Wochen werden nun immer wieder und für mich nicht vorhersehbar Programme (immer: rtorrent) gekillt. Ist der Pool exportiert, liegt die CPU-Last <1%, sobald der Pool importiert wird, bei nahezu 100% auf beiden CPU. Von 32GB RAM sind meist nur 20% belegt.
zpool list -v

Code: Alles auswählen

NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
data        83.4T  64.9T  18.5T        -         -    24%    77%  1.00x    ONLINE  -
mirror-0  12.6T  12.5T   129G        -         -    41%  99.0%      -    ONLINE
n14_00  12.7T      -      -        -         -      -      -      -    ONLINE
n14_01  12.7T      -      -        -         -      -      -      -    ONLINE
mirror-1  12.6T  12.5T   119G        -         -    43%  99.1%      -    ONLINE
n14_02  12.7T      -      -        -         -      -      -      -    ONLINE
n14_03  12.7T      -      -        -         -      -      -      -    ONLINE
mirror-2  9.06T  8.98T  87.9G        -         -    46%  99.0%      -    ONLINE
n14_04  9.10T      -      -        -         -      -      -      -    ONLINE
n14_05  9.10T      -      -        -         -      -      -      -    ONLINE
mirror-3  9.06T  8.98T  88.6G        -         -    45%  99.0%      -    ONLINE
n14_06  9.10T      -      -        -         -      -      -      -    ONLINE
n14_07  9.10T      -      -        -         -      -      -      -    ONLINE
mirror-4  12.7T  8.56T  4.16T        -         -     6%  67.3%      -    ONLINE
n14_08  12.7T      -      -        -         -      -      -      -    ONLINE
n14_09  12.7T      -      -        -         -      -      -      -    ONLINE
mirror-5  9.09T  7.70T  1.39T        -         -     9%  84.7%      -    ONLINE
n14_10  9.10T      -      -        -         -      -      -      -    ONLINE
n14_11  9.10T      -      -        -         -      -      -      -    ONLINE
mirror-6  18.2T  5.65T  12.5T        -         -     1%  31.0%      -    ONLINE
n14_13  18.2T      -      -        -         -      -      -      -    ONLINE
n14_12  18.2T      -      -        -         -      -      -      -    ONLINE

Ich bin erstaunt, daß die Verteilung der Daten so ungleichmäßig ist und habe keine Erklärung, warum einzelne VDEV bei 99% liegen. Ich dachte, ZFS kümmert sich selbst um eine gleichmäßige Befüllung. Wenn ich ein weiteres VDEV hinzugefügt habe, dachte ich, würde dieses bevorzugt beschrieben, bis weitgehend gleiche Füllstände mit den anderen VEDEVs erreicht ist. Es ist mindestes zwei Jahre her, daß ich den Pool um VDEVs erweitert habe, seitdem nur Plattenwechsel.

Ein paar Fragen in die Runde der Wissenden hier:

1. Ist die hohe CPU-Last durch die Befüllung der einzelnen VDEV >80% zu erklären?
2. Wenn ja, kann ich das korrigieren, ohne den gesamten Pool neu aufsetzen zu müssen?

[heisenberg]

Grundsätzlich sieht mir das so aus, dass bei Dir die zeitlich ältesten Platten die höchste Belegung aufweisen. D. h. dass bei Dir da vielleicht nichts frei / umverteilt wurde, weil keine bestehenden Daten gelöscht wurden. Dass da etwas verteilt wird, müssen auch immer wieder Daten gelöscht und neu geschrieben werden.

Zu 2) Maßnahmen zur Abhilfe

1. VDEV Re-Integration
   
   Einen Rebalance gibt es AFAIK bei ZFS nicht. Meine Recherchen dazu, das doch machen zu wollen, führten zu Threads in anderen Foren zu der Aussage, dass man dass doch lassen solle, weil ZFS sich da selbst drum kümmere und das zu kompliziert ist, dass selbst tun zu wollen.
   
   Eine Möglichkeit für eine teilwesie Abhilfe wäre, dass Du - bei ausreichend freiem Speicherplatz im Pool - dasjenige VDEV entfernst, dass die höchste Belegung aufweist. Damit werden die evakuierten Daten auf die anderen VDEVs kopiert, bevorzugt auf die, die am wenigsten Daten gespeichert haben. Anschließend fügst Du die Platten erneut als Mirror hinzu. Wenn Du das mehrfach mit den vollsten Mirror-VDEVs tust wird as mit Sicherheit helfen.
   
   Also z. B. so (Ungetestet! Prüfe die Dokumentation! Potentiell gefährliche Aktion! Datensicherung sollte da sein!):
   

   Code: Alles auswählen

   zpool remove data mirror-1 
   

2. Daten kopieren
   
   Du könntest sehr große Verzeichnisse kopieren auf dem gleichen Pool. z. B. /data/backup nach /data/backup2. Anschließend /data/backup löschen und /data/backup2 zu /data/backup umbenennen. Auf diese Art und Weise werden Daten neu geschrieben, gemäß der ZFS Policy auf dem am wenigsten vollen VDEV bevorzugt. Natürlich musst Du sicherstellen, dass während dieses Vorganges keine Daten in /data/backup geschrieben werden.
   .
3. ZFS-Dateisysteme exportieren, löschen und reimportieren
   
   Wenn Dein Pool nicht nur aus einem ZFS-Dateisystem besteht kannst Du spezifische Dateisysteme exportieren, löschen und wieder importieren. (Ohne Gewähr! Ungetestet! Selbst noch nicht gemacht!). Auch hier dürfen nach dem exportieren der Daten keine weiteren Daten in das Dateisystem geschrieben werden.

[bluestar]

Hast du evtl. ein bißchen mehr an Infos:
* Welche ZFS Version nutzt du?
* Wie viel RAM hat dein System und wie viel gönnst du ZFS?
* Hast du evtl. SMR Platten im Einsatz?

[manes]

Der Rechner läuft unter Debian stable, das zfs ist Version 2.1.11-1.
32GB RAM. Keine SMR-Platten.

und wie viel gönnst du ZFS?

/etc/modprobe.d/zfs.conf

Code: Alles auswählen

(…) options zfs zfs_arc_max=30000000000

Ich setze das max mal auf 26GB und teste, ob das einen Unterschied macht. Wenn ich in *top schaue, habe ich meist nahe 100% Last auf den CPU, aber nur wenig RAM-Belegung. Ich habe Zweifel, ob das der Flaschenhals ist.

[bluestar]

Ist ein Scrub aktiv?
Welcher Prozess zieht denn die 100% CPU?

[manes]

Tatsächlich lief ein scrub via monatlichem cronjob, der dauert in der Regel um die 30h. Die Programmabbrüche gehen aber über Wochen, unregelmäßig und nicht nur während des scrubbing.

Blöderweise ist jetzt gerade nichts mehr von den berichteten Problemen zu sehen, alles wirkt gesund: CPU Load ist immer mal hoch, aber nicht dauernd beide Kerne über 90%, und RAM wird auch genutzt, jetzt konstant ~80%.
Mehrere reboots, sonst habe ich nichts geändert, was nicht in den obigen Beiträgen steht.

Das ZFS hatte immer viele Prozesse laufen: viele Instanzen /usr/bin/zed und zahlreiche z-im-Namen-Prozesse, die ich auch mit erneutem scrub nicht mehr zu sehen bekomme.
edit: 15+ z_rd_int, dsl_scan_iss, kworker/ +kcryptd
Soweit erstmal.

Danke für eure Hilfe!

[manes]

Update:
32GB RAM, Poolgröße 83.4TB, reichlich Last (40MBit uplink dauerhaft saturiert) auf rtorrent, wenig nginx.

Mit /etc/modprobe.d/zfs.conf

Code: Alles auswählen

options zfs zfs_arc_min=20000000000
options zfs zfs_arc_max=24000000000

läuft es jetzt stabil. Danke nochmal allen, die hier mitgelesen und -geschrieben haben!

[bluestar]

Hast du deinen ZPool auf LUKS laufen?

[manes]

Hast du deinen ZPool auf LUKS laufen?

Ja, hab ich.

[bluestar]

Hast du deinen ZPool auf LUKS laufen?

Ja, hab ich.

Das erklärt dein beschriebenes Verhalten, da ZFS parallel beim Scrub auf die Devices zugreift, grillst du dir mit den vielen LUKS Devices deine „nicht mehr ganz aktuelle“ CPU natürlich.