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

Владислав Толмачев tolmachev.vlad на gmail.com
Сб Май 6 15:02:52 UTC 2017


А зачем сплит, если есть raid0, уровней было 1:2, но это никак не влиет ни
на что, как были глюки с переставанием чистки кэша так и остались.
Настройки лоадера тоже ни на что не влияют, что стандартные, что нет, тут
виснет сам nginx cache manager.

сб, 6 мая 2017 г. в 17:53, Vasiliy P. Melnik <basil на vpm.net.ua>:

> 1) а почему не сплит ?
> 2) почему так мало уровней?
> 3) зачем настраивать лоадер? как по мне то менять дефолтные настройки надо
> в случае, если четко понимаешь, что делаешь и зачем, а любые поиски решения
> проблем стоит начинать с возврата к дефолтным настройкам
>
> proxy_cache_path /var/lib/nginx/proxy levels=2:2 use_temp_path=off
> keys_zone=proxy:4m inactive=1h max_size=500m;
>
> proxy_cache_path /var/lib/nginx/sda1 levels=2:2
> keys_zone=pic_cache_sda1:500m max_size=400g inactive=60d use_temp_path=off;
> proxy_cache_path /var/lib/nginx/sdb1 levels=2:2
> keys_zone=pic_cache_sdb1:500m max_size=400g inactive=60d use_temp_path=off;
> proxy_cache_path /var/lib/nginx/sdc1 levels=2:2
> keys_zone=pic_cache_sdc1:250m max_size=200g inactive=60d use_temp_path=off;
> proxy_cache_path /var/lib/nginx/sdd1 levels=2:2
> keys_zone=pic_cache_sdd1:250m max_size=200g inactive=60d use_temp_path=off;
>
> split_clients http://$host$request_uri $domik_pic_cache {
>         33% pic_cache_sda1;
>         33% pic_cache_sdb1;
>         17% pic_cache_sdc1;
>         *   pic_cache_sdd1;
> }
>
>
> 6 мая 2017 г., 14:56 пользователь Владислав Толмачев <
> tolmachev.vlad на gmail.com> написал:
>
> 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
>>
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
> _______________________________________________
> 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/20170506/04e80ac4/attachment-0001.html>


Подробная информация о списке рассылки nginx-ru