Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
Antworten
Benutzeravatar
CountDracula
Beiträge: 86
Registriert: 14.01.2011 00:53:59
Wohnort: Transylvania

Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von CountDracula » 09.01.2019 12:12:49

Hi,

ich habe einen kleinen Heimserver (Ubuntu Server 18.04, 4.15.0-38-generic) und seit 3 Tagen reagiert dieser nicht mehr richtig. Ich kann mich noch per SSH verbinden, aber viele Befehle (Bsp: zfs list, lxc list, zpool status) oder Dienste (Bsp: virtuelle Container) reagieren überhaupt nicht mehr. (Auch die Verbindung per SSH funktioniert erst beim zweiten Versuch. Der erste Versuch liefert keine Rückmeldung.)

Code: Alles auswählen

root@server:~# cat /proc/loadavg
77.02 76.62 76.39 1/913 5045

root@server:~# uptime 
 11:49:49 up 68 days, 46 min,  1 user,  load average: 77,02, 76,62, 76,39
Ich habe gestern bereits einen Prozess (lxd) mit -9 versucht zu killen und für eine Sekunde wurden die Befehle wieder ausgeführt. Ich habe diesen Prozess versucht zu beenden, weil ps aux nicht mehr ausführbar war. Mittels strace habe ich gesehen, dass ps genau bei diesem Prozess ins Stocken gerät.

Ebenso habe ich bereits die SWAP mit swapoff deaktiviert.

dmesg sagt nichts zum Ausfall.

Wie kann herausfinden, worin genau das Problem besteht? Welcher Prozess wartet auf I/O? Welches device liefert dieses nicht? Lohnt sich überhaupt danach zu suchen, oder soll ich einfach einen Neustart wagen?

Mögliche Ursachen:
  • Das Betriebssytem liegt auf einem USB-Stick, welcher aber noch Platz bietet. Es können auch noch Dateien erstellt werden.
  • ZFS Bug? (0.7.5-1ubuntu16.4)
  • LXD Bug? (3.0.3-0ubuntu1~18.04.1) – Es laufen mehrere Container.
  • ...
Danke fürs Lesen. Ich liefere gerne weitere Details :wink:
I am Dracula. I bid you welcome.

Benutzeravatar
heisenberg
Beiträge: 3473
Registriert: 04.06.2015 01:17:27
Lizenz eigener Beiträge: MIT Lizenz

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von heisenberg » 09.01.2019 12:41:37

Wie kann herausfinden, worin genau das Problem besteht? Welcher Prozess wartet auf I/O? Welches device liefert dieses nicht? Lohnt sich überhaupt danach zu suchen, oder soll ich einfach einen Neustart wagen?
Im Zweifelsfall warten alle Prozesse auf I/O. I/O heisst entweder Netzwerk oder Festplatte/SSD - ich vermute letzteres.

Meine Vermutung ist dass die Last zu hoch ist, weil ein oder mehrere Prozesse den Server bzgl. I/O total überlasten, dass dann gar nichts mehr geht. Vielleicht ist auch der regelmässige zfs scrub losgelaufen(siehe zpool status) und belastet das System stark, so dass der Server die normale Last nicht mehr verarbeiten kann.

Ein überlastetes System zu analysieren ist schwer, da - wie Du bereits bemerkst - kaum noch Befehle ausführbar sind. Wenn Du es noch hinbekommst installiere bzw. führe mal aus "iotop", dass zeigt Dir die Prozesse an, die viele I/O-Last verursachen.

Anderer Ansatz wäre per Performance-Monitoring den Server zu überwachen und so mal Daten zu haben und nicht erst dann wenn er ausfällt. Also so etwas wie check_mk, munin, ...
... unterhält sich hier gelegentlich mangels wunschgemäßer Gesprächspartner mal mit sich selbst.

Benutzeravatar
CountDracula
Beiträge: 86
Registriert: 14.01.2011 00:53:59
Wohnort: Transylvania

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von CountDracula » 09.01.2019 13:03:26

Hi!

Danke für deine Antwort! :)
heisenberg hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 12:41:37
Vielleicht ist auch der regelmässige zfs scrub losgelaufen(siehe zpool status) und belastet das System stark, so dass der Server die normale Last nicht mehr verarbeiten kann.
Die 4 Daten-Festplatten sind im sleep-Modus. Gestern ging der zpool status Befehl noch und es gab keinen Scrub und keine Fehler.
heisenberg hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 12:41:37
Wenn Du es noch hinbekommst installiere bzw. führe mal aus "iotop", dass zeigt Dir die Prozesse an, die viele I/O-Last verursachen.
Da ist nichts zu sehen, oder? https://imgur.com/a/LaTsGgi
heisenberg hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 12:41:37
Anderer Ansatz wäre per Performance-Monitoring den Server zu überwachen und so mal Daten zu haben und nicht erst dann wenn er ausfällt. Also so etwas wie check_mk, munin, ...
Ich sammele Daten mit Debiancollectd. Allerdings kann ich zurzeit darauf nicht zugreifen, weil der Webserver nicht mehr reagiert :mrgreen:

