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 <[email protected] <mailto:[email protected]>>: 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 [email protected] <mailto:[email protected]> http://mailman.nginx.org/mailman/listinfo/nginx-ru -- С уважением Толмачев Владислав. [email protected] <mailto:[email protected]> skype: vladislaviki icq: 274888266 _______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
