Schleppender Zugriff auf Ordner #NFS #XFS

[maxmad]

Hallo zusammen! Ich beschreibe zuerst einmal mein Problem und dann gehe ich genauer auf die technischen Eckdaten zu den Systemen ein. Grundsätzlich:

Auf einem Linux System "A" existiert ein Ordner der relativ langsam reagiert wenn man per cd auf der Kommandozeile in Ihn wechselt bzw. das gleich langsame Reaktionsverhalten tritt auf wenn man per ls -la den Inhalt auflistet. Nun kommt jedoch noch hinzu dass dieser Ordner per NFS-Export freigegeben ist und auf einem Linux-System "B" per fstab eingebunden ist. Auf System "B" läuft ein per Cronjob gesteuertes Script das mit Daten aus diesem Ordner arbeitet. Auf System B ist der Wechsel in den besagten Ordner und das Auflisten seiner Inhalte noch deutlich langsamer als auf dem Quellsystem A. Das scheint dazu zu führen dass das Script abbricht und man anschließend auf beiden Systemen nicht mehr in den besagten Ordner wechseln kann. Alle Prozesse die auf ihn zugreifen sind mit dem Zustand "D" gekennzeichnet.

Meine Frage wäre nun, woran liegt das? Auf beiden Systemen ist Suse Linux Enterprise 12 mit SP1 installiert. Als Dateisystem kommt XFS zum einsatz und die Partition auf der der Ordner liegt ist ca. 1,5 TB groß. Das Script habe ich nicht selber geschrieben sondern nur übernommen. Würde ich als Ursache aber ehr ausschließen da ja auch auf dem Quellsystem A der Zugriff auf den Ordner leicht verzögert ist.

Meine erste Vermutung war das es Probleme mit dem NFS-Mount gibt aber grade gehen meine Vermutungen mehr in die Richtung dass das XFS-Dateisystem so stark fragmentiert ist dass die Zugriffszeiten so langsam werden dass der Mount aus dem Tritt kommt und das Script die Verarbeitung abbricht und alles andere "mitreißt". Kann das bei einer Fragmentierung von ca. 51 % als Ursache in betracht kommen?

Bzw. wie ist XFS als Dateisystem generell zu sehen was die Stabilität und Zuverlässigkeit angeht? Ich bin für jegliche Denkanstöße und Lösungsansätze dankbar!

 

[andy_m4]

Stell die Log-Level entsprechend hoch um einzugrenzen, wo es denn nu genau hängt. Ansonsten bleiben es Ratespielchen. Und wozu, wenn man so ein Hilfsmittel zur Hand hat.

 

[maxmad]

Stell die Log-Level entsprechend hoch um einzugrenzen, wo es denn nu genau hängt. Ansonsten bleiben es Ratespielchen. Und wozu, wenn man so ein Hilfsmittel zur Hand hat.

Naja, die Idee hatte ich auch schon aber leider bin ich in der Loganalyse noch nicht sonderlich erfahren. In welchen von den diversen Logfiles könnte ich denn nach Ereignissen im Zusammenhang mit NFS und XFS suchen?

 

[snaxilian]

- Mit welchen Parametern ist das XFS-Dateisystem gemountet auf Server A? Siehe /etc/fstab
- Liegt das XFS auf einem Raid oder einer einzelnen Platte?
- Mit welchen Parametern wird das NFS exportiert? Siehe /etc/exports
- Wie hast du den Grad der Defragmentierung festgestellt? (xfs_db -c frag -r /dev/sdX) ?
- Falls er wirklich so hoch ist > Bessert sich das Verhalten nach einer Defragmentierung?

 

[andy_m4]

In welchen von den diversen Logfiles könnte ich denn nach Ereignissen im Zusammenhang mit NFS und XFS suchen?

Na komm. Das Du herausfindest, wo Deine Logs liegen trau ich Dir schon noch selbst zu.
Andernfalls darfst Du auch gern eine Suchmaschine Deiner Wahl bemühen.
Aber erwarte bitte nicht, alles vorgekaut zu bekommen.

 

[maxmad]

- Mit welchen Parametern ist das XFS-Dateisystem gemountet auf Server A? Siehe /etc/fstab
- Liegt das XFS auf einem Raid oder einer einzelnen Platte?
- Mit welchen Parametern wird das NFS exportiert? Siehe /etc/exports
- Wie hast du den Grad der Defragmentierung festgestellt? (xfs_db -c frag -r /dev/sdX) ?
- Falls er wirklich so hoch ist > Bessert sich das Verhalten nach einer Defragmentierung?