Edit: Hier noch die Ausgabe von iostat: NoPaste-Eintrag40578

Edit 2: Der Datenpool, welcher aus 4 Festplatten besteht, hat auch ein Cache Device (ZFS: metadata). Das lag auf einem USB-Stick. Erst habe ich versucht, das Cache Device zu entfernen aber der Befehl reagierte nicht. Dann habe ich den Stick gestern probeweise einfach gezogen, weil der Server ja nicht mehr reagierte. Ich hatte die Hoffnung, dass der Stick die Ursache für die I/O Problemetatik ist. Das hat aber keinen Effekt gehabt. Einzig dmesg loggte "usb 1-1.3: USB disconnect, device number 3".
I am Dracula. I bid you welcome.

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von r4pt0r » 09.01.2019 14:48:51

CountDracula hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 13:03:26
Der Datenpool, welcher aus 4 Festplatten besteht, hat auch ein Cache Device (ZFS: metadata). Das lag auf einem USB-Stick.
Dir ist schon klar dass ein L2ARC schneller als die vdevs sein *muss*, da er als Überlaufcache bei zu wenig RAM agieren soll?
Was du gebaut hast ist in etwa vergleichbar mit einem swapfile auf FDD.
Erst habe ich versucht, das Cache Device zu entfernen aber der Befehl reagierte nicht. Dann habe ich den Stick gestern probeweise einfach gezogen, weil der Server ja nicht mehr reagierte. Ich hatte die Hoffnung, dass der Stick die Ursache für die I/O Problemetatik ist. Das hat aber keinen Effekt gehabt. Einzig dmesg loggte "usb 1-1.3: USB disconnect, device number 3".
Der pool dürfte jetzt degraded sein. Also exportieren, 'import -N' (ggf -f/F) und das cache-device sauber entfernen ('remove pool cache device'). Lass den cache weg - der macht erst wirklich Sinn wenn man nicht mehr RAM verbauen kann und dann auch nur wenn er auf schnellem speicher liegt (NVMe).
An einem Server hat nichts kritisches etwas auf einem USB-Speicher zu suchen! 1. zu langsam (erst recht für FS-cache), 2. zu unzuverlässig, 3. fallen USB-Flashspeicher aus wie die fliegen wenn sie für normalen i/o verwendet werden. Wenn USB/Flash genutzt wird, dann (quasi-)RO z.b. um ein immutable system (hypervisor o.ä.) zu booten. Nur updates für dieses system werden auf den Flashspeicher geschrieben (i.d.r. ein komplettes image), ansonsten gibt es keinerlei Schreibzugriffe darauf.

Die 4 Daten-Festplatten sind im sleep-Modus.
Da gehören Platten in einem Server garantiert nicht hin, erst recht nicht mit ZFS, das in regelmäßigen/kurzen intervallen housekeeping betreibt. Die Platten werden mehrere hundert mal am Tag aufgeweckt und sterben dir in kürzester Zeit ohne jegliche Chance auf RMA (da zu hohe power_cycle_count).
Die Wahrscheinlichkeit, dass die Ursache für deine Probleme eine oder mehrere sterbende Platten sind ist ziemlich hoch. Wie sehen die I/O Latenzen aus bzw ganz allgemein erstmal die SMART-Werte? Wenn hier schon Fehler/Warnungen vorhanden sind brauchst du nicht weiter suchen...
I.d.r wirft ZFS aber platten bereits wegen zu hohen Fehlerraten und/oder Latenzen aus dem pool noch bevor die Platte via SMART zugibt dass sie nichts mehr taugt; das kann sich aber u.U. mehrere Stunden mit den von dir beobachtetet Syptomen hinziehen wenn die Platte immer wieder entscheidet sich nochmal zu melden anstatt einfach nur zu Sterben (been there, done that...).

Wie ist der pool konfiguriert (mirror, raidz)? Korrekte blocksize/ashift? Läuft der zfsd und mit welcher Konfiguration? Grundlegende Infos die bisher nicht genannt wurden...

