Re: nginx перестает следить за размером каталога proxy_cache_patch

[Dmitry Volyntsev]

On 02.05.2017 15:35, Владислав Толмачев wrote:
> Максим, нельзя ли как-то пофиксить это, я искал в гугле и нашел кучу
> проблем аналогичного характера и ни одного решения. У меня nginx
> занимается только проксированием, он без модулей и прочего, абсолютно
> чистый. Ок не смог он удалить 20 этих элементов, возможно там их тормоз
> качет (хотя если их сейчас качают то это уже не самый старый элемент),
> пусть пробует дальше и вернется к ним позже, если в кэше около 2 000 000
> элементов. Никаких Sigterm и Sigkill перед переполнением точно нет,
> сервер никтотне трогает в это время. В логах critical пусто.
>

Вячеслав, а не могли бы вы предоставить более подробную информацию о 
своей конфигурации nginx? Как то: вывод nginx -V, версию операционной 
системы, информация о дисковых разделах и релевантный кусок конфига, 
кроме директивы proxy_cache_path.

Лог уровня alert (до и после начала роста кеша), так же мог бы оказаться 
полезным.

>
> вт, 2 мая 2017 г. в 19:17, Maxim Dounin <mdounin на mdounin.ru
> <mailto:mdounin на mdounin.ru>>:
>
>     Hello!
>
>     On Fri, Apr 28, 2017 at 12:22:20PM +0700, Владислав Толмачев wrote:
>
>     > иногда, в не зависимости от нагрузки, nginx перестает следить за
>     размером
>     > каталога proxy_cache_patch и каталог начинает выходить за пределы
>     > установленного размера и забивает полностью диск. Каталог находится на
>     > raid0  из 12 ssd по 240G, там около 2.5М файлов кэша hls видео
>     >
>     >     proxy_cache_path   /var/www/nginx/nginx_proxy_cache  levels=1:2
>     > keys_zone=two:1536m  inactive=1y max_size=2350G loader_files=1000
>     > loader_sleep=10ms loader_threshold=8000ms manager_files=500
>     > manager_threshold=1000ms manager_sleep=50ms use_temp_path=off;
>     >
>     > не помогает kill процесс nginx cache manager, только полный
>     рестарт nginx,
>     > после чего он очищает забитый диск/папку до установленного лимита.
>     >
>     > Что сделать, что бы он не переставал следить за размером кэша? поймать
>     > дебаг трудно так как это может произойти только раз в месяц, а может и
>     > через 2 дня никакой зависимости не выявлено. Стандартные параметры
>     > manager_file или те, которые я установил не дают эффекта, все
>     равно в один
>     > прекрасный момент диск забивается полностью.
>
>     Кеш перестаёт чистится по max_size, если 20 самых старых элементов
>     в кеше - кем-то заблокированы и не могут быть удалены (при очистке
>     по inactive такие элементы приводят к alert'ам "ignore long locked
>     inactive cache entry").  Появиться такие элементы могут из-за
>     естественных причин - например, какой-то запрос с ними на самом
>     деле очень долго получает ответ от бекенда.  Однако на практике
>     чаще всего причина наблюдаемых проблем - падение рабочего
>     процесса, и соответственно оставшиеся от него блокировки.
>
>     Так что начать стоит с простого - проверить логи на предмет
>     падений рабочих процессов, если они есть - найти и устранить
>     причину падений.
>
>     Отмечу также, что к аналогичным падению результатам (неочищенные
>     блокировки, и соответственно "сломавшаяся" очистка по max_size,
>     alert'ы "long locked inactive cache entry" при очистке по
>     inactive) может привести и некорректное управление рабочими
>     процессами, в частности - использование SIGTERM (не говоря уже про
>     SIGKILL) для быстрого завершения старых рабочих процессов.
>
>     --
>     Maxim Dounin
>     http://nginx.org/
>     _______________________________________________
>     nginx-ru mailing list
>     nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>     http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> --
>
> С уважением Толмачев Владислав.
> tolmachev.vlad на gmail.com <mailto:tolmachev.vlad на gmail.com>
> skype: vladislaviki
> icq: 274888266
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>