- System A exportiert per NFS sein Verzeichnis /daten an System B. Parameter nur das nötigsten. Also nfs und 0 0
- Es handelt sich jeweils im virtuelle Festplatten die per ISCSI von einem SAN-Cluster in einen ESXi eingebunden werden
- xfs_db -c frag -r /dev/sdX ja genau auf diese Weise
- Hab ich noch aufgrund der Größe von 1,5 TB und laufenden Zugriffen noch nicht getestet. Geht ja soweit ich weiß nur wenn das Volume nicht eingehängt ist. Das anfertigen des Backups hat etwas länger gedauert aber die Woche kann ich wohl noch einen Test wagen.

Ergänzung (28. März 2017)

Na komm. Das Du herausfindest, wo Deine Logs liegen trau ich Dir schon noch selbst zu.
Andernfalls darfst Du auch gern eine Suchmaschine Deiner Wahl bemühen.
Aber erwarte bitte nicht, alles vorgekaut zu bekommen.

Dass die Logs im Regelfall unter /var/log liegen ist mir wohl bekannt und das es sich um ein System handelt das diese Version von SLES bereits systemd und damit journalctl nutzt ist mir wohl bewusst auch ohne eine Suchmaschine zu bedienen. Ich hatte nur die Hoffnung das vielleicht jemand einen gezielten Tip hat bevor ich Seitenweise Foren wühle bis ich einen Hinweis finde worauf bei NFS ggf. zu achten ist. Leider findet sich dazu bisher kein brauchbarer Eintrag aber die Suche geht weiter.

 

[snaxilian]

Okay auch wenn Server_B das Verzeichnis /daten per NFS erhält, muss dieser Pfad bzw Partition ja auch irgendwie auf Server_A gemountet sein. Diese Mount-Parameter meine ich.
Ich vermisse auch Antwort auf die /etc/exports, z.B. kann man den Wert "async" setzen. Damit gewinnst Performance, riskierst aber Datenverlust bei instabiler Verbindung oder falls einer der Server spontan abraucht.

Wenn du die Daten vom SAN durch einen ESXi durch eine VM per NFS woandershin durch reichst: Das SAN als Bottleneck hast du bereits ausgeschlossen hoffe ich?
So oder so: Ggf mal überlegen ob es nicht eine Option ist, die LUN des SAN direkt Server_B zur Verfügung zu stellen sofern möglich?

Die Defragmentierung kannst auch im laufenden Betrieb durchführen und musst das Dateisystem nicht unmounten. Lektüre der manpage empfehle ich trotzdem.

 

[andy_m4]

Dass die Logs im Regelfall unter /var/log liegen ist mir wohl bekannt und das es sich um ein System handelt das diese Version von SLES bereits systemd und damit journalctl nutzt ist mir wohl bewusst auch ohne eine Suchmaschine zu bedienen.

Und wo ist dann also das Problem sich die Logs mal anzuschauen bzw. bei Unklarheiten konkrete Fragen zu stellen?

Ich hatte nur die Hoffnung das vielleicht jemand einen gezielten Tip hat bevor ich Seitenweise Foren wühle bis ich einen Hinweis finde worauf bei NFS ggf. zu achten ist. Leider findet sich dazu bisher kein brauchbarer Eintrag aber die Suche geht weiter.

Theoretisch kann man nicht viel falsch machen. Falls doch ein Problem auftritt, hilft ein Blick in die Logs die man notfalls auch hier posten kann, wenn man sie nicht versteht.

 

[mensch183]

Ordner der relativ langsam reagiert wenn man per cd auf der Kommandozeile in Ihn wechselt bzw. das gleich langsame Reaktionsverhalten tritt auf wenn man per ls -la den Inhalt auflistet

Führe die Operationen mit strace aus. Dann siehst du, wobei genau er so viel Zeit vertüdelt. Also etwa:
strace -r ls ordner
strace -c ls ordner

Wenn man den/die syscall(s) gefunden, die so ewig brauchen, kommt man mit der Suche nach der Ursache ggf. einen Schritt weiter.

Bei "cd" (als shellinternes Kommando) funktioniert das auf diese Weise nicht. Da müsstest du die ganze Shell im strace beobachten.

 

[maxmad]