sdf und dm0 haben hohe await Zeiten; dort solltest du anfangen zu suchen. Zudem: liegt hier etwa ein dm-device unterhalb von ZFS? Den devicemapper braucht kein Mensch mehr mit ZFS...
Wirf sonst ggf wenn sdf eindeutig als Übeltäter identifiziert wurde den provider aus dem vdev (Redundanz ist ja hoffentlich vorhanden??) damit der pool wieder normal reagiert und du mit der weiteren Fehlersuche bzw Aufräumarbeiten vorankommst und nicht ständig von lockups/timeouts behindert wirst.
Dass sämtliche Dienste/Container/VMs (erst recht wenn kritische Daten "in flight" sein können) beendet werden sollten während der Fehlersuche/-behebung versteht sich hoffentlich von selbst (und um auszuschließen dass hier nirgends ein Dienst/script/job amok läuft). Da der pool vorher schon exportiert wurde, dürfte das aber sowieso bereits erledigt sein.


Sorry, aber wenn ich allein die wenigen bisher genannten Eckdaten des pools so anschaue, ist das wieder ein typischer Fall von vorsätzlich selbst in den Fuß geschossen... :roll:
Ich empfehle dir dich nochmal eingehend mit den Grundlagen von ZFS zu befassen, das wird dir zukünftig sicher einiges an Kopfschmerzen ersparen. Ich kann hierzu die beiden ZFS-Bücher von Michael W. Lucas wärmstens empfehlen.
Meine Empfehlung wäre dann: backup + nuke from orbit und nochmal mit einem neuen, sauberen pool anfangen. Ohne USB; ohne devicemapper; ohne sleepmode/standby an den HDDs.

hec_tech
Beiträge: 1093
Registriert: 28.06.2007 21:49:36
Wohnort: Wien
Kontaktdaten:

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von hec_tech » 09.01.2019 14:51:16

HDDs im sleep Modus und ZFS halte ich sowieso für keine gute Idee.
Die Metadaten würde ich auf eine SSD legen.

ZFS ist zwar nett aber braucht auch nicht gerade wenig Resourcen.

Was sagen eigentlich die SMART Werte der Disken?

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von r4pt0r » 09.01.2019 15:01:01

hec_tech hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 14:51:16
ZFS ist zwar nett aber braucht auch nicht gerade wenig Resourcen.
ZFS läuft bei mir (und vielen anderen) auch auf VPS mit 1GB RAM problemlos - der ARC kann (auf Kosten der Performance) so weit wie nötig zusammengestutzt werden bzw wird <512MB per default sogar komplett deaktiviert (zumindest unter FreeBSD und illumos; KA ob das in ZoL ebenfalls default ist) bzw kann auch manuell deaktiviert werden. ZFS läuft dann wie ein klassisches FS ohne zusätzlichen cache im RAM. Für Systeme mit niedriger I/O-Last und SSDs völlig legitim und praktikabel - der router/fw in meinem homelab läuft exakt in einer solchen Konfiguration um den begrenzten RAM für state- und BGP-tables zu nutzen.

Benutzeravatar
CountDracula
Beiträge: 86
Registriert: 14.01.2011 00:53:59
Wohnort: Transylvania

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von CountDracula » 09.01.2019 15:27:19

Hey r4pt0r! Danke für deine Antwort! :D
r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 14:48:51
Dir ist schon klar dass ein L2ARC schneller als die vdevs sein *muss*, da er als Überlaufcache bei zu wenig RAM agieren soll?
Ich habe dazu diese Anleitung gelesen: https://pthree.org/2013/05/09/zfs-admin ... sb-drives/
r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 14:48:51
Der pool dürfte jetzt degraded sein.
Wenn es nur ein READ-Cache war? Warum sollte der Pool dann degraded sein? Von ZFS erwarte ich eigentlich soviel Mitdenken, dass er nicht den ganzen Pool gegen die Wand fährt, nur weil der L2ARC ausfällt.
r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 14:48:51
Lass den cache weg - der macht erst wirklich Sinn wenn man nicht mehr RAM verbauen kann und dann auch nur wenn er auf schnellem speicher liegt (NVMe).
Als Langzeitlösung war das auch so geplant, aber ich wollte das erst so ausprobieren.
r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 14:48:51
Die 4 Daten-Festplatten sind im sleep-Modus.
Da gehören Platten in einem Server garantiert nicht hin, erst recht nicht mit ZFS, das in regelmäßigen/kurzen intervallen housekeeping betreibt.
Bei mir wachen die Festplatten etwa 3 mal pro Tag auf. (Heimserver)
r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 14:48:51
Wie sehen die I/O Latenzen aus bzw ganz allgemein erstmal die SMART-Werte? Wenn hier schon Fehler/Warnungen vorhanden sind brauchst du nicht weiter suchen...
SMART Werte (4x HDD, 2x SSD): NoPaste-Eintrag40579
r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 14:48:51
Wie ist der pool konfiguriert (mirror, raidz)? Korrekte blocksize/ashift? Läuft der zfsd und mit welcher Konfiguration? Grundlegende Infos die bisher nicht genannt wurden...
3 Pools:
  • mypool: 4x HDD Festplatten im raid-z1 (ja, kenne die Diskussionen um raid-z1) und ashift: 12. Blocksize habe ich nicht geändert.
  • ctpool: SSD ohne Verschlüsselung, ashift: 9
  • sofo: SSD, ashift: 12
