<div>Максим, нельзя ли как-то пофиксить это, я искал в гугле и нашел кучу проблем аналогичного характера и ни одного решения. У меня nginx занимается только проксированием, он без модулей и прочего, абсолютно чистый. Ок не смог он удалить 20 этих элементов, возможно там их тормоз качет (хотя если их сейчас качают то это уже не самый старый элемент), пусть пробует дальше и вернется к ним позже, если в кэше около 2 000 000 элементов. Никаких Sigterm и Sigkill перед переполнением точно нет, сервер никтотне трогает в это время. В логах critical пусто.</div><div><br></div><div><br><div class="gmail_quote"><div>вт, 2 мая 2017 г. в 19:17, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<br>
On Fri, Apr 28, 2017 at 12:22:20PM +0700, Владислав Толмачев wrote:<br>
<br>
> иногда, в не зависимости от нагрузки, nginx перестает следить за размером<br>
> каталога proxy_cache_patch и каталог начинает выходить за пределы<br>
> установленного размера и забивает полностью диск. Каталог находится на<br>
> raid0  из 12 ssd по 240G, там около 2.5М файлов кэша hls видео<br>
><br>
>     proxy_cache_path   /var/www/nginx/nginx_proxy_cache  levels=1:2<br>
> keys_zone=two:1536m  inactive=1y max_size=2350G loader_files=1000<br>
> loader_sleep=10ms loader_threshold=8000ms manager_files=500<br>
> manager_threshold=1000ms manager_sleep=50ms use_temp_path=off;<br>
><br>
> не помогает kill процесс nginx cache manager, только полный рестарт nginx,<br>
> после чего он очищает забитый диск/папку до установленного лимита.<br>
><br>
> Что сделать, что бы он не переставал следить за размером кэша? поймать<br>
> дебаг трудно так как это может произойти только раз в месяц, а может и<br>
> через 2 дня никакой зависимости не выявлено. Стандартные параметры<br>
> manager_file или те, которые я установил не дают эффекта, все равно в один<br>
> прекрасный момент диск забивается полностью.<br>
<br>
Кеш перестаёт чистится по max_size, если 20 самых старых элементов<br>
в кеше - кем-то заблокированы и не могут быть удалены (при очистке<br>
по inactive такие элементы приводят к alert'ам "ignore long locked<br>
inactive cache entry").  Появиться такие элементы могут из-за<br>
естественных причин - например, какой-то запрос с ними на самом<br>
деле очень долго получает ответ от бекенда.  Однако на практике<br>
чаще всего причина наблюдаемых проблем - падение рабочего<br>
процесса, и соответственно оставшиеся от него блокировки.<br>
<br>
Так что начать стоит с простого - проверить логи на предмет<br>
падений рабочих процессов, если они есть - найти и устранить<br>
причину падений.<br>
<br>
Отмечу также, что к аналогичным падению результатам (неочищенные<br>
блокировки, и соответственно "сломавшаяся" очистка по max_size,<br>
alert'ы "long locked inactive cache entry" при очистке по<br>
inactive) может привести и некорректное управление рабочими<br>
процессами, в частности - использование SIGTERM (не говоря уже про<br>
SIGKILL) для быстрого завершения старых рабочих процессов.<br>
<br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><br>С уважением Толмачев Владислав.<br><a href="mailto:tolmachev.vlad@gmail.com" target="_blank">tolmachev.vlad@gmail.com</a><br>skype: vladislaviki<br>icq: 274888266<br></div>