Lord Gurke
Nur echt mit 32 Zähnen
Hallo zusammen,
ich suche nach einer Möglichkeit herauszufinden, welche Dateien vom NFS-Server-Prozess geöffnet sind. Bonus wäre, wenn sich herausfinden ließe, welcher Client sie geöffnet hält.
Hintergrund:
Ich habe hier einen NFS-Server stehen, welcher zwei logische Volumes hat, die per NFS zur Verfügung gestellt werden. Auf beiden Volumes sind jeweils ca. 2-3 Millionen Dateien vorhanden, verteilt auf einige Tausend Verzeichnisse und Unterverzeichnisse.
Diese werden beide auf 12 verschiedenen Clients per NFS4 eingemounted und können auch von allen Clients beschrieben werden.
Einige der Datein auf den Shares sind ZIP-Archive mit bis zu mehreren GB Größe, welche per Cronjob erstellt und nahezu täglich überschrieben werden.
Sowohl Server als auch Clients sind aktuelle CEntOS 7-Systeme.
Jetzt tritt das Problem auf, dass das Dateisystem (ext4) einer dieser Freigaben über mehrere Tage hinweg kontinuierlich voll läuft.
Zudem läuft auch der Arbeitsspeicher immer weiter voll, so dass es bereits zu OOM-Kills kam. Beendet man den NFS-Dienst, ist das Dateisystem innerhalb weniger Sekunden wieder auf normalem Level und der RAM quasi leer. Dann wiederholt sich das Spiel wieder.
Betroffen ist aber nur einer von beiden Shares - das kann aber eventuell auch daran liegen, dass auf diesem Share einfach viel mehr Schreiboperationen von verschiedenen Systemen stattfinden.
Lässt man einen fsck auf einen Snapshot des Dateisystems laufen, werden hunderttausende "orphaned Inodes" gemeldet.
Zudem steigt im Betrieb auch die Anzahl allozierter File-Descriptors (abgefragt über sysctl) stetig an und passt zum RAM- und Dateisystemverbrauch.
Insgesamt manifestiert sich daher bei mir der Eindruck, dass auf dem NFS-Server (oder einem der Clients) die Dateien nicht ordentlich geschlossen werden und deshalb der Platz weiterhin belegt wird.
Bisher ist es mir nicht gelungen, mit den bekannten Mitteln wie lsof oder der Suche im /proc-Verzeichnis herauszufinden, welche Dateien betroffen sind - geschweige denn, welcher Client diese Datei offen hält.
Ich bin mir nicht einmal sicher, ob überhaupt ein Client daran Schuld ist...
Es wurde einmal testweise der Share auf allen Clients unmounted, was keine Verbesserung brachte. Erst das Stoppen des NFS-Servers gab den blockierten Platz wieder frei.
Gibt es irgendwelche Tools, mit denen ich herausfinden kann, welche Dateien konkret per NFS geöffnet sind und (Bonus) von wem?
Auch die ekligsten Debug-Möglichkeiten sind mir herzlich willkommen - ich suche nun schon seit November nach der Ursache und stehe kurz davor, morgen den Kernel per Sysrq crashen zu lassen um den Dump zu analysieren
Danke!
ich suche nach einer Möglichkeit herauszufinden, welche Dateien vom NFS-Server-Prozess geöffnet sind. Bonus wäre, wenn sich herausfinden ließe, welcher Client sie geöffnet hält.
Hintergrund:
Ich habe hier einen NFS-Server stehen, welcher zwei logische Volumes hat, die per NFS zur Verfügung gestellt werden. Auf beiden Volumes sind jeweils ca. 2-3 Millionen Dateien vorhanden, verteilt auf einige Tausend Verzeichnisse und Unterverzeichnisse.
Diese werden beide auf 12 verschiedenen Clients per NFS4 eingemounted und können auch von allen Clients beschrieben werden.
Einige der Datein auf den Shares sind ZIP-Archive mit bis zu mehreren GB Größe, welche per Cronjob erstellt und nahezu täglich überschrieben werden.
Sowohl Server als auch Clients sind aktuelle CEntOS 7-Systeme.
Jetzt tritt das Problem auf, dass das Dateisystem (ext4) einer dieser Freigaben über mehrere Tage hinweg kontinuierlich voll läuft.
Zudem läuft auch der Arbeitsspeicher immer weiter voll, so dass es bereits zu OOM-Kills kam. Beendet man den NFS-Dienst, ist das Dateisystem innerhalb weniger Sekunden wieder auf normalem Level und der RAM quasi leer. Dann wiederholt sich das Spiel wieder.
Betroffen ist aber nur einer von beiden Shares - das kann aber eventuell auch daran liegen, dass auf diesem Share einfach viel mehr Schreiboperationen von verschiedenen Systemen stattfinden.
Lässt man einen fsck auf einen Snapshot des Dateisystems laufen, werden hunderttausende "orphaned Inodes" gemeldet.
Zudem steigt im Betrieb auch die Anzahl allozierter File-Descriptors (abgefragt über sysctl) stetig an und passt zum RAM- und Dateisystemverbrauch.
Insgesamt manifestiert sich daher bei mir der Eindruck, dass auf dem NFS-Server (oder einem der Clients) die Dateien nicht ordentlich geschlossen werden und deshalb der Platz weiterhin belegt wird.
Bisher ist es mir nicht gelungen, mit den bekannten Mitteln wie lsof oder der Suche im /proc-Verzeichnis herauszufinden, welche Dateien betroffen sind - geschweige denn, welcher Client diese Datei offen hält.
Ich bin mir nicht einmal sicher, ob überhaupt ein Client daran Schuld ist...
Es wurde einmal testweise der Share auf allen Clients unmounted, was keine Verbesserung brachte. Erst das Stoppen des NFS-Servers gab den blockierten Platz wieder frei.
Gibt es irgendwelche Tools, mit denen ich herausfinden kann, welche Dateien konkret per NFS geöffnet sind und (Bonus) von wem?
Auch die ekligsten Debug-Möglichkeiten sind mir herzlich willkommen - ich suche nun schon seit November nach der Ursache und stehe kurz davor, morgen den Kernel per Sysrq crashen zu lassen um den Dump zu analysieren
Danke!