r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 14:48:51
Zudem: liegt hier etwa ein dm-device unterhalb von ZFS? Den devicemapper braucht kein Mensch mehr mit ZFS...
Bisher unterstützt ZFS keine Verschlüsselung, daher liegt ZFS bei mir auf verschlüsselten Volumes.
I am Dracula. I bid you welcome.

hec_tech
Beiträge: 1093
Registriert: 28.06.2007 21:49:36
Wohnort: Wien
Kontaktdaten:

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von hec_tech » 09.01.2019 16:07:20

r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 15:01:01
hec_tech hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 14:51:16
ZFS ist zwar nett aber braucht auch nicht gerade wenig Resourcen.
ZFS läuft bei mir (und vielen anderen) auch auf VPS mit 1GB RAM problemlos - der ARC kann (auf Kosten der Performance) so weit wie nötig zusammengestutzt werden bzw wird <512MB per default sogar komplett deaktiviert (zumindest unter FreeBSD und illumos; KA ob das in ZoL ebenfalls default ist) bzw kann auch manuell deaktiviert werden. ZFS läuft dann wie ein klassisches FS ohne zusätzlichen cache im RAM. Für Systeme mit niedriger I/O-Last und SSDs völlig legitim und praktikabel - der router/fw in meinem homelab läuft exakt in einer solchen Konfiguration um den begrenzten RAM für state- und BGP-tables zu nutzen.
Ja in dieser Konfiguration ist das sicher ok. Wenn ich allerdings ZFS einsetze dann will ich da auch die Performance bekommen und die Features haben wie Dedup. Das kostet dann recht viel RAM.
Bei einer pfSense stimme ich deiner Konfiguration ganz zu wobei ich da mittlerweile auch Kisten mit mehr RAM habe. BGP Tables sind nicht gerade klein durch die ganze Fragmentierung und Dualstack.

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von r4pt0r » 09.01.2019 16:41:50

CountDracula hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 15:27:19
Hey r4pt0r! Danke für deine Antwort! :D
Ich habe dazu diese Anleitung gelesen: https://pthree.org/2013/05/09/zfs-admin ... sb-drives/
Nicht alles was man im Internet findet sollte man auch nachmachen. Es gibt Leute die sich Filmen während sie sich ins Gemächt treten lassen - würde ich ebenfalls nie nachmachen :wink:
Gerade zum Thema ZFS gibt es so einige gruselige und zweifelhafte Anleitungen. Ohne zu wissen was man da wirklich treibt sollte man grundsätzlich die Finger von _jedem_ 'how-to' lassen, erst recht wenn man vor hat dem entstandenen Monstrum seine Daten anzuvertrauen...
ZFS hat exzellente manpages; dort findet man schon die wichtigsten Grundlagen und eine Übersicht wie und warum ZFS so funktioniert wie es das tut und was im vergleich zu anderen FS beachtet werden sollte.
Alles weitere kann man sich über viel suchen und Dokumentation und/oder Quellcode bzw dessen Kommentare zusammensuchen - oder komprimiert, unterhaltsam und mit vielen Erfahrungen/Beispielen/Empfehlungen in den beiden genannten Büchern (die gemessen am Informationsgehalt spottbillig sind!)
Wenn es nur ein READ-Cache war? Warum sollte der Pool dann degraded sein? Von ZFS erwarte ich eigentlich soviel Mitdenken, dass er nicht den ganzen Pool gegen die Wand fährt, nur weil der L2ARC ausfällt.
Es fehlt ein provider, also ist der pool degraded. Da alle Daten aber noch zugänglich sind (auf den HDDs) arbeitet aber noch weiter, ansonsten wäre er FAULTED. Wenn auf dem USB-Stick auch noch ein SLOG gewesen wäre, hätte ZFS den pool deaktiviert (FAULTED), weil ein Teil der Daten (alle dirty writes die noch im log waren) fehlen - der pool müsste dann zuerst manuell wiederhergestellt werden indem er auf die letzte erfolgreiche "known good" transaktion zurückgesetzt wird.
Ich habe dir nur geraten den pool zu exportieren und ohne mounts wieder zu importieren, um zu verhindern dass auf den pool wieder "normal" zugegriffen wird und damit die von dir beschriebenen Symptome (lockups/timeouts) ausgelöst werden, bis du das Problem gefunden und behoben hast.