Okay auch wenn Server_B das Verzeichnis /daten per NFS erhält, muss dieser Pfad bzw Partition ja auch irgendwie auf Server_A gemountet sein. Diese Mount-Parameter meine ich.
Ich vermisse auch Antwort auf die /etc/exports, z.B. kann man den Wert "async" setzen. Damit gewinnst Performance, riskierst aber Datenverlust bei instabiler Verbindung oder falls einer der Server spontan abraucht.

Wenn du die Daten vom SAN durch einen ESXi durch eine VM per NFS woandershin durch reichst: Das SAN als Bottleneck hast du bereits ausgeschlossen hoffe ich?
So oder so: Ggf mal überlegen ob es nicht eine Option ist, die LUN des SAN direkt Server_B zur Verfügung zu stellen sofern möglich?

Die Defragmentierung kannst auch im laufenden Betrieb durchführen und musst das Dateisystem nicht unmounten. Lektüre der manpage empfehle ich trotzdem.

Die Exports sind mit den Parametern (rw,no_root_squash,sync,no_subtree_check) konfiguriert. Habe sync testweise auch schon auf async gesetzt. Hat leider keinen Effekt auf den Fehler gehabt.

Das SAN hat soweit ich das beurteilen kann noch "Luft". Mein Problem ist halt das ich das Setting nicht selber aufgebaut sondern nur übernommen habe und auch nur wenig Zeit habe mich intensiv mit dem Thema zu befassen es aber trotzdem irgendwie gelöst bekommen muss.

Als nächstes wollte ich mich dann an der Defragmentierung versuchen und schauen welche Effekte das hat. Momentan würde ich wirklich ehr auf das Filesystem als Fehlerquelle tippen als auf ein Problem mit NFS. Oder kann es sein das der Ordner beim Zugriff blockiert weil bereits zu viele Verbindungen darauf existieren? Wenn ja wie bekomme ich das ggf. raus?

Ergänzung (30. März 2017)

Und wo ist dann also das Problem sich die Logs mal anzuschauen bzw. bei Unklarheiten konkrete Fragen zu stellen?



Theoretisch kann man nicht viel falsch machen. Falls doch ein Problem auftritt, hilft ein Blick in die Logs die man notfalls auch hier posten kann, wenn man sie nicht versteht.

Speziell zu NFS habe ich in den Logs noch nichts gefunden. Die kompletten Logs dürfen nicht veröffentlicht werden.

 

[mensch183]

Wenn der Server (dein Linux System "A" ) ganz für sich allein schon Auffälligkeiten zeigt, lohnt es sich doch gar nicht, sich zuerst um das von diesem Server bereitgestellte NFS zu kümmern, was die Probleme des Servers lediglich weiter trägt.

 

[exuser0815]

Auf einem Linux System "A" existiert ein Ordner der relativ langsam reagiert wenn man per cd auf der Kommandozeile in Ihn wechselt bzw. das gleich langsame Reaktionsverhalten tritt auf wenn man per ls -la den Inhalt auflistet.

Hast du 100.000e Files/Dirs direkt in diesem Verzeichnis?
Dann hast Du deine Antwort schon.

 

[andy_m4]

Speziell zu NFS habe ich in den Logs noch nichts gefunden.

Du willst uns verarschen, oder?

Also halten wir fest: Du willst keine Logs einsehen. Du willst den Vorschlag mit strace nicht ausprobieren.

Allzu ernst kann es Dir also mit der Fehlersuche nicht sein.

[...]
Habe sync testweise auch schon auf async gesetzt. Hat leider keinen Effekt auf den Fehler gehabt.
[...]
Als nächstes wollte ich mich dann an der Defragmentierung versuchen und schauen welche Effekte das hat.

Das ist doch alles nur ein stochern im Nebel. Schau Dir endlich die Logs an oder mach was mit strace.
Alles andere ist planloses Vorgehen.

Wenn ja wie bekomme ich das ggf. raus?

Antwort wie immer: Logs.

Mein Problem ist halt das ich das Setting nicht selber aufgebaut sondern nur übernommen habe und auch nur wenig Zeit habe mich intensiv mit dem Thema zu befassen es aber trotzdem irgendwie gelöst bekommen muss.

Wenn man derart konsequent alle hilfreichen Hinweise ignoriert, dann bist Du eindeutig der falsche Mann für den Job. Sorry, wenn ich das so klar sage.