La suppression du cache NGINX place les erreurs critiques de désassociation dans le journal des erreurs

Publié : 15 février 2025 à 11:24:05 UTC

Cet article explique comment supprimer des éléments du cache de NGINX sans que vos fichiers journaux ne soient encombrés de messages d'erreur. Bien que cette approche ne soit généralement pas recommandée, elle peut s'avérer utile dans certains cas extrêmes.

Cette page a été traduite de l'anglais afin de la rendre accessible au plus grand nombre. Malheureusement, la traduction automatique n'est pas encore une technologie parfaite, et des erreurs peuvent donc se produire. Si vous préférez, vous pouvez consulter la version originale en anglais ici :

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Les informations contenues dans cet article sont basées sur la mise en cache FastCGI sur NGINX 1.4.6 exécuté sur Ubuntu Server 14.04 x64. Elles peuvent ou non être valables pour d'autres versions.

(Mise à jour 2025 : entre le moment où j'ai écrit le message original et maintenant, beaucoup de choses ont changé. Les serveurs sont plus rapides et moins chers, donc je ne recommanderais en fait pas l'approche décrite dans ce message où j'essaie de microgérer l'expiration du cache juste pour économiser quelques générations supplémentaires de contenu dynamique. Je laisserai le contenu ici pour référence future et au cas où quelqu'un en aurait réellement besoin pour une raison quelconque. Je n'ai pas confirmé que cela fonctionne toujours pour les versions actuelles de NGINX, mais je pense que c'est le cas).

Après avoir migré plusieurs sites d'Apache vers NGINX, je suis devenu très attaché à ses capacités de mise en cache intégrées, qui fonctionnent extrêmement bien dans la plupart des circonstances sans trop d'intervention de ma part.

Cependant, pour l'un des sites, j'avais vraiment besoin de pouvoir vider le cache (à la fois complètement et supprimer des entrées individuelles) moi-même. L'édition communautaire gratuite de NGINX ne prend en charge que l'expiration du cache basée sur le temps (c'est-à-dire que vous pouvez la configurer pour vérifier si quelque chose a changé après une heure, un jour, etc.). Mais que se passe-t-il s'il n'existe aucun moyen fiable de déterminer à l'avance quand une certaine ressource va changer ? Par exemple, je n'ai aucune idée si cela prendra une heure, un jour ou un an avant de revenir et de modifier quelque chose dans cet article - et pourquoi ne mettre en cache que pendant une heure si la mise en cache pendant un jour aurait été acceptable ?

C'est là qu'il est nécessaire de pouvoir vider le cache manuellement (ou en demandant à votre application Web d'avertir NGINX qu'un élément doit être purgé). Les personnes derrière NGINX sont clairement conscientes de la nécessité de cette fonctionnalité, car cette fonctionnalité est prise en charge dans la version payante de leur produit. Mais même s'ils ont certainement le droit de configurer leur licence comme ils le souhaitent, le prix est un peu élevé pour moi alors que cette fonction est la seule fonctionnalité payante dont j'ai vraiment besoin.

Heureusement, il s'avère que vous pouvez simplement supprimer vous-même les fichiers du répertoire cache et NGINX s'en rendra compte et en récupérera une nouvelle copie depuis votre back-end sans problème. Cependant, si vous faites cela sans modifier votre configuration, vous risquez de voir apparaître tout un tas de messages similaires à celui-ci dans votre journal d'erreurs après un certain temps :

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

Il semble que ces erreurs se produisent lorsque NGINX lui-même essaie de supprimer les entrées de cache après le délai spécifié par le paramètre inactive de la directive fastcgi_cache_path . La valeur par défaut est de 10 minutes seulement, mais vous pouvez la définir sur la valeur de votre choix. Si vous la définissez sur, disons, 10 ans, il est probablement peu probable que vous n'ayez pas redémarré le serveur entre-temps, de sorte que l'index de clé en mémoire aurait été effacé entre-temps. Si vous faites cela, devez-vous vous assurer de vider le cache vous-même, NGINX ne le fera plus pour vous.

Je trouve vraiment étrange que l'on considère comme une erreur critique le fait qu'une entrée de cache ne puisse pas être supprimée parce qu'elle n'existe pas. Le fait que sa classification de gravité soit si élevée signifie qu'il est impossible de s'en débarrasser simplement en ignorant les entrées de journal en dessous d'un certain seuil. Dès qu'une nouvelle copie est récupérée depuis le back-end, l'entrée existera à nouveau, donc cela devrait être un avertissement au maximum, à mon avis.

Maintenant, si l'entrée de cache ne pouvait pas être supprimée en raison de problèmes d'autorisations ou de quelque chose de tiers, ce serait une erreur critique, car cela pourrait amener NGINX à continuer à diffuser du contenu mis en cache longtemps après son heure d'expiration, mais le processus de nettoyage ne semble pas faire cette distinction.