Bei mir wachen die Festplatten etwa 3 mal pro Tag auf. (Heimserver)
Wie hoch sind die power_cycle_counts der platten?
ZFS schreibt (sofern nicht geändert) mindestens alle 30sek eine transaktionsgruppe bzw sobald sie voll ist; dazu kommen metadaten (atime auch bei daten aus dem cache!) und natürlich periodische snapshots oder evtl laufende scrubs. Selbst auf einem leeren pool summiert sich das so weit, dass Platten mit extrem kurzen standby-timeouts immer sofort wieder aufgeweckt werden.
Da ZFS stark "burstig" schreibt, da transaktionen gesamelt und dann zusammen in einem langen zugriff linear geschrieben werden, kann das bei Platten mit extrem kurzen timeouts (WD green... :roll: ) exakt so interferieren, dass die platte unmittelbar vor dem nächsten flush in standby geht, nur um sofort wieder für die nächste TXgroup aufgeweckt zu werden. Der Zugriff hat dann extrem hohe Latenzen, was ZFS u.U. zusätzlich veranlasst stark zu throtteln (um die vermeintlich ausgelastete Platte zu schonen), was die Performance endgültig in die Knie reißt.
Man *könnte* ZFS soweit zurechtstutzen dass es damit zurechtkommt - der Aufwand und die Nachteile lohnen sich aber in keinster Weise. I.d.r. wiegen die kosten für häufige HDD-Defekte durch den extrem hohen Verschleiß beim anlaufen/ausschalten die Stromkosten beim Dauerlauf wieder auf - zumal es heutzutage etliche Serverplattenserien gibt, die für "lauwarmen" Speicher mit niedrigen I/O Anforderungen optimiert sind und sehr geringen Leistungsbedarf haben (2-3W im "freien Flug" ohne I/O)

Wenn man einen Storageserver Zuhause betreibt, macht es ohnehin Sinn dieses Datengrab auch für alles zu nutzen; dann ergibt sich automatisch ein ständiger bedarf an I/O; dafür spart man dann an den anderen Systemen. Mein Desktop hat Z.B. nur noch 1x 256MB NVMe und 2x 256MB SSD - alles was potentiell viel Speicherbedarf hat landet auf mounts am Storageserver. Testsysteme und ein NUC im Wohnzimmer laufen komplett ohne eigene Platten - die booten von NFS oder zvols am server. Man spart sich damit je nach Anzahl der Systeme im Haus massenhaft verteilte HDDs/SSDs die nie voll genutzt werden - dafür kann man eine Handvoll HDDs locker durchlaufen lassen...

SMART Werte (4x HDD, 2x SSD): NoPaste-Eintrag40579
load_cycle_count weit >3000 - q.e.d. :wink:
Dazu kommen extrem hohe command_timeout werte und viele power-off-retract-counts (=saft weg währrend die platte sich ausschaltet, also cache leert und in parkstellung geht).
hoher raw-wert für seek_error_rate ist bei seagate normal, die haben noch immer nicht gelernt normal zu zählen :roll:

Ein gut gemeinter Rat, da hier auch mal 6 Seagate ST4000VN in Betrieb waren: Migriere die Daten auf andere Platten und trenne dich ASAP von den Seagates. Ausfallrate betrug hier 100% in den ersten 2 Jahren, von den RMA-Platten sind 4 innerhalb eines Jahres wieder ausgefallen :roll: Mit anderen Seagate Serien in den letzten ~5 Jahren sah es oft nicht besser aus.
Mittlerweile gibt es hier für spinning rust nur noch HGST oder ggf noch WD.

3 Pools:
  • mypool: 4x HDD Festplatten im raid-z1 (ja, kenne die Diskussionen um raid-z1) und ashift: 12. Blocksize habe ich nicht geändert.
  • ctpool: SSD ohne Verschlüsselung, ashift: 9
  • sofo: SSD, ashift: 12
Zum Verständniss: ashift = alignment in 2^ashift bytes
SSDs melden sich leider immer noch mit blocksize von 512 bytes (danke an Redmont; deren spielzeug-OS hatte nämlich anno dazumal probleme mit größeren blöcken, daher dieser bescheuerte hack :roll: ) - korrekt wäre _mindestens_ 4k bzw für halbwegs aktuelle SSDs 8k. Je nach dem was auf den SSDs liegt können auch größere Blockgrößen (bis 1MB) Sinn machen um den overhead beim schreiben/lesen zu verringern und etwas mehr Performance zu bekommen (der Platzberarf-overhead durch padding steigt aber natürlich!).

