Wie finde ich ein Dateideskriptorleck?

11

Ich habe einen Java-Prozess (Glassfish), bei dem Dateideskriptoren verloren gehen. Ich weiß das, weil ich die hilfreiche java.io.IOException: Too many open filesAusnahme bekomme . Ich kann /proc/PID#/fdalle offenen Dateideskriptoren einsehen und sehen. Wenn ich lsof benutze, bekomme ich eine sehr große Anzahl solcher Einträge:

Java 18510 Wurzel 8811u Socke 0,4 1576079 kann Protokoll nicht identifizieren
Java 18510 Wurzel 8812u Socke 0,4 1576111 kann Protokoll nicht identifizieren
Java 18510 Wurzel 8813u Socke 0,4 1576150 kann Protokoll nicht identifizieren

Ich sehe 12 neue pro Minute erstellt. Welche Optionen kann ich auf lsof verwenden oder welche anderen Tools stehen mir zur Verfügung, um Socket-Dateideskriptoren aufzuspüren, bei denen das Protokoll nicht identifiziert werden kann?

lsof max-file-descriptors

— cclark
quelle

//, Viele gute Antworten auf diese Frage sind nur eine Suchmaschinenabfrage entfernt ... duckduckgo.com/?q=How+to+track+down+a+file+descriptor+leak

— Nathan Basanese

7

So zeigen Sie die Top-20-Dateihandles mithilfe von Prozessen an:

for x in `ps -eF| awk '{ print $2 }'`;do echo `ls /proc/$x/fd 2> /dev/null | wc -l` $x `cat /proc/$x/cmdline 2> /dev/null`;done | sort -n -r | head -n 20

Die Ausgabe erfolgt im Format Dateihandle count, pid, cmndline für den Prozess

Beispielausgabe

701 1216 /sbin/rsyslogd-n-c5
169 11835 postgres: spaceuser spaceschema [local] idle
164 13621 postgres: spaceuser spaceschema [local] idle
161 13622 postgres: spaceuser spaceschema [local] idle
161 13618 postgres: spaceuser spaceschema [local] idle

— Johnjamesmiller
quelle

4

Machen Sie sich mit dem Befehl strace vertraut. Es überwacht Systemaufrufe. Ich habe es kürzlich verwendet, um Dateideskriptorlecks aufzuspüren, die dazu führten, dass unser snmpd-Daemon wiederholt abstürzte. Es ist gewöhnungsbedürftig, aber es ist ein mächtiges Werkzeug.

Sie können strace verwenden, um eine Verbindung zu einem laufenden Prozess herzustellen (vergessen Sie nicht das Flag -f, um untergeordneten Prozessen zu folgen).

— yoonix
quelle

1

Was genau versuchst du aufzuspüren? Die Remote-IP-Adresse (n), die den durchgesickerten FDs zugeordnet sind, der fehlerhafte Code oder etwas anderes?

Da Sie bereits festgestellt haben, dass ein Leck vorliegt, erscheint es als vernünftiger nächster Schritt, sich an die für diesen Java-Prozess verantwortlichen Ingenieure zu wenden.

— An̲̳̳drew
quelle

Ich versuche, alle Informationen zu diesen Dateideskriptoren aufzuspüren. can't identify protocolgibt den Ingenieuren nicht viel zum Laufen. Gibt es Tools oder Optionen in lsof, bei denen ich nicht sehe, welche ich verwenden soll? Das Problem tritt in der Testumgebung nicht auf und wurde erst nach einer Schrankmigration in dieser Umgebung gestartet. Derselbe Code hatte vor der Migration keine Probleme, und wenn die Anwendung nicht bereitgestellt wird, leckt Glassfish immer noch von selbst. Meine beste Vermutung ist, dass aus Netzwerksicht etwas kaputt gegangen ist und Sockets versuchen zu initialisieren, aber nicht können, und dann hängen sie und bleiben herum.

— Clark