Ich habe einen CentOS 6.4-Dateiserver mit NFS 4, der einige XFS-Dateisysteme bedient. Es sind einige Dutzend Clients damit verbunden. Heute kam es für die Clients nur noch langsam voran – die Clients blieben hängen oder reagierten erst nach einigen Minuten, wenn sie vom Server aus auf die gemountete NFS-Freigabe zugriffen. Auf dem Server selbst konnte ich problemlos auf die freigegebenen Dateisysteme zugreifen. Das Problem war nach etwa vier Stunden behoben, aber ich weiß nicht, warum – siehe unten.
topzeigte mehrere migrationProzesse und xfssyncdProzesse, die ungewöhnlich viel CPU-Leistung verbrauchten, wobei die Leistung alle paar Sekunden zwischen 0 % und bis zu 100 % schwankte. Es waren keine anderen Prozesse merklich aktiv. Die von top gemeldete Gesamt-CPU-Auslastung war niedrig, wie folgt:
Cpu(s): 0.0%us, 4.2%sy, 0.0%ni, 95.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Ich konnte online nichts Spezielles zu diesem Thema finden, außer vielleicht einem RHEL-Supporteintrag im Abonnentenbereich, den ich nicht sehen kann.
Ich habe ausgeführt service nfs restart. Dann service nfs statuswurden laufende Daemons angezeigt, außer nfsd dead but subsys locked. Nach einem weiteren Neustart war dies verschwunden und NFSD lief, aber die Clients hingen immer noch.
Ich habe einige Dinge ausprobiert, die für xfssyncd-bezogene Probleme vorgeschlagen wurden:
1) mount –o remount /mnt/dataauf dem exportierten Dateisystem. Interessanterweise dauerte die Ausführung dieses Befehls etwa eine Minute, und während dieser Zeit beruhigten sich die „wilden“ Prozesse. Aber nachdem der Befehl fertig ausgeführt war, war die CPU-Auslastung der Prozesse wieder hoch.
2) echo 720000 > /proc/sys/fs/xfs/xfssyncd_centisecsum das Synchronisierungsintervall für xfssyncd zu ändern. Dies machte keinen merklichen Unterschied, was nicht allzu überraschend ist, da das FS mit NFS-Clients beschäftigt ist und das Problem etwas anderes sein muss.
Ich hatte vor 3 Wochen ein Problem mit diesem Server, bei dem eine .nfsNNN-Datei (aus einer entfernten Datei, die noch geöffnet ist und auf die zugegriffen wird) schnell voll wurde und auf einem Client eine sich wiederholende Fehlermeldung ausgab. Durch das Beenden des Problemprozesses wurde die NFS-Verlangsamung behoben. [Allerdings wurde der Dateiserver dann ein paar Tage später wieder langsamer, ohne dass ein solches .nfsNNN-Dateiproblem auftrat, und ich musste ihn schließlich einfach neu starten. Zu der Zeit sah ich einige Prozesse mit ungewöhnlichen CPU-Levels, habe mir aber nicht gemerkt, welche das waren, und kann mich jetzt nicht erinnern, ob es dieselben waren wie das aktuelle Problem.]
Ich habe heute erneut nach offenen .nfsNNN-Dateien gesucht, die möglicherweise Probleme verursachten, aber keine gefunden. Ich habe einige von vor ein paar Monaten gelöscht, aber sie wurden derzeit nicht geändert, also dachte ich, sie wären kein Problem. Ich habe nach dem Löschen dieser Dateien keinen Unterschied festgestellt.
Ungefähr eine Stunde nachdem ich die oben genannten Dinge ausprobiert hatte, lief der Server wieder normal und die migrationProzesse xfssyncdhatten keine hohe CPU-Auslastung mehr. Ich weiß nicht, was sich geändert hat, aber ich würde gerne versuchen, das herauszufinden, da es so aussieht, als könnte es wieder passieren.
Danke für alle Vorschläge.
-M
Antwort1
Ich habe einen RHEL 6.10 mit ähnlichen Problemen. Das einzige, was zu helfen scheint, ist, lang laufende Benutzer-SFTP-Prozesse auf dem NFS-Client zu beenden. Dabei handelte es sich um Prozesse, die von GUI-basierten SFTP-Clients (z. B. WinSCP, Nimble Commander) viele Stunden (> 10 Stunden) lang offen gehalten wurden.
Die Überwachung zeigt, dass einige NFSv3-Client-Aktivitäten mit dem Problem zusammenfallen, tatsächlich ist die Aktivität jedoch geringer als eine andere typische Aktivität auf anderen Clients (es gibt > 100 Clients), die das Problem nicht verursacht.
Es wird auch nicht wirklich viel E/A durchgeführt.
UPDATE 2019-12-10: Die Hauptursache scheinen XFS-Kontingente auf dem NFS-Server gewesen zu sein. Den Home-Verzeichnissen der Benutzer werden Kontingente auferlegt, wobei das Soft-Limit 2 GB unter dem Hard-Limit liegt. Einige Benutzer versuchten, eine vollständige Anaconda Python zu installieren, die das Soft-Limit überschritt. Das Anaconda-Installationsprogramm schien keine Möglichkeit zu haben, die Warnungen abzufangen, und lud weiterhin Dateien über das Soft-Limit hinaus herunter. Dies führte zu einer enormen Anzahl von Kontingentwarnungen, die das System völlig ausbremsten und es reaktionslos machten.
Ich sage „scheint“, weil die Beweise nur Indizien sind. Als die Benutzer versuchten, die Installation in einem Verzeichnis ohne Kontingent durchzuführen, lief alles problemlos.