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

[Maxim Dounin]

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/