„Running out of filedescriptors“

Wenn trotz funktionierender Netzwerk-Infrastruktur der Proxy-Server Squid nicht mehr oder nur extrem langsam auf HTTP-Anfragen reagiert, könnte ein Mangel an verfügbaren File-Handles die Ursache dafür sein.

Squid führt einen Festplatten-Cache häufig benutzer Objekte und muss deshalb mit vielen gleichzeitig geöffneten Dateien hantieren. Bedient die Squid-Installation nun viele Clients, oder hat es mit einem „ungewöhnlichem“ Datenaufkommen zu tun, kommt es zu Fehlern: Der Squid-Prozess stößt an eine Grenze die beschreibt, wie viele Dateien gleichzeitig offen gehalten werden dürfen. Erkennbar ist das Problem an folgender Meldung im store.log:

WARNING! Your cache is running out of filedescriptors

Und wer ist schuld daran?

Grund dafür sind Beschränkungen, die eigentlich dazu dienen sollen, das System vor Überlast (z.B. DOS) zu schützen. Nur sind bei einigen Standard-Installationen diese Beschränkungen etwas zu übervorsichtig gesetzt, so dass irgendwann ganz unvermittelt obige Fehlermeldung im Log erscheint und Squid den Dienst verweigert.

Die Beschränkungen können an verschiedenen Stellen gesetzt sein:

• als Parameter für „ulimit -n“
  Irgendwo in der Umgebung, aus der heraus der Dienst gestartet wird, könnte ein Limit per ulimit gesetzt worden sein. Eine entsprechende Anweisung könnte z.B. direkt im Start-/Stop-Skript stehen.
• als Parameter in einer distributionsspezifischen Konfigurationsdatei
  Bei Ubuntu gibt es z.B. die Datei /etc/default/squid mit dem Parameter „SQUID_MAXFD“ (der bei Ubuntu 10.04 leider keine Wirkung zeigt 😉 – siehe unten)
• als Parameter „max_filedescriptors“ direkt in der squid.conf
  Das ist die Stelle, bei der man eigentlich als erstes suchen sollte. Der Parameter hilft jedoch nicht sehr viel, wenn die Umgebung schon per ulimit beschränkt ist, bzw. Squid mit zu niedrigen Grenzen kompiliert wurde.
• als Konstante beim Kompilieren von squid
  Das „./configure“ -Skript verwendet Defaults oder das auf dem Build-Host gesetzte Limit, um diese Konstante festzulegen. Hier hilft nur ein neukompilieren von Squid aus den Sourcen und ein Studium der Ausgabe von „./configure –help“

Die Lösung

Die Lösung hängt natürlich von dem begrenzenden Faktor ab (siehe oben). Hier ist je nach Distribution möglicherweise etwas Detektiv-Arbeit angesagt.

Als erstes würde ich im Squid-Init-Skript nach dem ulimit Kommando suchen:

grep ulimit /etc/init.d/squid

Bei Ubuntu hilft ein außerdem Blick in die Datei /etc/default/squid, und das Setzen des Parameters „SQUID_MAXFD“ auf einen höheren Wert (z.B. 4096).

Leider scheint z.B. bei Ubuntu 10.04 das Start-/Stop-Skript diesen Parameter komplett zu ignorieren, so dass hier in /etc/squid/squid.conf der Parameter „max_filedescriptors“ auf den entsprechenden Wert zu setzen ist.

Wie es um den aktuellen Status der File-Handles steht, erfährt der Admin mit folgendem Kommando:

squidclient mgr:info

Das Kommando „squidclient“ gehört nicht zum Stadard-Umfang jeder Installation und muss deshalb möglicherweise nachinstalliert werden. Außerdem hört Squid vielleicht auf einen anderen, als den Default-Port (z.B. auf 8080). Wenn man die Ausgabe des Kommandos jetzt auch noch etwas filtern möchte, könnte folgende Kommandozeile hilfreich sein:

squidclient -p 8080 mgr:info | grep "file descriptor"

Sollte sich der Wert für „Maximum number of file descriptors“ nicht wie gewünscht ändern, war der geänderte Parameter doch noch nicht der richtige, oder der Admin hat schlicht vergessen, den Squid-Dienst nach der vorgenommenen Änderung durchzustarten 😉