Für SSD-pools also ashift=13, für HDDs die nicht nativ mit 512b arbeiten ashift=12

Raidz-1 ist OK, performance und overhead ist nicht gerade optimal, aber es gibt schlimmeres. Ich persönlich gehe bei 4 platten aber eher auf 2x2 mirror (+1 spare je nach system)

Bisher unterstützt ZFS keine Verschlüsselung, daher liegt ZFS bei mir auf verschlüsselten Volumes.
ZoL hat doch bereits seit einiger zeit native Verschlüsselung für datasets? In FreeBSD-CURRENT ist es AFAIK noch als experimentell markiert bzw deaktiviert.
Grundsätzlich sollte ZFS immer direkt auf die Platte; ohne Zwischenschicht oder Abstraktion (auch kein hw-raid!). Verschlüsselung ist gerade an einem Storageserver der ständig läuft IMHO auf Dateiebene besser aufgehoben - sobald der Server läuft sind die daten ohnehin entschlüsselt zugänglich. Die Verschlüsselung unterhalb von ZFS schützt also nur im unwahrscheinlichen Fall dass dir jemand alle Platten ausbaut und klaut...
Verschlüsselung auf Dateiebene ermöglicht alle normalen Backupstrategien ohne dass die Daten danach unverschlüsselt rumliegen und ist auch sonst wesentlich flexibler - ich habe den hype oder angeblich "dringenden Bedarf" an nativer Verschlüsselung in ZFS daher nie wirklich verstanden. Der einzig "halbwegs" sinnvolle Anwendungsfall wäre ggf mobile Geräte (Laptop); aber selbst hier ist IMHO Dateibasierte Verschlüsselung die bessere und flexiblere Wahl.
Nur meine Meinung dazu - hoffentlich wird der Thread jetzt nicht für Glaubenskriege missbraucht :oops:

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von r4pt0r » 09.01.2019 16:59:57

hec_tech hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 16:07:20
Ja in dieser Konfiguration ist das sicher ok. Wenn ich allerdings ZFS einsetze dann will ich da auch die Performance bekommen und die Features haben wie Dedup. Das kostet dann recht viel RAM.
Bei einer pfSense stimme ich deiner Konfiguration ganz zu wobei ich da mittlerweile auch Kisten mit mehr RAM habe. BGP Tables sind nicht gerade klein durch die ganze Fragmentierung und Dualstack.
Dedup hat heutzutage kaum noch wirklich legitime Anwendungsfälle. Plattenkapazitäten sind so hoch bei gleichzeitig extrem niedrigen Preisen, dass es sich nicht lohnt den vergleichsweise teuren RAM dafür zu verschwenden riesige deduptables vorzuhalten. Ganz abgesehen davon, dass bei den heutigen Poolgrößen die Wiederherstellung der deduptables beim reboot _extrem_ lange dauern kann und nicht mehr praktikabel ist.
Dedup lief hier testweise für datasets mit vielen jails die alle mit dem selben base-system liefen - die sinnvollere Lösung (auch was den Aufwand beim update angeht) ist aber ein nullfs-mount für alle diese jails. So läuft das bis heute - ganz ohne dedup und mit instant-upgrades für alle jails auf einmal "on-the-fly" 8)
Der Performancegewinn durch einen größeren ARC (am besten mit komprimierten datasets, dann sind die blöcke im arc ebenfalls compressed!), speziell jetzt mit resumable ARC, ist um ein vielfaches größer als der kleine "Kostenvorteil" durch etwas gesparten Plattenplatz - wie gesagt: die Dinger kosten sowieso nix mehr!

pfSense ist ohnehin sehr... sagen wir "seltsam" was den ressourcenverbrauch und die "optimierungen" betrifft.
OpenBGPd benötigt für die gesamte RIB mit v4+v6 fulltables etwas über 100MB (~120MB als ich das letzte mal nachgeschaut hab...). Da hat sich die letzten ~6 Monate _richtig_ viel getan, auch bei der Geschwindigkeit der filterengine (leider nur in OpenBSD, der port auf FreeBSD ist eingeschlafen...). Der Konfigurationssyntax ist ohnehin eine absolute Wohltat. Ich "mag" zwar IOS (hier läuft nur cisco im netzwerk...), aber diesen syntax für BGP bzw allgemein die Konfiguration eines Dienstes zu verwenden ist einfach abartig...

Mein FreeBSD-gateway läuft mit 8GB RAM - vor allem weil der sowieso billig verfügbar war.
Das OpenBSD gateway (router/gw/fw für testumgebung + fallback für "rest") läuft mit anteiligen 3GB RAM in seiner ldom, da der T1000 nur 8GB gesamt hat und es einfach nirgends mehr Sun-kompatiblen RAM zu "normalen" preisen gibt :roll:

