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

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

nginx -V
nginx version: nginx/1.13.0
built by gcc 4.9.2 (Debian 4.9.2-10)
built with OpenSSL 1.0.2h  3 May 2016
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx
--modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf
--error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock
--http-client-body-temp-path=/var/cache/nginx/client_temp
--http-proxy-temp-path=/var/cache/nginx/proxy_temp
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx
--with-compat --with-file-aio --with-threads --with-http_addition_module
--with-http_auth_request_module --with-http_dav_module
--with-http_flv_module --with-http_gunzip_module
--with-http_gzip_static_module --with-http_mp4_module
--with-http_random_index_module --with-http_realip_module
--with-http_secure_link_module --with-http_slice_module
--with-http_ssl_module --with-http_stub_status_module
--with-http_sub_module --with-http_v2_module --with-mail
--with-mail_ssl_module --with-stream --with-stream_realip_module
--with-stream_ssl_module --with-stream_ssl_preread_module
--with-openssl=/root/openssl-1.0.2h

nginx.conf:

user www-data www-data;
worker_processes 50;
worker_cpu_affinity auto;
timer_resolution 100ms;
worker_rlimit_nofile 65535;

    proxy_cache_path   /var/www/nginx/nginx_proxy_cache  levels=1:1
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;

  server {
            proxy_cache_min_uses 2;
            proxy_cache_revalidate on;
            proxy_cache two;
            proxy_cache_lock on;
            proxy_cache_lock_age 90s;
            proxy_cache_lock_timeout 90s;
            proxy_cache_use_stale  error timeout invalid_header updating
http_500 http_502 http_503 http_504 http_404;
            proxy_cache_key    "$proxy_host$uri";
            proxy_read_timeout 180s;
            proxy_connect_timeout 180s;
            proxy_send_timeout 180s;
            proxy_ignore_headers X-Accel-Limit-Rate X-Accel-Expires Expires
Cache-Control Set-Cookie Vary;
            proxy_max_temp_file_size 0;
            proxy_read_timeout 70s;
            proxy_connect_timeout 70s;
            proxy_send_timeout 70s;
            proxy_buffers 32 384k;
            proxy_force_ranges on;

            output_buffers  32 384k;
            send_timeout 180s;
            sendfile on;
            sendfile_max_chunk 512k;


location / {
            proxy_pass http://backend;
}
}

Диск состоит из raid0 12 SSD по 240Gb, линк 10Gbps в мир, при пике выдает
около 8-9Gbps iotop показывает, что в пик диск не занят на 100%

Проблема с тем, что nginx перестает чистить папку proxy_cache_path может
случиться в любой момент (не обязательно в пик посещаемости) например в 5
утра, когда трафик почти на нуле, помогает только рестарт nginx



С уважением Толмачев Владислав.
tolmachev.vlad на gmail.com
skype: vladislaviki
icq: 274888266

2 мая 2017 г., 17:31 пользователь Maxim Dounin <mdounin на mdounin.ru> написал:

> Hello!
>
> On Tue, May 02, 2017 at 12:35:55PM +0000, Владислав Толмачев wrote:
>
> > Максим, нельзя ли как-то пофиксить это, я искал в гугле и нашел кучу
> > проблем аналогичного характера и ни одного решения. У меня nginx
> занимается
> > только проксированием, он без модулей и прочего, абсолютно чистый. Ок не
> > смог он удалить 20 этих элементов, возможно там их тормоз качет (хотя
> если
> > их сейчас качают то это уже не самый старый элемент), пусть пробует
> дальше
> > и вернется к ним позже, если в кэше около 2 000 000 элементов. Никаких
> > Sigterm и Sigkill перед переполнением точно нет, сервер никтотне трогает
> в
> > это время. В логах critical пусто.
>
> "Тормоз качает" - не должно быть причиной, nginx складывает в кеш
> ответ сразу, как получает его от бекенда, и от клиента тут ничего
> не зависит.  Причиной может быть бекенд - если он кешируемый ответ
> возвращает очень долго.  В старых версиях (до 1.11.6) та же
> проблема могла возникать, если при включённом кеше использовалось
> проксирование без буферизации и/или проксирование вебсокетов -
> элемент кеша оставался залоченным до окончания соединения.
>
> Получить более подробную информацию о происходящем можно, уменьшив
> inactive и добившись очистки по нему, в этом случае в аналогичной
> ситуации будет alert про "ignore long locked inactive cache
> entry".  По идентификатору можно будет узнать, что за ресурс
> вызвал проблему, и проанализировать возможные причины.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170506/3c9ca0e2/attachment-0001.html>