La Suppression Du Cache NGINX Met Des ErreurS De Dissociation CritiqueS Dans Le Journal Des ErreurS

Publié : 15 février 2025 à 11 h 29 min 23 s UTC

Cet article explique comment supprimer des éléments du cache de NGINX sans que vos fichiers journaux soient encombrés de messages d’erreur. Bien qu’il ne s’agisse généralement pas d’une approche recommandée, elle peut être utile dans certains cas limites.

Cette page a été automatiquement traduite de l'anglais afin de la rendre accessible au plus grand nombre. Malheureusement, la traduction automatique n'est pas encore une technologie au point, des erreurs peuvent donc survenir. 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 s’exécutant sur Ubuntu Server 14.04 x64. Il peut ou non être valide pour d’autres versions.

(Mise à jour 2025 : Dans le temps entre j’ai écrit le post 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 cet article où j’essaie de micro-gérer l’expiration du cache juste pour économiser quelques générations supplémentaires de contenu dynamique. Je vais laisser le contenu ici pour référence future et au cas où quelqu’un en a réellement besoin pour une raison quelconque. Je n’ai pas confirmé que cela fonctionne toujours pour les versions actuelles de NGINX, cependant, mais je pense que c’est le cas).

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

Cependant, pour l’un des sites, j’avais vraiment besoin de la possibilité d’effacer 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’y a pas de moyen fiable de déterminer à l’avance quand une certaine ressource changera ? Par exemple, je n’ai aucune idée si ce sera une heure, un jour ou un an avant de revenir et de modifier quelque chose dans ce post - et pourquoi seulement mettre en cache pendant une heure si la mise en cache pour une journée aurait été très bien ?

C’est là que la possibilité d’effacer le cache manuellement (ou en demandant à votre application Web d’informer NGINX que quelque chose doit être purgé) est nécessaire. Les gens derrière NGINX sont clairement conscients de la nécessité de cela car la fonctionnalité est prise en charge dans la version payante de leur produit - mais bien qu’ils aient certainement le droit de configurer leur licence comme ils le souhaitent, le prix est un peu raide pour moi lorsque 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 des fichiers du répertoire de cache et NGINX s’en saisira et récupérera une nouvelle copie de votre back-end sans accroc. Cependant, si vous faites ceci sans peaufiner votre configuration vous êtes susceptible de voir tout un tas de messages semblables à celui-ci dans votre journal d’erreur 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 tente de supprimer des entrées de cache après l’heure spécifiée par le paramètre inactif de la directive fastcgi_cache_path . La valeur par défaut pour cela n’est que de 10 minutes, mais vous pouvez la définir sur la valeur de votre choix. Si vous le 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 que vous effacez le cache vous-même, NGINX ne le fera plus pour vous.

Je trouve vraiment étrange qu’il soit considéré comme une erreur critique qu’une entrée de cache ne puisse pas être supprimée car 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 dans le back-end, l’entrée existera à nouveau, donc cela devrait être un avertissement tout au plus, à 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 troisième, ce serait une erreur critique, car cela pourrait faire en sorte que NGINX continue à diffuser du contenu mis en cache longtemps après son heure d’expiration, mais le processus de nettoyage ne semble pas faire cette distinction.