Benutzeravatar
CountDracula
Beiträge: 86
Registriert: 14.01.2011 00:53:59
Wohnort: Transylvania

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von CountDracula » 09.01.2019 17:17:14

Vielen Dank für die zahlreichen Denkanstöße und Tipps :wink:

Ich bräuchte noch Hilfe was ich jetzt tun kann. Ich kann die Pools ja nicht exportieren. Es geht ja derzeit nichts mehr. (Kein zfs list, kein zfs export, kein zpool status, etc.)

Lässt sich irgendwo diese Klemme finden?

Hier z.B. ein strace von zfs list: NoPaste-Eintrag40580
I am Dracula. I bid you welcome.

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von r4pt0r » 09.01.2019 17:53:28

- reboot im singleuser-mode (bzw recovery mode nennt sichs glaube ich)
- zfs module manuell laden
- pool manuell importieren ohne mounts (-N); ggf mit -f/F da er DEGRADED ist (siehe auch manpage zu zpool und zfs)
- das cache device entfernen (zpool remove pool cache device)

Dann die Ursache für die I/O Latenzen lokalisieren. Wie gesagt: sdf hat hohe awaits; wenn diese ständig so hoch bzw deutlich höher als bei den anderen platten war ist das vermutlich die Ursache. Da die Plattenbezeichnungen sich ändern können, *irgendwie* feststellen welche jetzt sdf ist - nicht nur mit ZFS macht es _immer_ Sinn statt diesen random vergebenen Bezeichnern Labels (GPT) zu verwenden, dann findet man eine Platte absolut sicher wieder. Nimmt man als Label die/einen Teil der Seriennr/UUID und ggf noch die physikalische position im Server, tut man sich nochmals einfacher bei der Fehlersuche (wie jetzt z.B....)

Wenn du dir sicher bist, dass sdf die ursache ist, diese aus dem vdev entfernen (zfs detach - NICHT remove!). Am besten schon einen Ersatz bereithalten fürs anstehende resilvern. Normalerweise startet man vor dem entfernen einer fehlerhaften Platte das resilvering; in diesem Fall würde die Platte wohl das ganze nur blockieren - daher hier erst detach; dann resilver.
Alle mountpunkte des pools einhängen (zfs mount -a) und wenn dann soweit alles passt in multiuser-mode wechseln (oder reboot).

Ich hoffe du hast sowieso immer ein aktuelles backup - ansonsten trotzdem nochmal der Hinweis: backups! Mindestens eine Platte stirbt hier wohl gerade; die anderen sehen IMHO auch nicht mehr gesund aus (und sind Seagates mit denen ich katastrophale Erfahrungen gesammelt habe...) - die Daten in dem Pool sind aktuell also höchst gefährdet. Jetzt noch ein zfs send|receive anstoßen wird eher aussichtslos sein, da die blockierende Platte das wohl unmöglich macht. Spätestens nach dem entfernen (und resilver) würde ich aber sicherheitshalber auf eine "gesunde" platte den gesamten Pool sichern und dieses backup dann auch aktuell halten.

Benutzeravatar
CountDracula
Beiträge: 86
Registriert: 14.01.2011 00:53:59
Wohnort: Transylvania

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von CountDracula » 09.01.2019 17:56:44

r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 17:53:28
Wie gesagt: sdf hat hohe awaits;
sdf ist der USB-Stick auf dem das Betriebssystem (ext4) liegt. Dieser funktioniert ja noch. Nur auf ZFS Pools und dessen Verzeichnisse lässt sich nicht mehr zugreifen.

Code: Alles auswählen

root@server:~# parted /dev/sdf print free
Modell: SanDisk Ultra (scsi)
Festplatte  /dev/sdf:  62,2GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ      Dateisystem   Flags
        32,3kB  1049kB  1016kB           Freier Platz
 1      1049kB  2000MB  1999MB  primary  ext4          boot
 2      2000MB  62,2GB  60,2GB  primary
        62,2GB  62,2GB  1049kB           Freier Platz
I am Dracula. I bid you welcome.

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von r4pt0r » 09.01.2019 18:32:35

CountDracula hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 17:56:44
sdf ist der USB-Stick auf dem das Betriebssystem (ext4) liegt. Dieser funktioniert ja noch. Nur auf ZFS Pools und dessen Verzeichnisse lässt sich nicht mehr zugreifen.
Gut, USB erklärt natürlich die grottenschlechten latenzen...

