Удаление кэша NGINX приводит к появлению критических ошибок отмены связи в журнале ошибок
Опубликовано: 15 февраля 2025 г. в 11:24:50 UTC
В этой статье объясняется, как удалить элементы из кэша NGINX, не загромождая файлы журналов сообщениями об ошибках. Хотя это не рекомендуемый подход, он может быть полезен в некоторых крайних случаях.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
Информация в этом посте основана на кэшировании FastCGI на NGINX 1.4.6, работающем на Ubuntu Server 14.04 x64. Она может быть верна или нет для других версий.
(Обновление 2025 г.: за время, прошедшее с момента написания оригинального поста и до настоящего момента, многое изменилось. Серверы стали быстрее и дешевле, поэтому я бы не рекомендовал подход, описанный в этом посте, где я пытаюсь микроуправлять истечением срока действия кэша, чтобы сэкономить несколько дополнительных поколений динамического контента. Я оставлю контент здесь для дальнейшего использования и на случай, если кому-то он действительно понадобится по какой-либо причине. Я не подтверждал, что это все еще работает для текущих версий NGINX, но я думаю, что это так).
После миграции нескольких сайтов с Apache на NGINX я очень полюбил его встроенные возможности кэширования, которые работают очень хорошо в большинстве случаев без особого вмешательства с моей стороны.
Однако для одного из сайтов мне действительно нужна была возможность очищать кэш (как полностью, так и удалять отдельные записи) самостоятельно. Бесплатная версия сообщества NGINX поддерживает только истечение срока действия кэша на основе времени (т. е. вы можете настроить его на проверку изменений через час, день и т. д.). Но что делать, если нет надежного способа заранее определить, когда изменится определенный ресурс? Например, я понятия не имею, пройдет ли час, день или год, прежде чем я вернусь и отредактирую что-то в этом посте — и почему кэшировать только на час, если кэшировать на день было бы нормально?
Вот тут-то и нужна возможность очищать кэш вручную (или уведомлять NGINX о том, что что-то нужно очистить). Люди, стоящие за NGINX, явно знают о необходимости этого, поскольку эта функция поддерживается в платной версии их продукта, но хотя они, безусловно, имеют право настраивать лицензирование любым желаемым способом, цена для меня немного высока, поскольку эта функция — единственная платная функция, которая мне действительно нужна.
К счастью, оказывается, что вы можете просто удалить файлы из каталога кэша самостоятельно, и NGINX подхватит это и без проблем загрузит новую копию с вашего бэкэнда. Однако, если вы сделаете это без настройки конфигурации, вы, скорее всего, увидите в своем журнале ошибок через некоторое время целую кучу сообщений, похожих на это:
Похоже, что эти ошибки возникают, когда сам NGINX пытается удалить записи кэша после времени, указанного параметром inactive директивы fastcgi_cache_path . Значение по умолчанию составляет всего 10 минут, но вы можете установить его на любое другое значение. Если вы установите его, скажем, на 10 лет, то вряд ли вы не перезапускали сервер за это время, поэтому ключевой индекс в памяти был бы очищен за это время. Если вы это сделаете, вам нужно убедиться, что вы очищаете кэш самостоятельно, NGINX больше не будет делать это за вас.
Я нахожу очень странным, что считается критической ошибкой то, что запись кэша не может быть удалена, потому что ее не существует. Тот факт, что ее классификация серьезности настолько высока, означает, что от нее невозможно избавиться, просто игнорируя записи журнала ниже определенного порога. Как только новая копия будет извлечена из бэкэнда, запись снова появится, так что это должно быть максимум предупреждением, по моему мнению.
Теперь, если запись кэша не может быть удалена из-за проблем с разрешениями или по какой-то третьей причине, это будет критической ошибкой, поскольку это может привести к тому, что NGINX продолжит обслуживать кэшированный контент в течение длительного времени после истечения срока его действия, но процесс очистки, похоже, не делает этого различия.