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

[Владислав Толмачев]

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


вт, 2 мая 2017 г. в 19:17, Maxim Dounin <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
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 

С уважением Толмачев Владислав.
tolmachev.vlad на gmail.com
skype: vladislaviki
icq: 274888266
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170502/7ed2ecb2/attachment.html>