Dann nochmal weiter unten ansetzen bzw die basics abklappern, da diese noch nicht von dir als gecheckt genannt wurden... Irgendwas *scheint* blockierend auf I/O zu warten; da das schlechteste/langsamste Gerät der USB-Stick ist können wir erstmal mal von ZFS absehen (auch wenn der pool nicht gerade 'sauber' ist...). Ich nehme an du hast dir schon angeschaut welche Prozesse laufen und es ist nichts dabei was hohe cpu-last (evtl auch in bursts) verursacht bzw im "LOCK", "WAIT" oder "ZOMBIE" state ist? (-> top)

Alle Dienste (ausser ssh natürlich...) und container sind beendet?
Keine hängenden NFS-mounts?
/var/log/messages und/oder syslog sind sauber (du hast bisher nur was von dmesg geschrieben)? Ggf auch mal die Größe aller Dateien in /var/log anschauen ob ggf die dedizierte logfile eines bestimmten Dienstes überläuft (wäre der einfachste Fall...)
Dateisysteme auf denen das OS liegt sind nicht voll? Speziell für /var und ggf /cache und /usr. Linux hält sich schon lange nicht mehr sauber an die FS-hierarchie, da wird auch gerne mal /etc oder /lib mit Laufzeitdaten zugemüllt - also _alle_ Dateisysteme auf vorhandenen platz Prüfen! (df -alh) [edit]: Du hast anscheinend sowieso alles auf einer partition - trotzdem: läuft die über?

SWAP läuft nicht über (hattest du IIRC deaktiviert)? Wieviel RAM ist verfügbar? (Schießt der oom-killer von Linux eigentlich noch immer wahllos sämtlichen Prozessen in den Kopf die sich nicht schnell genug ducken?)

Und nur um sicher zu gehen: wurde das System seither neu gestartet? Wenn nicht: NICHT neu starten; wir sind nicht bei Microsoft. Fehler analysieren, beheben, DANN neu starten.

Benutzeravatar
CountDracula
Beiträge: 86
Registriert: 14.01.2011 00:53:59
Wohnort: Transylvania

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von CountDracula » 09.01.2019 19:27:09

r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 18:32:35
Ich nehme an du hast dir schon angeschaut welche Prozesse laufen und es ist nichts dabei was hohe cpu-last (evtl auch in bursts) verursacht bzw im "LOCK", "WAIT" oder "ZOMBIE" state ist? (-> top)
htop: https://imgur.com/a/RnTuNuo

top: https://imgur.com/a/Q3ELMt5

Es gibt tatsächlich einen Zombie:

Code: Alles auswählen

root@server:~# ps aux | grep Z
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       814  0.6  0.0      0     0 ?        Zsl   2018 139:30 [lxd] <defunct>
Das müsste der Prozess sein, den ich gestern versucht habe zu killen.
r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 18:32:35
Alle Dienste (ausser ssh natürlich...) und container sind beendet?
Nein. Ich kann nichts mehr beenden, weil z.B. lxc list auch nicht mehr ausführbar ist. Das heißt, die Container laufen aber sind im Grunde auch nicht nutzbar. Die Container System liegen auf dem ZFS Pool ctpool. (Edit: Der Dienst collectd läuft noch und schreibt seine Daten im RAM/tmpfs. Diesen habe ich jetzt beendet.)

Das Wurzelverzeichnis / (ext4) ist mit 30% ausgelastet und /boot (ext4) mit 13%. Für das Betriebssystem und die Logs ist dementsprechend noch genug Speicherplatz da. Die Logdateien (wie syslog) werden weiterhin normal geschrieben.

Die SWAP habe ich deaktiviert, weil ich vermutet habe, dass dort der Flaschenhals ist. War leider nicht der Fall. SWAP war glaub zu 5% ausgelastet davor.
r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2019 18:32:35
Und nur um sicher zu gehen: wurde das System seither neu gestartet?
Nein. Bisher läuft es unverändert weiter. Würde am liebsten die blockierenden Prozess killen oder das blockierende Device resetten und dann neu starten.
I am Dracula. I bid you welcome.

Benutzeravatar
CountDracula
Beiträge: 86
Registriert: 14.01.2011 00:53:59
Wohnort: Transylvania

Re: Server reagiert nur eingeschränkt (load average >75, i/o wait ~50%)

Beitrag von CountDracula » 10.01.2019 19:52:41

Ich habe den Rechner jetzt neugestartet. Beim Herunterfahren konnte er einige ZFS mounts nicht aushängen:
Bild

Den USB-Stick, auf dem das Betriebssystem läuft, habe ich an einem anderen Rechner komplett mit dd eingelesen. Dabei gab es keine Lesefehler. Das cache device habe vom Pool entfernt. Als nächstes werde ich den großen Datenpool mypool überprüfen lassen.
I am Dracula. I bid you welcome.

Antworten