Видалення кешу NGINX призводить до критичних помилок від'єднання в журналі помилок
Опубліковано: 15 лютого 2025 р. о 11:24:59 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 намагається видалити записи кешу після закінчення часу, вказаного неактивним параметром директиви fastcgi_cache_path . За замовчуванням це лише 10 хвилин, але ви можете встановити будь-яке значення. Якщо ви встановили його, скажімо, на 10 років, малоймовірно, що ви не перезавантажили сервер за цей час, тому індекс ключа в пам'яті тим часом був би очищений. Якщо ви це зробите, вам потрібно переконатися , що ви очистили кеш самостійно, NGINX більше не зробить це за вас.
Мені здається дуже дивним, що вважається критичною помилкою, що запис у кеші не можна видалити, оскільки його не існує. Той факт, що його класифікація за ступенем серйозності настільки висока, означає, що його неможливо позбутися, просто ігноруючи записи в журналі нижче певного порогу. Як тільки нова копія буде отримана з серверної частини, запис знову буде існувати, тому, на мою думку, це має бути попередженням.
Тепер, якщо запис у кеші не вдалося видалити через проблеми з дозволами або щось третє, це було б критичною помилкою, оскільки це може змусити NGINX продовжувати обслуговувати кешований вміст ще довго після закінчення терміну його дії, але процес очищення, схоже, не робить цієї різниці.