Durch das Löschen des NGINX-Cache werden kritische Unlink-Fehler in das Fehlerprotokoll eingetragen

Veröffentlicht: 15. Februar 2025 um 11:23:50 UTC

In diesem Artikel wird erläutert, wie Sie Elemente aus dem Cache von NGINX löschen, ohne dass Ihre Protokolldateien mit Fehlermeldungen überladen werden. Obwohl dies im Allgemeinen kein empfohlener Ansatz ist, kann er in einigen Randfällen nützlich sein.

Diese Seite wurde maschinell aus dem Englischen übersetzt, um sie so vielen Menschen wie möglich zugänglich zu machen. Leider ist die maschinelle Übersetzung noch keine ausgereifte Technologie, so dass Fehler auftreten können. Wenn Sie es vorziehen, können Sie sich die englische Originalversion hier ansehen:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Die Informationen in diesem Beitrag basieren auf FastCGI-Caching auf NGINX 1.4.6, das auf Ubuntu Server 14.04 x64 ausgeführt wird. Sie können für andere Versionen gültig sein, müssen es aber nicht.

(Update 2025: In der Zeit zwischen dem Verfassen des Originalbeitrags und heute hat sich viel geändert. Server sind schneller und billiger, daher würde ich den in diesem Beitrag beschriebenen Ansatz, bei dem ich versuche, das Ablaufen des Caches im Detail zu verwalten, nur um ein paar zusätzliche Generationen dynamischer Inhalte zu speichern, eigentlich nicht empfehlen. Ich werde den Inhalt hier lassen, um ihn später wieder zu verwenden und für den Fall, dass ihn jemand aus irgendeinem Grund tatsächlich braucht. Ich habe allerdings nicht bestätigt, dass dies für aktuelle Versionen von NGINX noch funktioniert, aber ich würde annehmen, dass es so ist.)

Nachdem ich mehrere Sites von Apache zu NGINX migriert habe, bin ich von den integrierten Caching-Funktionen sehr angetan, die unter den meisten Umständen ohne viel Eingreifen meinerseits hervorragend funktionieren.

Für eine der Websites brauchte ich jedoch unbedingt die Möglichkeit, den Cache selbst zu leeren (sowohl vollständig als auch einzelne Einträge zu entfernen). Die kostenlose Community-Edition von NGINX unterstützt nur zeitbasiertes Ablaufen des Caches (d. h. Sie können es so einrichten, dass nach einer Stunde, einem Tag usw. geprüft wird, ob sich etwas geändert hat). Aber was, wenn es keine zuverlässige Möglichkeit gibt, im Voraus zu bestimmen, wann sich eine bestimmte Ressource ändern wird? Ich habe beispielsweise keine Ahnung, ob es eine Stunde, einen Tag oder ein Jahr dauern wird, bis ich zurückkomme und etwas in diesem Beitrag bearbeite – und warum nur für eine Stunde cachen, wenn ein Cache für einen Tag ausreichend gewesen wäre?

Hier ist die Möglichkeit erforderlich, den Cache manuell zu leeren (oder indem Ihre Webanwendung NGINX benachrichtigt, dass etwas gelöscht werden soll). Die Leute hinter NGINX sind sich dieser Notwendigkeit offensichtlich bewusst, da die Funktion in der kostenpflichtigen Version ihres Produkts unterstützt wird. Obwohl sie natürlich das Recht haben, ihre Lizenzierung nach Belieben einzurichten, ist mir der Preis etwas zu hoch, da diese Funktion die einzige kostenpflichtige Funktion ist, die ich wirklich brauche.

Glücklicherweise können Sie Dateien einfach selbst aus dem Cache-Verzeichnis löschen. NGINX erkennt dies und holt problemlos eine neue Kopie von Ihrem Backend. Wenn Sie dies jedoch tun, ohne Ihre Konfiguration zu optimieren, werden Sie wahrscheinlich nach einer Weile eine ganze Reihe von Meldungen wie diese in Ihrem Fehlerprotokoll sehen:

2015/03/04 17:35:24 [crit] 16665#0: unlink() \"/path/to/nginx/cache/9/a0/53eb903773998c16dcc570e6daebda09\" failed (2: No such file or directory)

Es scheint, dass diese Fehler auftreten, wenn NGINX selbst versucht, Cache-Einträge nach der durch den inaktiven Parameter der Direktive fastcgi_cache_path angegebenen Zeit zu löschen. Der Standardwert hierfür beträgt nur 10 Minuten, Sie können ihn jedoch auf jeden beliebigen Wert einstellen. Wenn Sie ihn beispielsweise auf 10 Jahre einstellen, ist es wahrscheinlich unwahrscheinlich, dass Sie den Server in der Zwischenzeit nicht neu gestartet haben, sodass der Schlüsselindex im Speicher in der Zwischenzeit gelöscht worden wäre. Wenn Sie dies tun, müssen Sie sicherstellen , dass Sie den Cache selbst löschen, da NGINX dies nicht mehr für Sie tun wird.

Ich finde es wirklich seltsam, dass es als kritischer Fehler gilt, wenn ein Cache-Eintrag nicht gelöscht werden kann, weil er nicht existiert. Die Tatsache, dass seine Schweregradklassifizierung so hoch ist, bedeutet, dass es unmöglich ist, ihn einfach durch Ignorieren von Protokolleinträgen unter einem bestimmten Schwellenwert zu beseitigen. Sobald eine neue Kopie vom Backend abgerufen wird, existiert der Eintrag wieder, daher sollte dies meiner Meinung nach höchstens eine Warnung sein.

Wenn der Cache-Eintrag aufgrund von Berechtigungsproblemen oder aus anderen Gründen nicht gelöscht werden kann, wäre das ein kritischer Fehler, da NGINX dadurch möglicherweise noch lange nach Ablauf der Gültigkeitsdauer zwischengespeicherte Inhalte bereitstellt. Der Bereinigungsprozess scheint diesen Unterschied jedoch nicht zu berücksichtigen.