From chipitsine на gmail.com  Tue Aug  4 12:14:45 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 4 Aug 2020 17:14:45 +0500
Subject: =?UTF-8?B?0LDQutC60YPRgNCw0YLQvdC+0LUg0LLRi9Cy0LXQtNC10L3QuNC1INCx0LXQutC1?=
 =?UTF-8?B?0L3QtNCwINC90LAg0YHRgtGA0LjQvNCw0YU=?=
Message-ID: <CAFHpkQE=j3RDSp_Hq5AWHCtB+fubBYo4V7mSwuL07XGSiQxSCA@mail.gmail.com>

привет!

вижу такую штуку. есть проксирование на стримах на 5 серверов. я хочу
вывести из эксплуатации 1-й. чтобы запросы доработали.

я каким-то образом делаю шаманство и говорю "если это SYN, то его надо на 4
сервера, а если это установленное с 1-м, ок, кидаем пакетики на 1-й". потом
когда горшочек перестает варить, я физически выключаю 1-й.

можно что-то такое на SYN-ах намутить ? на уровне идеи вроде норм. по
реализации ?


Илья Шипицин
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200804/e1e37560/attachment.htm>

From mdounin на mdounin.ru  Tue Aug  4 12:30:07 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 4 Aug 2020 15:30:07 +0300
Subject: =?UTF-8?B?UmU6INCw0LrQutGD0YDQsNGC0L3QvtC1INCy0YvQstC10LTQtdC90LjQtSDQsdC1?=
 =?UTF-8?B?0LrQtdC90LTQsCDQvdCwINGB0YLRgNC40LzQsNGF?=
In-Reply-To: <CAFHpkQE=j3RDSp_Hq5AWHCtB+fubBYo4V7mSwuL07XGSiQxSCA@mail.gmail.com>
References: <CAFHpkQE=j3RDSp_Hq5AWHCtB+fubBYo4V7mSwuL07XGSiQxSCA@mail.gmail.com>
Message-ID: <20200804123007.GV12747@mdounin.ru>

Hello!

On Tue, Aug 04, 2020 at 05:14:45PM +0500, Илья Шипицин wrote:

> вижу такую штуку. есть проксирование на стримах на 5 серверов. я хочу
> вывести из эксплуатации 1-й. чтобы запросы доработали.
> 
> я каким-то образом делаю шаманство и говорю "если это SYN, то его надо на 4
> сервера, а если это установленное с 1-м, ок, кидаем пакетики на 1-й". потом
> когда горшочек перестает варить, я физически выключаю 1-й.
> 
> можно что-то такое на SYN-ах намутить ? на уровне идеи вроде норм. по
> реализации ?

А что мешает просто убрать сервер из конфига и сделать reload?  
Ранее усановленные соединения доработают, новые будут 
устанавливаться только к бэкендам из новой конфигурации.

-- 
Maxim Dounin
http://mdounin.ru/

From chipitsine на gmail.com  Tue Aug  4 14:04:32 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 4 Aug 2020 19:04:32 +0500
Subject: =?UTF-8?B?UmU6INCw0LrQutGD0YDQsNGC0L3QvtC1INCy0YvQstC10LTQtdC90LjQtSDQsdC1?=
 =?UTF-8?B?0LrQtdC90LTQsCDQvdCwINGB0YLRgNC40LzQsNGF?=
In-Reply-To: <20200804123007.GV12747@mdounin.ru>
References: <CAFHpkQE=j3RDSp_Hq5AWHCtB+fubBYo4V7mSwuL07XGSiQxSCA@mail.gmail.com>
 <20200804123007.GV12747@mdounin.ru>
Message-ID: <CAFHpkQGoJsZyF_BjD6Wkt0_Rc9Esy=pTobF3f8JQHAvxy34=8A@mail.gmail.com>

вт, 4 авг. 2020 г. в 17:30, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Tue, Aug 04, 2020 at 05:14:45PM +0500, Илья Шипицин wrote:
>
> > вижу такую штуку. есть проксирование на стримах на 5 серверов. я хочу
> > вывести из эксплуатации 1-й. чтобы запросы доработали.
> >
> > я каким-то образом делаю шаманство и говорю "если это SYN, то его надо
> на 4
> > сервера, а если это установленное с 1-м, ок, кидаем пакетики на 1-й".
> потом
> > когда горшочек перестает варить, я физически выключаю 1-й.
> >
> > можно что-то такое на SYN-ах намутить ? на уровне идеи вроде норм. по
> > реализации ?
>
> А что мешает просто убрать сервер из конфига и сделать reload?
> Ранее усановленные соединения доработают, новые будут
> устанавливаться только к бэкендам из новой конфигурации.
>


пожалуй, что можно и так.
мы так раньше делали, и поскольку мы не контролировали сколько у нас
worker-ов (а на каждый релоад запускается новый набор), то время от времени
ловили out of memory.


>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200804/a25fdec9/attachment.htm>

From gmm на csdoc.com  Tue Aug  4 14:24:21 2020
From: gmm на csdoc.com (Gena Makhomed)
Date: Tue, 4 Aug 2020 17:24:21 +0300
Subject: =?UTF-8?B?UmU6INCw0LrQutGD0YDQsNGC0L3QvtC1INCy0YvQstC10LTQtdC90LjQtSDQsdC1?=
 =?UTF-8?B?0LrQtdC90LTQsCDQvdCwINGB0YLRgNC40LzQsNGF?=
In-Reply-To: <CAFHpkQGoJsZyF_BjD6Wkt0_Rc9Esy=pTobF3f8JQHAvxy34=8A@mail.gmail.com>
References: <CAFHpkQE=j3RDSp_Hq5AWHCtB+fubBYo4V7mSwuL07XGSiQxSCA@mail.gmail.com>
 <20200804123007.GV12747@mdounin.ru>
 <CAFHpkQGoJsZyF_BjD6Wkt0_Rc9Esy=pTobF3f8JQHAvxy34=8A@mail.gmail.com>
Message-ID: <05c63d7d-157a-def8-929e-ba42952687ba@csdoc.com>

On 04.08.2020 17:04, Илья Шипицин wrote:

>> А что мешает просто убрать сервер из конфига и сделать reload?
>> Ранее усановленные соединения доработают, новые будут
>> устанавливаться только к бэкендам из новой конфигурации.

> пожалуй, что можно и так.
> мы так раньше делали, и поскольку мы не контролировали сколько у нас
> worker-ов (а на каждый релоад запускается новый набор), то время от времени
> ловили out of memory.

если добавить в конфиг директиву worker_shutdown_timeout 60s;
- разве это не поможет избавиться от ошибок out of memory ?
и/или делать релоад nginx не чаще чем раз в минуту.

-- 
Best regards,
  Gena


From chipitsine на gmail.com  Tue Aug  4 16:20:33 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 4 Aug 2020 21:20:33 +0500
Subject: =?UTF-8?B?UmU6INCw0LrQutGD0YDQsNGC0L3QvtC1INCy0YvQstC10LTQtdC90LjQtSDQsdC1?=
 =?UTF-8?B?0LrQtdC90LTQsCDQvdCwINGB0YLRgNC40LzQsNGF?=
In-Reply-To: <05c63d7d-157a-def8-929e-ba42952687ba@csdoc.com>
References: <CAFHpkQE=j3RDSp_Hq5AWHCtB+fubBYo4V7mSwuL07XGSiQxSCA@mail.gmail.com>
 <20200804123007.GV12747@mdounin.ru>
 <CAFHpkQGoJsZyF_BjD6Wkt0_Rc9Esy=pTobF3f8JQHAvxy34=8A@mail.gmail.com>
 <05c63d7d-157a-def8-929e-ba42952687ba@csdoc.com>
Message-ID: <CAFHpkQHGhW1OwLnxQWNo2T7-vod8TbdnJ+HTHOF+iLcbNsrBog@mail.gmail.com>

вт, 4 авг. 2020 г. в 19:24, Gena Makhomed <gmm на csdoc.com>:

> On 04.08.2020 17:04, Илья Шипицин wrote:
>
> >> А что мешает просто убрать сервер из конфига и сделать reload?
> >> Ранее усановленные соединения доработают, новые будут
> >> устанавливаться только к бэкендам из новой конфигурации.
>
> > пожалуй, что можно и так.
> > мы так раньше делали, и поскольку мы не контролировали сколько у нас
> > worker-ов (а на каждый релоад запускается новый набор), то время от
> времени
> > ловили out of memory.
>
> если добавить в конфиг директиву worker_shutdown_timeout 60s;
> - разве это не поможет избавиться от ошибок out of memory ?
> и/или делать релоад nginx не чаще чем раз в минуту.
>

позволит. только установленные подключения порвутся


>
> --
> Best regards,
>   Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200804/a233febb/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Tue Aug  4 17:44:41 2020
From: nginx-forum на forum.nginx.org (Raice)
Date: Tue, 04 Aug 2020 13:44:41 -0400
Subject: =?UTF-8?B?0J/RgNC+0LrRgdC40YDQvtCy0LDQvdC40LUg0YEg0LrRjdGI0LXQvCDQuNC3IENE?=
 =?UTF-8?B?Tg==?=
Message-ID: <04189a9960aaec58f63cc0931ea41289.NginxMailingListRussian@forum.nginx.org>

Добрый день! Подскажите, пожалуйста, как правильно настроить проксирование с
кэшем из CDN. Задача такая: есть CDN, с него нужно скачивать достаточной
большой объем информации, но это достаточно дорого обходится, поэтому
появилась такая мысль - поднять прокси на nginx, который будет проксировать
запросы на CDN и кэшировать их. Файлы там статика, меняются крайне редко и
размер файла может быть 200Гб и выше. Хотелось бы чтобы с CDN закачка через
прокси шла только один раз, т.е. чтобы скачивал сам nginx и потом раздавал.
Я тут промучился, сначала с rh-nginx114 - с ним толком не работало. Файлы в
несколько ГБ вроде работали, 50ГБ - постоянные обрывы и т.д. Поставил 1.18
из оригинального репозитория - вроде дело пошло лучше, но хотелось бы
убедиться, что все сделал правильно. Обычное кэширование мне не подходило,
т.к. хосты начинают качать одновременно и получалось, что т.к. файлы большие
все равно почти все уходило на CDN. Решил сделать через слайсы. Кэш вроде
наполняется. 

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request"
'
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    tcp_nopush      on;
    tcp_nodelay     on;
    keepalive_timeout  65;
    types_hash_max_size 2048;
....
    proxy_cache_path /data/nginx/cache keys_zone=mycache:100m levels=1:2
max_size=1500g inactive=7d use_temp_path=off;
    proxy_buffering           on;
    proxy_buffer_size         4k;
    proxy_buffers             256 4k;
....
    log_format cache_status '[$time_local] $remote_addr  "$request"
$upstream_cache_status';
    access_log /var/log/nginx/cache_access.log cache_status;
....
    gzip on;
    gzip_disable "msie6";
....
    gzip_proxied any;
....
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
....
    include /etc/nginx/conf.d/*.conf;

}

server {
        listen 81;
        resolver 172.17.19.10;
        location / {
                limit_rate 30m;
                proxy_read_timeout 3600;

                proxy_cache mycache;
                proxy_pass http://cdnhost.tld$request_uri;

                slice              30m;

                proxy_cache_key $host$uri$is_args$args$slice_range;


                proxy_set_header   Range $slice_range;
                proxy_http_version 1.1;


                proxy_hide_header ETag;

                proxy_cache_valid      200 206 301 302 7d;
                proxy_cache_valid 404      1m;

                proxy_set_header        Host cdnhost.tld

                proxy_ignore_headers "Set-Cookie";
                proxy_ignore_headers Cache-Control;

                proxy_temp_path /data/nginx/temp;
        }
}


Подскажите, все ли правильно сделал? Будет ли работать так, как нужно?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288966,288966#msg-288966


From red-fox0 на ya.ru  Wed Aug  5 03:27:58 2020
From: red-fox0 на ya.ru (fox)
Date: Wed, 5 Aug 2020 10:27:58 +0700
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INGBINC60Y3RiNC10Lwg0Lg=?=
 =?UTF-8?B?0LcgQ0RO?=
In-Reply-To: <04189a9960aaec58f63cc0931ea41289.NginxMailingListRussian@forum.nginx.org>
References: <04189a9960aaec58f63cc0931ea41289.NginxMailingListRussian@forum.nginx.org>
Message-ID: <3899ffee-cf43-ca79-98cf-88f1415e122e@ya.ru>

А если сделать так: парсить логи доступа (/var/www/proxy-access.log) на
предмет скачивания файлов. Внешним скриптом/программой да хоть wget с
ключом -c выкачивать файлы и складывать в папку /var/www/cache

Конфиг:

location / {
    root /var/www/cache;
    try_files $uri @proxy;
}

location @proxy {
    proxy_pass http://cdnhost.tld$request_uri;
    access_log /var/www/proxy-access.log;
}

Nginx будет сначала пытаться брать из локального "кеша", если не
получилось - выкачает с сервера.

Недостатки: "кеш" не протухает (может быть достоинством) и может устареть.


05.08.2020 00:44, Raice пишет:
> Добрый день! Подскажите, пожалуйста, как правильно настроить проксирование с
> кэшем из CDN. Задача такая: есть CDN, с него нужно скачивать достаточной
> большой объем информации, но это достаточно дорого обходится, поэтому
> появилась такая мысль - поднять прокси на nginx, который будет проксировать
> запросы на CDN и кэшировать их. Файлы там статика, меняются крайне редко и
> размер файла может быть 200Гб и выше. Хотелось бы чтобы с CDN закачка через
> прокси шла только один раз, т.е. чтобы скачивал сам nginx и потом раздавал.
> Я тут промучился, сначала с rh-nginx114 - с ним толком не работало. Файлы в
> несколько ГБ вроде работали, 50ГБ - постоянные обрывы и т.д. Поставил 1.18
> из оригинального репозитория - вроде дело пошло лучше, но хотелось бы
> убедиться, что все сделал правильно. Обычное кэширование мне не подходило,
> т.к. хосты начинают качать одновременно и получалось, что т.к. файлы большие
> все равно почти все уходило на CDN. Решил сделать через слайсы. Кэш вроде
> наполняется. 
> 
> http {
>     log_format  main  '$remote_addr - $remote_user [$time_local] "$request"
> '
>                       '$status $body_bytes_sent "$http_referer" '
>                       '"$http_user_agent" "$http_x_forwarded_for"';
> 
>     access_log  /var/log/nginx/access.log  main;
> 
>     sendfile        on;
>     tcp_nopush      on;
>     tcp_nodelay     on;
>     keepalive_timeout  65;
>     types_hash_max_size 2048;
> ....
>     proxy_cache_path /data/nginx/cache keys_zone=mycache:100m levels=1:2
> max_size=1500g inactive=7d use_temp_path=off;
>     proxy_buffering           on;
>     proxy_buffer_size         4k;
>     proxy_buffers             256 4k;
> ....
>     log_format cache_status '[$time_local] $remote_addr  "$request"
> $upstream_cache_status';
>     access_log /var/log/nginx/cache_access.log cache_status;
> ....
>     gzip on;
>     gzip_disable "msie6";
> ....
>     gzip_proxied any;
> ....
>     include       /etc/nginx/mime.types;
>     default_type  application/octet-stream;
> ....
>     include /etc/nginx/conf.d/*.conf;
> 
> }
> 
> server {
>         listen 81;
>         resolver 172.17.19.10;
>         location / {
>                 limit_rate 30m;
>                 proxy_read_timeout 3600;
> 
>                 proxy_cache mycache;
>                 proxy_pass http://cdnhost.tld$request_uri;
> 
>                 slice              30m;
> 
>                 proxy_cache_key $host$uri$is_args$args$slice_range;
> 
> 
>                 proxy_set_header   Range $slice_range;
>                 proxy_http_version 1.1;
> 
> 
>                 proxy_hide_header ETag;
> 
>                 proxy_cache_valid      200 206 301 302 7d;
>                 proxy_cache_valid 404      1m;
> 
>                 proxy_set_header        Host cdnhost.tld
> 
>                 proxy_ignore_headers "Set-Cookie";
>                 proxy_ignore_headers Cache-Control;
> 
>                 proxy_temp_path /data/nginx/temp;
>         }
> }
> 
> 
> Подскажите, все ли правильно сделал? Будет ли работать так, как нужно?
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288966,288966#msg-288966
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 


From nginx-forum на forum.nginx.org  Wed Aug  5 04:04:16 2020
From: nginx-forum на forum.nginx.org (Raice)
Date: Wed, 05 Aug 2020 00:04:16 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INGBINC60Y3RiNC10Lwg0Lg=?=
 =?UTF-8?B?0LcgQ0RO?=
In-Reply-To: <3899ffee-cf43-ca79-98cf-88f1415e122e@ya.ru>
References: <3899ffee-cf43-ca79-98cf-88f1415e122e@ya.ru>
Message-ID: <2063d5f793bfd05cdf48db22ba67e942.NginxMailingListRussian@forum.nginx.org>

Интересная идея, спасибо! Выкачивать можно многопоточной арией, если что. 
Не могли бы Вы пояснить пример конфига? Я еще не очень в nginx, не понял его

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288966,288968#msg-288968


From nginx-forum на forum.nginx.org  Wed Aug  5 04:37:10 2020
From: nginx-forum на forum.nginx.org (Raice)
Date: Wed, 05 Aug 2020 00:37:10 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INGBINC60Y3RiNC10Lwg0Lg=?=
 =?UTF-8?B?0LcgQ0RO?=
In-Reply-To: <3899ffee-cf43-ca79-98cf-88f1415e122e@ya.ru>
References: <3899ffee-cf43-ca79-98cf-88f1415e122e@ya.ru>
Message-ID: <10d37dd58a0c4d2295e67350563bfa8a.NginxMailingListRussian@forum.nginx.org>

Попробовал Ваш конфиг, да, он выкачивает с сервера, но в папке
/var/www/cache не сохраняет

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288966,288969#msg-288969


From red-fox0 на ya.ru  Wed Aug  5 05:03:39 2020
From: red-fox0 на ya.ru (fox)
Date: Wed, 5 Aug 2020 12:03:39 +0700
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INGBINC60Y3RiNC10Lwg0Lg=?=
 =?UTF-8?B?0LcgQ0RO?=
In-Reply-To: <2063d5f793bfd05cdf48db22ba67e942.NginxMailingListRussian@forum.nginx.org>
References: <3899ffee-cf43-ca79-98cf-88f1415e122e@ya.ru>
 <2063d5f793bfd05cdf48db22ba67e942.NginxMailingListRussian@forum.nginx.org>
Message-ID: <900b69e7-0c56-df9d-4193-2c299ac68ca7@ya.ru>

https://nginx.org/ru/docs/http/ngx_http_core_module.html#try_files

05.08.2020 11:04, Raice пишет:
> Интересная идея, спасибо! Выкачивать можно многопоточной арией, если что. 
> Не могли бы Вы пояснить пример конфига? Я еще не очень в nginx, не понял его
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288966,288968#msg-288968
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 


From nginx-forum на forum.nginx.org  Wed Aug  5 05:21:17 2020
From: nginx-forum на forum.nginx.org (Raice)
Date: Wed, 05 Aug 2020 01:21:17 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INGBINC60Y3RiNC10Lwg0Lg=?=
 =?UTF-8?B?0LcgQ0RO?=
In-Reply-To: <900b69e7-0c56-df9d-4193-2c299ac68ca7@ya.ru>
References: <900b69e7-0c56-df9d-4193-2c299ac68ca7@ya.ru>
Message-ID: <63d88b411712566b3530710ec2bf9312.NginxMailingListRussian@forum.nginx.org>

Спасибо, нагуглил, прочитал. Работает, но не сохраняет файлы. Я так понимаю,
это нужно как-то дополнительно прикручивать? Не подскажете, в какую сторону
копать?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288966,288971#msg-288971


From nginx-forum на forum.nginx.org  Wed Aug  5 06:21:26 2020
From: nginx-forum на forum.nginx.org (oradba25)
Date: Wed, 05 Aug 2020 02:21:26 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INGBINC60Y3RiNC10Lwg0Lg=?=
 =?UTF-8?B?0LcgQ0RO?=
In-Reply-To: <63d88b411712566b3530710ec2bf9312.NginxMailingListRussian@forum.nginx.org>
References: <900b69e7-0c56-df9d-4193-2c299ac68ca7@ya.ru>
 <63d88b411712566b3530710ec2bf9312.NginxMailingListRussian@forum.nginx.org>
Message-ID: <eb611f4c3cf9887132fd2f052cd2ff60.NginxMailingListRussian@forum.nginx.org>

Насколько понимаю, это должно работать в комплекте с proxy_store
https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_store

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288966,288972#msg-288972


From nginx-forum на forum.nginx.org  Wed Aug  5 06:39:38 2020
From: nginx-forum на forum.nginx.org (Raice)
Date: Wed, 05 Aug 2020 02:39:38 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INGBINC60Y3RiNC10Lwg0Lg=?=
 =?UTF-8?B?0LcgQ0RO?=
In-Reply-To: <eb611f4c3cf9887132fd2f052cd2ff60.NginxMailingListRussian@forum.nginx.org>
References: <900b69e7-0c56-df9d-4193-2c299ac68ca7@ya.ru>
 <63d88b411712566b3530710ec2bf9312.NginxMailingListRussian@forum.nginx.org>
 <eb611f4c3cf9887132fd2f052cd2ff60.NginxMailingListRussian@forum.nginx.org>
Message-ID: <b606ffce5b76fb0cdc166be6724a7325.NginxMailingListRussian@forum.nginx.org>

Да, работает! Но получается, пока он файл не скачает, он будет просто
проксировать на CDN все. Т.е. если одновременно клиенты начнут качать, то в
итоге мы все равно получим N скачиваний с CDN, а клиенты все начинают качать
одновременно практически.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288966,288973#msg-288973


From chipitsine на gmail.com  Wed Aug  5 07:46:04 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 5 Aug 2020 12:46:04 +0500
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INGBINC60Y3RiNC10Lwg0Lg=?=
 =?UTF-8?B?0LcgQ0RO?=
In-Reply-To: <b606ffce5b76fb0cdc166be6724a7325.NginxMailingListRussian@forum.nginx.org>
References: <900b69e7-0c56-df9d-4193-2c299ac68ca7@ya.ru>
 <63d88b411712566b3530710ec2bf9312.NginxMailingListRussian@forum.nginx.org>
 <eb611f4c3cf9887132fd2f052cd2ff60.NginxMailingListRussian@forum.nginx.org>
 <b606ffce5b76fb0cdc166be6724a7325.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAFHpkQFmMmzMQ4HJ_kt9L6fTumgZRALO+wPtERVfZQaXBtCOGw@mail.gmail.com>

вот такая штука поможет ?

https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_lock

ср, 5 авг. 2020 г. в 11:39, Raice <nginx-forum на forum.nginx.org>:

> Да, работает! Но получается, пока он файл не скачает, он будет просто
> проксировать на CDN все. Т.е. если одновременно клиенты начнут качать, то в
> итоге мы все равно получим N скачиваний с CDN, а клиенты все начинают
> качать
> одновременно практически.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,288966,288973#msg-288973
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200805/ce0d6781/attachment.htm>

From nginx-forum на forum.nginx.org  Wed Aug  5 10:07:43 2020
From: nginx-forum на forum.nginx.org (oradba25)
Date: Wed, 05 Aug 2020 06:07:43 -0400
Subject: proxy_store tomcat
Message-ID: <92b7aa28039851b7aaeab8ef7f80a0c7.NginxMailingListRussian@forum.nginx.org>

Добрый день

Долгое время работал сайт под управлением tomcat 7.0.75 с настройкой кеша
под статику таким образом

    root                /nginx/root/site;
    location ~ ^/tst/(css|custom|galleries|i|images)/       {
        expires             3h;
        proxy_cache_valid   200 3h;
        add_header          "Cache-Control" "public";
        add_header          "Cache-Control" "no-transform";

        try_files   $uri @proxy_priv;
    }

    location @proxy_priv        {
        internal;
        proxy_intercept_errors  on;
        proxy_set_header        "Accept-Encoding" "identity";
        proxy_store             on;
        proxy_pass              http://site_priv_http;
    }


После очередного апгрейда приложения версия tomcat поменялась на 9.0.36

И вся эта кухня перестала работать. Точнее, работает только первый раз!

Потом тупо не возвращает например, тот же css -- идут ошибки HTTP 400 Bad
Request

Удаляешь файлики из  /nginx/root/site (== root) все опять ОДИН раз
отрабатывает, пока не закеширует снова

Есть подозрение, что мешает  proxy_set_header        "Accept-Encoding"
"identity";
Но тем же curl-ем тако заголовок отрабатывает вполне нормально

С другими значениями (или без этого заголовка вообще) данные приходят в
zip-виде, но браузер почему-то это не понимает и считает что они просто
кривые

Вот еще общие настройки по zip
    gzip                on;
    gzip_min_length     1000;
    gzip_disable        "msie6";
    gzip_types          text/plain text/css text/xml application/javascript
application/json application/msword application/pdf application/rtf
application/vnd.ms-excel application/vnd.ms-powerpoint application/xhtml+x
ml image/gif image/png image/tiff image/x-icon image/x-ms-bmp;
#    gzip_proxied       expired no-cache no-store private auth;
    gzip_proxied        any;
    gzip_vary           on;

Собственно, proxy_set_header        "Accept-Encoding" "identity"; и был
добавлен, чтоб контент нормальный, не зипованный приходил на frontend, а там
уж как угодно

Видимо, где-то я перемудрил
Мож кто опытным взглядом сразу увидит в чем ошибка?

Еще раз, в конфигурации с tomcat 7.0.75 все работает, при апгрейде на tomcat
9.0.36 все поломалось :-(
Спасибо

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288975,288975#msg-288975


From mdounin на mdounin.ru  Thu Aug  6 01:46:21 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 6 Aug 2020 04:46:21 +0300
Subject: proxy_store tomcat
In-Reply-To: <92b7aa28039851b7aaeab8ef7f80a0c7.NginxMailingListRussian@forum.nginx.org>
References: <92b7aa28039851b7aaeab8ef7f80a0c7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200806014621.GZ12747@mdounin.ru>

Hello!

On Wed, Aug 05, 2020 at 06:07:43AM -0400, oradba25 wrote:

> Добрый день
> 
> Долгое время работал сайт под управлением tomcat 7.0.75 с настройкой кеша
> под статику таким образом
> 
>     root                /nginx/root/site;
>     location ~ ^/tst/(css|custom|galleries|i|images)/       {
>         expires             3h;
>         proxy_cache_valid   200 3h;

Замечу, что директива "proxy_cache_valid" тут не делает ничего, 
так как ни проксирования, ни тем более проксирования с 
кэшированием в данном location'е нет.

>         add_header          "Cache-Control" "public";
>         add_header          "Cache-Control" "no-transform";
> 
>         try_files   $uri @proxy_priv;
>     }
> 
>     location @proxy_priv        {
>         internal;
>         proxy_intercept_errors  on;
>         proxy_set_header        "Accept-Encoding" "identity";
>         proxy_store             on;
>         proxy_pass              http://site_priv_http;
>     }
> 
> 
> После очередного апгрейда приложения версия tomcat поменялась на 9.0.36
> 
> И вся эта кухня перестала работать. Точнее, работает только первый раз!
> 
> Потом тупо не возвращает например, тот же css -- идут ошибки HTTP 400 Bad
> Request
> 
> Удаляешь файлики из  /nginx/root/site (== root) все опять ОДИН раз
> отрабатывает, пока не закеширует снова

Кто возвращает ошибки?  На какие запросы?  Есть ли при этом 
сохранённый файл у nginx'а для данного запроса?  Что при этом в 
access log'е и error log'е nginx'а?

> Есть подозрение, что мешает  proxy_set_header        "Accept-Encoding"
> "identity";
> Но тем же curl-ем тако заголовок отрабатывает вполне нормально

Я сомневаюсь, что дело в этом: если бы бэкенду не нравился 
заголовок "Accept-Encoding: identity", то он бы всё время 
возвращал ошибки, а не только после того, как что-то закэшируется.  
Впрочем, в любом случае самое правильное, что тут можно сделать, 
это убрать заголовок из запросов:

    proxy_set_header Accept-Encoding "";

Так заголовок не будет передаваться на бэкенд, и соответственно 
бэкенд должен будет возвращать несжатые ответы.  Ну или просто 
выключить сжатие на бэкенде и убрать вообще все манипуляции с 
заголовком Accept-Encoding.

> С другими значениями (или без этого заголовка вообще) данные приходят в
> zip-виде, но браузер почему-то это не понимает и считает что они просто
> кривые

Это ожидаемо: вы используете proxy_store, который умеет сохранять 
только тело ответа, и соответственно информация из заголовков, 
указывающая, что ответ сжат, теряется.  Браузеру в результате 
неоткуда узнать, что ответ был сжат, и с его точки зрения он 
получает мусор.

Если хочется, чтобы заголовки сохранялись и браузер мог прочитать 
такой ответ - используйте proxy_cache.  От необходимости отключать 
сжатие и/или убирать Accept-Encoding, впрочем, это не избавит: 
даже если бэкенд честно пришлёт "Vary: Accept-Encoding", 
кэшерование будет неэффективным.  С другой стороны, смысл 
использования тут proxy_store от меня так или иначе ускользает: на 
нём, конечно, можно построить много всего интересного, но он при 
этом и ограничений налагает немало.  В общем случае гораздо проще 
использовать для кэширования proxy_cache.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Thu Aug  6 07:22:20 2020
From: nginx-forum на forum.nginx.org (Raice)
Date: Thu, 06 Aug 2020 03:22:20 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INGBINC60Y3RiNC10Lwg0Lg=?=
 =?UTF-8?B?0LcgQ0RO?=
In-Reply-To: <CAFHpkQFmMmzMQ4HJ_kt9L6fTumgZRALO+wPtERVfZQaXBtCOGw@mail.gmail.com>
References: <CAFHpkQFmMmzMQ4HJ_kt9L6fTumgZRALO+wPtERVfZQaXBtCOGw@mail.gmail.com>
Message-ID: <09eba37bcb65b02a0b37922926550489.NginxMailingListRussian@forum.nginx.org>

Боюсь, что нет. Вообще, по ходу дела, nginx мне тут не поможет. Кэш
заполняется только одним потоком. На файле 200Гб (проверено сегодня) все
печально, учитывая что апстрим еще и перегружен ((

Илья Шипицин Wrote:
-------------------------------------------------------
> вот такая штука поможет ?
> 
> https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_
> lock

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288966,288985#msg-288985


From simplebox66 на gmail.com  Thu Aug  6 10:56:35 2020
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Thu, 6 Aug 2020 13:56:35 +0300
Subject: =?UTF-8?B?0J/RgNC+0LHQu9C10LzQsCDRgSDQvtGC0L7QsdGA0LDQttC10L3QuNC10LwgJHJl?=
 =?UTF-8?B?bW90ZV91c2Vy?=
Message-ID: <CA+ksgAANQbdTQs26xmGeSwLKQCOGGEmbe6bkpXcjxuj7vbcx1g@mail.gmail.com>

Всем привет.
Использую wget с ключами --http-user=USERNAME --http-password=PASSWORD при
этом в nginx в переменной $remote_user пусто. Пробовал и --user=USERNAME
--password=PASSWORD и wget  https:// USERNAME:PASSWORD на example.com, но во
всех случаях в логах в переменной $remote_user  стоит прочерк. При этом с
curl все работает ок. Подскажите в чем проблема?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200806/c0902563/attachment.htm>

From bgx на protva.ru  Thu Aug  6 11:59:36 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 6 Aug 2020 14:59:36 +0300
Subject: =?UTF-8?B?UmU6INCf0YDQvtCx0LvQtdC80LAg0YEg0L7RgtC+0LHRgNCw0LbQtdC90LjQtdC8?=
 =?UTF-8?B?ICRyZW1vdGVfdXNlcg==?=
In-Reply-To: <CA+ksgAANQbdTQs26xmGeSwLKQCOGGEmbe6bkpXcjxuj7vbcx1g@mail.gmail.com>
References: <CA+ksgAANQbdTQs26xmGeSwLKQCOGGEmbe6bkpXcjxuj7vbcx1g@mail.gmail.com>
Message-ID: <20200806115936.GA32150@sony.protva.ru>

On Thu, Aug 06, 2020 at 01:56:35PM +0300, Иван Мишин wrote:
>    Всем привет. 
>    Использую wget с ключами --http-user=USERNAME --http-password=PASSWORD при
>    этом в nginx в переменной $remote_user пусто. Пробовал и --user=USERNAME
>    --password=PASSWORD и wget  https:// [1]USERNAME:PASSWORD на example.com, но
>    во всех случаях в логах в переменной $remote_user  стоит прочерк. При этом
>    с curl все работает ок. Подскажите в чем проблема?

 Вероятно, сайт не требует авторизации, а поведение wget и curl
 в этом случае слегка различаются: curl шлёпает заголовок всегда,
 а wget лишь когда это реально нужно.
-- 
 Eugene Berdnikov

From mihakot на gmail.com  Thu Aug  6 16:26:51 2020
From: mihakot на gmail.com (MihaKot)
Date: Thu, 6 Aug 2020 19:26:51 +0300
Subject: ssl redirect
Message-ID: <CAB_7BgpnhWGE_7-fqr2_wuXp_WXzky379bt2pRoHhR06PBtKrQ@mail.gmail.com>

Всем привет.
Почему то не коректно работает редирект

server {
    listen 443 ssl;
    server_name monitor.domain;
    # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
    return 301 https://monitor.other-domain$request_uri;
}


редирект не проходит.
он подставляет сертификат от другого домена, который на этом хосте крутится.
вследствии чего браузер стопорит редирект.

Причем тоже самое но на другом сервере работает нормально.


-- 
P.S. Сохраняйте переписку в теле письма.
___________________________________
Best regards, Konstantin @MihaKot@ Aksarin.
Phone: +7 921 74 66 818
Skype: mihakot
E-mail: mihakot на gmail.com
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200806/6b36b899/attachment.htm>

From root на dl.sm.ua  Thu Aug  6 16:31:03 2020
From: root на dl.sm.ua (Dmytro Lavryk)
Date: Thu, 06 Aug 2020 19:31:03 +0300
Subject: =?UTF-8?B?0JLRltC00L/QvtCy0ZbQtNGMOiBzc2wgcmVkaXJlY3Q=?=
In-Reply-To: <CAB_7BgpnhWGE_7-fqr2_wuXp_WXzky379bt2pRoHhR06PBtKrQ@mail.gmail.com>
References: <CAB_7BgpnhWGE_7-fqr2_wuXp_WXzky379bt2pRoHhR06PBtKrQ@mail.gmail.com>
Message-ID: <173c49c968c.e205abbc82032.8333933423162519894@dl.sm.ua>

Ну так нет же тут сертификата. Пропишите для monitor.domains в конфиге.

---- Увімкнуто чт, 06 серп. 2020 19:26:51 +0300 MihaKot <mailto:mihakot на gmail.com> написав ----


Всем привет.Почему то не коректно работает редирект



server {
    listen 443 ssl;
    server_name monitor.domain;
    # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
    return 301 https://monitor.other-domain$request_uri;
}


редирект не проходит.

он подставляет сертификат от другого домена, который на этом хосте крутится.

вследствии чего браузер стопорит редирект.



Причем тоже самое но на другом сервере работает нормально.





-- 
P.S. Сохраняйте переписку в теле письма.
___________________________________
Best regards, Konstantin @MihaKot@ Aksarin.

Phone: +7 921 74 66 818

Skype: mihakot
E-mail: mailto:mihakot на gmail.com




_______________________________________________
nginx-ru mailing list
mailto:nginx-ru на nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200806/3227f27e/attachment.htm>

From chipitsine на gmail.com  Thu Aug  6 17:17:23 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 6 Aug 2020 22:17:23 +0500
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDogc3NsIHJlZGlyZWN0?=
In-Reply-To: <173c49c968c.e205abbc82032.8333933423162519894@dl.sm.ua>
References: <CAB_7BgpnhWGE_7-fqr2_wuXp_WXzky379bt2pRoHhR06PBtKrQ@mail.gmail.com>
 <173c49c968c.e205abbc82032.8333933423162519894@dl.sm.ua>
Message-ID: <CAFHpkQGCgVxeQdoYEVeUYEeY9ZyztbUcHL7R_=7bS1wpkep2Bw@mail.gmail.com>

Сертификат наследуется с уровня выше

On Thu, Aug 6, 2020, 9:31 PM Dmytro Lavryk <root на dl.sm.ua> wrote:

> Ну так нет же тут сертификата. Пропишите для monitor.domains в конфиге.
>
> ---- Увімкнуто чт, 06 серп. 2020 19:26:51 +0300 *MihaKot
> <mihakot на gmail.com <mihakot на gmail.com>>* написав ----
>
> Всем привет.
> Почему то не коректно работает редирект
>
> server {
>     listen 443 ssl;
>     server_name monitor.domain;
>     # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
>     return 301 https://monitor.other-domain$request_uri;
> }
>
>
> редирект не проходит.
> он подставляет сертификат от другого домена, который на этом хосте
> крутится.
> вследствии чего браузер стопорит редирект.
>
> Причем тоже самое но на другом сервере работает нормально.
>
>
> --
> P.S. Сохраняйте переписку в теле письма.
> ___________________________________
> Best regards, Konstantin @MihaKot@ Aksarin.
> Phone: +7 921 74 66 818
> Skype: mihakot
> E-mail: mihakot на gmail.com
> _______________________________________________
> 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
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200806/812702b7/attachment.htm>

From mihakot на gmail.com  Thu Aug  6 17:29:34 2020
From: mihakot на gmail.com (MihaKot)
Date: Thu, 6 Aug 2020 20:29:34 +0300
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDogc3NsIHJlZGlyZWN0?=
In-Reply-To: <CAFHpkQGCgVxeQdoYEVeUYEeY9ZyztbUcHL7R_=7bS1wpkep2Bw@mail.gmail.com>
References: <CAB_7BgpnhWGE_7-fqr2_wuXp_WXzky379bt2pRoHhR06PBtKrQ@mail.gmail.com>
 <173c49c968c.e205abbc82032.8333933423162519894@dl.sm.ua>
 <CAFHpkQGCgVxeQdoYEVeUYEeY9ZyztbUcHL7R_=7bS1wpkep2Bw@mail.gmail.com>
Message-ID: <CAB_7BgoH1AXSDPmSN6OhLAmkVyZcWeHKUSXtVvuUku=r+=Y6vg@mail.gmail.com>

Тогда почему на другом сервере точно такая же конфигурация работает.

чт, 6 авг. 2020 г. в 20:17, Илья Шипицин <chipitsine на gmail.com>:

> Сертификат наследуется с уровня выше
>
> On Thu, Aug 6, 2020, 9:31 PM Dmytro Lavryk <root на dl.sm.ua> wrote:
>
>> Ну так нет же тут сертификата. Пропишите для monitor.domains в конфиге.
>>
>> ---- Увімкнуто чт, 06 серп. 2020 19:26:51 +0300 *MihaKot
>> <mihakot на gmail.com <mihakot на gmail.com>>* написав ----
>>
>> Всем привет.
>> Почему то не коректно работает редирект
>>
>> server {
>>     listen 443 ssl;
>>     server_name monitor.domain;
>>     # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
>>     return 301 https://monitor.other-domain$request_uri;
>> }
>>
>>
>> редирект не проходит.
>> он подставляет сертификат от другого домена, который на этом хосте
>> крутится.
>> вследствии чего браузер стопорит редирект.
>>
>> Причем тоже самое но на другом сервере работает нормально.
>>
>>
>> --
>> P.S. Сохраняйте переписку в теле письма.
>> ___________________________________
>> Best regards, Konstantin @MihaKot@ Aksarin.
>> Phone: +7 921 74 66 818
>> Skype: mihakot
>> E-mail: mihakot на gmail.com
>> _______________________________________________
>> 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



-- 
P.S. Сохраняйте переписку в теле письма.
___________________________________
Best regards, Konstantin @MihaKot@ Aksarin.
Phone: +7 921 74 66 818
Skype: mihakot
E-mail: mihakot на gmail.com
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200806/c8b4ea24/attachment-0001.htm>

From chipitsine на gmail.com  Thu Aug  6 17:57:48 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 6 Aug 2020 22:57:48 +0500
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDogc3NsIHJlZGlyZWN0?=
In-Reply-To: <CAB_7BgoH1AXSDPmSN6OhLAmkVyZcWeHKUSXtVvuUku=r+=Y6vg@mail.gmail.com>
References: <CAB_7BgpnhWGE_7-fqr2_wuXp_WXzky379bt2pRoHhR06PBtKrQ@mail.gmail.com>
 <173c49c968c.e205abbc82032.8333933423162519894@dl.sm.ua>
 <CAFHpkQGCgVxeQdoYEVeUYEeY9ZyztbUcHL7R_=7bS1wpkep2Bw@mail.gmail.com>
 <CAB_7BgoH1AXSDPmSN6OhLAmkVyZcWeHKUSXtVvuUku=r+=Y6vg@mail.gmail.com>
Message-ID: <CAFHpkQH8==dEm5kKEvYTBZTgFg1yBFGarWVaK+Z7f0d=ufaDqw@mail.gmail.com>

Вероятно, дело в положении сервера. Или фазе луны. Попробуйте повернуть
сервер на 90%

On Thu, Aug 6, 2020, 10:30 PM MihaKot <mihakot на gmail.com> wrote:

> Тогда почему на другом сервере точно такая же конфигурация работает.
>
> чт, 6 авг. 2020 г. в 20:17, Илья Шипицин <chipitsine на gmail.com>:
>
>> Сертификат наследуется с уровня выше
>>
>> On Thu, Aug 6, 2020, 9:31 PM Dmytro Lavryk <root на dl.sm.ua> wrote:
>>
>>> Ну так нет же тут сертификата. Пропишите для monitor.domains в конфиге.
>>>
>>> ---- Увімкнуто чт, 06 серп. 2020 19:26:51 +0300 *MihaKot
>>> <mihakot на gmail.com <mihakot на gmail.com>>* написав ----
>>>
>>> Всем привет.
>>> Почему то не коректно работает редирект
>>>
>>> server {
>>>     listen 443 ssl;
>>>     server_name monitor.domain;
>>>     # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
>>>     return 301 https://monitor.other-domain$request_uri;
>>> }
>>>
>>>
>>> редирект не проходит.
>>> он подставляет сертификат от другого домена, который на этом хосте
>>> крутится.
>>> вследствии чего браузер стопорит редирект.
>>>
>>> Причем тоже самое но на другом сервере работает нормально.
>>>
>>>
>>> --
>>> P.S. Сохраняйте переписку в теле письма.
>>> ___________________________________
>>> Best regards, Konstantin @MihaKot@ Aksarin.
>>> Phone: +7 921 74 66 818
>>> Skype: mihakot
>>> E-mail: mihakot на gmail.com
>>> _______________________________________________
>>> 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
>
>
>
> --
> P.S. Сохраняйте переписку в теле письма.
> ___________________________________
> Best regards, Konstantin @MihaKot@ Aksarin.
> Phone: +7 921 74 66 818
> Skype: mihakot
> E-mail: mihakot на gmail.com
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200806/14d94bd2/attachment.htm>

From nginx-forum на forum.nginx.org  Fri Aug  7 08:46:19 2020
From: nginx-forum на forum.nginx.org (Raice)
Date: Fri, 07 Aug 2020 04:46:19 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INGBINC60Y3RiNC10Lwg0Lg=?=
 =?UTF-8?B?0LcgQ0RO?=
In-Reply-To: <09eba37bcb65b02a0b37922926550489.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQFmMmzMQ4HJ_kt9L6fTumgZRALO+wPtERVfZQaXBtCOGw@mail.gmail.com>
 <09eba37bcb65b02a0b37922926550489.NginxMailingListRussian@forum.nginx.org>
Message-ID: <16e4571f10372befd5111cebd9f99252.NginxMailingListRussian@forum.nginx.org>

Тестировал сегодня Apache Traffic Server, в принципе, под мои хотелки он
пока пойдет. Проверил, он умеет отдавать кэш даже если файл еще не закачан.
Т.е. на апстрим идет в любом случае один поток.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288966,289001#msg-289001


From nginx-forum на forum.nginx.org  Fri Aug  7 08:48:35 2020
From: nginx-forum на forum.nginx.org (Raice)
Date: Fri, 07 Aug 2020 04:48:35 -0400
Subject: =?UTF-8?B?0JLQvtC30LzQvtC20L3QviDQu9C4INGC0LDQutC+0LU/?=
Message-ID: <e31692b536c97eaa1b736d80a19e3d1d.NginxMailingListRussian@forum.nginx.org>

Клиент запрашивает файл, статику, nginx разбивает все это на несколько Range
и несколькими потоками выкачивает с апстрима и отдает клиенту. 

Понятно, что хочу странного, но все же.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289002,289002#msg-289002


From nginx-forum на forum.nginx.org  Sat Aug  8 06:42:15 2020
From: nginx-forum на forum.nginx.org (Raice)
Date: Sat, 08 Aug 2020 02:42:15 -0400
Subject: =?UTF-8?B?UmU6INCS0L7Qt9C80L7QttC90L4g0LvQuCDRgtCw0LrQvtC1Pw==?=
In-Reply-To: <e31692b536c97eaa1b736d80a19e3d1d.NginxMailingListRussian@forum.nginx.org>
References: <e31692b536c97eaa1b736d80a19e3d1d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <19bf1efdeeb00e36a6b4a9179e199f63.NginxMailingListRussian@forum.nginx.org>

Готового решения не нашел, сделал через njs и aria2

Сделал примерно так:
1. Клиент запрашивает файл, если он на сервере отсуствует, его кидает в
другой location, который вызывает через json-rpc арию, которая запущена в
режиме демона и отдает ей ссылку на файл на апстриме и кидает клиенту 404. 

2. Ария в несколько потоков его быстренько выкачивает и кладет куда надо.
Пока файл не скачался, клиенту на запросы отдается 404. 

3. Как только файл скачался - клиенту вместо 404 отдается файл. Все довольны
)

Костыльно - но вроде работает.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289002,289008#msg-289008


From nginx-forum на forum.nginx.org  Sat Aug  8 07:02:30 2020
From: nginx-forum на forum.nginx.org (bagas)
Date: Sat, 08 Aug 2020 03:02:30 -0400
Subject: =?UTF-8?B?bmdpbnggMS4xOC4wINC+0YjQuNCx0LrQsCBjb25mLmQvKi5jb25m?=
Message-ID: <f66b7043ffd1bdd324c68aeed038ef2d.NginxMailingListRussian@forum.nginx.org>

Добрый день.
Подскажите пожалуйста.
На одном из серверов nginx/1.18.0
Система FreeBSD

В конце файла /usr/local/etc/nginx/nginx.conf есть такая запись.
include /usr/local/etc/nginx/conf.d/*.conf;
include /usr/local/etc/nginx/sites-enabled/*;
}

Я решил закоментировать #include /usr/local/etc/nginx/conf.d/*.conf;
Сайты сразу падают.

в error.log
2020/08/08 09:41:41 [alert] 66331#101168: setpriority(-5) failed (13:
Permission denied)
2020/08/08 09:41:41 [alert] 66332#101620: setpriority(-5) failed (13:
Permission denied)
2020/08/08 09:41:41 [alert] 66333#100304: setpriority(-5) failed (13:
Permission denied)

Через sockstat -4 нет прослушивания ip адреса.
Директория conf.d пуста, ее я еще не создал.
ls -al /usr/local/etc/nginx/conf.d/
ls: /usr/local/etc/nginx/conf.d/: No such file or directory

Как только запись include /usr/local/etc/nginx/conf.d/*.conf; раскоментирую,
то сервер запускается нормально.
Почему такое происходит?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289009,289009#msg-289009


From marck на rinet.ru  Sat Aug  8 09:24:56 2020
From: marck на rinet.ru (Dmitry Morozovsky)
Date: Sat, 8 Aug 2020 12:24:56 +0300 (MSK)
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQvtGI0LjQsdC60LAgY29uZi5kLyouY29uZg==?=
In-Reply-To: <f66b7043ffd1bdd324c68aeed038ef2d.NginxMailingListRussian@forum.nginx.org>
References: <f66b7043ffd1bdd324c68aeed038ef2d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <alpine.BSF.2.00.2008081222320.99835@woozle.rinet.ru>

On Sat, 8 Aug 2020, bagas wrote:

> Добрый день.
> Подскажите пожалуйста.
> На одном из серверов nginx/1.18.0
> Система FreeBSD
> 
> В конце файла /usr/local/etc/nginx/nginx.conf есть такая запись.
> include /usr/local/etc/nginx/conf.d/*.conf;
> include /usr/local/etc/nginx/sites-enabled/*;
> }

в штатном nginx.conf для FreeBSD (из пакета/порта) таких строк нет, подозреваю, 
что конфиг "творчески переработан" с какого-либо из линуксов

что выдают 

nginx -V
nginx -t (для обоих случаев)
и
nginx -T (для случая когда "работает")

?


> 
> Я решил закоментировать #include /usr/local/etc/nginx/conf.d/*.conf;
> Сайты сразу падают.
> 
> в error.log
> 2020/08/08 09:41:41 [alert] 66331#101168: setpriority(-5) failed (13:
> Permission denied)
> 2020/08/08 09:41:41 [alert] 66332#101620: setpriority(-5) failed (13:
> Permission denied)
> 2020/08/08 09:41:41 [alert] 66333#100304: setpriority(-5) failed (13:
> Permission denied)
> 
> Через sockstat -4 нет прослушивания ip адреса.
> Директория conf.d пуста, ее я еще не создал.
> ls -al /usr/local/etc/nginx/conf.d/
> ls: /usr/local/etc/nginx/conf.d/: No such file or directory
> 
> Как только запись include /usr/local/etc/nginx/conf.d/*.conf; раскоментирую,
> то сервер запускается нормально.
> Почему такое происходит?
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289009,289009#msg-289009
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 

-- 
Sincerely,
D.Marck                                        [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                    marck на FreeBSD.org ]
---------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle на woozle.net ***
---------------------------------------------------------------------------

From nginx-forum на forum.nginx.org  Sat Aug  8 09:40:35 2020
From: nginx-forum на forum.nginx.org (bagas)
Date: Sat, 08 Aug 2020 05:40:35 -0400
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQvtGI0LjQsdC60LAgY29uZi5kLyouY29uZg==?=
In-Reply-To: <alpine.BSF.2.00.2008081222320.99835@woozle.rinet.ru>
References: <alpine.BSF.2.00.2008081222320.99835@woozle.rinet.ru>
Message-ID: <05638edb1752a53282e1455fc27fd205.NginxMailingListRussian@forum.nginx.org>

по 
nginx -t и nginx -T
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289009,289011#msg-289011


From marck на rinet.ru  Sat Aug  8 09:42:08 2020
From: marck на rinet.ru (Dmitry Morozovsky)
Date: Sat, 8 Aug 2020 12:42:08 +0300 (MSK)
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQvtGI0LjQsdC60LAgY29uZi5kLyouY29uZg==?=
In-Reply-To: <05638edb1752a53282e1455fc27fd205.NginxMailingListRussian@forum.nginx.org>
References: <alpine.BSF.2.00.2008081222320.99835@woozle.rinet.ru>
 <05638edb1752a53282e1455fc27fd205.NginxMailingListRussian@forum.nginx.org>
Message-ID: <alpine.BSF.2.00.2008081241280.99835@woozle.rinet.ru>

On Sat, 8 Aug 2020, bagas wrote:

> по 
> nginx -t и nginx -T
> nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful

тогда смотреть в error.log

-- 
Sincerely,
D.Marck                                        [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                    marck на FreeBSD.org ]
---------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle на woozle.net ***
---------------------------------------------------------------------------

From nginx-forum на forum.nginx.org  Sat Aug  8 09:51:16 2020
From: nginx-forum на forum.nginx.org (bagas)
Date: Sat, 08 Aug 2020 05:51:16 -0400
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQvtGI0LjQsdC60LAgY29uZi5kLyouY29uZg==?=
In-Reply-To: <alpine.BSF.2.00.2008081241280.99835@woozle.rinet.ru>
References: <alpine.BSF.2.00.2008081241280.99835@woozle.rinet.ru>
Message-ID: <5a41d44815b0ac98f130be576dc0f8b3.NginxMailingListRussian@forum.nginx.org>

нашел проблему.
    gzip_types text/plain application/x-javascript;

#    include /usr/local/etc/nginx/conf.d/*.conf;
    include /usr/local/etc/nginx/sites-enabled/*;
}

Параметр не был закрыт символом ;
 gzip_types text/plain application/x-javascript

После как добавил в конец строки символ закрытия параметра ; , то все
заработало нормально.
Странно почему изначально при тесте nginx -t конфига он не ругался на этоn
косяк.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289009,289013#msg-289013


From marck на rinet.ru  Sat Aug  8 09:53:22 2020
From: marck на rinet.ru (Dmitry Morozovsky)
Date: Sat, 8 Aug 2020 12:53:22 +0300 (MSK)
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQvtGI0LjQsdC60LAgY29uZi5kLyouY29uZg==?=
In-Reply-To: <5a41d44815b0ac98f130be576dc0f8b3.NginxMailingListRussian@forum.nginx.org>
References: <alpine.BSF.2.00.2008081241280.99835@woozle.rinet.ru>
 <5a41d44815b0ac98f130be576dc0f8b3.NginxMailingListRussian@forum.nginx.org>
Message-ID: <alpine.BSF.2.00.2008081252320.99835@woozle.rinet.ru>

On Sat, 8 Aug 2020, bagas wrote:

> нашел проблему.
>     gzip_types text/plain application/x-javascript;
> 
> #    include /usr/local/etc/nginx/conf.d/*.conf;
>     include /usr/local/etc/nginx/sites-enabled/*;
> }
> 
> Параметр не был закрыт символом ;
>  gzip_types text/plain application/x-javascript
> 
> После как добавил в конец строки символ закрытия параметра ; , то все
> заработало нормально.
> Странно почему изначально при тесте nginx -t конфига он не ругался на этоn
> косяк.

потому что "include /usr/local/etc/nginx/conf.d/*.conf;" воспринималось как 
параметры gzip_types (а в них там довольно свободный формат)


-- 
Sincerely,
D.Marck                                        [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                    marck на FreeBSD.org ]
---------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle на woozle.net ***
---------------------------------------------------------------------------

From nginx-forum на forum.nginx.org  Sat Aug  8 10:08:53 2020
From: nginx-forum на forum.nginx.org (bagas)
Date: Sat, 08 Aug 2020 06:08:53 -0400
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQvtGI0LjQsdC60LAgY29uZi5kLyouY29uZg==?=
In-Reply-To: <alpine.BSF.2.00.2008081252320.99835@woozle.rinet.ru>
References: <alpine.BSF.2.00.2008081252320.99835@woozle.rinet.ru>
Message-ID: <ca79f324a89cdb554572c09d803afb9a.NginxMailingListRussian@forum.nginx.org>

Не понял, это как так?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289009,289015#msg-289015


From nginx-forum на forum.nginx.org  Sat Aug  8 10:10:25 2020
From: nginx-forum на forum.nginx.org (bagas)
Date: Sat, 08 Aug 2020 06:10:25 -0400
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQvtGI0LjQsdC60LAgY29uZi5kLyouY29uZg==?=
In-Reply-To: <alpine.BSF.2.00.2008081252320.99835@woozle.rinet.ru>
References: <alpine.BSF.2.00.2008081252320.99835@woozle.rinet.ru>
Message-ID: <633e2b2ce9d2098e00fd7d1f15894811.NginxMailingListRussian@forum.nginx.org>

nginx думал что это один параметр?
gzip_types text/plain application/x-javascript
include /usr/local/etc/nginx/conf.d/*.conf;

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289009,289016#msg-289016


From marck на rinet.ru  Sat Aug  8 10:14:11 2020
From: marck на rinet.ru (Dmitry Morozovsky)
Date: Sat, 8 Aug 2020 13:14:11 +0300 (MSK)
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQvtGI0LjQsdC60LAgY29uZi5kLyouY29uZg==?=
In-Reply-To: <633e2b2ce9d2098e00fd7d1f15894811.NginxMailingListRussian@forum.nginx.org>
References: <alpine.BSF.2.00.2008081252320.99835@woozle.rinet.ru>
 <633e2b2ce9d2098e00fd7d1f15894811.NginxMailingListRussian@forum.nginx.org>
Message-ID: <alpine.BSF.2.00.2008081313020.99835@woozle.rinet.ru>

On Sat, 8 Aug 2020, bagas wrote:

> nginx думал что это один параметр?
> gzip_types text/plain application/x-javascript
> include /usr/local/etc/nginx/conf.d/*.conf;

читайте документакию, она рулез ;-)

переводы строк не ограничивают команду

(а вот что происходит если посредине возникает комментарий -- надо смотреть 
парсер, а мне сейчас лень ;-P)


-- 
Sincerely,
D.Marck                                        [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                    marck на FreeBSD.org ]
---------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle на woozle.net ***
---------------------------------------------------------------------------

From nginx-forum на forum.nginx.org  Sat Aug  8 15:41:00 2020
From: nginx-forum на forum.nginx.org (bagas)
Date: Sat, 08 Aug 2020 11:41:00 -0400
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQvtGI0LjQsdC60LAgY29uZi5kLyouY29uZg==?=
In-Reply-To: <alpine.BSF.2.00.2008081313020.99835@woozle.rinet.ru>
References: <alpine.BSF.2.00.2008081313020.99835@woozle.rinet.ru>
Message-ID: <4ac7bea3516d72a9a0f457f97b1aadf2.NginxMailingListRussian@forum.nginx.org>

Ясно.
Спасибо за содействие.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289009,289019#msg-289019


From slw на zxy.spb.ru  Sun Aug  9 21:13:09 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 10 Aug 2020 00:13:09 +0300
Subject: nginx proxy MISS
Message-ID: <20200809211309.GU2015@zxy.spb.ru>


Есть файл, не меняется, заголовков про expire не имеет.

Response: {'status': 200, 'headers': {'content-length': '615700', 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified': 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag': '"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
 'tx00000000000000451618a-005f306158-a6edb7b-default', 'date': 'Sun, 09 Aug 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason': 'OK'}
 
188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616316 HIT - - -
95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 MISS 0.000 0.020 616032

какие причины могут быть для возникновения MISS?

зона не заполнена даже наполовину.
proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2 max_size=6000g inactive=10d use_temp_path=off;

From mdounin на mdounin.ru  Mon Aug 10 00:26:25 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 10 Aug 2020 03:26:25 +0300
Subject: nginx proxy MISS
In-Reply-To: <20200809211309.GU2015@zxy.spb.ru>
References: <20200809211309.GU2015@zxy.spb.ru>
Message-ID: <20200810002625.GH12747@mdounin.ru>

Hello!

On Mon, Aug 10, 2020 at 12:13:09AM +0300, Slawa Olhovchenkov wrote:

> Есть файл, не меняется, заголовков про expire не имеет.
> 
> Response: {'status': 200, 'headers': {'content-length': '615700', 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified': 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag': '"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
>  'tx00000000000000451618a-005f306158-a6edb7b-default', 'date': 'Sun, 09 Aug 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason': 'OK'}
>  
> 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
> 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
> 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616316 HIT - - -
> 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 MISS 0.000 0.020 616032
> 
> какие причины могут быть для возникновения MISS?
> 
> зона не заполнена даже наполовину.
> proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2 max_size=6000g inactive=10d use_temp_path=off;

Если выше показаны заголовки ответа бэкенда, то я в первую очередь 
не вижу, почему бы этому файлу кэшироваться.  То есть - каковы 
причины для возникновения HIT?

В отсутствии явно заданных заголовков Cache-Control / Expire / 
X-Accel-Expire - единственная возможная причина кэширования это 
директива proxy_cache_valid, если она в конфиге есть - то 
вероятнее всего отвечает на оба вопроса.

-- 
Maxim Dounin
http://mdounin.ru/

From slw на zxy.spb.ru  Mon Aug 10 08:22:57 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 10 Aug 2020 11:22:57 +0300
Subject: nginx proxy MISS
In-Reply-To: <20200810002625.GH12747@mdounin.ru>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru>
Message-ID: <20200810082257.GV2015@zxy.spb.ru>

On Mon, Aug 10, 2020 at 03:26:25AM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Mon, Aug 10, 2020 at 12:13:09AM +0300, Slawa Olhovchenkov wrote:
> 
> > Есть файл, не меняется, заголовков про expire не имеет.
> > 
> > Response: {'status': 200, 'headers': {'content-length': '615700', 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified': 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag': '"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
> >  'tx00000000000000451618a-005f306158-a6edb7b-default', 'date': 'Sun, 09 Aug 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason': 'OK'}
> >  
> > 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
> > 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
> > 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616316 HIT - - -
> > 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 MISS 0.000 0.020 616032
> > 
> > какие причины могут быть для возникновения MISS?
> > 
> > зона не заполнена даже наполовину.
> > proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2 max_size=6000g inactive=10d use_temp_path=off;
> 
> Если выше показаны заголовки ответа бэкенда, то я в первую очередь 
> не вижу, почему бы этому файлу кэшироваться.  То есть - каковы 
> причины для возникновения HIT?
> 
> В отсутствии явно заданных заголовков Cache-Control / Expire / 
> X-Accel-Expire - единственная возможная причина кэширования это 
> директива proxy_cache_valid, если она в конфиге есть - то 
> вероятнее всего отвечает на оба вопроса.

proxy_cache_valid      200  5d;


From mdounin на mdounin.ru  Mon Aug 10 12:40:58 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 10 Aug 2020 15:40:58 +0300
Subject: nginx proxy MISS
In-Reply-To: <20200810082257.GV2015@zxy.spb.ru>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru>
 <20200810082257.GV2015@zxy.spb.ru>
Message-ID: <20200810124058.GJ12747@mdounin.ru>

Hello!

On Mon, Aug 10, 2020 at 11:22:57AM +0300, Slawa Olhovchenkov wrote:

> On Mon, Aug 10, 2020 at 03:26:25AM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Mon, Aug 10, 2020 at 12:13:09AM +0300, Slawa Olhovchenkov wrote:
> > 
> > > Есть файл, не меняется, заголовков про expire не имеет.
> > > 
> > > Response: {'status': 200, 'headers': {'content-length': '615700', 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified': 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag': '"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
> > >  'tx00000000000000451618a-005f306158-a6edb7b-default', 'date': 'Sun, 09 Aug 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason': 'OK'}
> > >  
> > > 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
> > > 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
> > > 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616316 HIT - - -
> > > 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 MISS 0.000 0.020 616032
> > > 
> > > какие причины могут быть для возникновения MISS?
> > > 
> > > зона не заполнена даже наполовину.
> > > proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2 max_size=6000g inactive=10d use_temp_path=off;
> > 
> > Если выше показаны заголовки ответа бэкенда, то я в первую очередь 
> > не вижу, почему бы этому файлу кэшироваться.  То есть - каковы 
> > причины для возникновения HIT?
> > 
> > В отсутствии явно заданных заголовков Cache-Control / Expire / 
> > X-Accel-Expire - единственная возможная причина кэширования это 
> > директива proxy_cache_valid, если она в конфиге есть - то 
> > вероятнее всего отвечает на оба вопроса.
> 
> proxy_cache_valid      200  5d;

Я бы ещё внимательно посмотрел на тайминги.  Непонятно, что за 
времена приведены в логах, но $request_time там точно нет, а если 
запросы общаются с бэкендом одновременно и proxy_cache_lock не 
используется - то и MISS'ов может быть одновременно много, при 
этом завершаться запросы могут в заметно разное время.

-- 
Maxim Dounin
http://mdounin.ru/

From slw на zxy.spb.ru  Mon Aug 10 13:04:11 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 10 Aug 2020 16:04:11 +0300
Subject: nginx proxy MISS
In-Reply-To: <20200810124058.GJ12747@mdounin.ru>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru>
 <20200810082257.GV2015@zxy.spb.ru>
 <20200810124058.GJ12747@mdounin.ru>
Message-ID: <20200810130411.GW2015@zxy.spb.ru>

On Mon, Aug 10, 2020 at 03:40:58PM +0300, Maxim Dounin wrote:

> Hello!
> 
> On Mon, Aug 10, 2020 at 11:22:57AM +0300, Slawa Olhovchenkov wrote:
> 
> > On Mon, Aug 10, 2020 at 03:26:25AM +0300, Maxim Dounin wrote:
> > 
> > > Hello!
> > > 
> > > On Mon, Aug 10, 2020 at 12:13:09AM +0300, Slawa Olhovchenkov wrote:
> > > 
> > > > Есть файл, не меняется, заголовков про expire не имеет.
> > > > 
> > > > Response: {'status': 200, 'headers': {'content-length': '615700', 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified': 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag': '"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
> > > >  'tx00000000000000451618a-005f306158-a6edb7b-default', 'date': 'Sun, 09 Aug 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason': 'OK'}
> > > >  
> > > > 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
> > > > 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
> > > > 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616316 HIT - - -
> > > > 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 MISS 0.000 0.020 616032
> > > > 
> > > > какие причины могут быть для возникновения MISS?
> > > > 
> > > > зона не заполнена даже наполовину.
> > > > proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2 max_size=6000g inactive=10d use_temp_path=off;
> > > 
> > > Если выше показаны заголовки ответа бэкенда, то я в первую очередь 
> > > не вижу, почему бы этому файлу кэшироваться.  То есть - каковы 
> > > причины для возникновения HIT?
> > > 
> > > В отсутствии явно заданных заголовков Cache-Control / Expire / 
> > > X-Accel-Expire - единственная возможная причина кэширования это 
> > > директива proxy_cache_valid, если она в конфиге есть - то 
> > > вероятнее всего отвечает на оба вопроса.
> > 
> > proxy_cache_valid      200  5d;
> 
> Я бы ещё внимательно посмотрел на тайминги.  Непонятно, что за 
> времена приведены в логах, но $request_time там точно нет, а если 

$request_time $connection $upstream_cache_status $upstream_connect_time $upstream_response_time $upstream_bytes_received

> запросы общаются с бэкендом одновременно и proxy_cache_lock не 

да не вопрос.

> используется - то и MISS'ов может быть одновременно много, при 
> этом завершаться запросы могут в заметно разное время.

не понимаю. вот есть первый запрос, окончился в 21:01:48, начался ну пусть в 21:01:47. апстрим отдался почти мгновенно.
теперь на 5 дней должен быть хит независимо от. а в логе то хит то мисс.

188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.106 78233513 MISS 0.000 0.016 616206
212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.409 71530389 HIT - - -
109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.106 78883331 HIT - - -
165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.045 78875231 MISS 0.000 0.043 616196
176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.973 78738732 HIT - - -
178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.000 73778063 HIT - - -
85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 0.001 73446584 HIT - - -
91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.331 77746051 HIT - - -
128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.444 78915833 HIT - - -
5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616316 0.318 78021062 HIT - - -
95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.144 77651040 MISS 0.000 0.020 616032
95.153.130.125 :44399 [30/Jul/2020:21:04:23 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616316 0.109 79016152 HIT - - -
188.242.86.10 :33086 [31/Jul/2020:21:01:48 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.146 142965396 HIT - - -
185.150.15.3 :43144 [31/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.585 147489940 HIT - - -
5.139.125.143 :45274 [31/Jul/2020:21:01:52 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.000 139348909 HIT - - -
2.93.146.181 :64401 [31/Jul/2020:21:01:52 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.331 147881538 HIT - - -
45.14.20.210 :56346 [31/Jul/2020:21:01:48 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.557 147593212 MISS 0.000 0.034 616196
176.15.175.107 :64656 [31/Jul/2020:21:01:51 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.045 138478791 HIT - - -
31.173.27.253 :24479 [31/Jul/2020:21:02:15 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.336 138765630 HIT - - -
31.8.119.217 :44474 [01/Aug/2020:21:01:51 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.001 175116 HIT - - -
93.157.255.141 :55898 [01/Aug/2020:21:01:50 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.003 184720 HIT - - -
188.242.226.75 :50497 [01/Aug/2020:21:02:41 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.020 196184 MISS 0.000 0.019 616206
85.249.93.174 :61175 [01/Aug/2020:21:02:42 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.033 177157 MISS 0.000 0.005 616032
85.249.93.174 :61175 [01/Aug/2020:21:04:11 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.074 177157 HIT - - -
195.91.235.1 :51530 [02/Aug/2020:21:01:51 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.051 30760317 HIT - - -
178.35.97.85 :39544 [02/Aug/2020:21:01:50 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.610 30713067 MISS 0.000 0.059 616196
185.210.141.93 :31497 [02/Aug/2020:21:01:53 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.001 27394454 HIT - - -
95.106.51.194 :49978 [02/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.083 30106701 HIT - - -
31.173.242.246 :43492 [02/Aug/2020:21:02:18 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.125 30729007 HIT - - -
178.214.244.168 :62584 [02/Aug/2020:21:02:37 +0300] "GET /720p_02815.ts HTTP/1.1" 200 616316 0.064 27345988 MISS 0.000 0.063 616032
5.59.246.39 :54222 [03/Aug/2020:21:01:48 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 0.627 75630042 HIT - - -
178.46.84.175 :1297 [03/Aug/2020:21:01:50 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.646 82246680 MISS 0.001 0.009 616206
31.42.202.16 :54256 [03/Aug/2020:21:01:49 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 1.024 82699416 HIT - - -
178.141.203.153 :49142 [03/Aug/2020:21:01:49 +0300] "GET /720p_02815.ts HTTP/1.1" 200 616330 0.083 82933835 HIT - - -
95.106.51.194 :64821 [03/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.081 81742475 HIT - - -
37.57.177.193 :40080 [03/Aug/2020:21:01:49 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.173 81979125 HIT - - -
109.126.206.105 :32934 [03/Aug/2020:21:01:50 +0300] "GET /720p_02815.ts HTTP/1.1" 200 616330 0.423 82865568 HIT - - -
188.162.48.9 :53456 [03/Aug/2020:21:01:54 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.219 82944963 HIT - - -
77.222.122.114 :51574 [03/Aug/2020:21:01:46 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.092 75876544 MISS 0.000 0.092 616196
85.140.27.24 :30386 [03/Aug/2020:21:01:53 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.000 79100194 HIT - - -
81.177.200.155 :37464 [03/Aug/2020:21:02:04 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.001 82246005 HIT - - -
95.27.40.105 :6659 [03/Aug/2020:21:02:14 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 0.000 79931961 HIT - - -
217.107.126.16 :1690 [03/Aug/2020:21:02:30 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.150 83000660 MISS 0.000 0.009 616032
89.113.139.97 :20539 [03/Aug/2020:21:02:44 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.375 82804373 HIT - - -
188.233.116.101 :46197 [04/Aug/2020:21:01:47 +0300] "GET /720p_02815.ts HTTP/1.1" 200 616330 0.249 137854093 MISS 0.000 0.091 616196
91.221.176.225 :35008 [04/Aug/2020:21:01:49 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.781 139347091 HIT - - -
37.112.20.234 :14044 [04/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.221 139452444 HIT - - -
5.172.21.239 :48116 [04/Aug/2020:21:01:51 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.809 139288096 HIT - - -
89.232.84.205 :52780 [04/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.334 139454730 HIT - - -
77.222.122.52 :49651 [04/Aug/2020:21:01:48 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.001 133695884 HIT - - -
90.151.84.91 :1123 [04/Aug/2020:21:01:50 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 0.490 139195030 HIT - - -
2.56.181.13 :50021 [04/Aug/2020:21:01:51 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 0.178 139435015 HIT - - -
94.51.121.147 :64072 [04/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.226 139382518 MISS 0.000 0.013 616206
92.124.204.243 :3506 [04/Aug/2020:21:01:57 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.432 132803534 HIT - - -
128.69.245.154 :42206 [04/Aug/2020:21:02:01 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.445 138341412 HIT - - -
194.15.118.1 :51417 [04/Aug/2020:21:02:34 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616316 1.224 136548989 MISS 0.000 0.008 616032
89.113.189.95 :51856 [04/Aug/2020:21:02:40 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.000 136555467 HIT - - -
109.105.70.145 :53657 [05/Aug/2020:21:01:49 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 0.352 190821258 HIT - - -
89.169.48.215 :49391 [05/Aug/2020:21:01:54 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.034 190437436 HIT - - -
178.46.116.40 :1291 [05/Aug/2020:21:01:50 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 1.954 199717854 MISS 0.000 0.027 616206
5.18.254.171 :5066 [05/Aug/2020:21:01:52 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 0.000 192022051 HIT - - -
78.29.103.136 :49362 [05/Aug/2020:21:01:59 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.393 199373868 HIT - - -
78.37.193.55 :42336 [05/Aug/2020:21:01:49 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.090 199524641 MISS 0.000 0.012 616196
46.147.234.69 :49796 [05/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.192 198440282 HIT - - -
31.173.31.32 :2698 [05/Aug/2020:21:02:33 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616316 0.220 199860483 MISS 0.000 0.008 616032
85.26.232.197 :42741 [05/Aug/2020:21:03:08 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.001 199675636 HIT - - -
176.214.139.229 :54162 [07/Aug/2020:21:01:57 +0300] "GET /720p_02815.ts HTTP/1.1" 200 616330 0.174 320872769 MISS 0.001 0.031 616196
178.70.10.90 :42298 [07/Aug/2020:21:02:24 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 0.089 311085923 HIT - - -
46.146.255.161 :65434 [07/Aug/2020:21:02:30 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616316 0.276 319791320 MISS 0.000 0.006 616032
213.87.120.119 :15102 [07/Aug/2020:21:02:37 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616316 0.457 322097116 HIT - - -
46.45.199.227 :64596 [08/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.300 402068415 HIT - - -
109.252.29.102 :6096 [08/Aug/2020:21:01:48 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.233 392777294 MISS 0.000 0.181 616196
94.50.150.211 :64486 [08/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 0.398 401696010 MISS 0.000 0.011 616206
85.140.12.87 :5579 [08/Aug/2020:21:01:57 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 1.038 401915843 HIT - - -
5.166.124.28 :52152 [08/Aug/2020:21:02:27 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616316 0.513 396688107 MISS 0.000 0.009 616032

From chipitsine на gmail.com  Mon Aug 10 13:38:11 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 10 Aug 2020 18:38:11 +0500
Subject: nginx proxy MISS
In-Reply-To: <20200810130411.GW2015@zxy.spb.ru>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru>
 <20200810082257.GV2015@zxy.spb.ru> <20200810124058.GJ12747@mdounin.ru>
 <20200810130411.GW2015@zxy.spb.ru>
Message-ID: <CAFHpkQGCwN1QarNsorrXsJ_E+7EKFRrfx0mo6O_g7q_-DXy==Q@mail.gmail.com>

а содержимое файла /720p_02815.ts может меняться ?

если контент уникален, может включить proxy store ?

пн, 10 авг. 2020 г. в 18:04, Slawa Olhovchenkov <slw на zxy.spb.ru>:

> On Mon, Aug 10, 2020 at 03:40:58PM +0300, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Mon, Aug 10, 2020 at 11:22:57AM +0300, Slawa Olhovchenkov wrote:
> >
> > > On Mon, Aug 10, 2020 at 03:26:25AM +0300, Maxim Dounin wrote:
> > >
> > > > Hello!
> > > >
> > > > On Mon, Aug 10, 2020 at 12:13:09AM +0300, Slawa Olhovchenkov wrote:
> > > >
> > > > > Есть файл, не меняется, заголовков про expire не имеет.
> > > > >
> > > > > Response: {'status': 200, 'headers': {'content-length': '615700',
> 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified':
> 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag':
> '"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
> > > > >  'tx00000000000000451618a-005f306158-a6edb7b-default', 'date':
> 'Sun, 09 Aug 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason':
> 'OK'}
> > > > >
> > > > > 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET
> /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
> > > > > 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]    "GET
> /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
> > > > > 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]    "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300]     "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET
> /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]    "GET
> /720p_02815.ts HTTP/1.1" 200 616316 HIT - - -
> > > > > 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET
> /720p_02815.ts HTTP/1.1" 200 616316 MISS 0.000 0.020 616032
> > > > >
> > > > > какие причины могут быть для возникновения MISS?
> > > > >
> > > > > зона не заполнена даже наполовину.
> > > > > proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2
> max_size=6000g inactive=10d use_temp_path=off;
> > > >
> > > > Если выше показаны заголовки ответа бэкенда, то я в первую очередь
> > > > не вижу, почему бы этому файлу кэшироваться.  То есть - каковы
> > > > причины для возникновения HIT?
> > > >
> > > > В отсутствии явно заданных заголовков Cache-Control / Expire /
> > > > X-Accel-Expire - единственная возможная причина кэширования это
> > > > директива proxy_cache_valid, если она в конфиге есть - то
> > > > вероятнее всего отвечает на оба вопроса.
> > >
> > > proxy_cache_valid      200  5d;
> >
> > Я бы ещё внимательно посмотрел на тайминги.  Непонятно, что за
> > времена приведены в логах, но $request_time там точно нет, а если
>
> $request_time $connection $upstream_cache_status $upstream_connect_time
> $upstream_response_time $upstream_bytes_received
>
> > запросы общаются с бэкендом одновременно и proxy_cache_lock не
>
> да не вопрос.
>
> > используется - то и MISS'ов может быть одновременно много, при
> > этом завершаться запросы могут в заметно разное время.
>
> не понимаю. вот есть первый запрос, окончился в 21:01:48, начался ну пусть
> в 21:01:47. апстрим отдался почти мгновенно.
> теперь на 5 дней должен быть хит независимо от. а в логе то хит то мисс.
>
> 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.106 78233513 MISS 0.000 0.016 616206
> 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.409 71530389 HIT - - -
> 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.106 78883331 HIT - - -
> 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.045 78875231 MISS 0.000 0.043 616196
> 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.973 78738732 HIT - - -
> 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.000 73778063 HIT - - -
> 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300]     "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.001 73446584 HIT - - -
> 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.331 77746051 HIT - - -
> 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.444 78915833 HIT - - -
> 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.318 78021062 HIT - - -
> 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.144 77651040 MISS 0.000 0.020 616032
> 95.153.130.125 :44399 [30/Jul/2020:21:04:23 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.109 79016152 HIT - - -
> 188.242.86.10 :33086 [31/Jul/2020:21:01:48 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.146 142965396 HIT - - -
> 185.150.15.3 :43144 [31/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.585 147489940 HIT - - -
> 5.139.125.143 :45274 [31/Jul/2020:21:01:52 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.000 139348909 HIT - - -
> 2.93.146.181 :64401 [31/Jul/2020:21:01:52 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.331 147881538 HIT - - -
> 45.14.20.210 :56346 [31/Jul/2020:21:01:48 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.557 147593212 MISS 0.000 0.034 616196
> 176.15.175.107 :64656 [31/Jul/2020:21:01:51 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.045 138478791 HIT - - -
> 31.173.27.253 :24479 [31/Jul/2020:21:02:15 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.336 138765630 HIT - - -
> 31.8.119.217 :44474 [01/Aug/2020:21:01:51 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.001 175116 HIT - - -
> 93.157.255.141 :55898 [01/Aug/2020:21:01:50 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.003 184720 HIT - - -
> 188.242.226.75 :50497 [01/Aug/2020:21:02:41 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.020 196184 MISS 0.000 0.019 616206
> 85.249.93.174 :61175 [01/Aug/2020:21:02:42 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.033 177157 MISS 0.000 0.005 616032
> 85.249.93.174 :61175 [01/Aug/2020:21:04:11 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.074 177157 HIT - - -
> 195.91.235.1 :51530 [02/Aug/2020:21:01:51 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.051 30760317 HIT - - -
> 178.35.97.85 :39544 [02/Aug/2020:21:01:50 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.610 30713067 MISS 0.000 0.059 616196
> 185.210.141.93 :31497 [02/Aug/2020:21:01:53 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.001 27394454 HIT - - -
> 95.106.51.194 :49978 [02/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.083 30106701 HIT - - -
> 31.173.242.246 :43492 [02/Aug/2020:21:02:18 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.125 30729007 HIT - - -
> 178.214.244.168 :62584 [02/Aug/2020:21:02:37 +0300] "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.064 27345988 MISS 0.000 0.063 616032
> 5.59.246.39 :54222 [03/Aug/2020:21:01:48 +0300]     "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.627 75630042 HIT - - -
> 178.46.84.175 :1297 [03/Aug/2020:21:01:50 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.646 82246680 MISS 0.001 0.009 616206
> 31.42.202.16 :54256 [03/Aug/2020:21:01:49 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 1.024 82699416 HIT - - -
> 178.141.203.153 :49142 [03/Aug/2020:21:01:49 +0300] "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.083 82933835 HIT - - -
> 95.106.51.194 :64821 [03/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.081 81742475 HIT - - -
> 37.57.177.193 :40080 [03/Aug/2020:21:01:49 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.173 81979125 HIT - - -
> 109.126.206.105 :32934 [03/Aug/2020:21:01:50 +0300] "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.423 82865568 HIT - - -
> 188.162.48.9 :53456 [03/Aug/2020:21:01:54 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.219 82944963 HIT - - -
> 77.222.122.114 :51574 [03/Aug/2020:21:01:46 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.092 75876544 MISS 0.000 0.092 616196
> 85.140.27.24 :30386 [03/Aug/2020:21:01:53 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.000 79100194 HIT - - -
> 81.177.200.155 :37464 [03/Aug/2020:21:02:04 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.001 82246005 HIT - - -
> 95.27.40.105 :6659 [03/Aug/2020:21:02:14 +0300]     "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.000 79931961 HIT - - -
> 217.107.126.16 :1690 [03/Aug/2020:21:02:30 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.150 83000660 MISS 0.000 0.009 616032
> 89.113.139.97 :20539 [03/Aug/2020:21:02:44 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.375 82804373 HIT - - -
> 188.233.116.101 :46197 [04/Aug/2020:21:01:47 +0300] "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.249 137854093 MISS 0.000 0.091 616196
> 91.221.176.225 :35008 [04/Aug/2020:21:01:49 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.781 139347091 HIT - - -
> 37.112.20.234 :14044 [04/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.221 139452444 HIT - - -
> 5.172.21.239 :48116 [04/Aug/2020:21:01:51 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.809 139288096 HIT - - -
> 89.232.84.205 :52780 [04/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.334 139454730 HIT - - -
> 77.222.122.52 :49651 [04/Aug/2020:21:01:48 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.001 133695884 HIT - - -
> 90.151.84.91 :1123 [04/Aug/2020:21:01:50 +0300]     "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.490 139195030 HIT - - -
> 2.56.181.13 :50021 [04/Aug/2020:21:01:51 +0300]     "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.178 139435015 HIT - - -
> 94.51.121.147 :64072 [04/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.226 139382518 MISS 0.000 0.013 616206
> 92.124.204.243 :3506 [04/Aug/2020:21:01:57 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.432 132803534 HIT - - -
> 128.69.245.154 :42206 [04/Aug/2020:21:02:01 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.445 138341412 HIT - - -
> 194.15.118.1 :51417 [04/Aug/2020:21:02:34 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616316 1.224 136548989 MISS 0.000 0.008 616032
> 89.113.189.95 :51856 [04/Aug/2020:21:02:40 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.000 136555467 HIT - - -
> 109.105.70.145 :53657 [05/Aug/2020:21:01:49 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.352 190821258 HIT - - -
> 89.169.48.215 :49391 [05/Aug/2020:21:01:54 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.034 190437436 HIT - - -
> 178.46.116.40 :1291 [05/Aug/2020:21:01:50 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 1.954 199717854 MISS 0.000 0.027 616206
> 5.18.254.171 :5066 [05/Aug/2020:21:01:52 +0300]     "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.000 192022051 HIT - - -
> 78.29.103.136 :49362 [05/Aug/2020:21:01:59 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.393 199373868 HIT - - -
> 78.37.193.55 :42336 [05/Aug/2020:21:01:49 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.090 199524641 MISS 0.000 0.012 616196
> 46.147.234.69 :49796 [05/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.192 198440282 HIT - - -
> 31.173.31.32 :2698 [05/Aug/2020:21:02:33 +0300]     "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.220 199860483 MISS 0.000 0.008 616032
> 85.26.232.197 :42741 [05/Aug/2020:21:03:08 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.001 199675636 HIT - - -
> 176.214.139.229 :54162 [07/Aug/2020:21:01:57 +0300] "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.174 320872769 MISS 0.001 0.031 616196
> 178.70.10.90 :42298 [07/Aug/2020:21:02:24 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.089 311085923 HIT - - -
> 46.146.255.161 :65434 [07/Aug/2020:21:02:30 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.276 319791320 MISS 0.000 0.006 616032
> 213.87.120.119 :15102 [07/Aug/2020:21:02:37 +0300]  "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.457 322097116 HIT - - -
> 46.45.199.227 :64596 [08/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.300 402068415 HIT - - -
> 109.252.29.102 :6096 [08/Aug/2020:21:01:48 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.233 392777294 MISS 0.000 0.181 616196
> 94.50.150.211 :64486 [08/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts
> HTTP/1.1" 200 616330 0.398 401696010 MISS 0.000 0.011 616206
> 85.140.12.87 :5579 [08/Aug/2020:21:01:57 +0300]     "GET /720p_02815.ts
> HTTP/1.1" 200 616330 1.038 401915843 HIT - - -
> 5.166.124.28 :52152 [08/Aug/2020:21:02:27 +0300]    "GET /720p_02815.ts
> HTTP/1.1" 200 616316 0.513 396688107 MISS 0.000 0.009 616032
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200810/f7f1a833/attachment-0001.htm>

From slw на zxy.spb.ru  Mon Aug 10 14:07:00 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 10 Aug 2020 17:07:00 +0300
Subject: nginx proxy MISS
In-Reply-To: <CAFHpkQGCwN1QarNsorrXsJ_E+7EKFRrfx0mo6O_g7q_-DXy==Q@mail.gmail.com>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru>
 <20200810082257.GV2015@zxy.spb.ru>
 <20200810124058.GJ12747@mdounin.ru>
 <20200810130411.GW2015@zxy.spb.ru>
 <CAFHpkQGCwN1QarNsorrXsJ_E+7EKFRrfx0mo6O_g7q_-DXy==Q@mail.gmail.com>
Message-ID: <20200810140700.GX2015@zxy.spb.ru>

On Mon, Aug 10, 2020 at 06:38:11PM +0500, Илья Шипицин wrote:

> а содержимое файла /720p_02815.ts может меняться ?

я же показал что таймстамп июньский.

> если контент уникален, может включить proxy store ?

а как объем контролировать и устаревание?
и в принципе да, содержимое меняться теоретически может.

> пн, 10 авг. 2020 г. в 18:04, Slawa Olhovchenkov <slw на zxy.spb.ru>:
> 
> > On Mon, Aug 10, 2020 at 03:40:58PM +0300, Maxim Dounin wrote:
> >
> > > Hello!
> > >
> > > On Mon, Aug 10, 2020 at 11:22:57AM +0300, Slawa Olhovchenkov wrote:
> > >
> > > > On Mon, Aug 10, 2020 at 03:26:25AM +0300, Maxim Dounin wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > On Mon, Aug 10, 2020 at 12:13:09AM +0300, Slawa Olhovchenkov wrote:
> > > > >
> > > > > > Есть файл, не меняется, заголовков про expire не имеет.
> > > > > >
> > > > > > Response: {'status': 200, 'headers': {'content-length': '615700',
> > 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified':
> > 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag':
> > '"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
> > > > > >  'tx00000000000000451618a-005f306158-a6edb7b-default', 'date':
> > 'Sun, 09 Aug 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason':
> > 'OK'}
> > > > > >
> > > > > > 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
> > > > > > 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]    "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
> > > > > > 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]    "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300]     "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET
> > /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > > 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]    "GET
> > /720p_02815.ts HTTP/1.1" 200 616316 HIT - - -
> > > > > > 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET
> > /720p_02815.ts HTTP/1.1" 200 616316 MISS 0.000 0.020 616032
> > > > > >
> > > > > > какие причины могут быть для возникновения MISS?
> > > > > >
> > > > > > зона не заполнена даже наполовину.
> > > > > > proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2
> > max_size=6000g inactive=10d use_temp_path=off;
> > > > >
> > > > > Если выше показаны заголовки ответа бэкенда, то я в первую очередь
> > > > > не вижу, почему бы этому файлу кэшироваться.  То есть - каковы
> > > > > причины для возникновения HIT?
> > > > >
> > > > > В отсутствии явно заданных заголовков Cache-Control / Expire /
> > > > > X-Accel-Expire - единственная возможная причина кэширования это
> > > > > директива proxy_cache_valid, если она в конфиге есть - то
> > > > > вероятнее всего отвечает на оба вопроса.
> > > >
> > > > proxy_cache_valid      200  5d;
> > >
> > > Я бы ещё внимательно посмотрел на тайминги.  Непонятно, что за
> > > времена приведены в логах, но $request_time там точно нет, а если
> >
> > $request_time $connection $upstream_cache_status $upstream_connect_time
> > $upstream_response_time $upstream_bytes_received
> >
> > > запросы общаются с бэкендом одновременно и proxy_cache_lock не
> >
> > да не вопрос.
> >
> > > используется - то и MISS'ов может быть одновременно много, при
> > > этом завершаться запросы могут в заметно разное время.
> >
> > не понимаю. вот есть первый запрос, окончился в 21:01:48, начался ну пусть
> > в 21:01:47. апстрим отдался почти мгновенно.
> > теперь на 5 дней должен быть хит независимо от. а в логе то хит то мисс.
> >
> > 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.106 78233513 MISS 0.000 0.016 616206
> > 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.409 71530389 HIT - - -
> > 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.106 78883331 HIT - - -
> > 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.045 78875231 MISS 0.000 0.043 616196
> > 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.973 78738732 HIT - - -
> > 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.000 73778063 HIT - - -
> > 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300]     "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.001 73446584 HIT - - -
> > 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.331 77746051 HIT - - -
> > 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.444 78915833 HIT - - -
> > 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.318 78021062 HIT - - -
> > 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.144 77651040 MISS 0.000 0.020 616032
> > 95.153.130.125 :44399 [30/Jul/2020:21:04:23 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.109 79016152 HIT - - -
> > 188.242.86.10 :33086 [31/Jul/2020:21:01:48 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.146 142965396 HIT - - -
> > 185.150.15.3 :43144 [31/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.585 147489940 HIT - - -
> > 5.139.125.143 :45274 [31/Jul/2020:21:01:52 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.000 139348909 HIT - - -
> > 2.93.146.181 :64401 [31/Jul/2020:21:01:52 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.331 147881538 HIT - - -
> > 45.14.20.210 :56346 [31/Jul/2020:21:01:48 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.557 147593212 MISS 0.000 0.034 616196
> > 176.15.175.107 :64656 [31/Jul/2020:21:01:51 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.045 138478791 HIT - - -
> > 31.173.27.253 :24479 [31/Jul/2020:21:02:15 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.336 138765630 HIT - - -
> > 31.8.119.217 :44474 [01/Aug/2020:21:01:51 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.001 175116 HIT - - -
> > 93.157.255.141 :55898 [01/Aug/2020:21:01:50 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.003 184720 HIT - - -
> > 188.242.226.75 :50497 [01/Aug/2020:21:02:41 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.020 196184 MISS 0.000 0.019 616206
> > 85.249.93.174 :61175 [01/Aug/2020:21:02:42 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.033 177157 MISS 0.000 0.005 616032
> > 85.249.93.174 :61175 [01/Aug/2020:21:04:11 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.074 177157 HIT - - -
> > 195.91.235.1 :51530 [02/Aug/2020:21:01:51 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.051 30760317 HIT - - -
> > 178.35.97.85 :39544 [02/Aug/2020:21:01:50 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.610 30713067 MISS 0.000 0.059 616196
> > 185.210.141.93 :31497 [02/Aug/2020:21:01:53 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.001 27394454 HIT - - -
> > 95.106.51.194 :49978 [02/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.083 30106701 HIT - - -
> > 31.173.242.246 :43492 [02/Aug/2020:21:02:18 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.125 30729007 HIT - - -
> > 178.214.244.168 :62584 [02/Aug/2020:21:02:37 +0300] "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.064 27345988 MISS 0.000 0.063 616032
> > 5.59.246.39 :54222 [03/Aug/2020:21:01:48 +0300]     "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.627 75630042 HIT - - -
> > 178.46.84.175 :1297 [03/Aug/2020:21:01:50 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.646 82246680 MISS 0.001 0.009 616206
> > 31.42.202.16 :54256 [03/Aug/2020:21:01:49 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 1.024 82699416 HIT - - -
> > 178.141.203.153 :49142 [03/Aug/2020:21:01:49 +0300] "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.083 82933835 HIT - - -
> > 95.106.51.194 :64821 [03/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.081 81742475 HIT - - -
> > 37.57.177.193 :40080 [03/Aug/2020:21:01:49 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.173 81979125 HIT - - -
> > 109.126.206.105 :32934 [03/Aug/2020:21:01:50 +0300] "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.423 82865568 HIT - - -
> > 188.162.48.9 :53456 [03/Aug/2020:21:01:54 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.219 82944963 HIT - - -
> > 77.222.122.114 :51574 [03/Aug/2020:21:01:46 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.092 75876544 MISS 0.000 0.092 616196
> > 85.140.27.24 :30386 [03/Aug/2020:21:01:53 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.000 79100194 HIT - - -
> > 81.177.200.155 :37464 [03/Aug/2020:21:02:04 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.001 82246005 HIT - - -
> > 95.27.40.105 :6659 [03/Aug/2020:21:02:14 +0300]     "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.000 79931961 HIT - - -
> > 217.107.126.16 :1690 [03/Aug/2020:21:02:30 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.150 83000660 MISS 0.000 0.009 616032
> > 89.113.139.97 :20539 [03/Aug/2020:21:02:44 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.375 82804373 HIT - - -
> > 188.233.116.101 :46197 [04/Aug/2020:21:01:47 +0300] "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.249 137854093 MISS 0.000 0.091 616196
> > 91.221.176.225 :35008 [04/Aug/2020:21:01:49 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.781 139347091 HIT - - -
> > 37.112.20.234 :14044 [04/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.221 139452444 HIT - - -
> > 5.172.21.239 :48116 [04/Aug/2020:21:01:51 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.809 139288096 HIT - - -
> > 89.232.84.205 :52780 [04/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.334 139454730 HIT - - -
> > 77.222.122.52 :49651 [04/Aug/2020:21:01:48 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.001 133695884 HIT - - -
> > 90.151.84.91 :1123 [04/Aug/2020:21:01:50 +0300]     "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.490 139195030 HIT - - -
> > 2.56.181.13 :50021 [04/Aug/2020:21:01:51 +0300]     "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.178 139435015 HIT - - -
> > 94.51.121.147 :64072 [04/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.226 139382518 MISS 0.000 0.013 616206
> > 92.124.204.243 :3506 [04/Aug/2020:21:01:57 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.432 132803534 HIT - - -
> > 128.69.245.154 :42206 [04/Aug/2020:21:02:01 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.445 138341412 HIT - - -
> > 194.15.118.1 :51417 [04/Aug/2020:21:02:34 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 1.224 136548989 MISS 0.000 0.008 616032
> > 89.113.189.95 :51856 [04/Aug/2020:21:02:40 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.000 136555467 HIT - - -
> > 109.105.70.145 :53657 [05/Aug/2020:21:01:49 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.352 190821258 HIT - - -
> > 89.169.48.215 :49391 [05/Aug/2020:21:01:54 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.034 190437436 HIT - - -
> > 178.46.116.40 :1291 [05/Aug/2020:21:01:50 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 1.954 199717854 MISS 0.000 0.027 616206
> > 5.18.254.171 :5066 [05/Aug/2020:21:01:52 +0300]     "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.000 192022051 HIT - - -
> > 78.29.103.136 :49362 [05/Aug/2020:21:01:59 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.393 199373868 HIT - - -
> > 78.37.193.55 :42336 [05/Aug/2020:21:01:49 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.090 199524641 MISS 0.000 0.012 616196
> > 46.147.234.69 :49796 [05/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.192 198440282 HIT - - -
> > 31.173.31.32 :2698 [05/Aug/2020:21:02:33 +0300]     "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.220 199860483 MISS 0.000 0.008 616032
> > 85.26.232.197 :42741 [05/Aug/2020:21:03:08 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.001 199675636 HIT - - -
> > 176.214.139.229 :54162 [07/Aug/2020:21:01:57 +0300] "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.174 320872769 MISS 0.001 0.031 616196
> > 178.70.10.90 :42298 [07/Aug/2020:21:02:24 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.089 311085923 HIT - - -
> > 46.146.255.161 :65434 [07/Aug/2020:21:02:30 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.276 319791320 MISS 0.000 0.006 616032
> > 213.87.120.119 :15102 [07/Aug/2020:21:02:37 +0300]  "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.457 322097116 HIT - - -
> > 46.45.199.227 :64596 [08/Aug/2020:21:01:51 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.300 402068415 HIT - - -
> > 109.252.29.102 :6096 [08/Aug/2020:21:01:48 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.233 392777294 MISS 0.000 0.181 616196
> > 94.50.150.211 :64486 [08/Aug/2020:21:01:50 +0300]   "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 0.398 401696010 MISS 0.000 0.011 616206
> > 85.140.12.87 :5579 [08/Aug/2020:21:01:57 +0300]     "GET /720p_02815.ts
> > HTTP/1.1" 200 616330 1.038 401915843 HIT - - -
> > 5.166.124.28 :52152 [08/Aug/2020:21:02:27 +0300]    "GET /720p_02815.ts
> > HTTP/1.1" 200 616316 0.513 396688107 MISS 0.000 0.009 616032
> > _______________________________________________
> > 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


From mdounin на mdounin.ru  Mon Aug 10 16:13:22 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 10 Aug 2020 19:13:22 +0300
Subject: nginx proxy MISS
In-Reply-To: <20200810130411.GW2015@zxy.spb.ru>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru>
 <20200810082257.GV2015@zxy.spb.ru>
 <20200810124058.GJ12747@mdounin.ru>
 <20200810130411.GW2015@zxy.spb.ru>
Message-ID: <20200810161322.GO12747@mdounin.ru>

Hello!

On Mon, Aug 10, 2020 at 04:04:11PM +0300, Slawa Olhovchenkov wrote:

> On Mon, Aug 10, 2020 at 03:40:58PM +0300, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Mon, Aug 10, 2020 at 11:22:57AM +0300, Slawa Olhovchenkov wrote:
> > 
> > > On Mon, Aug 10, 2020 at 03:26:25AM +0300, Maxim Dounin wrote:
> > > 
> > > > Hello!
> > > > 
> > > > On Mon, Aug 10, 2020 at 12:13:09AM +0300, Slawa Olhovchenkov wrote:
> > > > 
> > > > > Есть файл, не меняется, заголовков про expire не имеет.
> > > > > 
> > > > > Response: {'status': 200, 'headers': {'content-length': '615700', 'x-rgw-object-type': 'Normal', 'accept-ranges': 'bytes', 'last-modified': 'Wed, 08 Jul 2020 01:35:48 GMT', 'connection': 'Keep-Alive', 'etag': '"1f722dbb169b83ea4f5897d638d39c8d"', 'x-amz-request-id':
> > > > >  'tx00000000000000451618a-005f306158-a6edb7b-default', 'date': 'Sun, 09 Aug 2020 20:49:28 GMT', 'content-type': 'video/MP2T'}, 'reason': 'OK'}
> > > > >  
> > > > > 188.242.226.75 :62964 [30/Jul/2020:21:01:48 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.016 616206
> > > > > 212.164.64.179 :6700 [30/Jul/2020:21:01:50 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 109.94.87.178 :56019 [30/Jul/2020:21:01:51 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 165.225.66.51 :3581 [30/Jul/2020:21:01:46 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 MISS 0.000 0.043 616196
> > > > > 176.59.135.87 :41598 [30/Jul/2020:21:01:47 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 178.184.45.0 :45255 [30/Jul/2020:21:01:50 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 85.26.233.17 :6656 [30/Jul/2020:21:01:59 +0300]     "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 91.214.220.143 :43841 [30/Jul/2020:21:01:59 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 128.71.141.232 :57462 [30/Jul/2020:21:02:31 +0300]  "GET /720p_02815.ts HTTP/1.1" 200 616330 HIT - - -
> > > > > 5.167.161.39 :64139 [30/Jul/2020:21:02:36 +0300]    "GET /720p_02815.ts HTTP/1.1" 200 616316 HIT - - -
> > > > > 95.105.98.204 :49869 [30/Jul/2020:21:02:34 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 MISS 0.000 0.020 616032
> > > > > 
> > > > > какие причины могут быть для возникновения MISS?
> > > > > 
> > > > > зона не заполнена даже наполовину.
> > > > > proxy_cache_path /cache keys_zone=RGW:1000m levels=2:2 max_size=6000g inactive=10d use_temp_path=off;
> > > > 
> > > > Если выше показаны заголовки ответа бэкенда, то я в первую очередь 
> > > > не вижу, почему бы этому файлу кэшироваться.  То есть - каковы 
> > > > причины для возникновения HIT?
> > > > 
> > > > В отсутствии явно заданных заголовков Cache-Control / Expire / 
> > > > X-Accel-Expire - единственная возможная причина кэширования это 
> > > > директива proxy_cache_valid, если она в конфиге есть - то 
> > > > вероятнее всего отвечает на оба вопроса.
> > > 
> > > proxy_cache_valid      200  5d;
> > 
> > Я бы ещё внимательно посмотрел на тайминги.  Непонятно, что за 
> > времена приведены в логах, но $request_time там точно нет, а если 
> 
> $request_time $connection $upstream_cache_status $upstream_connect_time $upstream_response_time $upstream_bytes_received
> 
> > запросы общаются с бэкендом одновременно и proxy_cache_lock не 
> 
> да не вопрос.
> 
> > используется - то и MISS'ов может быть одновременно много, при 
> > этом завершаться запросы могут в заметно разное время.
> 
> не понимаю. вот есть первый запрос, окончился в 21:01:48, начался ну пусть в 21:01:47. апстрим отдался почти мгновенно.
> теперь на 5 дней должен быть хит независимо от. а в логе то хит то мисс.

Дальше имеет смысл смотреть на:

1. Откуда вообще логи, с одной ли машины?  Такой разброс времени 
при логгировании можно, конечно, получить при буферизированном 
логгировании, но выглядит подозрительно.

2. Что на самом деле в заголовках ответов бэкенда?  Скажем, 
наличие какого-нибудь Vary легко объясняет наблюдаемый эффект.  
Особенно в этом плане характерны запросы от одного клиента:

> 85.249.93.174 :61175 [01/Aug/2020:21:02:42 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.033 177157 MISS 0.000 0.005 616032
> 85.249.93.174 :61175 [01/Aug/2020:21:04:11 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.074 177157 HIT - - -

3. Ну и проверить, что вообще в ключе кэширования, не добавлено ли 
там чего-либо клиентоспецифичного случайно.

Если не поможет - смотреть debug log'и, там всё должно быть 
плюс-минус очевидно.

-- 
Maxim Dounin
http://mdounin.ru/

From slw на zxy.spb.ru  Mon Aug 10 16:33:22 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 10 Aug 2020 19:33:22 +0300
Subject: nginx proxy MISS
In-Reply-To: <20200810161322.GO12747@mdounin.ru>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru>
 <20200810082257.GV2015@zxy.spb.ru>
 <20200810124058.GJ12747@mdounin.ru>
 <20200810130411.GW2015@zxy.spb.ru>
 <20200810161322.GO12747@mdounin.ru>
Message-ID: <20200810163322.GY2015@zxy.spb.ru>

On Mon, Aug 10, 2020 at 07:13:22PM +0300, Maxim Dounin wrote:

> > > Я бы ещё внимательно посмотрел на тайминги.  Непонятно, что за 
> > > времена приведены в логах, но $request_time там точно нет, а если 
> > 
> > $request_time $connection $upstream_cache_status $upstream_connect_time $upstream_response_time $upstream_bytes_received
> > 
> > > запросы общаются с бэкендом одновременно и proxy_cache_lock не 
> > 
> > да не вопрос.
> > 
> > > используется - то и MISS'ов может быть одновременно много, при 
> > > этом завершаться запросы могут в заметно разное время.
> > 
> > не понимаю. вот есть первый запрос, окончился в 21:01:48, начался ну пусть в 21:01:47. апстрим отдался почти мгновенно.
> > теперь на 5 дней должен быть хит независимо от. а в логе то хит то мисс.
> 
> Дальше имеет смысл смотреть на:
> 
> 1. Откуда вообще логи, с одной ли машины?  Такой разброс времени 
> при логгировании можно, конечно, получить при буферизированном 
> логгировании, но выглядит подозрительно.

с одной, буферезированно

> 2. Что на самом деле в заголовках ответов бэкенда?  Скажем, 
> наличие какого-нибудь Vary легко объясняет наблюдаемый эффект.  

я поищу объект в кеше на диске.
бакэнд -- ceph radosgw, он довстаточно тупой, кмк и ничего такого
выдавать не должен.
у типичного объекта заголовки выглядят так:

KEY:
http://rgw/xxx....xxx/720p_00480.ts
HTTP/1.1 200 OK
Content-Length: 925524
Accept-Ranges: bytes
Last-Modified: Tue, 28 Jul 2020 11:24:38 GMT
x-rgw-object-type: Normal
ETag: "872d2e58236625d418f4c5b5b95938a6"
x-amz-request-id: tx000000000000004e0151a-005f316581-a67b17a-default
Access-Control-Allow-Origin: https://some.site
Vary: Origin
Access-Control-Allow-Methods: GET
Access-Control-Expose-Headers: Content-Length,Content-Type
Content-Type: video/MP2T
Date: Mon, 10 Aug 2020 15:19:29 GMT
Connection: close

это что, Vary: Origin гадит? фильтрануть его с бэкенда, что ли?

> Особенно в этом плане характерны запросы от одного клиента:
> 
> > 85.249.93.174 :61175 [01/Aug/2020:21:02:42 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.033 177157 MISS 0.000 0.005 616032
> > 85.249.93.174 :61175 [01/Aug/2020:21:04:11 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.074 177157 HIT - - -
> 
> 3. Ну и проверить, что вообще в ключе кэширования, не добавлено ли 
> там чего-либо клиентоспецифичного случайно.

вообще не модифицировалось

> Если не поможет - смотреть debug log'и, там всё должно быть 
> плюс-минус очевидно.

это продакшен, с дебаг логами боюсь все станет раком (а так бы я прямо
с них и начал бы).

From mdounin на mdounin.ru  Mon Aug 10 17:16:49 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 10 Aug 2020 20:16:49 +0300
Subject: nginx proxy MISS
In-Reply-To: <20200810163322.GY2015@zxy.spb.ru>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru>
 <20200810082257.GV2015@zxy.spb.ru>
 <20200810124058.GJ12747@mdounin.ru>
 <20200810130411.GW2015@zxy.spb.ru>
 <20200810161322.GO12747@mdounin.ru>
 <20200810163322.GY2015@zxy.spb.ru>
Message-ID: <20200810171649.GP12747@mdounin.ru>

Hello!

On Mon, Aug 10, 2020 at 07:33:22PM +0300, Slawa Olhovchenkov wrote:

> On Mon, Aug 10, 2020 at 07:13:22PM +0300, Maxim Dounin wrote:
> 
> > > > Я бы ещё внимательно посмотрел на тайминги.  Непонятно, что за 
> > > > времена приведены в логах, но $request_time там точно нет, а если 
> > > 
> > > $request_time $connection $upstream_cache_status $upstream_connect_time $upstream_response_time $upstream_bytes_received
> > > 
> > > > запросы общаются с бэкендом одновременно и proxy_cache_lock не 
> > > 
> > > да не вопрос.
> > > 
> > > > используется - то и MISS'ов может быть одновременно много, при 
> > > > этом завершаться запросы могут в заметно разное время.
> > > 
> > > не понимаю. вот есть первый запрос, окончился в 21:01:48, начался ну пусть в 21:01:47. апстрим отдался почти мгновенно.
> > > теперь на 5 дней должен быть хит независимо от. а в логе то хит то мисс.
> > 
> > Дальше имеет смысл смотреть на:
> > 
> > 1. Откуда вообще логи, с одной ли машины?  Такой разброс времени 
> > при логгировании можно, конечно, получить при буферизированном 
> > логгировании, но выглядит подозрительно.
> 
> с одной, буферезированно
> 
> > 2. Что на самом деле в заголовках ответов бэкенда?  Скажем, 
> > наличие какого-нибудь Vary легко объясняет наблюдаемый эффект.  
> 
> я поищу объект в кеше на диске.
> бакэнд -- ceph radosgw, он довстаточно тупой, кмк и ничего такого
> выдавать не должен.
> у типичного объекта заголовки выглядят так:
> 
> KEY:
> http://rgw/xxx....xxx/720p_00480.ts
> HTTP/1.1 200 OK
> Content-Length: 925524
> Accept-Ranges: bytes
> Last-Modified: Tue, 28 Jul 2020 11:24:38 GMT
> x-rgw-object-type: Normal
> ETag: "872d2e58236625d418f4c5b5b95938a6"
> x-amz-request-id: tx000000000000004e0151a-005f316581-a67b17a-default
> Access-Control-Allow-Origin: https://some.site
> Vary: Origin
> Access-Control-Allow-Methods: GET
> Access-Control-Expose-Headers: Content-Length,Content-Type
> Content-Type: video/MP2T
> Date: Mon, 10 Aug 2020 15:19:29 GMT
> Connection: close
> 
> это что, Vary: Origin гадит? фильтрануть его с бэкенда, что ли?

Это выглядит как наиболее вероятная причина.

При наличии "Vary: Origin" запросы с разными значениями заголовка 
Origin - это запросы, на которые могут быть разные ответы, и 
соответственно каждое новое значение - это очередной MISS в логах.

Для лечения есть ручка "proxy_ignore_headers Vary;" 
(http://nginx.org/r/proxy_ignore_headers).

> > Особенно в этом плане характерны запросы от одного клиента:
> > 
> > > 85.249.93.174 :61175 [01/Aug/2020:21:02:42 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.033 177157 MISS 0.000 0.005 616032
> > > 85.249.93.174 :61175 [01/Aug/2020:21:04:11 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.074 177157 HIT - - -
> > 
> > 3. Ну и проверить, что вообще в ключе кэширования, не добавлено ли 
> > там чего-либо клиентоспецифичного случайно.
> 
> вообще не модифицировалось

По умолчанию там конструкция, близкая к 
$scheme$proxy_host$request_uri, и, скажем $proxy_host может 
зависить от клиента, если в proxy_pass написать что-нибудь с 
переменными.

> > Если не поможет - смотреть debug log'и, там всё должно быть 
> > плюс-минус очевидно.
> 
> это продакшен, с дебаг логами боюсь все станет раком (а так бы я прямо
> с них и начал бы).

Just in case, дебаг можно включать не для всех, а только для части 
клиентов (http://nginx.org/r/debug_connection), это можно 
относительно безопасно делать в том числе и в продакшне.  Следя, 
естественно, чтобы не включить слишком много, и чтобы место под 
логи не кончалось.

-- 
Maxim Dounin
http://mdounin.ru/

From gmm на csdoc.com  Mon Aug 10 17:19:40 2020
From: gmm на csdoc.com (Gena Makhomed)
Date: Mon, 10 Aug 2020 20:19:40 +0300
Subject: nginx proxy MISS
In-Reply-To: <20200810163322.GY2015@zxy.spb.ru>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru> <20200810082257.GV2015@zxy.spb.ru>
 <20200810124058.GJ12747@mdounin.ru> <20200810130411.GW2015@zxy.spb.ru>
 <20200810161322.GO12747@mdounin.ru> <20200810163322.GY2015@zxy.spb.ru>
Message-ID: <cd808d60-dd33-95d4-0ff2-6fd811c66371@csdoc.com>

On 10.08.2020 19:33, Slawa Olhovchenkov wrote:

>> Если не поможет - смотреть debug log'и, там всё должно быть
>> плюс-минус очевидно.

> это продакшен, с дебаг логами боюсь все станет раком (а так бы я прямо
> с них и начал бы).

http://nginx.org/ru/docs/ngx_core_module.html#debug_connection

разве не поможет сделать отладку прямо на проде?

-- 
Best regards,
  Gena


From slw на zxy.spb.ru  Mon Aug 10 17:30:53 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 10 Aug 2020 20:30:53 +0300
Subject: nginx proxy MISS
In-Reply-To: <20200810171649.GP12747@mdounin.ru>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru>
 <20200810082257.GV2015@zxy.spb.ru>
 <20200810124058.GJ12747@mdounin.ru>
 <20200810130411.GW2015@zxy.spb.ru>
 <20200810161322.GO12747@mdounin.ru>
 <20200810163322.GY2015@zxy.spb.ru>
 <20200810171649.GP12747@mdounin.ru>
Message-ID: <20200810173053.GZ2015@zxy.spb.ru>

On Mon, Aug 10, 2020 at 08:16:49PM +0300, Maxim Dounin wrote:

> > это что, Vary: Origin гадит? фильтрануть его с бэкенда, что ли?
> 
> Это выглядит как наиболее вероятная причина.
> 
> При наличии "Vary: Origin" запросы с разными значениями заголовка 
> Origin - это запросы, на которые могут быть разные ответы, и 
> соответственно каждое новое значение - это очередной MISS в логах.
> 
> Для лечения есть ручка "proxy_ignore_headers Vary;" 
> (http://nginx.org/r/proxy_ignore_headers).

попробую, спасибо.

> > > Особенно в этом плане характерны запросы от одного клиента:
> > > 
> > > > 85.249.93.174 :61175 [01/Aug/2020:21:02:42 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.033 177157 MISS 0.000 0.005 616032
> > > > 85.249.93.174 :61175 [01/Aug/2020:21:04:11 +0300]   "GET /720p_02815.ts HTTP/1.1" 200 616316 0.074 177157 HIT - - -
> > > 
> > > 3. Ну и проверить, что вообще в ключе кэширования, не добавлено ли 
> > > там чего-либо клиентоспецифичного случайно.
> > 
> > вообще не модифицировалось
> 
> По умолчанию там конструкция, близкая к 
> $scheme$proxy_host$request_uri, и, скажем $proxy_host может 
> зависить от клиента, если в proxy_pass написать что-нибудь с 
> переменными.

не, такого нет. у меня proxy_pass тупо на upstream;

> > > Если не поможет - смотреть debug log'и, там всё должно быть 
> > > плюс-минус очевидно.
> > 
> > это продакшен, с дебаг логами боюсь все станет раком (а так бы я прямо
> > с них и начал бы).
> 
> Just in case, дебаг можно включать не для всех, а только для части 
> клиентов (http://nginx.org/r/debug_connection), это можно 
> относительно безопасно делать в том числе и в продакшне.  Следя, 
> естественно, чтобы не включить слишком много, и чтобы место под 
> логи не кончалось.

да кто ж знает что там за клиент(ы).
я просто заинтересовался чего это у меня MISS много?
дальше поел смотреть по какому URI из больше всего и почему бы это
могло быть.

From slw на zxy.spb.ru  Mon Aug 10 17:32:13 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 10 Aug 2020 20:32:13 +0300
Subject: nginx proxy MISS
In-Reply-To: <cd808d60-dd33-95d4-0ff2-6fd811c66371@csdoc.com>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru>
 <20200810082257.GV2015@zxy.spb.ru>
 <20200810124058.GJ12747@mdounin.ru>
 <20200810130411.GW2015@zxy.spb.ru>
 <20200810161322.GO12747@mdounin.ru>
 <20200810163322.GY2015@zxy.spb.ru>
 <cd808d60-dd33-95d4-0ff2-6fd811c66371@csdoc.com>
Message-ID: <20200810173213.GA2015@zxy.spb.ru>

On Mon, Aug 10, 2020 at 08:19:40PM +0300, Gena Makhomed wrote:

> On 10.08.2020 19:33, Slawa Olhovchenkov wrote:
> 
> >> Если не поможет - смотреть debug log'и, там всё должно быть
> >> плюс-минус очевидно.
> 
> > это продакшен, с дебаг логами боюсь все станет раком (а так бы я прямо
> > с них и начал бы).
> 
> http://nginx.org/ru/docs/ngx_core_module.html#debug_connection
> 
> разве не поможет сделать отладку прямо на проде?

и что я туда напишу?
нет, у меня так не со всеми клиентами.
нет, я не знаю чем отличаются те клиенты от которых MISS.
или после которых MISS.

From mdounin на mdounin.ru  Mon Aug 10 18:06:28 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 10 Aug 2020 21:06:28 +0300
Subject: nginx proxy MISS
In-Reply-To: <20200810173053.GZ2015@zxy.spb.ru>
References: <20200809211309.GU2015@zxy.spb.ru>
 <20200810002625.GH12747@mdounin.ru>
 <20200810082257.GV2015@zxy.spb.ru>
 <20200810124058.GJ12747@mdounin.ru>
 <20200810130411.GW2015@zxy.spb.ru>
 <20200810161322.GO12747@mdounin.ru>
 <20200810163322.GY2015@zxy.spb.ru>
 <20200810171649.GP12747@mdounin.ru>
 <20200810173053.GZ2015@zxy.spb.ru>
Message-ID: <20200810180628.GQ12747@mdounin.ru>

Hello!

On Mon, Aug 10, 2020 at 08:30:53PM +0300, Slawa Olhovchenkov wrote:

> On Mon, Aug 10, 2020 at 08:16:49PM +0300, Maxim Dounin wrote:

[...]

> > > > Если не поможет - смотреть debug log'и, там всё должно быть 
> > > > плюс-минус очевидно.
> > > 
> > > это продакшен, с дебаг логами боюсь все станет раком (а так бы я прямо
> > > с них и начал бы).
> > 
> > Just in case, дебаг можно включать не для всех, а только для части 
> > клиентов (http://nginx.org/r/debug_connection), это можно 
> > относительно безопасно делать в том числе и в продакшне.  Следя, 
> > естественно, чтобы не включить слишком много, и чтобы место под 
> > логи не кончалось.
> 
> да кто ж знает что там за клиент(ы).
> я просто заинтересовался чего это у меня MISS много?
> дальше поел смотреть по какому URI из больше всего и почему бы это
> могло быть.

Если клиенты неизвестны - через debug_connection можно включить 
дебаг для какой-то части интернета (85.0.0.0/8, скажем), и 
подождать, пока в логе появится интересующий запрос от клиента из 
этой части.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Tue Aug 11 13:41:27 2020
From: nginx-forum на forum.nginx.org (bagas)
Date: Tue, 11 Aug 2020 09:41:27 -0400
Subject: =?UTF-8?B?0YDQtdC00LjRgNC10LrRgiDQt9Cw0L/RgNC+0YHQsCDQsdC10LcgZ2V0INC/0LA=?=
 =?UTF-8?B?0YDQsNC80LXRgtGA0L7Qsg==?=
Message-ID: <eb4f71839bf4b11f9864c968bdf28565.NginxMailingListRussian@forum.nginx.org>

Добрый день.
Подскажите пожалуйста по структуре редиректа.

При запросе к директориям /files/products и /files/content с
GET-параметром(-ами) и при существовании файла - 301 редирект на основной
url без GET-параметров (нужно удалить все GET-параметры из URL картинок из
указанных папок).

Уточнение если файла не существует, то запрос перенаправляется на php-скрипт
как и сейчас (try_files $uri $uri/ /resize/resize.php?file=$1&token=$args;)
вне зависимости от наличия/отсутствия GET-параметров в запросе. 

Имееются url
https://local.local/files/products/paal.320x504.png?bca30a33g344y444w5577
должен сработать 301й редирект на
https://local.local/files/products/paal.320x504.png

В nginx делаю.
location ~ ^/files/products/(.+) {
try_files $uri $uri/ @bagas;
if ($query_string ~ "^[A-fa-f0-9]{32}$") {
    rewrite ^(.*)$ $uri? permanent;
}
}
location @bagas {
    try_files $uri /resize/resize.php?file=$1&token=$args;
}


GET информация обрезается в url, но если нет файла то не происходит передача
get запроса.
Подскажите как лучше такое сделать?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289056,289056#msg-289056


From mdounin на mdounin.ru  Tue Aug 11 15:12:17 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 11 Aug 2020 18:12:17 +0300
Subject: nginx-1.19.2
Message-ID: <20200811151217.GV12747@mdounin.ru>

Изменения в nginx 1.19.2                                          11.08.2020

    *) Изменение: теперь nginx начинает закрывать keepalive-соединения, не
       дожидаясь исчерпания всех свободных соединений, а также пишет об этом
       предупреждение в лог ошибок.

    *) Изменение: оптимизация чтения тела запроса при использовании chunked
       transfer encoding.

    *) Исправление: утечки памяти при использовании директивы ssl_ocsp.

    *) Исправление: в логах могли появляться сообщения "zero size buf in
       output", если FastCGI-сервер возвращал некорректный ответ; ошибка
       появилась в 1.19.1.

    *) Исправление: в рабочем процессе мог произойти segmentation fault,
       если размеры large_client_header_buffers отличались в разных
       виртуальных серверах.

    *) Исправление: SSL shutdown мог не работать.

    *) Исправление: в логах могли появляться сообщения "SSL_shutdown()
       failed (SSL: ... bad write retry)".

    *) Исправление: в модуле ngx_http_slice_module.

    *) Исправление: в модуле ngx_http_xslt_filter_module.


-- 
Maxim Dounin
http://nginx.org/

From nginx-forum на forum.nginx.org  Wed Aug 12 15:00:20 2020
From: nginx-forum на forum.nginx.org (mageside)
Date: Wed, 12 Aug 2020 11:00:20 -0400
Subject: =?UTF-8?B?0J3QsNGB0YLRgNC+0LnQutCwIHN0b3JlIGZyb250IGFuZCBiZWNrZW5kINC90LAg?=
 =?UTF-8?B?0L7QtNC90L7QvCDQtNC+0LzQtdC90LUu?=
Message-ID: <e7ad30074a51038527dff2adb872504c.NginxMailingListRussian@forum.nginx.org>

Здавствуйте. Помогите настроить нгинк для корректной работы фронта (написан
на реакте) и бекента (маджента).
Фронт обращается на мадженту по определенным урлам (домен/graphql? и тд) что
бы получить данные.
Маджента по определенному урлу используется для админки и для формирования
статики.

https://domen.com/ - открывается реакт
https://domen.com/graphql - реакт ходит по данные на мадженту
https://domen.com/admin - открывается маджентовская админка

upstream fastcgi_backend {
        server  unix:/run/php/php7.2-fpm.sock;
}

server {
        listen 443 ssl http2 default_server;
        listen [::]:443 ssl http2 default_server;

        server_name domen.com;
        set $MAGE_ROOT /home/ubuntu/www/magento;
        set $base /home/ubuntu/www;

        # SSL
        ssl_certificate /etc/letsencrypt/live/domen/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/domen/privkey.pem;
        ssl_trusted_certificate /etc/letsencrypt/live/domen/chain.pem;

        access_log /home/ubuntu/www/magento/var/log/access.log combined;
        error_log /home/ubuntu/www/magento/var/log/error.log error;

        index index.html index.php;

        location / {
                root $base/react;
                try_files $uri $uri/ /index.html;
        }

        location /admin {
                root $MAGE_ROOT/pub;
                try_files /index.php =404;

                location ~ \.php$ {
                        fastcgi_pass fastcgi_backend;
                        fastcgi_index index.php;
                        include fastcgi_params;
               }
       }
}

При таком конфиге сейчас открывается реакт фронт но маджентовская админка не
откывается. Просто скачивается пхп файл.
Я так понимаю нгинкс не отдает пхп файл на фпм для интерпретации. 

Настройкой нгинкса занимаюсь впервые. Буду благодарен за любую помощ.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289074,289074#msg-289074


From red-fox0 на ya.ru  Wed Aug 12 15:24:21 2020
From: red-fox0 на ya.ru (fox)
Date: Wed, 12 Aug 2020 22:24:21 +0700
Subject: =?UTF-8?B?UmU6INGA0LXQtNC40YDQtdC60YIg0LfQsNC/0YDQvtGB0LAg0LHQtdC3IGdldCA=?=
 =?UTF-8?B?0L/QsNGA0LDQvNC10YLRgNC+0LI=?=
In-Reply-To: <eb4f71839bf4b11f9864c968bdf28565.NginxMailingListRussian@forum.nginx.org>
References: <eb4f71839bf4b11f9864c968bdf28565.NginxMailingListRussian@forum.nginx.org>
Message-ID: <95cd461c-dddc-296d-4faf-15d9bf2f29c3@ya.ru>

Можно попробовать так:
location /files/products/ {
    # root or alias
    if (!-f $request_filename) { # файл не существует
        rewrite # /resize/resize.php;
        break;
    }
    if ($request_uri ~ '\?') {
        return 301 $uri;
    }
}

location #.php {
    # …
}

11.08.2020 20:41, bagas пишет:
> Добрый день.
> Подскажите пожалуйста по структуре редиректа.
> 
> При запросе к директориям /files/products и /files/content с
> GET-параметром(-ами) и при существовании файла - 301 редирект на основной
> url без GET-параметров (нужно удалить все GET-параметры из URL картинок из
> указанных папок).
> 
> Уточнение если файла не существует, то запрос перенаправляется на php-скрипт
> как и сейчас (try_files $uri $uri/ /resize/resize.php?file=$1&token=$args;)
> вне зависимости от наличия/отсутствия GET-параметров в запросе. 
> 
> Имееются url
> https://local.local/files/products/paal.320x504.png?bca30a33g344y444w5577
> должен сработать 301й редирект на
> https://local.local/files/products/paal.320x504.png
> 
> В nginx делаю.
> location ~ ^/files/products/(.+) {
> try_files $uri $uri/ @bagas;
> if ($query_string ~ "^[A-fa-f0-9]{32}$") {
>     rewrite ^(.*)$ $uri? permanent;
> }
> }
> location @bagas {
>     try_files $uri /resize/resize.php?file=$1&token=$args;
> }
> 
> 
> GET информация обрезается в url, но если нет файла то не происходит передача
> get запроса.
> Подскажите как лучше такое сделать?
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289056,289056#msg-289056
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 


From red-fox0 на ya.ru  Wed Aug 12 15:40:37 2020
From: red-fox0 на ya.ru (fox)
Date: Wed, 12 Aug 2020 22:40:37 +0700
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDogc3NsIHJlZGlyZWN0?=
In-Reply-To: <CAFHpkQH8==dEm5kKEvYTBZTgFg1yBFGarWVaK+Z7f0d=ufaDqw@mail.gmail.com>
References: <CAB_7BgpnhWGE_7-fqr2_wuXp_WXzky379bt2pRoHhR06PBtKrQ@mail.gmail.com>
 <173c49c968c.e205abbc82032.8333933423162519894@dl.sm.ua>
 <CAFHpkQGCgVxeQdoYEVeUYEeY9ZyztbUcHL7R_=7bS1wpkep2Bw@mail.gmail.com>
 <CAB_7BgoH1AXSDPmSN6OhLAmkVyZcWeHKUSXtVvuUku=r+=Y6vg@mail.gmail.com>
 <CAFHpkQH8==dEm5kKEvYTBZTgFg1yBFGarWVaK+Z7f0d=ufaDqw@mail.gmail.com>
Message-ID: <c4a65ac5-997d-6274-5059-a89ca6365eed@ya.ru>

Сертификат-то от домена monitor.domain есть?

Сдаётся мне, что на втором сервере этот сертификат есть.


07.08.2020 00:57, Илья Шипицин пишет:
> Вероятно, дело в положении сервера. Или фазе луны. Попробуйте повернуть
> сервер на 90%
> 
> On Thu, Aug 6, 2020, 10:30 PM MihaKot <mihakot на gmail.com
> <mailto:mihakot на gmail.com>> wrote:
> 
>     Тогда почему на другом сервере точно такая же конфигурация работает.
> 
>     чт, 6 авг. 2020 г. в 20:17, Илья Шипицин <chipitsine на gmail.com
>     <mailto:chipitsine на gmail.com>>:
> 
>         Сертификат наследуется с уровня выше
> 
>         On Thu, Aug 6, 2020, 9:31 PM Dmytro Lavryk <root на dl.sm.ua
>         <mailto:root на dl.sm.ua>> wrote:
> 
>             __
>             Ну так нет же тут сертификата. Пропишите для monitor.domains
>             в конфиге.
> 
>             ---- Увімкнуто чт, 06 серп. 2020 19:26:51 +0300 *MihaKot
>             <mihakot на gmail.com <mailto:mihakot на gmail.com>>* написав ----
> 
>                 Всем привет.
>                 Почему то не коректно работает редирект
> 
>                 server {
>                 listen 443 ssl;
>                 server_name monitor.domain;
>                 # Redirect all HTTP requests to HTTPS with a 301 Moved
>                 Permanently response.
>                 return 301 https://monitor.other-domain$request_uri;
>                 }
> 
> 
>                 редирект не проходит.
>                 он подставляет сертификат от другого домена, который на
>                 этом хосте крутится.
>                 вследствии чего браузер стопорит редирект.
> 
>                 Причем тоже самое но на другом сервере работает нормально.
> 
> 
>                 -- 
>                 P.S. Сохраняйте переписку в теле письма.
>                 ___________________________________
>                 Best regards, Konstantin @MihaKot@ Aksarin.
>                 Phone: +7 921 74 66 818
>                 Skype: mihakot
>                 E-mail: mihakot на gmail.com <mailto:mihakot на gmail.com>
>                 _______________________________________________
>                 nginx-ru mailing list
>                 nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>                 http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> 
> 
>             _______________________________________________
>             nginx-ru mailing list
>             nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>             http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
>         _______________________________________________
>         nginx-ru mailing list
>         nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>         http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> 
> 
>     -- 
>     P.S. Сохраняйте переписку в теле письма.
>     ___________________________________
>     Best regards, Konstantin @MihaKot@ Aksarin.
>     Phone: +7 921 74 66 818
>     Skype: mihakot
>     E-mail: mihakot на gmail.com <mailto:mihakot на gmail.com>
>     _______________________________________________
>     nginx-ru mailing list
>     nginx-ru на nginx.org <mailto: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
> 


From nginx-forum на forum.nginx.org  Wed Aug 12 16:26:54 2020
From: nginx-forum на forum.nginx.org (bagas)
Date: Wed, 12 Aug 2020 12:26:54 -0400
Subject: =?UTF-8?B?UmU6INGA0LXQtNC40YDQtdC60YIg0LfQsNC/0YDQvtGB0LAg0LHQtdC3IGdldCA=?=
 =?UTF-8?B?0L/QsNGA0LDQvNC10YLRgNC+0LI=?=
In-Reply-To: <95cd461c-dddc-296d-4faf-15d9bf2f29c3@ya.ru>
References: <95cd461c-dddc-296d-4faf-15d9bf2f29c3@ya.ru>
Message-ID: <7ec7ad7398250718021fc8abce6be920.NginxMailingListRussian@forum.nginx.org>

Спасибо за содействие, сделал так.
if переписывал переменную $1 в ресайзе.
Получилось так.

location ~ ^/files/products/(.+) {
        set $file_name_prod $1;
if ($request_uri ~ "[A-fa-f0-9]{32}$") {
        rewrite ^(.*)$ $uri? permanent;
}
        try_files $uri $uri/
/resize/resize.php?file=$file_name_prod&token=$args;
}


fox Wrote:
-------------------------------------------------------
> Можно попробовать так:
> location /files/products/ {
>     # root or alias
>     if (!-f $request_filename) { # файл не существует
>         rewrite # /resize/resize.php;
>         break;
>     }
>     if ($request_uri ~ '\?') {
>         return 301 $uri;
>     }
> }
> 
> location #.php {
>     # …
> }
>

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289056,289079#msg-289079


From chipitsine на gmail.com  Wed Aug 12 17:44:07 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Wed, 12 Aug 2020 22:44:07 +0500
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDogc3NsIHJlZGlyZWN0?=
In-Reply-To: <c4a65ac5-997d-6274-5059-a89ca6365eed@ya.ru>
References: <CAB_7BgpnhWGE_7-fqr2_wuXp_WXzky379bt2pRoHhR06PBtKrQ@mail.gmail.com>
 <173c49c968c.e205abbc82032.8333933423162519894@dl.sm.ua>
 <CAFHpkQGCgVxeQdoYEVeUYEeY9ZyztbUcHL7R_=7bS1wpkep2Bw@mail.gmail.com>
 <CAB_7BgoH1AXSDPmSN6OhLAmkVyZcWeHKUSXtVvuUku=r+=Y6vg@mail.gmail.com>
 <CAFHpkQH8==dEm5kKEvYTBZTgFg1yBFGarWVaK+Z7f0d=ufaDqw@mail.gmail.com>
 <c4a65ac5-997d-6274-5059-a89ca6365eed@ya.ru>
Message-ID: <CAFHpkQGH1w_qbnwDKKS_8aj2vCLF5udz_rwa9g5+ywrju0MP6w@mail.gmail.com>

если сертификат не указать (вообще никакой), то nginx не запустится

ср, 12 авг. 2020 г. в 20:40, fox <red-fox0 на ya.ru>:

> Сертификат-то от домена monitor.domain есть?
>
> Сдаётся мне, что на втором сервере этот сертификат есть.
>
>
> 07.08.2020 00:57, Илья Шипицин пишет:
> > Вероятно, дело в положении сервера. Или фазе луны. Попробуйте повернуть
> > сервер на 90%
> >
> > On Thu, Aug 6, 2020, 10:30 PM MihaKot <mihakot на gmail.com
> > <mailto:mihakot на gmail.com>> wrote:
> >
> >     Тогда почему на другом сервере точно такая же конфигурация работает.
> >
> >     чт, 6 авг. 2020 г. в 20:17, Илья Шипицин <chipitsine на gmail.com
> >     <mailto:chipitsine на gmail.com>>:
> >
> >         Сертификат наследуется с уровня выше
> >
> >         On Thu, Aug 6, 2020, 9:31 PM Dmytro Lavryk <root на dl.sm.ua
> >         <mailto:root на dl.sm.ua>> wrote:
> >
> >             __
> >             Ну так нет же тут сертификата. Пропишите для monitor.domains
> >             в конфиге.
> >
> >             ---- Увімкнуто чт, 06 серп. 2020 19:26:51 +0300 *MihaKot
> >             <mihakot на gmail.com <mailto:mihakot на gmail.com>>* написав ----
> >
> >                 Всем привет.
> >                 Почему то не коректно работает редирект
> >
> >                 server {
> >                 listen 443 ssl;
> >                 server_name monitor.domain;
> >                 # Redirect all HTTP requests to HTTPS with a 301 Moved
> >                 Permanently response.
> >                 return 301 https://monitor.other-domain$request_uri;
> >                 }
> >
> >
> >                 редирект не проходит.
> >                 он подставляет сертификат от другого домена, который на
> >                 этом хосте крутится.
> >                 вследствии чего браузер стопорит редирект.
> >
> >                 Причем тоже самое но на другом сервере работает
> нормально.
> >
> >
> >                 --
> >                 P.S. Сохраняйте переписку в теле письма.
> >                 ___________________________________
> >                 Best regards, Konstantin @MihaKot@ Aksarin.
> >                 Phone: +7 921 74 66 818
> >                 Skype: mihakot
> >                 E-mail: mihakot на gmail.com <mailto:mihakot на gmail.com>
> >                 _______________________________________________
> >                 nginx-ru mailing list
> >                 nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> >                 http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >
> >
> >             _______________________________________________
> >             nginx-ru mailing list
> >             nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> >             http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >         _______________________________________________
> >         nginx-ru mailing list
> >         nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> >         http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> >
> >
> >     --
> >     P.S. Сохраняйте переписку в теле письма.
> >     ___________________________________
> >     Best regards, Konstantin @MihaKot@ Aksarin.
> >     Phone: +7 921 74 66 818
> >     Skype: mihakot
> >     E-mail: mihakot на gmail.com <mailto:mihakot на gmail.com>
> >     _______________________________________________
> >     nginx-ru mailing list
> >     nginx-ru на nginx.org <mailto: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
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200812/f76b9ea4/attachment-0001.htm>

From mdounin на mdounin.ru  Thu Aug 13 13:19:08 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 13 Aug 2020 16:19:08 +0300
Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC50LrQsCBzdG9yZSBmcm9udCBhbmQgYmVja2VuZCA=?=
 =?UTF-8?B?0L3QsCDQvtC00L3QvtC8INC00L7QvNC10L3QtS4=?=
In-Reply-To: <e7ad30074a51038527dff2adb872504c.NginxMailingListRussian@forum.nginx.org>
References: <e7ad30074a51038527dff2adb872504c.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20200813131908.GA12747@mdounin.ru>

Hello!

On Wed, Aug 12, 2020 at 11:00:20AM -0400, mageside wrote:

> Здавствуйте. Помогите настроить нгинк для корректной работы фронта (написан
> на реакте) и бекента (маджента).
> Фронт обращается на мадженту по определенным урлам (домен/graphql? и тд) что
> бы получить данные.
> Маджента по определенному урлу используется для админки и для формирования
> статики.
> 
> https://domen.com/ - открывается реакт
> https://domen.com/graphql - реакт ходит по данные на мадженту
> https://domen.com/admin - открывается маджентовская админка
> 
> upstream fastcgi_backend {
>         server  unix:/run/php/php7.2-fpm.sock;
> }
> 
> server {
>         listen 443 ssl http2 default_server;
>         listen [::]:443 ssl http2 default_server;
> 
>         server_name domen.com;
>         set $MAGE_ROOT /home/ubuntu/www/magento;
>         set $base /home/ubuntu/www;
> 
>         # SSL
>         ssl_certificate /etc/letsencrypt/live/domen/fullchain.pem;
>         ssl_certificate_key /etc/letsencrypt/live/domen/privkey.pem;
>         ssl_trusted_certificate /etc/letsencrypt/live/domen/chain.pem;
> 
>         access_log /home/ubuntu/www/magento/var/log/access.log combined;
>         error_log /home/ubuntu/www/magento/var/log/error.log error;
> 
>         index index.html index.php;
> 
>         location / {
>                 root $base/react;
>                 try_files $uri $uri/ /index.html;
>         }
> 
>         location /admin {
>                 root $MAGE_ROOT/pub;
>                 try_files /index.php =404;
> 
>                 location ~ \.php$ {
>                         fastcgi_pass fastcgi_backend;
>                         fastcgi_index index.php;
>                         include fastcgi_params;
>                }
>        }
> }
> 
> При таком конфиге сейчас открывается реакт фронт но маджентовская админка не
> откывается. Просто скачивается пхп файл.
> Я так понимаю нгинкс не отдает пхп файл на фпм для интерпретации. 
> 
> Настройкой нгинкса занимаюсь впервые. Буду благодарен за любую помощ.

У вас в конфиге в "location /admin" сказано, что, если запрошенный 
файл не *.php, то нужно отдавать статический файл 
$base/pub/index.php, если он есть, иначе возвращать 404:

>                 root $MAGE_ROOT/pub;
>                 try_files /index.php =404;

Скорее всего это не то, что имелось в виду, и директиву try_files 
нужно просто убрать.

-- 
Maxim Dounin
http://mdounin.ru/

From gmm на csdoc.com  Fri Aug 14 11:37:05 2020
From: gmm на csdoc.com (Gena Makhomed)
Date: Fri, 14 Aug 2020 14:37:05 +0300
Subject: =?UTF-8?B?0L3QvtGA0LzQsNC70LjQt9Cw0YbQuNGPIHVyaQ==?=
Message-ID: <11340993-9a92-7a56-52d0-1bed4db7b109@csdoc.com>

Здравствуйте, All!

Есть такая конфигурация:

client <=> nginx-frontend <=> nginx-backend <=> php-fpm

Есть задача от SEO'шников/клиентов сделать так, чтобы несколько слешей,
идущих подряд в uri, превращались в один слеш с помощью 301 редиректа,
и чтобы точка в конце домена также убиралась с помощью 301 редиректа.

Сейчас эту задачу можно решить только на стороне nginx-frontend
с помощью такого программирования на конфигах nginx для каждого
виртуального сервера:

     # remove multiple sequences of forward slashes
     # The $uri variable with have duplicate slashes removed by default 
via [merge_slashes on] - just need to rewrite back to $uri
     # note: use of the "^[^?]*?" pattern avoids any matches in the 
querystring section of URI - which would cause an infinite redirect loop
     if ($request_uri ~ "^[^?]*?//") {
         rewrite "^" $scheme://$host$uri permanent;
     }

     if ($http_host ~ "\.$") {
         rewrite "^" $scheme://$host$uri permanent;
     }

Хотелось бы избежать программирования на конфигах nginx-frontend
и перенести всю логику нормализации урлов на сторону php-fpm,
если это вообще теоретически возможно без дополнительного 
программирования и дополнительного оверхеда на стороне nginx-frontend,
или обойтись всего одной директивой в конфиге на уровне http {},
например, merge_slashes redirect; или normalize_uri on;

На одном физическом сервере несколько сотен виртуальных хостов,
программирование на конфигах nginx делает конфиги трудночитаемыми,
и есть стойкое ощущение, что это не самый оптимальный solution.

Насколько высока вероятность того, что патч, реализующий
дополнительную функциональность merge_slashes redirect;
или normalize_uri on; будет принят в основную ветку nginx?

Какой есть самый правильный и самый оптимальный с точки зрения
экономии человеческих и машинных ресурсов способ решения этой задачи?

-- 
Best regards,
  Gena


From mdounin на mdounin.ru  Fri Aug 14 14:27:29 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 14 Aug 2020 17:27:29 +0300
Subject: =?UTF-8?B?UmU6INC90L7RgNC80LDQu9C40LfQsNGG0LjRjyB1cmk=?=
In-Reply-To: <11340993-9a92-7a56-52d0-1bed4db7b109@csdoc.com>
References: <11340993-9a92-7a56-52d0-1bed4db7b109@csdoc.com>
Message-ID: <20200814142729.GI12747@mdounin.ru>

Hello!

On Fri, Aug 14, 2020 at 02:37:05PM +0300, Gena Makhomed wrote:

> Есть такая конфигурация:
> 
> client <=> nginx-frontend <=> nginx-backend <=> php-fpm
> 
> Есть задача от SEO'шников/клиентов сделать так, чтобы несколько слешей,
> идущих подряд в uri, превращались в один слеш с помощью 301 редиректа,
> и чтобы точка в конце домена также убиралась с помощью 301 редиректа.
> 
> Сейчас эту задачу можно решить только на стороне nginx-frontend

Никто не запрещает решать эту задачу на любых других уровнях, в 
том числе в php.  Другой вопрос, что если менять URI на строне 
nginx'а (например, проксируя с заменой части URI) - исходный URI 
придётся явно пробрасывать и отдельно обрабатывать.

> с помощью такого программирования на конфигах nginx для каждого
> виртуального сервера:
> 
>     # remove multiple sequences of forward slashes
>     # The $uri variable with have duplicate slashes removed by default via [merge_slashes on] - just need to rewrite back to $uri
>     # note: use of the "^[^?]*?" pattern avoids any matches in the querystring section of URI - which would cause an infinite redirect loop
>     if ($request_uri ~ "^[^?]*?//") {
>         rewrite "^" $scheme://$host$uri permanent;
>     }
> 
>     if ($http_host ~ "\.$") {
>         rewrite "^" $scheme://$host$uri permanent;
>     }

Отмечу, что тут "напрограммировано на конфигах" два XSS'а.
Эту и другие подобные проблемы умеет, AFAIK, ловить 
https://github.com/yandex/gixy.

> Хотелось бы избежать программирования на конфигах nginx-frontend
> и перенести всю логику нормализации урлов на сторону php-fpm,
> если это вообще теоретически возможно без дополнительного программирования и дополнительного оверхеда на стороне nginx-frontend,

См. выше, это выглядит как легко решаемая задача.

> или обойтись всего одной директивой в конфиге на уровне http {},
> например, merge_slashes redirect; или normalize_uri on;
> 
> На одном физическом сервере несколько сотен виртуальных хостов,
> программирование на конфигах nginx делает конфиги трудночитаемыми,
> и есть стойкое ощущение, что это не самый оптимальный solution.
> 
> Насколько высока вероятность того, что патч, реализующий
> дополнительную функциональность merge_slashes redirect;
> или normalize_uri on; будет принят в основную ветку nginx?

Задача не кажется типичной.  Если очень хочется решать её силами 
nginx'а - я бы рекомендовал начать с инкапсуляции нужных 
перенаправленый в отдельных include-файлах, и/или решений на 
скриптовых языках, или же отдельного модуля для нормализации.

-- 
Maxim Dounin
http://mdounin.ru/

From nginx-forum на forum.nginx.org  Fri Aug 14 16:38:45 2020
From: nginx-forum на forum.nginx.org (mageside)
Date: Fri, 14 Aug 2020 12:38:45 -0400
Subject: =?UTF-8?B?UmU6INCd0LDRgdGC0YDQvtC50LrQsCBzdG9yZSBmcm9udCBhbmQgYmVja2VuZCA=?=
 =?UTF-8?B?0L3QsCDQvtC00L3QvtC8INC00L7QvNC10L3QtS4=?=
In-Reply-To: <20200813131908.GA12747@mdounin.ru>
References: <20200813131908.GA12747@mdounin.ru>
Message-ID: <3f764abfa21a712c8676a4b065145e10.NginxMailingListRussian@forum.nginx.org>

Вопрос решон спасибо.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289074,289113#msg-289113


From nginx-forum на forum.nginx.org  Mon Aug 17 07:07:22 2020
From: nginx-forum на forum.nginx.org (akoval)
Date: Mon, 17 Aug 2020 03:07:22 -0400
Subject: server location from http to https on same server
Message-ID: <19fcd6f534610c19385c297880bbd93a.NginxMailingListRussian@forum.nginx.org>

Всем привет!

Есть конфиг:

server {
        listen 80;
        server_name domen.com;

        location /ua/articles/article1/ { return 301
https://domen.com/blog-item/article1/; }
        location /ua/articles/article2/ { return 301
https://domen.com/blog-item/article3/; }
        ...

        location / { return 301 https://domen.com; }
}

server {
        listen 80;
        server_name www.domen.com;
        return 301 https://domen.com;
}

server {
        listen 443 ssl;
        server_name www.domen.com;
        ssl_certificate ...;
        ssl_certificate_...;
        return 301 https://domen.com;
}

server {
        listen 443 ssl;
        server_name domen.com;
        root /.../public;
        ssl_certificate ...;
        ssl_certificate_key ...;
        ...
}

Проблема в:
location /ua/articles/article1/ { return 301
https://domen.com/blog-item/article1/; }
путь в location не определяеться, редирект не происходит, а пытаеться зайти
на https://domen.com/ua/articles/article1...
перепробовал уже регулярки в location =, ~*, ... не работает.
куда смотреть?

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289118,289118#msg-289118


From gmm на csdoc.com  Mon Aug 17 07:54:43 2020
From: gmm на csdoc.com (Gena Makhomed)
Date: Mon, 17 Aug 2020 10:54:43 +0300
Subject: =?UTF-8?B?UmU6INC90L7RgNC80LDQu9C40LfQsNGG0LjRjyB1cmk=?=
In-Reply-To: <20200814142729.GI12747@mdounin.ru>
References: <11340993-9a92-7a56-52d0-1bed4db7b109@csdoc.com>
 <20200814142729.GI12747@mdounin.ru>
Message-ID: <5f041d55-e0ea-0c09-0879-d7dcf20724bd@csdoc.com>

On 14.08.2020 17:27, Maxim Dounin wrote:

>> Есть такая конфигурация:
>>
>> client <=> nginx-frontend <=> nginx-backend <=> php-fpm
>>
>> Есть задача от SEO'шников/клиентов сделать так, чтобы несколько слешей,
>> идущих подряд в uri, превращались в один слеш с помощью 301 редиректа,
>> и чтобы точка в конце домена также убиралась с помощью 301 редиректа.
>>
>> Сейчас эту задачу можно решить только на стороне nginx-frontend
> 
> Никто не запрещает решать эту задачу на любых других уровнях, в
> том числе в php.  Другой вопрос, что если менять URI на строне
> nginx'а (например, проксируя с заменой части URI) - исходный URI
> придётся явно пробрасывать и отдельно обрабатывать.

Проксирование без замены части URI можно сделать так:
location / { proxy_pass http://172.16.1.124$request_uri; }
А как сделать проксирование с заменой части URI ?

Например, поменяв /path1/ на /path2/ при проксировании:
location /path1/ { proxy_pass http://172.16.1.124/path2/; }
не выключая при этом merge_slashes on; в конфиге nginx ?

Кроме того, задача убрать точку в конце домена example.com.
выглядит нерешаемой на уровне php, потому что на nginx-backend
запрос приходит уже без точки в конце доменного имени.

>> с помощью такого программирования на конфигах nginx для каждого
>> виртуального сервера:
>>
>>      # remove multiple sequences of forward slashes
>>      # The $uri variable with have duplicate slashes removed by default via [merge_slashes on] - just need to rewrite back to $uri
>>      # note: use of the "^[^?]*?" pattern avoids any matches in the querystring section of URI - which would cause an infinite redirect loop
>>      if ($request_uri ~ "^[^?]*?//") {
>>          rewrite "^" $scheme://$host$uri permanent;
>>      }
>>
>>      if ($http_host ~ "\.$") {
>>          rewrite "^" $scheme://$host$uri permanent;
>>      }
> 
> Отмечу, что тут "напрограммировано на конфигах" два XSS'а.
> Эту и другие подобные проблемы умеет, AFAIK, ловить
> https://github.com/yandex/gixy.

gixy говорит про Possible HTTP-Splitting vulnerability.
Using variables that can contain "\n" or "\r" may lead to http injection.
https://github.com/yandex/gixy/blob/master/docs/en/plugins/httpsplitting.md
Reason: At least variable "$uri" can contain "\n"

Где здесь XSS ?

И почему nginx не может закодировать "\n" or "\r" перед тем,
как применять $uri для построения проксированого запроса?
Это выглядит как не закрытая security vulnerability в nginx.

>> Насколько высока вероятность того, что патч, реализующий
>> дополнительную функциональность merge_slashes redirect;
>> или normalize_uri on; будет принят в основную ветку nginx?

> Задача не кажется типичной. Если очень хочется решать её силами
> nginx'а - я бы рекомендовал начать с инкапсуляции нужных
> перенаправленый в отдельных include-файлах, и/или решений на
> скриптовых языках, или же отдельного модуля для нормализации.

Что написать в include-файлах вместо

     if ($request_uri ~ "^[^?]*?//") {
         rewrite "^" $scheme://$host$uri permanent;
     }

     if ($http_host ~ "\.$") {
         rewrite "^" $scheme://$host$uri permanent;
     }

чтобы не было XSS ?

-- 
Best regards,
  Gena


From mdounin на mdounin.ru  Mon Aug 17 14:58:45 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 17 Aug 2020 17:58:45 +0300
Subject: =?UTF-8?B?UmU6INC90L7RgNC80LDQu9C40LfQsNGG0LjRjyB1cmk=?=
In-Reply-To: <5f041d55-e0ea-0c09-0879-d7dcf20724bd@csdoc.com>
References: <11340993-9a92-7a56-52d0-1bed4db7b109@csdoc.com>
 <20200814142729.GI12747@mdounin.ru>
 <5f041d55-e0ea-0c09-0879-d7dcf20724bd@csdoc.com>
Message-ID: <20200817145845.GL12747@mdounin.ru>

Hello!

On Mon, Aug 17, 2020 at 10:54:43AM +0300, Gena Makhomed wrote:

> On 14.08.2020 17:27, Maxim Dounin wrote:
> 
> > > Есть такая конфигурация:
> > > 
> > > client <=> nginx-frontend <=> nginx-backend <=> php-fpm
> > > 
> > > Есть задача от SEO'шников/клиентов сделать так, чтобы несколько слешей,
> > > идущих подряд в uri, превращались в один слеш с помощью 301 редиректа,
> > > и чтобы точка в конце домена также убиралась с помощью 301 редиректа.
> > > 
> > > Сейчас эту задачу можно решить только на стороне nginx-frontend
> > 
> > Никто не запрещает решать эту задачу на любых других уровнях, в
> > том числе в php.  Другой вопрос, что если менять URI на строне
> > nginx'а (например, проксируя с заменой части URI) - исходный URI
> > придётся явно пробрасывать и отдельно обрабатывать.
> 
> Проксирование без замены части URI можно сделать так:
> location / { proxy_pass http://172.16.1.124$request_uri; }
> А как сделать проксирование с заменой части URI ?

Проксирование без заменыы части URI можно и нужно делать так:

location / { proxy_pass http://172.16.1.124; }

Подробнее об этом рассказано в описании директивы proxy_pass 
(http://nginx.org/r/proxy_pass/ru), со слов "URI запроса 
передаётся на сервер так: ..." и далее.

> Например, поменяв /path1/ на /path2/ при проксировании:
> location /path1/ { proxy_pass http://172.16.1.124/path2/; }
> не выключая при этом merge_slashes on; в конфиге nginx ?

Если хочется менять путь - исходный $request_uri можно пробросить 
на бэкенд явно, в виде отдельного заголовка.  E.g.,

    proxy_set_header X-Original-URI $request_uri;

и его обрабатывать на бэкенде.

> Кроме того, задача убрать точку в конце домена example.com.
> выглядит нерешаемой на уровне php, потому что на nginx-backend
> запрос приходит уже без точки в конце доменного имени.

Поведение по умолчанию при проксировании предполагает, что на 
бэкенд приходит имя, написанное в директиве proxy_pass.  Никто не 
мешает отправить на бэкенд ровно то, что пришло от клиента в 
заголовке Host - либо собственно в заголовке Host запроса на 
бэкенд (при этом, впрочем, отвалится обработка authority в строке 
запроса), либо опяь же в виде отдельного заголовка.

> > > с помощью такого программирования на конфигах nginx для каждого
> > > виртуального сервера:
> > > 
> > >      # remove multiple sequences of forward slashes
> > >      # The $uri variable with have duplicate slashes removed by default via [merge_slashes on] - just need to rewrite back to $uri
> > >      # note: use of the "^[^?]*?" pattern avoids any matches in the querystring section of URI - which would cause an infinite redirect loop
> > >      if ($request_uri ~ "^[^?]*?//") {
> > >          rewrite "^" $scheme://$host$uri permanent;
> > >      }
> > > 
> > >      if ($http_host ~ "\.$") {
> > >          rewrite "^" $scheme://$host$uri permanent;
> > >      }
> > 
> > Отмечу, что тут "напрограммировано на конфигах" два XSS'а.
> > Эту и другие подобные проблемы умеет, AFAIK, ловить
> > https://github.com/yandex/gixy.
> 
> gixy говорит про Possible HTTP-Splitting vulnerability.
> Using variables that can contain "\n" or "\r" may lead to http injection.
> https://github.com/yandex/gixy/blob/master/docs/en/plugins/httpsplitting.md
> Reason: At least variable "$uri" can contain "\n"
> 
> Где здесь XSS ?

HTTP response splitting предоставляет атакующему контроль над 
ответом, и XSS - одно из прямых и наиболее очевидных следствий.

> И почему nginx не может закодировать "\n" or "\r" перед тем,
> как применять $uri для построения проксированого запроса?
> Это выглядит как не закрытая security vulnerability в nginx.

Ничего не мешает, равно как и, скажем, заменить в отправляемом 
перенаправлении A на B.  Тут и в остальных подобныых директивах 
(return, add_header, proxy_set_header, proxy_pass) nginx ожидает 
корректно закодированне значения.

В случае директивы rewrite дополнительно гарантируется, что 
переменные $1..$9, полученные из раскодированного URI запроса с 
помощью регулярного выражения в первом параметре, будут 
рассматриваться как раскодированные.

> > > Насколько высока вероятность того, что патч, реализующий
> > > дополнительную функциональность merge_slashes redirect;
> > > или normalize_uri on; будет принят в основную ветку nginx?
> 
> > Задача не кажется типичной. Если очень хочется решать её силами
> > nginx'а - я бы рекомендовал начать с инкапсуляции нужных
> > перенаправленый в отдельных include-файлах, и/или решений на
> > скриптовых языках, или же отдельного модуля для нормализации.
> 
> Что написать в include-файлах вместо
> 
>     if ($request_uri ~ "^[^?]*?//") {
>         rewrite "^" $scheme://$host$uri permanent;
>     }
> 
>     if ($http_host ~ "\.$") {
>         rewrite "^" $scheme://$host$uri permanent;
>     }
> 
> чтобы не было XSS ?

rewrite ^(.*) $scheme://$host$1 permanent;

-- 
Maxim Dounin
http://mdounin.ru/

From gmm на csdoc.com  Tue Aug 18 08:16:43 2020
From: gmm на csdoc.com (Gena Makhomed)
Date: Tue, 18 Aug 2020 11:16:43 +0300
Subject: =?UTF-8?B?UmU6INC90L7RgNC80LDQu9C40LfQsNGG0LjRjyB1cmk=?=
In-Reply-To: <20200817145845.GL12747@mdounin.ru>
References: <11340993-9a92-7a56-52d0-1bed4db7b109@csdoc.com>
 <20200814142729.GI12747@mdounin.ru>
 <5f041d55-e0ea-0c09-0879-d7dcf20724bd@csdoc.com>
 <20200817145845.GL12747@mdounin.ru>
Message-ID: <52fd259e-f0bb-3cc7-97de-a0e4b0aa2f4c@csdoc.com>

On 17.08.2020 17:58, Maxim Dounin wrote:

> HTTP response splitting предоставляет атакующему контроль над
> ответом, и XSS - одно из прямых и наиболее очевидных следствий.

>> И почему nginx не может закодировать "\n" or "\r" перед тем,
>> как применять $uri для построения проксированого запроса?
>> Это выглядит как не закрытая security vulnerability в nginx.

> Ничего не мешает, равно как и, скажем, заменить в отправляемом
> перенаправлении A на B.  Тут и в остальных подобныых директивах
> (return, add_header, proxy_set_header, proxy_pass) nginx ожидает
> корректно закодированне значения.

Если эти ожидания не оправдались - nginx ведь может понять,
что ему не предоставили корректно закодированные значения.

И в таком случае - он может ведь вернуть 500 ошибку вместо
того, чтобы предоставлять атакующему возможность сделать XSS.

Например, проведите голосование среди пользователей nginx+,
какую реакцию nginx+ они предпочитают - 500 ошибку или XSS?
Я почти уверен, что никто не захочет, чтобы у них была XSS.

Просканировать строку на предмет наличия в ней символов
"\n" или "\r" окажет влияне на производительность
на уровне статистической погрешности, около нуля.

Почему нет? Ведь тогда nginx станет неуязвим к атаке
вида HTTP response splitting - разве это того не стоит?

Наверное нет смысла делать в nginx отдельную директиву
HTTP_response_splitting_security_vulnerability on/off;

> В случае директивы rewrite дополнительно гарантируется, что
> переменные $1..$9, полученные из раскодированного URI запроса с
> помощью регулярного выражения в первом параметре, будут
> рассматриваться как раскодированные.

Может быть имеет смысл для каждой переменной в nginx добавить
поле статуса, показывающее, является ли эта переменная
корректно закодированной или корректно раскодированной?

Тогда nginx смог бы сам на лету превращать раскодированные
переменные в закодированные, например, при использовании их
в тех директивах, где необходимо корректно закодированное
значение переменной.

>>>> Насколько высока вероятность того, что патч, реализующий
>>>> дополнительную функциональность merge_slashes redirect;
>>>> или normalize_uri on; будет принят в основную ветку nginx?
>>
>>> Задача не кажется типичной. Если очень хочется решать её силами
>>> nginx'а - я бы рекомендовал начать с инкапсуляции нужных
>>> перенаправленый в отдельных include-файлах, и/или решений на
>>> скриптовых языках, или же отдельного модуля для нормализации.
>>
>> Что написать в include-файлах вместо
>>
>>      if ($request_uri ~ "^[^?]*?//") {
>>          rewrite "^" $scheme://$host$uri permanent;
>>      }
>>
>>      if ($http_host ~ "\.$") {
>>          rewrite "^" $scheme://$host$uri permanent;
>>      }
>>
>> чтобы не было XSS ?
> 
> rewrite ^(.*) $scheme://$host$1 permanent;

Спасибо. Получился такой конфиг:

if ($request_uri ~ "^[^?]*?//") { rewrite ^(.*) $scheme://$host$1 
permanent; }
if ($http_host ~ "\.$") { rewrite ^(.*) $scheme://$host$1 permanent; }

Похоже, что это максимум из того, что можно выжать из nginx
в его современном виде и эту ситуацию уже никак улучшить нельзя?

Например, путем создания в nginx директивы normalize_uri со значением
по умолчанию on. Тогда все работало бы так как надо прямо из коробки.

Задача является более, чем типичной, вот например, такая проблема:
http://mailman.nginx.org/pipermail/nginx-ru/2014-April/053860.html
Здесь бы тоже normalize_uri on; было бы решением проблемы.

Случаев, когда normalize_uri on; будет создавать проблемы
при включенном merge_slashes on; не обнаружено ни одного.

-- 
Best regards,
  Gena


From chipitsine на gmail.com  Tue Aug 18 08:44:23 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Tue, 18 Aug 2020 13:44:23 +0500
Subject: =?UTF-8?B?UmU6INC90L7RgNC80LDQu9C40LfQsNGG0LjRjyB1cmk=?=
In-Reply-To: <52fd259e-f0bb-3cc7-97de-a0e4b0aa2f4c@csdoc.com>
References: <11340993-9a92-7a56-52d0-1bed4db7b109@csdoc.com>
 <20200814142729.GI12747@mdounin.ru>
 <5f041d55-e0ea-0c09-0879-d7dcf20724bd@csdoc.com>
 <20200817145845.GL12747@mdounin.ru>
 <52fd259e-f0bb-3cc7-97de-a0e4b0aa2f4c@csdoc.com>
Message-ID: <CAFHpkQHSD4+gPft0O1F+icXo-ApBKHt2xpse-q7kjBYPQz95fg@mail.gmail.com>

вт, 18 авг. 2020 г. в 13:16, Gena Makhomed <gmm на csdoc.com>:

> On 17.08.2020 17:58, Maxim Dounin wrote:
>
> > HTTP response splitting предоставляет атакующему контроль над
> > ответом, и XSS - одно из прямых и наиболее очевидных следствий.
>
> >> И почему nginx не может закодировать "\n" or "\r" перед тем,
> >> как применять $uri для построения проксированого запроса?
> >> Это выглядит как не закрытая security vulnerability в nginx.
>
> > Ничего не мешает, равно как и, скажем, заменить в отправляемом
> > перенаправлении A на B.  Тут и в остальных подобныых директивах
> > (return, add_header, proxy_set_header, proxy_pass) nginx ожидает
> > корректно закодированне значения.
>
> Если эти ожидания не оправдались - nginx ведь может понять,
> что ему не предоставили корректно закодированные значения.
>
> И в таком случае - он может ведь вернуть 500 ошибку вместо
> того, чтобы предоставлять атакующему возможность сделать XSS.
>
> Например, проведите голосование среди пользователей nginx+,
> какую реакцию nginx+ они предпочитают - 500 ошибку или XSS?
> Я почти уверен, что никто не захочет, чтобы у них была XSS.
>

XSS предполагает, что атака идет на браузер. если (а это вполне легитимный
кейс)
клиент не браузер, то у него другая семантика и логика. и вы можете ему
что-то сломать.

nginx как реверс прокси ничего не знает про семантику приложения. но про
нее знают
на бекенде. кажется, что данные штуки логично тащить на бекенд

но вы правы, есть WAF-ы, naxsi, например. если оператор реверс прокси
принимает решение, он, конечно, может себе втащить WAF-чик


>
> Просканировать строку на предмет наличия в ней символов
> "\n" или "\r" окажет влияне на производительность
> на уровне статистической погрешности, около нуля.
>
> Почему нет? Ведь тогда nginx станет неуязвим к атаке
> вида HTTP response splitting - разве это того не стоит?
>
> Наверное нет смысла делать в nginx отдельную директиву
> HTTP_response_splitting_security_vulnerability on/off;
>

поменять поведение по умолчанию и сломать кому-то сценарии, так себе
удовольствие



>
> > В случае директивы rewrite дополнительно гарантируется, что
> > переменные $1..$9, полученные из раскодированного URI запроса с
> > помощью регулярного выражения в первом параметре, будут
> > рассматриваться как раскодированные.
>
> Может быть имеет смысл для каждой переменной в nginx добавить
> поле статуса, показывающее, является ли эта переменная
> корректно закодированной или корректно раскодированной?
>
> Тогда nginx смог бы сам на лету превращать раскодированные
> переменные в закодированные, например, при использовании их
> в тех директивах, где необходимо корректно закодированное
> значение переменной.
>
> >>>> Насколько высока вероятность того, что патч, реализующий
> >>>> дополнительную функциональность merge_slashes redirect;
> >>>> или normalize_uri on; будет принят в основную ветку nginx?
> >>
> >>> Задача не кажется типичной. Если очень хочется решать её силами
> >>> nginx'а - я бы рекомендовал начать с инкапсуляции нужных
> >>> перенаправленый в отдельных include-файлах, и/или решений на
> >>> скриптовых языках, или же отдельного модуля для нормализации.
> >>
> >> Что написать в include-файлах вместо
> >>
> >>      if ($request_uri ~ "^[^?]*?//") {
> >>          rewrite "^" $scheme://$host$uri permanent;
> >>      }
> >>
> >>      if ($http_host ~ "\.$") {
> >>          rewrite "^" $scheme://$host$uri permanent;
> >>      }
> >>
> >> чтобы не было XSS ?
> >
> > rewrite ^(.*) $scheme://$host$1 permanent;
>
> Спасибо. Получился такой конфиг:
>
> if ($request_uri ~ "^[^?]*?//") { rewrite ^(.*) $scheme://$host$1
> permanent; }
> if ($http_host ~ "\.$") { rewrite ^(.*) $scheme://$host$1 permanent; }
>
> Похоже, что это максимум из того, что можно выжать из nginx
> в его современном виде и эту ситуацию уже никак улучшить нельзя?
>
> Например, путем создания в nginx директивы normalize_uri со значением
> по умолчанию on. Тогда все работало бы так как надо прямо из коробки.
>
> Задача является более, чем типичной, вот например, такая проблема:
> http://mailman.nginx.org/pipermail/nginx-ru/2014-April/053860.html
> Здесь бы тоже normalize_uri on; было бы решением проблемы.
>
> Случаев, когда normalize_uri on; будет создавать проблемы
> при включенном merge_slashes on; не обнаружено ни одного.
>
> --
> Best regards,
>   Gena
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200818/e935f970/attachment-0001.htm>

From nginx-forum на forum.nginx.org  Sun Aug 23 21:11:28 2020
From: nginx-forum на forum.nginx.org (edo1)
Date: Sun, 23 Aug 2020 17:11:28 -0400
Subject: =?UTF-8?B?UmU6INCf0YDQvtC60YHQuNGA0L7QstCw0L3QuNC1INGBINC60Y3RiNC10Lwg0Lg=?=
 =?UTF-8?B?0LcgQ0RO?=
In-Reply-To: <16e4571f10372befd5111cebd9f99252.NginxMailingListRussian@forum.nginx.org>
References: <CAFHpkQFmMmzMQ4HJ_kt9L6fTumgZRALO+wPtERVfZQaXBtCOGw@mail.gmail.com>
 <09eba37bcb65b02a0b37922926550489.NginxMailingListRussian@forum.nginx.org>
 <16e4571f10372befd5111cebd9f99252.NginxMailingListRussian@forum.nginx.org>
Message-ID: <0a654b5e0b551c376df1966df0e0798e.NginxMailingListRussian@forum.nginx.org>

у нжинкса с proxy_cache_lock  (и достаточно высокими
proxy_cache_lock_timeout/proxy_cache_lock_age) тоже пойдёт только один поток
на апстрим, но, пока файл не ляжет полностью в кэш, получать будет только
первый клиент

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,288966,289168#msg-289168


From nginx-forum на forum.nginx.org  Wed Aug 26 09:35:30 2020
From: nginx-forum на forum.nginx.org (jay15)
Date: Wed, 26 Aug 2020 05:35:30 -0400
Subject: Redirect nginx
Message-ID: <37ac7b658102034b774ed383f9c0dbb0.NginxMailingListRussian@forum.nginx.org>

Всем привет. В nginx не силен, но нужно сделать исключение из редиректа.

Есть сайт, там настроено http перенаправлять на https. Вот кусок конфига:
server {
    listen 80;
    server_name site.com www.site.com;

    location /.well-known/acme-challenge/ { alias
/var/lib/dehydrated/acme-challenges/; }
    location / {
        rewrite        ^ https://site.com$request_uri? permanent;
    }
}

server {
    listen 443;
    server_name www.site.com;

    ssl on;
          ssl_certificate /etc/letsencrypt/live/site.com/fullchain.pem;
          ssl_certificate_key /etc/letsencrypt/live/site.com/privkey.pem;

    location / {
        rewrite        ^ https://site.com$request_uri? permanent;
    }
}

Нужно вот такой адрес убрать из редиректа, чтобы он работал по http и https
отдельно - http://site.com/my_api/set/ – my_api/set - это не дирректория на
веб сервере. По сути мне кажется /my_api/set/ это не location. Это просто
POST запрос в таком виде http(s)://site.com/my_api/set, который
обрабатывается index.php. На сайте есть Kohana Controller_Locations_Api
который интерпретируется как /my_api/set. Там настроена Кохановская система
роутинга, которая считывает URL реквеста и распределяет на нужный
контроллер.
Глобально нужно, чтобы код был сразу 200, а сечас HTTP/1.1 301 Moved
Permanently и потом HTTP/1.1 200 OK.

Пробовал вот так, но это не работает:

server {
    listen 80;
    server_name site.com www.site.com;

    location /.well-known/acme-challenge/ { alias
/var/lib/dehydrated/acme-challenges/; }
    location / {
        if ($request_uri !~ /my_api/set) {
        rewrite        ^ https://site.com$request_uri? permanent;
        }
    }
}


Подскажите плииз как быть.

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289197,289197#msg-289197


From nginx-forum на forum.nginx.org  Wed Aug 26 09:41:05 2020
From: nginx-forum на forum.nginx.org (jay15)
Date: Wed, 26 Aug 2020 05:41:05 -0400
Subject: Redirect nginx
In-Reply-To: <37ac7b658102034b774ed383f9c0dbb0.NginxMailingListRussian@forum.nginx.org>
References: <37ac7b658102034b774ed383f9c0dbb0.NginxMailingListRussian@forum.nginx.org>
Message-ID: <370b4a158cf3c182ec145874b15b13c7.NginxMailingListRussian@forum.nginx.org>

nginx version: nginx/1.10.3

Posted at Nginx Forum: https://forum.nginx.org/read.php?21,289197,289198#msg-289198


From shilov на extmail.info  Sat Aug 29 16:21:44 2020
From: shilov на extmail.info (Shilov)
Date: Sat, 29 Aug 2020 19:21:44 +0300
Subject: =?UTF-8?B?0JrQsNC6INC30LDRiNC40YTRgNC+0LLQsNGC0Ywg0LrQsNC90LDQuyDRgSDQv9C+?=
 =?UTF-8?B?0LzQvtGJ0YzRjiBOZ2lueA==?=
Message-ID: <20200829192144.086d7fbd2521179560589e90@extmail.info>

Приветствую уважаемых знатоков Nginx! :)

Вы мне прошлый раз очень помогли, подарив конфиг Nginx для реверсного прокси, который понимает сокеты, за что вам еще раз огромное спасибо!
И теперь прошу вас еще разочек подсказать, как зашифровать трафик с помощью двух Nginx прокси.

Для читабельности я выложил свой вопрос на openennet: 
	
https://www.opennet.ru/openforum/vsluhforumID8/8227.html

хотя был уверен, что там никто не осилит эту задачу, зато - наглядно.

Друзья, помогите, пожалуйста, с конфигами для этих прокси, очень нужно!



-- 
Shilov <shilov на extmail.info>

From root на dl.sm.ua  Sun Aug 30 06:09:37 2020
From: root на dl.sm.ua (Dmytro Lavryk)
Date: Sun, 30 Aug 2020 09:09:37 +0300
Subject: =?UTF-8?B?0JLRltC00L/QvtCy0ZbQtNGMOiDQmtCw0Log0LfQsNGI0LjRhNGA0L7QstCw0YI=?=
 =?UTF-8?B?0Ywg0LrQsNC90LDQuyDRgSDQv9C+0LzQvtGJ0YzRjiBOZ2lueA==?=
In-Reply-To: <20200829192144.086d7fbd2521179560589e90@extmail.info>
References: <20200829192144.086d7fbd2521179560589e90@extmail.info>
Message-ID: <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua>

proxy_pass       http://77.77.77.770:80443;


?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200830/3a971f57/attachment.htm>

From root на dl.sm.ua  Sun Aug 30 06:11:44 2020
From: root на dl.sm.ua (Dmytro Lavryk)
Date: Sun, 30 Aug 2020 09:11:44 +0300
Subject: =?UTF-8?B?0JLRltC00L/QvtCy0ZbQtNGMOiDQmtCw0Log0LfQsNGI0LjRhNGA0L7QstCw0YI=?=
 =?UTF-8?B?0Ywg0LrQsNC90LDQuyDRgSDQv9C+0LzQvtGJ0YzRjiBOZ2lueA==?=
In-Reply-To: <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua>
References: <20200829192144.086d7fbd2521179560589e90@extmail.info>
 <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua>
Message-ID: <1743dfe37e6.d8bcbf4c95916.671721987137944739@dl.sm.ua>

proxy_pass       http://77.77.77.770:80443;



?





Вот так имел ввиду
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200830/44702db7/attachment.htm>

From shilov на extmail.info  Sun Aug 30 11:06:38 2020
From: shilov на extmail.info (Shilov)
Date: Sun, 30 Aug 2020 14:06:38 +0300
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDog0JrQsNC6INC30LDRiNC40YTRgNC+0LI=?=
 =?UTF-8?B?0LDRgtGMINC60LDQvdCw0Lsg0YEg0L/QvtC80L7RidGM0Y4gTmdpbng=?=
In-Reply-To: <1743dfe37e6.d8bcbf4c95916.671721987137944739@dl.sm.ua>
References: <20200829192144.086d7fbd2521179560589e90@extmail.info>
 <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua>
 <1743dfe37e6.d8bcbf4c95916.671721987137944739@dl.sm.ua>
Message-ID: <20200830140638.7f3bf5651ac220fd0d3d8e84@extmail.info>

Спасибо, Дмитрий, за сам ответ, только к сожалению, ничего из него не понял.
Можете привести полные конфиги для обоих прокси - внешнего и локального?



On Sun, 30 Aug 2020 09:11:44 +0300
Dmytro Lavryk <root на dl.sm.ua> wrote:

> proxy_pass       http://77.77.77.770:80443;

> 
> ?
> 
> Вот так имел ввиду


-- 
Shilov <shilov на extmail.info>

From root на dl.sm.ua  Sun Aug 30 12:43:24 2020
From: root на dl.sm.ua (Dmytro Lavryk)
Date: Sun, 30 Aug 2020 15:43:24 +0300
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDog0JrQsNC6INC30LDRiNC40YTRgNC+0LI=?=
 =?UTF-8?B?0LDRgtGMINC60LDQvdCw0Lsg0YEg0L/QvtC80L7RidGM0Y4gTmdpbng=?=
In-Reply-To: <20200830140638.7f3bf5651ac220fd0d3d8e84@extmail.info>
References: <20200829192144.086d7fbd2521179560589e90@extmail.info>
 <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua>
 <1743dfe37e6.d8bcbf4c95916.671721987137944739@dl.sm.ua>
 <20200830140638.7f3bf5651ac220fd0d3d8e84@extmail.info>
Message-ID: <1743f64ccf6.118f39b2f99233.7265807939715888516@dl.sm.ua>

Чето неудачи с мэйл клиентом...

Конфиги привести не могу - лень чистить от конфиденциального, но основная идея в том, что proxy_pass прекрасно работает через https, в чем проблема то?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200830/33519cf9/attachment.htm>

From shilov на extmail.info  Sun Aug 30 15:34:17 2020
From: shilov на extmail.info (Shilov)
Date: Sun, 30 Aug 2020 18:34:17 +0300
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDog0JrQsNC6INC30LDRiNC40YTRgNC+0LI=?=
 =?UTF-8?B?0LDRgtGMINC60LDQvdCw0Lsg0YEg0L/QvtC80L7RidGM0Y4gTmdpbng=?=
In-Reply-To: <1743f64ccf6.118f39b2f99233.7265807939715888516@dl.sm.ua>
References: <20200829192144.086d7fbd2521179560589e90@extmail.info>
 <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua>
 <1743dfe37e6.d8bcbf4c95916.671721987137944739@dl.sm.ua>
 <20200830140638.7f3bf5651ac220fd0d3d8e84@extmail.info>
 <1743f64ccf6.118f39b2f99233.7265807939715888516@dl.sm.ua>
Message-ID: <20200830183417.b42a226226038910d41c382a@extmail.info>

On Sun, 30 Aug 2020 15:43:24 +0300
Dmytro Lavryk <root на dl.sm.ua> wrote:

> Чето неудачи с мэйл клиентом...
> 
> Конфиги привести не могу - лень чистить от конфиденциального, но основная идея в том, что proxy_pass прекрасно работает через https, в чем проблема то?

Проблема в том, что я ничего не понимаю в этих конфигах. Совсем.
И никакие идеи мне не помогут. Я не линуксоид. Так, слегка.
Все, что я умею - воткнуть в работу готовый конфиг, который мне дадут.

Тем более, что тут не один конфиг нужен, а два.


-- 
Shilov <shilov на extmail.info>

From root на dl.sm.ua  Mon Aug 31 06:16:07 2020
From: root на dl.sm.ua (Dmytro Lavryk)
Date: Mon, 31 Aug 2020 09:16:07 +0300
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDog0JrQsNC6INC30LDRiNC40YTRgNC+0LI=?=
 =?UTF-8?B?0LDRgtGMINC60LDQvdCw0Lsg0YEg0L/QvtC80L7RidGM0Y4gTmdpbng=?=
In-Reply-To: <20200830183417.b42a226226038910d41c382a@extmail.info>
References: <20200829192144.086d7fbd2521179560589e90@extmail.info>
 <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua>
 <1743dfe37e6.d8bcbf4c95916.671721987137944739@dl.sm.ua>
 <20200830140638.7f3bf5651ac220fd0d3d8e84@extmail.info>
 <1743f64ccf6.118f39b2f99233.7265807939715888516@dl.sm.ua>
 <20200830183417.b42a226226038910d41c382a@extmail.info>
Message-ID: <1744328962a.101566d89106857.6326385665270579186@dl.sm.ua>

Ну тогда уж извините. Я думаю никто не будет за вас писать конфиги, тем более, что как всегда вылезет куча нюансов. Если Вы не можете освоить элементарно документацию, значит наймите кого-то, кто может.

---- Увімкнуто нд, 30 серп. 2020 18:34:17 +0300 Shilov <mailto:shilov на extmail.info> написав ----


On Sun, 30 Aug 2020 15:43:24 +0300
Dmytro Lavryk <mailto:root на dl.sm.ua> wrote:

> Чето неудачи с мэйл клиентом...
> 
> Конфиги привести не могу - лень чистить от конфиденциального, но основная идея в том, что proxy_pass прекрасно работает через https, в чем проблема то?

Проблема в том, что я ничего не понимаю в этих конфигах. Совсем.
И никакие идеи мне не помогут. Я не линуксоид. Так, слегка.
Все, что я умею - воткнуть в работу готовый конфиг, который мне дадут.

Тем более, что тут не один конфиг нужен, а два.


-- 
Shilov <mailto:shilov на extmail.info>
_______________________________________________
nginx-ru mailing list
mailto:nginx-ru на nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/fe13ab04/attachment.htm>

From shilov на extmail.info  Mon Aug 31 06:31:15 2020
From: shilov на extmail.info (Shilov)
Date: Mon, 31 Aug 2020 09:31:15 +0300
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDog0JrQsNC6INC30LDRiNC40YTRgNC+0LI=?=
 =?UTF-8?B?0LDRgtGMINC60LDQvdCw0Lsg0YEg0L/QvtC80L7RidGM0Y4gTmdpbng=?=
In-Reply-To: <1744328962a.101566d89106857.6326385665270579186@dl.sm.ua>
References: <20200829192144.086d7fbd2521179560589e90@extmail.info>
 <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua>
 <1743dfe37e6.d8bcbf4c95916.671721987137944739@dl.sm.ua>
 <20200830140638.7f3bf5651ac220fd0d3d8e84@extmail.info>
 <1743f64ccf6.118f39b2f99233.7265807939715888516@dl.sm.ua>
 <20200830183417.b42a226226038910d41c382a@extmail.info>
 <1744328962a.101566d89106857.6326385665270579186@dl.sm.ua>
Message-ID: <20200831093115.f9ee69543c74ba708bed1b60@extmail.info>

Так их и не нужно его писать, наверняка есть готовые - задача ведь самая что ни на есть классическая и элементарная.
К тому же, когда я здесь же попросил сделать сделать конфиг реверсного прокси, который пропускал бы сокеты, мне без лишних слов выложили его.
К сожалению, в переписке не сохранилось, кто мне так тогда безвозмездно помог, возможно, это был Максим, а может и вы.


On Mon, 31 Aug 2020 09:16:07 +0300
Dmytro Lavryk <root на dl.sm.ua> wrote:

> Ну тогда уж извините. Я думаю никто не будет за вас писать конфиги, тем более, что как всегда вылезет куча нюансов. Если Вы не можете освоить элементарно документацию, значит наймите кого-то, кто может.
> 
> ---- Увімкнуто нд, 30 серп. 2020 18:34:17 +0300 Shilov <mailto:shilov на extmail.info> написав ----
> 
> 
> On Sun, 30 Aug 2020 15:43:24 +0300
> Dmytro Lavryk <mailto:root на dl.sm.ua> wrote:
> 
> > Чето неудачи с мэйл клиентом...
> > 
> > Конфиги привести не могу - лень чистить от конфиденциального, но основная идея в том, что proxy_pass прекрасно работает через https, в чем проблема то?
> 
> Проблема в том, что я ничего не понимаю в этих конфигах. Совсем.
> И никакие идеи мне не помогут. Я не линуксоид. Так, слегка.
> Все, что я умею - воткнуть в работу готовый конфиг, который мне дадут.
> 
> Тем более, что тут не один конфиг нужен, а два.
> 
> 
> -- 
> Shilov <mailto:shilov на extmail.info>
> _______________________________________________
> nginx-ru mailing list
> mailto:nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Shilov <shilov на extmail.info>

From chipitsine на gmail.com  Mon Aug 31 08:31:09 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 31 Aug 2020 13:31:09 +0500
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDog0JrQsNC6INC30LDRiNC40YTRgNC+0LI=?=
 =?UTF-8?B?0LDRgtGMINC60LDQvdCw0Lsg0YEg0L/QvtC80L7RidGM0Y4gTmdpbng=?=
In-Reply-To: <20200831093115.f9ee69543c74ba708bed1b60@extmail.info>
References: <20200829192144.086d7fbd2521179560589e90@extmail.info>
 <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua>
 <1743dfe37e6.d8bcbf4c95916.671721987137944739@dl.sm.ua>
 <20200830140638.7f3bf5651ac220fd0d3d8e84@extmail.info>
 <1743f64ccf6.118f39b2f99233.7265807939715888516@dl.sm.ua>
 <20200830183417.b42a226226038910d41c382a@extmail.info>
 <1744328962a.101566d89106857.6326385665270579186@dl.sm.ua>
 <20200831093115.f9ee69543c74ba708bed1b60@extmail.info>
Message-ID: <CAFHpkQEuTEs92W+0xS3zKN_TLTFfcMqw=X9squB5PdJsZgmCjQ@mail.gmail.com>

наличие готовых конфигов можно посмотреть вокруг.
специализированные сайты по поиску (Google, Yandex), каталог готовых
примеров на сайте nginx.com

обращаясь в рассылку за "готовым" конфигом вы несколько ставите в тупик
всех участников

пн, 31 авг. 2020 г. в 11:31, Shilov <shilov на extmail.info>:

> Так их и не нужно его писать, наверняка есть готовые - задача ведь самая
> что ни на есть классическая и элементарная.
> К тому же, когда я здесь же попросил сделать сделать конфиг реверсного
> прокси, который пропускал бы сокеты, мне без лишних слов выложили его.
> К сожалению, в переписке не сохранилось, кто мне так тогда безвозмездно
> помог, возможно, это был Максим, а может и вы.
>
>
> On Mon, 31 Aug 2020 09:16:07 +0300
> Dmytro Lavryk <root на dl.sm.ua> wrote:
>
> > Ну тогда уж извините. Я думаю никто не будет за вас писать конфиги, тем
> более, что как всегда вылезет куча нюансов. Если Вы не можете освоить
> элементарно документацию, значит наймите кого-то, кто может.
> >
> > ---- Увімкнуто нд, 30 серп. 2020 18:34:17 +0300 Shilov <mailto:
> shilov на extmail.info> написав ----
> >
> >
> > On Sun, 30 Aug 2020 15:43:24 +0300
> > Dmytro Lavryk <mailto:root на dl.sm.ua> wrote:
> >
> > > Чето неудачи с мэйл клиентом...
> > >
> > > Конфиги привести не могу - лень чистить от конфиденциального, но
> основная идея в том, что proxy_pass прекрасно работает через https, в чем
> проблема то?
> >
> > Проблема в том, что я ничего не понимаю в этих конфигах. Совсем.
> > И никакие идеи мне не помогут. Я не линуксоид. Так, слегка.
> > Все, что я умею - воткнуть в работу готовый конфиг, который мне дадут.
> >
> > Тем более, что тут не один конфиг нужен, а два.
> >
> >
> > --
> > Shilov <mailto:shilov на extmail.info>
> > _______________________________________________
> > nginx-ru mailing list
> > mailto:nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> --
> Shilov <shilov на extmail.info>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/5900ea79/attachment-0001.htm>

From mif на me.com  Mon Aug 31 10:51:25 2020
From: mif на me.com (Alexey Galygin)
Date: Mon, 31 Aug 2020 13:51:25 +0300
Subject: =?UTF-8?B?bmdpbnggMS4xOC4wINC10YHRgiDQstGB0Y4g0L/QsNC80Y/RgtGMINC4IHN3YXAg?=
 =?UTF-8?B?0L3QsCBVYnVudHUgU2VydmVyIDIwLjA0LjEgTFRT?=
Message-ID: <E581FBC1-9EED-491D-9E62-100691807149@me.com>

привет всем
 
случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
 
через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>)
в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
 
пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
 
из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений
  
исключили уже всё — и zfs, который переформатировали в ext4 с отключенным atime
и из docker вынесли nginx в хост
 
и внутренние системы исключили…
 
меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
 
упорно кончается вся память через 5 минут, все 256 Гб и своп
 
идей практически не осталось, куда можно ещё копать?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/60968356/attachment.htm>

From shilov на extmail.info  Mon Aug 31 10:58:17 2020
From: shilov на extmail.info (Shilov)
Date: Mon, 31 Aug 2020 13:58:17 +0300
Subject: =?UTF-8?B?UmU6INCS0ZbQtNC/0L7QstGW0LTRjDog0JrQsNC6INC30LDRiNC40YTRgNC+0LI=?=
 =?UTF-8?B?0LDRgtGMINC60LDQvdCw0Lsg0YEg0L/QvtC80L7RidGM0Y4gTmdpbng=?=
In-Reply-To: <CAFHpkQEuTEs92W+0xS3zKN_TLTFfcMqw=X9squB5PdJsZgmCjQ@mail.gmail.com>
References: <20200829192144.086d7fbd2521179560589e90@extmail.info>
 <1743dfc46b1.d2d2dbe195910.2444208520271662466@dl.sm.ua>
 <1743dfe37e6.d8bcbf4c95916.671721987137944739@dl.sm.ua>
 <20200830140638.7f3bf5651ac220fd0d3d8e84@extmail.info>
 <1743f64ccf6.118f39b2f99233.7265807939715888516@dl.sm.ua>
 <20200830183417.b42a226226038910d41c382a@extmail.info>
 <1744328962a.101566d89106857.6326385665270579186@dl.sm.ua>
 <20200831093115.f9ee69543c74ba708bed1b60@extmail.info>
 <CAFHpkQEuTEs92W+0xS3zKN_TLTFfcMqw=X9squB5PdJsZgmCjQ@mail.gmail.com>
Message-ID: <20200831135817.c2c7d151980fe030862ac6b0@extmail.info>

On Mon, 31 Aug 2020 13:31:09 +0500
Илья Шипицин <chipitsine на gmail.com> wrote:

> наличие готовых конфигов можно посмотреть вокруг.
> специализированные сайты по поиску (Google, Yandex),

вот не нашел такой конфиг под свой случай, иначе бы в рассылку не обращался


>  каталог готовых  примеров на сайте nginx.com

это же просто ссылка на главный сайт https://www.nginx.com/, 
но каталога примеров там увы,не обнаружил


> обращаясь в рассылку за "готовым" конфигом 
> вы несколько ставите в тупик всех участников


Почему в тупик? Для чего тогда вообще эта рассылка?

Вот, нашел: в прошлый раз со своим вопросом я обратился в тикеты:
https://trac.nginx.org/nginx/ticket/1947#ticket

Maxim Dounin дал мне дельный совет, но при этом заметил:

"В случае, если есть ещё вопросы, их лучше задавать там, где вопросам место - в ​списках рассылки."

Какие-то противоречивые советы получаются. Кто же из вас прав?









> 
> пн, 31 авг. 2020 г. в 11:31, Shilov <shilov на extmail.info>:
> 
> > Так их и не нужно его писать, наверняка есть готовые - задача ведь самая
> > что ни на есть классическая и элементарная.
> > К тому же, когда я здесь же попросил сделать сделать конфиг реверсного
> > прокси, который пропускал бы сокеты, мне без лишних слов выложили его.
> > К сожалению, в переписке не сохранилось, кто мне так тогда безвозмездно
> > помог, возможно, это был Максим, а может и вы.
> >
> >
> > On Mon, 31 Aug 2020 09:16:07 +0300
> > Dmytro Lavryk <root на dl.sm.ua> wrote:
> >
> > > Ну тогда уж извините. Я думаю никто не будет за вас писать конфиги, тем
> > более, что как всегда вылезет куча нюансов. Если Вы не можете освоить
> > элементарно документацию, значит наймите кого-то, кто может.
> > >
> > > ---- Увімкнуто нд, 30 серп. 2020 18:34:17 +0300 Shilov <mailto:
> > shilov на extmail.info> написав ----
> > >
> > >
> > > On Sun, 30 Aug 2020 15:43:24 +0300
> > > Dmytro Lavryk <mailto:root на dl.sm.ua> wrote:
> > >
> > > > Чето неудачи с мэйл клиентом...
> > > >
> > > > Конфиги привести не могу - лень чистить от конфиденциального, но
> > основная идея в том, что proxy_pass прекрасно работает через https, в чем
> > проблема то?
> > >
> > > Проблема в том, что я ничего не понимаю в этих конфигах. Совсем.
> > > И никакие идеи мне не помогут. Я не линуксоид. Так, слегка.
> > > Все, что я умею - воткнуть в работу готовый конфиг, который мне дадут.
> > >
> > > Тем более, что тут не один конфиг нужен, а два.
> > >
> > >
> > > --
> > > Shilov <mailto:shilov на extmail.info>
> > > _______________________________________________
> > > nginx-ru mailing list
> > > mailto:nginx-ru на nginx.org
> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> > --
> > Shilov <shilov на extmail.info>
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru


-- 
Shilov <shilov на extmail.info>

From slw на zxy.spb.ru  Mon Aug 31 11:00:48 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 31 Aug 2020 14:00:48 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
Message-ID: <20200831110048.GK2015@zxy.spb.ru>

On Mon, Aug 31, 2020 at 01:51:25PM +0300, Alexey Galygin wrote:

> привет всем
>  
> случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
>  
> через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>)
> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
>  
> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
>  
> из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений
>   
> исключили уже всё — и zfs, который переформатировали в ext4 с отключенным atime
> и из docker вынесли nginx в хост
>  
> и внутренние системы исключили…
>  
> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>  
> упорно кончается вся память через 5 минут, все 256 Гб и своп
>  
> идей практически не осталось, куда можно ещё копать?

Попробовать FreeBSD?

From mif на me.com  Mon Aug 31 11:11:53 2020
From: mif на me.com (Alexey Galygin)
Date: Mon, 31 Aug 2020 14:11:53 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <20200831110048.GK2015@zxy.spb.ru>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <20200831110048.GK2015@zxy.spb.ru>
Message-ID: <9A71B784-7AC0-4F18-B44C-51A5D8CEE197@me.com>

у нас многое завязано на LXD, и LXC-контейнеры (особенно исторические) мы не заведём под FreeBSD,
поэтому ОС резко сменить не получится

хотелось бы понять: почему nginx может так активно есть всю память?
никогда такого не было, глаза на лоб лезут

он даже бедный REDIS вытеснил в своп…

перезапуск nginx освобождает память…

> On 31 Aug 2020, at 14:00, Slawa Olhovchenkov <slw на zxy.spb.ru> wrote:
> 
> On Mon, Aug 31, 2020 at 01:51:25PM +0300, Alexey Galygin wrote:
> 
>> привет всем
>> 
>> случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
>> 
>> через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0> <https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>>)
>> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
>> 
>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
>> 
>> из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений
>> 
>> исключили уже всё — и zfs, который переформатировали в ext4 с отключенным atime
>> и из docker вынесли nginx в хост
>> 
>> и внутренние системы исключили…
>> 
>> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>> 
>> упорно кончается вся память через 5 минут, все 256 Гб и своп
>> 
>> идей практически не осталось, куда можно ещё копать?
> 
> Попробовать FreeBSD?
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/4789c7df/attachment-0001.htm>

From chipitsine на gmail.com  Mon Aug 31 11:19:01 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 31 Aug 2020 14:19:01 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
Message-ID: <CAFHpkQFgBwpSDG9j_=BbLEMEFdxL29KurfP2+aXYQOhhcPFK7w@mail.gmail.com>

Посмотрите, не увеличивается ли у вас число воркеров.

Ещё поможет вывод nginx -V

И поможет конфиг

On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin <mif на me.com> wrote:

> привет всем
>
> случилось странное, переехали на сервера по параметрам в разы большие, чем
> сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния
> на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный
> в 10%))
>
> через 5 минут после старта nginx ест всю память и весь swap! (см.
> https://prnt.sc/u8nia0)
> в итоге сервер умирает, никогда такого не видели, это же кэширующий
> прокси, а не БД!…
>
> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri
> Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост
> nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера
> nginx:1.18.0)
>
> из особенностей используются ngx_http_js_module.so — для исторического
> escape/unescape URI и ngx_http_image_filter_module.so — для подрезки
> изображений
>
> исключили уже всё — и zfs, который переформатировали в ext4 с отключенным
> atime
> и из docker вынесли nginx в хост
>
> и внутренние системы исключили…
>
> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>
> упорно кончается вся память через 5 минут, все 256 Гб и своп
>
> идей практически не осталось, куда можно ещё копать?
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/e151b420/attachment.htm>

From bgx на protva.ru  Mon Aug 31 11:27:54 2020
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Mon, 31 Aug 2020 14:27:54 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
Message-ID: <20200831112754.GC2673@protva.ru>

On Mon, Aug 31, 2020 at 01:51:25PM +0300, Alexey Galygin wrote:
>    случилось странное, переехали на сервера по параметрам в разы большие, чем
>    сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния
>    на штатные параметры sysctl осталось отключение ipv6
>    и swapness выставленный в 10%))
...
>    меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>     
>    упорно кончается вся память через 5 минут, все 256 Гб и своп
>     
>    идей практически не осталось, куда можно ещё копать?

 Вы с серверами сменили ОС, ядро и поставили nginx другой версии?
 Если да, то для начала запустите старую систему на новой железке,
 и память системе дайте столько, сколько было на старой.
 А потом двигайтесь пошагово в сторону проблемной конфигурации.
-- 
 Eugene Berdnikov

From karamba66 на ukr.net  Mon Aug 31 11:35:04 2020
From: karamba66 на ukr.net (karamba66 на ukr.net)
Date: Mon, 31 Aug 2020 13:35:04 +0200
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <9A71B784-7AC0-4F18-B44C-51A5D8CEE197@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <20200831110048.GK2015@zxy.spb.ru>
 <9A71B784-7AC0-4F18-B44C-51A5D8CEE197@me.com>
Message-ID: <67013C3E-2931-4979-AE83-3C11F41EC289@ukr.net>

Видел такой симптом когда на сервер приходит много медленных https клиентов. Посмотрите не происходит ли быстрый рост активных коннектов до больших (сотни тысяч) чисел.

> 31 авг. 2020 г., в 13:11, Alexey Galygin <mif на me.com> написал(а):
> 
> у нас многое завязано на LXD, и LXC-контейнеры (особенно исторические) мы не заведём под FreeBSD,
> поэтому ОС резко сменить не получится
> 
> хотелось бы понять: почему nginx может так активно есть всю память?
> никогда такого не было, глаза на лоб лезут
> 
> он даже бедный REDIS вытеснил в своп…
> 
> перезапуск nginx освобождает память…
> 
>> On 31 Aug 2020, at 14:00, Slawa Olhovchenkov <slw на zxy.spb.ru <mailto:slw на zxy.spb.ru>> wrote:
>> 
>> On Mon, Aug 31, 2020 at 01:51:25PM +0300, Alexey Galygin wrote:
>> 
>>> привет всем
>>> 
>>> случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
>>> 
>>> через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0> <https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>>)
>>> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
>>> 
>>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>>> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
>>> 
>>> из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений
>>> 
>>> исключили уже всё — и zfs, который переформатировали в ext4 с отключенным atime
>>> и из docker вынесли nginx в хост
>>> 
>>> и внутренние системы исключили…
>>> 
>>> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>>> 
>>> упорно кончается вся память через 5 минут, все 256 Гб и своп
>>> 
>>> идей практически не осталось, куда можно ещё копать?
>> 
>> Попробовать FreeBSD?
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/b5468cc9/attachment-0001.htm>

From mif на me.com  Mon Aug 31 11:38:21 2020
From: mif на me.com (Alexey Galygin)
Date: Mon, 31 Aug 2020 14:38:21 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <CAFHpkQFgBwpSDG9j_=BbLEMEFdxL29KurfP2+aXYQOhhcPFK7w@mail.gmail.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <CAFHpkQFgBwpSDG9j_=BbLEMEFdxL29KurfP2+aXYQOhhcPFK7w@mail.gmail.com>
Message-ID: <15639139-E8BD-4A5F-ADED-0637CBE3F3A6@me.com>

стандартная сборка из docker hub nginx:1.18.0

docker exec nginx nginx -V

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-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.18.0/debian/debuild-base/nginx-1.18.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie’

тестировать можем только по ночам, днём пользователи работают
поэтому посмотреть рост воркеров сейчас не представляется возможным + требуется именно получить нагрузку (пока сервер не трогают там штиль и спокойствие)

хочу собрать идеи, что крутить ночью

возможно дело и не в количестве воркеров: по скриншоту видно, что всего 5-10 воркеров набрали всю память

конфиг большой, светить бы его прод версию не хотелось

могу точечно надёргать:

worker_processes                auto;

events {
        worker_connections      4096;
        multi_accept on;
        use epoll;
}
worker_rlimit_nofile    10240;

http {
  client_max_body_size                2000m;
    sendfile                                    on;
    tcp_nopush                                  on;
    tcp_nodelay                                 on;
    server_tokens                               off;
    keepalive_timeout                   60;
        reset_timedout_connection       on;
        if_modified_since                       before;

  proxy_buffer_size                   128k;
    proxy_buffers                               24 32k;
    proxy_busy_buffers_size             256k;
    proxy_temp_file_write_size  4m;

 client_header_buffer_size   8k;
    large_client_header_buffers 8 128k;
        client_body_buffer_size         256K;

  server_names_hash_max_size          4096;
    server_names_hash_bucket_size       128;
        map_hash_max_size                               8500;
        proxy_headers_hash_bucket_size  128;

   gzip                                on;
    gzip_types                  text/plain text/css text/xml application/xml application/x-javascript application/javascript application/json application/rss+xml application/rss application/x-rss+xml;
    gzip_http_version   1.1;
        gzip_min_length         900;
    gzip_comp_level             7;
    gzip_proxied                any;
    gzip_buffers                32 8k;
        gzip_disable            msie6;

  proxy_cache_path                    /var/lib/nginx/cache  levels=1:2  keys_zone=C1:20m inactive=24h max_size=20000m;
    proxy_cache_use_stale               updating error timeout invalid_header http_500 http_502 http_503 http_504;
    proxy_cache_background_update on;
    proxy_temp_path                             /var/run/nginx/proxy;
        proxy_cache_lock                        on;
        proxy_cache_lock_timeout        25s;
    proxy_cache_methods                 GET HEAD;
    proxy_cache_valid                   404     1m;

  open_file_cache                         max=1024 inactive=30s;
        open_file_cache_valid           60s;
        open_file_cache_min_uses        2;
        open_file_cache_errors          on;
        open_log_file_cache                     max=100 inactive=30s valid=1m min_uses=2;
}


к слову, на новом стенде cache выел всего 300 Мб из 10-20 Гб разрешённых (а на рабочем старом стенде вообще пишется в RAM /var/run — и всё там ок)
нюанс в том, что эта конфигурация отлично работает на старом сервере рядом, где только Ubuntu более старая

> On 31 Aug 2020, at 14:19, Илья Шипицин <chipitsine на gmail.com> wrote:
> 
> Посмотрите, не увеличивается ли у вас число воркеров.
> 
> Ещё поможет вывод nginx -V
> 
> И поможет конфиг
> 
> On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin <mif на me.com <mailto:mif на me.com>> wrote:
> привет всем
>  
> случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
>  
> через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>)
> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
>  
> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
>  
> из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений
>   
> исключили уже всё — и zfs, который переформатировали в ext4 с отключенным atime
> и из docker вынесли nginx в хост
>  
> и внутренние системы исключили…
>  
> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>  
> упорно кончается вся память через 5 минут, все 256 Гб и своп
>  
> идей практически не осталось, куда можно ещё копать?
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>_______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/aff2df26/attachment-0001.htm>

From mif на me.com  Mon Aug 31 12:10:43 2020
From: mif на me.com (Alexey Galygin)
Date: Mon, 31 Aug 2020 15:10:43 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <67013C3E-2931-4979-AE83-3C11F41EC289@ukr.net>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <20200831110048.GK2015@zxy.spb.ru>
 <9A71B784-7AC0-4F18-B44C-51A5D8CEE197@me.com>
 <67013C3E-2931-4979-AE83-3C11F41EC289@ukr.net>
Message-ID: <2971793B-33B7-42F1-A7EC-9CE05D4520A8@me.com>

мы за DDoS Protection
к нам ходит один и тот же сервис, пользователи напрямую не ходят

я просто меняю апстрим для теста
и наблюдаю, как кончается память и дохнет сервер

через 5 минут переключаюсь на прежний сервер и там всё ок

> On 31 Aug 2020, at 14:35, karamba66 на ukr.net wrote:
> 
> Видел такой симптом когда на сервер приходит много медленных https клиентов. Посмотрите не происходит ли быстрый рост активных коннектов до больших (сотни тысяч) чисел.
> 
>> 31 авг. 2020 г., в 13:11, Alexey Galygin <mif на me.com <mailto:mif на me.com>> написал(а):
>> 
>> у нас многое завязано на LXD, и LXC-контейнеры (особенно исторические) мы не заведём под FreeBSD,
>> поэтому ОС резко сменить не получится
>> 
>> хотелось бы понять: почему nginx может так активно есть всю память?
>> никогда такого не было, глаза на лоб лезут
>> 
>> он даже бедный REDIS вытеснил в своп…
>> 
>> перезапуск nginx освобождает память…
>> 
>>> On 31 Aug 2020, at 14:00, Slawa Olhovchenkov <slw на zxy.spb.ru <mailto:slw на zxy.spb.ru>> wrote:
>>> 
>>> On Mon, Aug 31, 2020 at 01:51:25PM +0300, Alexey Galygin wrote:
>>> 
>>>> привет всем
>>>> 
>>>> случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
>>>> 
>>>> через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0> <https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>>)
>>>> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
>>>> 
>>>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>>>> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
>>>> 
>>>> из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений
>>>> 
>>>> исключили уже всё — и zfs, который переформатировали в ext4 с отключенным atime
>>>> и из docker вынесли nginx в хост
>>>> 
>>>> и внутренние системы исключили…
>>>> 
>>>> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>>>> 
>>>> упорно кончается вся память через 5 минут, все 256 Гб и своп
>>>> 
>>>> идей практически не осталось, куда можно ещё копать?
>>> 
>>> Попробовать FreeBSD?
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org <mailto: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

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/0d9ca2c0/attachment.htm>

From chipitsine на gmail.com  Mon Aug 31 13:07:33 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 31 Aug 2020 16:07:33 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <15639139-E8BD-4A5F-ADED-0637CBE3F3A6@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <CAFHpkQFgBwpSDG9j_=BbLEMEFdxL29KurfP2+aXYQOhhcPFK7w@mail.gmail.com>
 <15639139-E8BD-4A5F-ADED-0637CBE3F3A6@me.com>
Message-ID: <CAFHpkQGG6v5p2_fu=oa72zz8DLruxWzxD2xcqf6p4ur4i9whow@mail.gmail.com>

Количество воркеров можно посмотреть

 ps auxw | grep nginx | grep worker | wc -l


Это безопасно

On Mon, Aug 31, 2020, 2:38 PM Alexey Galygin <mif на me.com> wrote:

> стандартная сборка из docker hub nginx:1.18.0
>
> docker exec nginx nginx -V
>
> 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-cc-opt='-g
> -O2
> -fdebug-prefix-map=/data/builder/debuild/nginx-1.18.0/debian/debuild-base/nginx-1.18.0=.
> -fstack-protector-strong -Wformat -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now
> -Wl,--as-needed -pie’
>
> тестировать можем только по ночам, днём пользователи работают
> поэтому посмотреть рост воркеров сейчас не представляется возможным +
> требуется именно получить нагрузку (пока сервер не трогают там штиль и
> спокойствие)
>
> хочу собрать идеи, что крутить ночью
>
> возможно дело и не в количестве воркеров: по скриншоту видно, что всего
> 5-10 воркеров набрали всю память
>
> конфиг большой, светить бы его прод версию не хотелось
>
> могу точечно надёргать:
>
> worker_processes                auto;
>
> events {
>         worker_connections      4096;
>         multi_accept on;
>         use epoll;
> }
> worker_rlimit_nofile    10240;
>
> http {
>   client_max_body_size                2000m;
>     sendfile                                    on;
>     tcp_nopush                                  on;
>     tcp_nodelay                                 on;
>     server_tokens                               off;
>     keepalive_timeout                   60;
>         reset_timedout_connection       on;
>         if_modified_since                       before;
>
>   proxy_buffer_size                   128k;
>     proxy_buffers                               24 32k;
>     proxy_busy_buffers_size             256k;
>     proxy_temp_file_write_size  4m;
>
>  client_header_buffer_size   8k;
>     large_client_header_buffers 8 128k;
>         client_body_buffer_size         256K;
>
>   server_names_hash_max_size          4096;
>     server_names_hash_bucket_size       128;
>         map_hash_max_size                               8500;
>         proxy_headers_hash_bucket_size  128;
>
>    gzip                                on;
>     gzip_types                  text/plain text/css text/xml
> application/xml application/x-javascript application/javascript
> application/json application/rss+xml application/rss application/x-rss+xml;
>     gzip_http_version   1.1;
>         gzip_min_length         900;
>     gzip_comp_level             7;
>     gzip_proxied                any;
>     gzip_buffers                32 8k;
>         gzip_disable            msie6;
>
>   proxy_cache_path                    /var/lib/nginx/cache  levels=1:2
>  keys_zone=C1:20m inactive=24h max_size=20000m;
>     proxy_cache_use_stale               updating error timeout
> invalid_header http_500 http_502 http_503 http_504;
>     proxy_cache_background_update on;
>     proxy_temp_path                             /var/run/nginx/proxy;
>         proxy_cache_lock                        on;
>         proxy_cache_lock_timeout        25s;
>     proxy_cache_methods                 GET HEAD;
>     proxy_cache_valid                   404     1m;
>
>   open_file_cache                         max=1024 inactive=30s;
>         open_file_cache_valid           60s;
>         open_file_cache_min_uses        2;
>         open_file_cache_errors          on;
>         open_log_file_cache                     max=100 inactive=30s
> valid=1m min_uses=2;
> }
>
>
> к слову, на новом стенде cache выел всего 300 Мб из 10-20 Гб разрешённых
> (а на рабочем старом стенде вообще пишется в RAM /var/run — и всё там ок)
> нюанс в том, что эта конфигурация отлично работает на старом сервере
> рядом, где только Ubuntu более старая
>
> On 31 Aug 2020, at 14:19, Илья Шипицин <chipitsine на gmail.com> wrote:
>
> Посмотрите, не увеличивается ли у вас число воркеров.
>
> Ещё поможет вывод nginx -V
>
> И поможет конфиг
>
> On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin <mif на me.com> wrote:
>
>> привет всем
>>
>> случилось странное, переехали на сервера по параметрам в разы большие,
>> чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров
>> влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный
>> в 10%))
>>
>> через 5 минут после старта nginx ест всю память и весь swap! (см.
>> https://prnt.sc/u8nia0)
>> в итоге сервер умирает, никогда такого не видели, это же кэширующий
>> прокси, а не БД!…
>>
>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri
>> Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост
>> nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера
>> nginx:1.18.0)
>>
>> из особенностей используются ngx_http_js_module.so — для исторического
>> escape/unescape URI и ngx_http_image_filter_module.so — для подрезки
>> изображений
>>
>> исключили уже всё — и zfs, который переформатировали в ext4 с
>> отключенным atime
>> и из docker вынесли nginx в хост
>>
>> и внутренние системы исключили…
>>
>> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>>
>> упорно кончается вся память через 5 минут, все 256 Гб и своп
>>
>> идей практически не осталось, куда можно ещё копать?
>> _______________________________________________
>> 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
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/eb6ed4ca/attachment-0001.htm>

From mif на me.com  Mon Aug 31 13:19:55 2020
From: mif на me.com (Alexey Galygin)
Date: Mon, 31 Aug 2020 16:19:55 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <CAFHpkQGG6v5p2_fu=oa72zz8DLruxWzxD2xcqf6p4ur4i9whow@mail.gmail.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <CAFHpkQFgBwpSDG9j_=BbLEMEFdxL29KurfP2+aXYQOhhcPFK7w@mail.gmail.com>
 <15639139-E8BD-4A5F-ADED-0637CBE3F3A6@me.com>
 <CAFHpkQGG6v5p2_fu=oa72zz8DLruxWzxD2xcqf6p4ur4i9whow@mail.gmail.com>
Message-ID: <2968C73A-C8DB-45BB-B3CC-CEB205A82E76@me.com>

сервер сейчас не под нагрузкой
в ночи проверю

сейчас 32 воркера

> On 31 Aug 2020, at 16:07, Илья Шипицин <chipitsine на gmail.com> wrote:
> 
> Количество воркеров можно посмотреть
> 
>  ps auxw | grep nginx | grep worker | wc -l
> 
> 
> Это безопасно
> 
> On Mon, Aug 31, 2020, 2:38 PM Alexey Galygin <mif на me.com <mailto:mif на me.com>> wrote:
> стандартная сборка из docker hub nginx:1.18.0
> 
> docker exec nginx nginx -V
> 
> 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-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.18.0/debian/debuild-base/nginx-1.18.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie’
> 
> тестировать можем только по ночам, днём пользователи работают
> поэтому посмотреть рост воркеров сейчас не представляется возможным + требуется именно получить нагрузку (пока сервер не трогают там штиль и спокойствие)
> 
> хочу собрать идеи, что крутить ночью
> 
> возможно дело и не в количестве воркеров: по скриншоту видно, что всего 5-10 воркеров набрали всю память
> 
> конфиг большой, светить бы его прод версию не хотелось
> 
> могу точечно надёргать:
> 
> worker_processes                auto;
> 
> events {
>         worker_connections      4096;
>         multi_accept on;
>         use epoll;
> }
> worker_rlimit_nofile    10240;
> 
> http {
>   client_max_body_size                2000m;
>     sendfile                                    on;
>     tcp_nopush                                  on;
>     tcp_nodelay                                 on;
>     server_tokens                               off;
>     keepalive_timeout                   60;
>         reset_timedout_connection       on;
>         if_modified_since                       before;
> 
>   proxy_buffer_size                   128k;
>     proxy_buffers                               24 32k;
>     proxy_busy_buffers_size             256k;
>     proxy_temp_file_write_size  4m;
> 
>  client_header_buffer_size   8k;
>     large_client_header_buffers 8 128k;
>         client_body_buffer_size         256K;
> 
>   server_names_hash_max_size          4096;
>     server_names_hash_bucket_size       128;
>         map_hash_max_size                               8500;
>         proxy_headers_hash_bucket_size  128;
> 
>    gzip                                on;
>     gzip_types                  text/plain text/css text/xml application/xml application/x-javascript application/javascript application/json application/rss+xml application/rss application/x-rss+xml;
>     gzip_http_version   1.1;
>         gzip_min_length         900;
>     gzip_comp_level             7;
>     gzip_proxied                any;
>     gzip_buffers                32 8k;
>         gzip_disable            msie6;
> 
>   proxy_cache_path                    /var/lib/nginx/cache  levels=1:2  keys_zone=C1:20m inactive=24h max_size=20000m;
>     proxy_cache_use_stale               updating error timeout invalid_header http_500 http_502 http_503 http_504;
>     proxy_cache_background_update on;
>     proxy_temp_path                             /var/run/nginx/proxy;
>         proxy_cache_lock                        on;
>         proxy_cache_lock_timeout        25s;
>     proxy_cache_methods                 GET HEAD;
>     proxy_cache_valid                   404     1m;
> 
>   open_file_cache                         max=1024 inactive=30s;
>         open_file_cache_valid           60s;
>         open_file_cache_min_uses        2;
>         open_file_cache_errors          on;
>         open_log_file_cache                     max=100 inactive=30s valid=1m min_uses=2;
> }
> 
> 
> к слову, на новом стенде cache выел всего 300 Мб из 10-20 Гб разрешённых (а на рабочем старом стенде вообще пишется в RAM /var/run — и всё там ок)
> нюанс в том, что эта конфигурация отлично работает на старом сервере рядом, где только Ubuntu более старая
> 
>> On 31 Aug 2020, at 14:19, Илья Шипицин <chipitsine на gmail.com <mailto:chipitsine на gmail.com>> wrote:
>> 
>> Посмотрите, не увеличивается ли у вас число воркеров.
>> 
>> Ещё поможет вывод nginx -V
>> 
>> И поможет конфиг
>> 
>> On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin <mif на me.com <mailto:mif на me.com>> wrote:
>> привет всем
>>  
>> случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
>>  
>> через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>)
>> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
>>  
>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
>>  
>> из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений
>>   
>> исключили уже всё — и zfs, который переформатировали в ext4 с отключенным atime
>> и из docker вынесли nginx в хост
>>  
>> и внутренние системы исключили…
>>  
>> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>>  
>> упорно кончается вся память через 5 минут, все 256 Гб и своп
>>  
>> идей практически не осталось, куда можно ещё копать?
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>_______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>_______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/6886c5bc/attachment-0001.htm>

From mif на me.com  Mon Aug 31 13:22:34 2020
From: mif на me.com (Alexey Galygin)
Date: Mon, 31 Aug 2020 16:22:34 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <2968C73A-C8DB-45BB-B3CC-CEB205A82E76@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <CAFHpkQFgBwpSDG9j_=BbLEMEFdxL29KurfP2+aXYQOhhcPFK7w@mail.gmail.com>
 <15639139-E8BD-4A5F-ADED-0637CBE3F3A6@me.com>
 <CAFHpkQGG6v5p2_fu=oa72zz8DLruxWzxD2xcqf6p4ur4i9whow@mail.gmail.com>
 <2968C73A-C8DB-45BB-B3CC-CEB205A82E76@me.com>
Message-ID: <574F27BB-2147-4E37-A5C2-43122393D5B1@me.com>

что в принципе логично и вряд ли изменится под нагрузкой — там 32 честных ядра
auto выбрал по одному воркеру на ядро

хотя не логично, вот на текущем стабильном стенде, где 20HT ядер, воркеров оказалось 53…

> On 31 Aug 2020, at 16:19, Alexey Galygin <mif на me.com> wrote:
> 
> сервер сейчас не под нагрузкой
> в ночи проверю
> 
> сейчас 32 воркера
> 
>> On 31 Aug 2020, at 16:07, Илья Шипицин <chipitsine на gmail.com <mailto:chipitsine на gmail.com>> wrote:
>> 
>> Количество воркеров можно посмотреть
>> 
>>  ps auxw | grep nginx | grep worker | wc -l
>> 
>> 
>> Это безопасно
>> 
>> On Mon, Aug 31, 2020, 2:38 PM Alexey Galygin <mif на me.com <mailto:mif на me.com>> wrote:
>> стандартная сборка из docker hub nginx:1.18.0
>> 
>> docker exec nginx nginx -V
>> 
>> 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-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.18.0/debian/debuild-base/nginx-1.18.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie’
>> 
>> тестировать можем только по ночам, днём пользователи работают
>> поэтому посмотреть рост воркеров сейчас не представляется возможным + требуется именно получить нагрузку (пока сервер не трогают там штиль и спокойствие)
>> 
>> хочу собрать идеи, что крутить ночью
>> 
>> возможно дело и не в количестве воркеров: по скриншоту видно, что всего 5-10 воркеров набрали всю память
>> 
>> конфиг большой, светить бы его прод версию не хотелось
>> 
>> могу точечно надёргать:
>> 
>> worker_processes                auto;
>> 
>> events {
>>         worker_connections      4096;
>>         multi_accept on;
>>         use epoll;
>> }
>> worker_rlimit_nofile    10240;
>> 
>> http {
>>   client_max_body_size                2000m;
>>     sendfile                                    on;
>>     tcp_nopush                                  on;
>>     tcp_nodelay                                 on;
>>     server_tokens                               off;
>>     keepalive_timeout                   60;
>>         reset_timedout_connection       on;
>>         if_modified_since                       before;
>> 
>>   proxy_buffer_size                   128k;
>>     proxy_buffers                               24 32k;
>>     proxy_busy_buffers_size             256k;
>>     proxy_temp_file_write_size  4m;
>> 
>>  client_header_buffer_size   8k;
>>     large_client_header_buffers 8 128k;
>>         client_body_buffer_size         256K;
>> 
>>   server_names_hash_max_size          4096;
>>     server_names_hash_bucket_size       128;
>>         map_hash_max_size                               8500;
>>         proxy_headers_hash_bucket_size  128;
>> 
>>    gzip                                on;
>>     gzip_types                  text/plain text/css text/xml application/xml application/x-javascript application/javascript application/json application/rss+xml application/rss application/x-rss+xml;
>>     gzip_http_version   1.1;
>>         gzip_min_length         900;
>>     gzip_comp_level             7;
>>     gzip_proxied                any;
>>     gzip_buffers                32 8k;
>>         gzip_disable            msie6;
>> 
>>   proxy_cache_path                    /var/lib/nginx/cache  levels=1:2  keys_zone=C1:20m inactive=24h max_size=20000m;
>>     proxy_cache_use_stale               updating error timeout invalid_header http_500 http_502 http_503 http_504;
>>     proxy_cache_background_update on;
>>     proxy_temp_path                             /var/run/nginx/proxy;
>>         proxy_cache_lock                        on;
>>         proxy_cache_lock_timeout        25s;
>>     proxy_cache_methods                 GET HEAD;
>>     proxy_cache_valid                   404     1m;
>> 
>>   open_file_cache                         max=1024 inactive=30s;
>>         open_file_cache_valid           60s;
>>         open_file_cache_min_uses        2;
>>         open_file_cache_errors          on;
>>         open_log_file_cache                     max=100 inactive=30s valid=1m min_uses=2;
>> }
>> 
>> 
>> к слову, на новом стенде cache выел всего 300 Мб из 10-20 Гб разрешённых (а на рабочем старом стенде вообще пишется в RAM /var/run — и всё там ок)
>> нюанс в том, что эта конфигурация отлично работает на старом сервере рядом, где только Ubuntu более старая
>> 
>>> On 31 Aug 2020, at 14:19, Илья Шипицин <chipitsine на gmail.com <mailto:chipitsine на gmail.com>> wrote:
>>> 
>>> Посмотрите, не увеличивается ли у вас число воркеров.
>>> 
>>> Ещё поможет вывод nginx -V
>>> 
>>> И поможет конфиг
>>> 
>>> On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin <mif на me.com <mailto:mif на me.com>> wrote:
>>> привет всем
>>>  
>>> случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
>>>  
>>> через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>)
>>> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
>>>  
>>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>>> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
>>>  
>>> из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений
>>>   
>>> исключили уже всё — и zfs, который переформатировали в ext4 с отключенным atime
>>> и из docker вынесли nginx в хост
>>>  
>>> и внутренние системы исключили…
>>>  
>>> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>>>  
>>> упорно кончается вся память через 5 минут, все 256 Гб и своп
>>>  
>>> идей практически не осталось, куда можно ещё копать?
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>_______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>_______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/ab1652ad/attachment-0001.htm>

From mdounin на mdounin.ru  Mon Aug 31 13:33:31 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 31 Aug 2020 16:33:31 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
Message-ID: <20200831133331.GX12747@mdounin.ru>

Hello!

On Mon, Aug 31, 2020 at 01:51:25PM +0300, Alexey Galygin wrote:

> случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
>  
> через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>)
> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
>  
> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
>  
> из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений

Отмечу, что в GD library бывают лики, см. например тут:

https://trac.nginx.org/nginx/ticket/1587

-- 
Maxim Dounin
http://mdounin.ru/

From mif на me.com  Mon Aug 31 13:48:36 2020
From: mif на me.com (Alexey Galygin)
Date: Mon, 31 Aug 2020 16:48:36 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <20200831133331.GX12747@mdounin.ru>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <20200831133331.GX12747@mdounin.ru>
Message-ID: <3A4262A6-9834-425B-AA5A-ED73AFE9C737@me.com>

мы запросили у организации, которая занимается DDoS Protection
список всех запросов за интервал теста

пытаемся по этим ссылкам ходить скриптом…

на штатный resize пришлось не более 800 запросов за всё время эксперимента, вряд ли бы это забило всю память
(файлики jpg они маленькие, ну допустим текло по 1 Мб на запрос, ну утёк бы 1 Гб за 5 минут, а не 300…)

ну и точно такой же nginx 1.18.0 на эталонном сервере так не утекает

изменилось в стенде только — Ubuntu — была 16.04 стала 20.04 (тут я подозреваю, сменился аллокатор памяти, что-то с FS подкрутили, может дескрипторы если не утекают, то кэш избыточный накапливается в ОЗУ)
память — было 192 — стало 256
FS как была ext4 так и осталась ext4…
ЦОД — было нормальное железо — стала платформа VMWare Cloud Director… на вид работает даже шустрее

> On 31 Aug 2020, at 16:33, Maxim Dounin <mdounin на mdounin.ru> wrote:
> 
> Hello!
> 
> On Mon, Aug 31, 2020 at 01:51:25PM +0300, Alexey Galygin wrote:
> 
>> случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
>> 
>> через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>)
>> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
>> 
>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
>> 
>> из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений
> 
> Отмечу, что в GD library бывают лики, см. например тут:
> 
> https://trac.nginx.org/nginx/ticket/1587
> 
> -- 
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From mif на me.com  Mon Aug 31 15:11:17 2020
From: mif на me.com (Alexey Galygin)
Date: Mon, 31 Aug 2020 18:11:17 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <15639139-E8BD-4A5F-ADED-0637CBE3F3A6@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <CAFHpkQFgBwpSDG9j_=BbLEMEFdxL29KurfP2+aXYQOhhcPFK7w@mail.gmail.com>
 <15639139-E8BD-4A5F-ADED-0637CBE3F3A6@me.com>
Message-ID: <6F1F0542-444B-4946-92A5-758F08FE17B7@me.com>

на тестовом запуске мы словили примерно 200 запросов к статике в секунду в среднем (иногда больше, иногда меньше)
в общем-то это не так уж и много (картинки, стили, документы

может быть такое, что если дисковая система стала медленнее (а судя по косвенным замерам, которые я провёл, она медленнее в разы)
то прежняя конфигурация nginx просто не успевает раздавать статику?

скорость сети больше чем скорость дисков
запросов от клиентов приходит масса
ком нарастает

процессы висят в статусе “D", медленно считывают и копят это в память

если отключить sendfile, включить aio, добавить ограничений, это поможет?

или уменьшить worker_connections 4096?

или уменьшить open_file_cache?

или это всё фантазия и медленный диск не мог стать причиной пожирания всей памяти?


> On 31 Aug 2020, at 14:38, Alexey Galygin <mif на me.com> wrote:
> 
> стандартная сборка из docker hub nginx:1.18.0
> 
> 
> worker_processes                auto;
> 
> events {
>         worker_connections      4096;
>         multi_accept on;
>         use epoll;
> }
> worker_rlimit_nofile    10240;
> 
> http {
>   client_max_body_size                2000m;
>     sendfile                                    on;
>     tcp_nopush                                  on;
>     tcp_nodelay                                 on;
>     server_tokens                               off;
>     keepalive_timeout                   60;
>         reset_timedout_connection       on;
>         if_modified_since                       before;
> 
>   proxy_buffer_size                   128k;
>     proxy_buffers                               24 32k;
>     proxy_busy_buffers_size             256k;
>     proxy_temp_file_write_size  4m;
> 
>  client_header_buffer_size   8k;
>     large_client_header_buffers 8 128k;
>         client_body_buffer_size         256K;
> 
>   server_names_hash_max_size          4096;
>     server_names_hash_bucket_size       128;
>         map_hash_max_size                               8500;
>         proxy_headers_hash_bucket_size  128;
> 
>    gzip                                on;
>     gzip_types                  text/plain text/css text/xml application/xml application/x-javascript application/javascript application/json application/rss+xml application/rss application/x-rss+xml;
>     gzip_http_version   1.1;
>         gzip_min_length         900;
>     gzip_comp_level             7;
>     gzip_proxied                any;
>     gzip_buffers                32 8k;
>         gzip_disable            msie6;
> 
>   proxy_cache_path                    /var/lib/nginx/cache  levels=1:2  keys_zone=C1:20m inactive=24h max_size=20000m;
>     proxy_cache_use_stale               updating error timeout invalid_header http_500 http_502 http_503 http_504;
>     proxy_cache_background_update on;
>     proxy_temp_path                             /var/run/nginx/proxy;
>         proxy_cache_lock                        on;
>         proxy_cache_lock_timeout        25s;
>     proxy_cache_methods                 GET HEAD;
>     proxy_cache_valid                   404     1m;
> 
>   open_file_cache                         max=1024 inactive=30s;
>         open_file_cache_valid           60s;
>         open_file_cache_min_uses        2;
>         open_file_cache_errors          on;
>         open_log_file_cache                     max=100 inactive=30s valid=1m min_uses=2;
> }
> 
> 
> к слову, на новом стенде cache выел всего 300 Мб из 10-20 Гб разрешённых (а на рабочем старом стенде вообще пишется в RAM /var/run — и всё там ок)
> нюанс в том, что эта конфигурация отлично работает на старом сервере рядом, где только Ubuntu более старая
> 
>> On 31 Aug 2020, at 14:19, Илья Шипицин <chipitsine на gmail.com <mailto:chipitsine на gmail.com>> wrote:
>> 
>> Посмотрите, не увеличивается ли у вас число воркеров.
>> 
>> Ещё поможет вывод nginx -V
>> 
>> И поможет конфиг
>> 
>> On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin <mif на me.com <mailto:mif на me.com>> wrote:
>> привет всем
>>  
>> случилось странное, переехали на сервера по параметрам в разы большие, чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 10%))
>>  
>> через 5 минут после старта nginx ест всю память и весь swap! (см. https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>)
>> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, а не БД!…
>>  
>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера nginx:1.18.0)
>>  
>> из особенностей используются ngx_http_js_module.so — для исторического escape/unescape URI и ngx_http_image_filter_module.so — для подрезки изображений
>>   
>> исключили уже всё — и zfs, который переформатировали в ext4 с отключенным atime
>> и из docker вынесли nginx в хост
>>  
>> и внутренние системы исключили…
>>  
>> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>>  
>> упорно кончается вся память через 5 минут, все 256 Гб и своп
>>  
>> идей практически не осталось, куда можно ещё копать?
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru <http://mailman.nginx.org/mailman/listinfo/nginx-ru>_______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/7a27b904/attachment-0001.htm>

From chipitsine на gmail.com  Mon Aug 31 16:02:18 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 31 Aug 2020 21:02:18 +0500
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <6F1F0542-444B-4946-92A5-758F08FE17B7@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <CAFHpkQFgBwpSDG9j_=BbLEMEFdxL29KurfP2+aXYQOhhcPFK7w@mail.gmail.com>
 <15639139-E8BD-4A5F-ADED-0637CBE3F3A6@me.com>
 <6F1F0542-444B-4946-92A5-758F08FE17B7@me.com>
Message-ID: <CAFHpkQFS_+4jkw7SgoNmJuj=C4GeRGdi1rchVPnT4ztd635YEA@mail.gmail.com>

пн, 31 авг. 2020 г. в 20:11, Alexey Galygin <mif на me.com>:

> на тестовом запуске мы словили примерно 200 запросов к статике в секунду в
> среднем (иногда больше, иногда меньше)
> в общем-то это не так уж и много (картинки, стили, документы
>
> может быть такое, что если дисковая система стала медленнее (а судя по
> косвенным замерам, которые я провёл, она медленнее в разы)
> то прежняя конфигурация nginx просто не успевает раздавать статику?
>
> скорость сети больше чем скорость дисков
> запросов от клиентов приходит масса
> ком нарастает
>

а отключите буферизацию ?

proxy_buffering off;
proxy_request_buffering off;

у вас статика раздается непосредственно с этого сервера или проксируете на
другие ?



> процессы висят в статусе “D", медленно считывают и копят это в память
>
> если отключить sendfile, включить aio, добавить ограничений, это поможет?
>
> или уменьшить worker_connections 4096?
>
> или уменьшить open_file_cache?
>
> или это всё фантазия и медленный диск не мог стать причиной пожирания всей
> памяти?
>
>
> On 31 Aug 2020, at 14:38, Alexey Galygin <mif на me.com> wrote:
>
> стандартная сборка из docker hub nginx:1.18.0
>
>
> worker_processes                auto;
>
> events {
>         worker_connections      4096;
>         multi_accept on;
>         use epoll;
> }
> worker_rlimit_nofile    10240;
>
> http {
>   client_max_body_size                2000m;
>     sendfile                                    on;
>     tcp_nopush                                  on;
>     tcp_nodelay                                 on;
>     server_tokens                               off;
>     keepalive_timeout                   60;
>         reset_timedout_connection       on;
>         if_modified_since                       before;
>
>   proxy_buffer_size                   128k;
>     proxy_buffers                               24 32k;
>     proxy_busy_buffers_size             256k;
>     proxy_temp_file_write_size  4m;
>
>  client_header_buffer_size   8k;
>     large_client_header_buffers 8 128k;
>         client_body_buffer_size         256K;
>
>   server_names_hash_max_size          4096;
>     server_names_hash_bucket_size       128;
>         map_hash_max_size                               8500;
>         proxy_headers_hash_bucket_size  128;
>
>    gzip                                on;
>     gzip_types                  text/plain text/css text/xml
> application/xml application/x-javascript application/javascript
> application/json application/rss+xml application/rss application/x-rss+xml;
>     gzip_http_version   1.1;
>         gzip_min_length         900;
>     gzip_comp_level             7;
>     gzip_proxied                any;
>     gzip_buffers                32 8k;
>         gzip_disable            msie6;
>
>   proxy_cache_path                    /var/lib/nginx/cache  levels=1:2
>  keys_zone=C1:20m inactive=24h max_size=20000m;
>     proxy_cache_use_stale               updating error timeout
> invalid_header http_500 http_502 http_503 http_504;
>     proxy_cache_background_update on;
>     proxy_temp_path                             /var/run/nginx/proxy;
>         proxy_cache_lock                        on;
>         proxy_cache_lock_timeout        25s;
>     proxy_cache_methods                 GET HEAD;
>     proxy_cache_valid                   404     1m;
>
>   open_file_cache                         max=1024 inactive=30s;
>         open_file_cache_valid           60s;
>         open_file_cache_min_uses        2;
>         open_file_cache_errors          on;
>         open_log_file_cache                     max=100 inactive=30s
> valid=1m min_uses=2;
> }
>
>
> к слову, на новом стенде cache выел всего 300 Мб из 10-20 Гб разрешённых
> (а на рабочем старом стенде вообще пишется в RAM /var/run — и всё там ок)
> нюанс в том, что эта конфигурация отлично работает на старом сервере
> рядом, где только Ubuntu более старая
>
> On 31 Aug 2020, at 14:19, Илья Шипицин <chipitsine на gmail.com> wrote:
>
> Посмотрите, не увеличивается ли у вас число воркеров.
>
> Ещё поможет вывод nginx -V
>
> И поможет конфиг
>
> On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin <mif на me.com> wrote:
>
>> привет всем
>>
>> случилось странное, переехали на сервера по параметрам в разы большие,
>> чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров
>> влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный
>> в 10%))
>>
>> через 5 минут после старта nginx ест всю память и весь swap! (см.
>> https://prnt.sc/u8nia0)
>> в итоге сервер умирает, никогда такого не видели, это же кэширующий
>> прокси, а не БД!…
>>
>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri
>> Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост
>> nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера
>> nginx:1.18.0)
>>
>> из особенностей используются ngx_http_js_module.so — для исторического
>> escape/unescape URI и ngx_http_image_filter_module.so — для подрезки
>> изображений
>>
>> исключили уже всё — и zfs, который переформатировали в ext4 с
>> отключенным atime
>> и из docker вынесли nginx в хост
>>
>> и внутренние системы исключили…
>>
>> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>>
>> упорно кончается вся память через 5 минут, все 256 Гб и своп
>>
>> идей практически не осталось, куда можно ещё копать?
>> _______________________________________________
>> 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
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/8e3725cd/attachment-0001.htm>

From tolmachev.vlad на gmail.com  Mon Aug 31 16:08:08 2020
From: tolmachev.vlad на gmail.com (=?UTF-8?B?0JLQu9Cw0LQg0KI=?=)
Date: Mon, 31 Aug 2020 19:08:08 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <CAFHpkQFS_+4jkw7SgoNmJuj=C4GeRGdi1rchVPnT4ztd635YEA@mail.gmail.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <CAFHpkQFgBwpSDG9j_=BbLEMEFdxL29KurfP2+aXYQOhhcPFK7w@mail.gmail.com>
 <15639139-E8BD-4A5F-ADED-0637CBE3F3A6@me.com>
 <6F1F0542-444B-4946-92A5-758F08FE17B7@me.com>
 <CAFHpkQFS_+4jkw7SgoNmJuj=C4GeRGdi1rchVPnT4ztd635YEA@mail.gmail.com>
Message-ID: <CANuGLW2iZVYyrFjj8tK3Me0Fp06dTb4d_S3g3N_K8ro6k5TEgg@mail.gmail.com>

Такая же проблема есть, когда диски проседают при наплыве клиентов, nginx
начинает жрать до 100% памяти, подтверждаю, раздается статика.

пн, 31 авг. 2020 г., 19:02 Илья Шипицин <chipitsine на gmail.com>:

>
>
> пн, 31 авг. 2020 г. в 20:11, Alexey Galygin <mif на me.com>:
>
>> на тестовом запуске мы словили примерно 200 запросов к статике в секунду
>> в среднем (иногда больше, иногда меньше)
>> в общем-то это не так уж и много (картинки, стили, документы
>>
>> может быть такое, что если дисковая система стала медленнее (а судя по
>> косвенным замерам, которые я провёл, она медленнее в разы)
>> то прежняя конфигурация nginx просто не успевает раздавать статику?
>>
>> скорость сети больше чем скорость дисков
>> запросов от клиентов приходит масса
>> ком нарастает
>>
>
> а отключите буферизацию ?
>
> proxy_buffering off;
> proxy_request_buffering off;
>
> у вас статика раздается непосредственно с этого сервера или проксируете на
> другие ?
>
>
>
>> процессы висят в статусе “D", медленно считывают и копят это в память
>>
>> если отключить sendfile, включить aio, добавить ограничений, это поможет?
>>
>> или уменьшить worker_connections 4096?
>>
>> или уменьшить open_file_cache?
>>
>> или это всё фантазия и медленный диск не мог стать причиной пожирания
>> всей памяти?
>>
>>
>> On 31 Aug 2020, at 14:38, Alexey Galygin <mif на me.com> wrote:
>>
>> стандартная сборка из docker hub nginx:1.18.0
>>
>>
>> worker_processes                auto;
>>
>> events {
>>         worker_connections      4096;
>>         multi_accept on;
>>         use epoll;
>> }
>> worker_rlimit_nofile    10240;
>>
>> http {
>>   client_max_body_size                2000m;
>>     sendfile                                    on;
>>     tcp_nopush                                  on;
>>     tcp_nodelay                                 on;
>>     server_tokens                               off;
>>     keepalive_timeout                   60;
>>         reset_timedout_connection       on;
>>         if_modified_since                       before;
>>
>>   proxy_buffer_size                   128k;
>>     proxy_buffers                               24 32k;
>>     proxy_busy_buffers_size             256k;
>>     proxy_temp_file_write_size  4m;
>>
>>  client_header_buffer_size   8k;
>>     large_client_header_buffers 8 128k;
>>         client_body_buffer_size         256K;
>>
>>   server_names_hash_max_size          4096;
>>     server_names_hash_bucket_size       128;
>>         map_hash_max_size                               8500;
>>         proxy_headers_hash_bucket_size  128;
>>
>>    gzip                                on;
>>     gzip_types                  text/plain text/css text/xml
>> application/xml application/x-javascript application/javascript
>> application/json application/rss+xml application/rss application/x-rss+xml;
>>     gzip_http_version   1.1;
>>         gzip_min_length         900;
>>     gzip_comp_level             7;
>>     gzip_proxied                any;
>>     gzip_buffers                32 8k;
>>         gzip_disable            msie6;
>>
>>   proxy_cache_path                    /var/lib/nginx/cache  levels=1:2
>>  keys_zone=C1:20m inactive=24h max_size=20000m;
>>     proxy_cache_use_stale               updating error timeout
>> invalid_header http_500 http_502 http_503 http_504;
>>     proxy_cache_background_update on;
>>     proxy_temp_path                             /var/run/nginx/proxy;
>>         proxy_cache_lock                        on;
>>         proxy_cache_lock_timeout        25s;
>>     proxy_cache_methods                 GET HEAD;
>>     proxy_cache_valid                   404     1m;
>>
>>   open_file_cache                         max=1024 inactive=30s;
>>         open_file_cache_valid           60s;
>>         open_file_cache_min_uses        2;
>>         open_file_cache_errors          on;
>>         open_log_file_cache                     max=100 inactive=30s
>> valid=1m min_uses=2;
>> }
>>
>>
>> к слову, на новом стенде cache выел всего 300 Мб из 10-20 Гб разрешённых
>> (а на рабочем старом стенде вообще пишется в RAM /var/run — и всё там ок)
>> нюанс в том, что эта конфигурация отлично работает на старом сервере
>> рядом, где только Ubuntu более старая
>>
>> On 31 Aug 2020, at 14:19, Илья Шипицин <chipitsine на gmail.com> wrote:
>>
>> Посмотрите, не увеличивается ли у вас число воркеров.
>>
>> Ещё поможет вывод nginx -V
>>
>> И поможет конфиг
>>
>> On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin <mif на me.com> wrote:
>>
>>> привет всем
>>>
>>> случилось странное, переехали на сервера по параметрам в разы большие,
>>> чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров
>>> влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный
>>> в 10%))
>>>
>>> через 5 минут после старта nginx ест всю память и весь swap! (см.
>>> https://prnt.sc/u8nia0)
>>> в итоге сервер умирает, никогда такого не видели, это же кэширующий
>>> прокси, а не БД!…
>>>
>>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri
>>> Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>>> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост
>>> nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера
>>> nginx:1.18.0)
>>>
>>> из особенностей используются ngx_http_js_module.so — для исторического
>>> escape/unescape URI и ngx_http_image_filter_module.so — для подрезки
>>> изображений
>>>
>>> исключили уже всё — и zfs, который переформатировали в ext4 с
>>> отключенным atime
>>> и из docker вынесли nginx в хост
>>>
>>> и внутренние системы исключили…
>>>
>>> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>>>
>>> упорно кончается вся память через 5 минут, все 256 Гб и своп
>>>
>>> идей практически не осталось, куда можно ещё копать?
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/611dcafd/attachment-0001.htm>

From chipitsine на gmail.com  Mon Aug 31 16:10:33 2020
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Mon, 31 Aug 2020 21:10:33 +0500
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <6F1F0542-444B-4946-92A5-758F08FE17B7@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <CAFHpkQFgBwpSDG9j_=BbLEMEFdxL29KurfP2+aXYQOhhcPFK7w@mail.gmail.com>
 <15639139-E8BD-4A5F-ADED-0637CBE3F3A6@me.com>
 <6F1F0542-444B-4946-92A5-758F08FE17B7@me.com>
Message-ID: <CAFHpkQGb7xqruKdMTUs_PeCGK_gY7o=2=NbGM4omCyegv2xtsw@mail.gmail.com>

вообще, по производительности дисковой системы есть тупо системные метрики
- io per second, disk queue size, т.е. упираетесь вы в дисковую систему или
нет, можно (и нужно) узнавать через мониторинг ведь ?

пн, 31 авг. 2020 г. в 20:11, Alexey Galygin <mif на me.com>:

> на тестовом запуске мы словили примерно 200 запросов к статике в секунду в
> среднем (иногда больше, иногда меньше)
> в общем-то это не так уж и много (картинки, стили, документы
>
> может быть такое, что если дисковая система стала медленнее (а судя по
> косвенным замерам, которые я провёл, она медленнее в разы)
> то прежняя конфигурация nginx просто не успевает раздавать статику?
>
> скорость сети больше чем скорость дисков
> запросов от клиентов приходит масса
> ком нарастает
>
> процессы висят в статусе “D", медленно считывают и копят это в память
>
> если отключить sendfile, включить aio, добавить ограничений, это поможет?
>
> или уменьшить worker_connections 4096?
>
> или уменьшить open_file_cache?
>
> или это всё фантазия и медленный диск не мог стать причиной пожирания всей
> памяти?
>
>
> On 31 Aug 2020, at 14:38, Alexey Galygin <mif на me.com> wrote:
>
> стандартная сборка из docker hub nginx:1.18.0
>
>
> worker_processes                auto;
>
> events {
>         worker_connections      4096;
>         multi_accept on;
>         use epoll;
> }
> worker_rlimit_nofile    10240;
>
> http {
>   client_max_body_size                2000m;
>     sendfile                                    on;
>     tcp_nopush                                  on;
>     tcp_nodelay                                 on;
>     server_tokens                               off;
>     keepalive_timeout                   60;
>         reset_timedout_connection       on;
>         if_modified_since                       before;
>
>   proxy_buffer_size                   128k;
>     proxy_buffers                               24 32k;
>     proxy_busy_buffers_size             256k;
>     proxy_temp_file_write_size  4m;
>
>  client_header_buffer_size   8k;
>     large_client_header_buffers 8 128k;
>         client_body_buffer_size         256K;
>
>   server_names_hash_max_size          4096;
>     server_names_hash_bucket_size       128;
>         map_hash_max_size                               8500;
>         proxy_headers_hash_bucket_size  128;
>
>    gzip                                on;
>     gzip_types                  text/plain text/css text/xml
> application/xml application/x-javascript application/javascript
> application/json application/rss+xml application/rss application/x-rss+xml;
>     gzip_http_version   1.1;
>         gzip_min_length         900;
>     gzip_comp_level             7;
>     gzip_proxied                any;
>     gzip_buffers                32 8k;
>         gzip_disable            msie6;
>
>   proxy_cache_path                    /var/lib/nginx/cache  levels=1:2
>  keys_zone=C1:20m inactive=24h max_size=20000m;
>     proxy_cache_use_stale               updating error timeout
> invalid_header http_500 http_502 http_503 http_504;
>     proxy_cache_background_update on;
>     proxy_temp_path                             /var/run/nginx/proxy;
>         proxy_cache_lock                        on;
>         proxy_cache_lock_timeout        25s;
>     proxy_cache_methods                 GET HEAD;
>     proxy_cache_valid                   404     1m;
>
>   open_file_cache                         max=1024 inactive=30s;
>         open_file_cache_valid           60s;
>         open_file_cache_min_uses        2;
>         open_file_cache_errors          on;
>         open_log_file_cache                     max=100 inactive=30s
> valid=1m min_uses=2;
> }
>
>
> к слову, на новом стенде cache выел всего 300 Мб из 10-20 Гб разрешённых
> (а на рабочем старом стенде вообще пишется в RAM /var/run — и всё там ок)
> нюанс в том, что эта конфигурация отлично работает на старом сервере
> рядом, где только Ubuntu более старая
>
> On 31 Aug 2020, at 14:19, Илья Шипицин <chipitsine на gmail.com> wrote:
>
> Посмотрите, не увеличивается ли у вас число воркеров.
>
> Ещё поможет вывод nginx -V
>
> И поможет конфиг
>
> On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin <mif на me.com> wrote:
>
>> привет всем
>>
>> случилось странное, переехали на сервера по параметрам в разы большие,
>> чем сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров
>> влияния на штатные параметры sysctl осталось отключение ipv6 и swapness выставленный
>> в 10%))
>>
>> через 5 минут после старта nginx ест всю память и весь swap! (см.
>> https://prnt.sc/u8nia0)
>> в итоге сервер умирает, никогда такого не видели, это же кэширующий
>> прокси, а не БД!…
>>
>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri
>> Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>> нагруженный nginx 1.18 (пробовали из официальных репок ставить на хост
>> nginx/stable 1.18.0-1~focal amd64 и в контейнер из официального докера
>> nginx:1.18.0)
>>
>> из особенностей используются ngx_http_js_module.so — для исторического
>> escape/unescape URI и ngx_http_image_filter_module.so — для подрезки
>> изображений
>>
>> исключили уже всё — и zfs, который переформатировали в ext4 с
>> отключенным atime
>> и из docker вынесли nginx в хост
>>
>> и внутренние системы исключили…
>>
>> меняли конфиги, отключали sendfile, кэши open-файлов, включали aio…
>>
>> упорно кончается вся память через 5 минут, все 256 Гб и своп
>>
>> идей практически не осталось, куда можно ещё копать?
>> _______________________________________________
>> 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
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200831/80775709/attachment-0001.htm>

From mdounin на mdounin.ru  Mon Aug 31 16:41:18 2020
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 31 Aug 2020 19:41:18 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <3A4262A6-9834-425B-AA5A-ED73AFE9C737@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <20200831133331.GX12747@mdounin.ru>
 <3A4262A6-9834-425B-AA5A-ED73AFE9C737@me.com>
Message-ID: <20200831164118.GY12747@mdounin.ru>

Hello!

On Mon, Aug 31, 2020 at 04:48:36PM +0300, Alexey Galygin wrote:

> мы запросили у организации, которая занимается DDoS Protection
> список всех запросов за интервал теста
> 
> пытаемся по этим ссылкам ходить скриптом…
> 
> на штатный resize пришлось не более 800 запросов за всё время эксперимента, вряд ли бы это забило всю память
> (файлики jpg они маленькие, ну допустим текло по 1 Мб на запрос, ну утёк бы 1 Гб за 5 минут, а не 300…)
> 
> ну и точно такой же nginx 1.18.0 на эталонном сервере так не утекает
> 
> изменилось в стенде только — Ubuntu — была 16.04 стала 20.04 (тут я подозреваю, сменился аллокатор памяти, что-то с FS подкрутили, может дескрипторы если не утекают, то кэш избыточный накапливается в ОЗУ)
> память — было 192 — стало 256
> FS как была ext4 так и осталась ext4…
> ЦОД — было нормальное железо — стала платформа VMWare Cloud Director… на вид работает даже шустрее

Это называется "сменилось примерно всё".
Я бы начал с простого:

0. Внимательно изучил конфигурацию.

Простая оценка максимального потребления памяти рабочим процессом: 
worker_connections * (сумма всех буферов в конфиге).  Стандартные 
размеры буферов невелики, и сумму всех можно смело считать как 
"меньше одного мегабайта", если в конфиге задано что-то иное - 
соответственно прибавлять.  Относительно большие размерыы буферов 
встречаются только в image-фильтре (image_filter_buffer 1m) и mp4 
(mp4_max_buffer_size 10m).

Нюанс: простая оценка не работает, если используются подзапросы 
(SSI, cache background update, и так далее - каждый подзапрос 
может иметь свои буфера, соответственно надо умножать на 
количество подзапросов в одном соединении) и/или HTTP/2 (умножать 
на http2_max_concurrent_streams + http2_max_concurrent_pushes).

Если результат больше или сравним с наблюдаемым потреблением 
памяти - то чинить конфигурацию, если заметно больше - то искать 
дальше.

Если я правильно помню приведённые фрагменты конфига, то там 4096 
worker_connections, буферов мегабайта на 2 минимум, используется 
background update.  Если HTTP/2 не используется, то общее 
потребление памяти в пределе будет 4096 * 2m * 2 == 16 гигабайт.  
Это меньше, чем наблюдается, но не сильно.  Что уже наводит на 
всяческие мысли.  Если же ещё и HTTP/2 используется - то один 
рабочий процесс может занимать до пары терабайт, что явно не 
соответствует возможностям машины.

То есть в принципе все наблюдаемые эффекты могут просто 
объясняться конфигурацией и характером нагрузки, без всяких 
утечек.  Можно попробовать отключить HTTP/2, если вдруг 
используется, и/или покрутить размеры буферов вниз.  Ну и 
количество рабочих процессов тоже.

Отдельный вопрос - почему не наблюдаются такие же или близкие 
размеры рабочих процессов на старом сервере.  Если конфигурации 
полностью совпадают - возможно, причина в несколько другом 
характере нагрузки, в частности - из-за смены ядра и платформы.  
Меня, в частности, сильно смущает, что все рабочие процессы в 
состоянии "D", смотреть стоит на дисковую подсистему.

1. Если есть какие-то сторонние модули - исключил их из конфига 
(или сборки, если они собраны статически), и убедился, что 
проблема воспроизводится.  Если модули очень нужны - то можно 
попробовать переписать конфиг так, чтобы вынести их в отдельный 
инстанс nginx'а.

2. Если в конфиге используется скриптовый код - perl, njs, 
whatever - то этот код может потреблять произвольный объём памяти, 
даже если код кажется простым.  Опять же, лучше всего попробовать 
воспроизвести проблему без этого кода.

Ну и логи таки имеет смысл почитать, дабы точно понимать, что 
происходит, а не строить предположения.

[...]

-- 
Maxim Dounin
http://mdounin.ru/

From slw на zxy.spb.ru  Mon Aug 31 19:12:46 2020
From: slw на zxy.spb.ru (Slawa Olhovchenkov)
Date: Mon, 31 Aug 2020 22:12:46 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <6F1F0542-444B-4946-92A5-758F08FE17B7@me.com>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <CAFHpkQFgBwpSDG9j_=BbLEMEFdxL29KurfP2+aXYQOhhcPFK7w@mail.gmail.com>
 <15639139-E8BD-4A5F-ADED-0637CBE3F3A6@me.com>
 <6F1F0542-444B-4946-92A5-758F08FE17B7@me.com>
Message-ID: <20200831191246.GL2015@zxy.spb.ru>

On Mon, Aug 31, 2020 at 06:11:17PM +0300, Alexey Galygin wrote:

> на тестовом запуске мы словили примерно 200 запросов к статике в секунду в среднем (иногда больше, иногда меньше)
> в общем-то это не так уж и много (картинки, стили, документы
> 
> может быть такое, что если дисковая система стала медленнее (а судя по косвенным замерам, которые я провёл, она медленнее в разы)
> то прежняя конфигурация nginx просто не успевает раздавать статику?
> 
> скорость сети больше чем скорость дисков
> запросов от клиентов приходит масса
> ком нарастает
> 
> процессы висят в статусе “D", медленно считывают и копят это в память
> 
> если отключить sendfile, включить aio, добавить ограничений, это поможет?

а у линукса aio научился в кешь?

From mif на me.com  Mon Aug 31 21:42:14 2020
From: mif на me.com (Alexey Galygin)
Date: Tue, 1 Sep 2020 00:42:14 +0300
Subject: =?UTF-8?B?UmU6IG5naW54IDEuMTguMCDQtdGB0YIg0LLRgdGOINC/0LDQvNGP0YLRjCDQuCBz?=
 =?UTF-8?B?d2FwINC90LAgVWJ1bnR1IFNlcnZlciAyMC4wNC4xIExUUw==?=
In-Reply-To: <20200831164118.GY12747@mdounin.ru>
References: <E581FBC1-9EED-491D-9E62-100691807149@me.com>
 <20200831133331.GX12747@mdounin.ru>
 <3A4262A6-9834-425B-AA5A-ED73AFE9C737@me.com>
 <20200831164118.GY12747@mdounin.ru>
Message-ID: <8CA18B57-1AB9-4239-A27C-B9B0CDB471D5@me.com>

в общем
передаю новости с полей

жруна нашли — это NJS, на паре детских безобидных функций

TL;DR

измерили скорости дисков, потрясли поддержку… даже уже собрались всё переключить на SSD (Tier1)… но

понизили воркеров до 20, убедились, что их не больше
понизили коннекты на каждого до 2048

включили лимит на sendfile — 1m

включили aio on

отключили http2 — пусть DDoS/CDN оператор транслирует другие протоколы, не важно

на боевом сервере проверили эту же конфигурацию днём — сбоев нет на более слабом железе

* * *

затаились с коллегами в кустах
включили в полночь аплинк и стали ждать 5 минут (пока он рассосётся)… нервно поглядывая на часы

казалось бы всё ровно, так иногда мигает “D”, но в целом “R”, стабильно
и только расслабились, как, вдруг, началось…

как это происходит?
кто-то входит на мозольную URL (мы пока не знаем какую), после чего начинается труба!

не дожидаясь вырубили аплинк, ушли на старый сервер
но смертный жор продолжился

все воркеры начинают (продолжают) есть память по старшинству, даже уже без нагрузки

как только OOM-K убивает одного, другой начинает всё дожирать
и так пока все не будут убиты

в процессе стали смотреть, чем же они там заняты без нагрузки

оказалось проблема в NJS части, какой-то баг там именно в связке 1.18.0 + Ubuntu 20.04

у нас есть такой артефакт (переписанный с Perl на NJS):

function unescapeURI(r) {
        return r.uri.replace(/%20/g, " ");
}
function escapeURI(r) {
        return r.uri.replace(/\s/g, "%20").replace(/_/g, "%5F");
};

conf.d/ege.conf:81:		try_files		$uri $escaped_uri $unescaped_uri =404;
nginx.conf:123:	js_set $unescaped_uri unescapeURI;
nginx.conf:124:	js_set $escaped_uri escapeURI;
parts/file-storage-new.conf:51:	try_files	$uri $escaped_uri $unescaped_uri =404;
parts/file-storage-new.conf:55:	try_files	$uri $escaped_uri $unescaped_uri =404;
parts/static-stuff-new.conf:23:	try_files		$uri $escaped_uri $unescaped_uri @backendCache-15m;
parts/static-stuff-new.conf:40:	try_files		$uri $escaped_uri $unescaped_uri @backend;
parts/static-stuff-new.conf:47:	try_files		$uri $escaped_uri $unescaped_uri @backend;
parts/static-stuff-new.conf:59:	try_files		$uri $escaped_uri @backendCache-alljs;
parts/static-stuff-new.conf:117:	try_files		$uri $escaped_uri @backend @accessTicketFailback;
parts/static-stuff-new.conf:124:	try_files		$uri $escaped_uri @backend @accessTicketFailback;

всё ради того, чтобы какие-то адские бубны, чтобы пробел и подчёркивание заменить на %20 %5F и наоборот…

больше NJS ни для чего не нужен, но все воркеры, которые жрали сидели примерно в этих местах:

0x00007ffac2a7e4cb in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
(gdb) bt
#0  0x00007ffac2a7e4cb in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#1  0x00007ffac2a552ba in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#2  0x00007ffac2a555ec in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#3  0x00007ffac2a54343 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#4  0x00007ffac2a54775 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#5  0x00007ffac2a561c2 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#6  0x00007ffac2a56440 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#7  0x00007ffac2a54343 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#8  0x00007ffac2a54775 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#9  0x00007ffac2a39b53 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#10 0x00007ffac2a54343 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#11 0x00007ffac2a329c8 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#12 0x00007ffac2a2a218 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#13 0x0000556030cef6a5 in ngx_http_get_indexed_variable ()
#14 0x0000556030cf0695 in ngx_http_script_copy_var_len_code ()
#15 0x0000556030cf269d in ngx_http_script_complex_value_code ()
#16 0x0000556030d26ec5 in ?? ()
#17 0x0000556030cdefbc in ngx_http_core_rewrite_phase ()
#18 0x0000556030cdaa3d in ngx_http_core_run_phases ()
#19 0x0000556030ce5b3f in ?? ()
#20 0x0000556030ce5f14 in ?? ()
#21 0x0000556030ccd6ae in ?? ()
#22 0x0000556030cc3bf6 in ngx_process_events_and_timers ()
#23 0x0000556030ccb951 in ?? ()
#24 0x0000556030cc9e7b in ngx_spawn_process ()
#25 0x0000556030ccb010 in ?? ()
#26 0x0000556030ccc327 in ngx_master_process_cycle ()
#27 0x0000556030ca330e in main ()
(gdb)

#0  0x00007ffac3eaa28a in ?? () from target:/lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffac3eaa73b in ?? () from target:/lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffac3eab759 in ?? () from target:/lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffac3eacdc8 in posix_memalign () from target:/lib/x86_64-linux-gnu/libc.so.6
#4  0x00007ffac2a8ad85 in njs_memalign () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#5  0x00007ffac2a7f735 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#6  0x00007ffac2a7fa06 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#7  0x00007ffac2a42aeb in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#8  0x00007ffac2a5520b in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#9  0x00007ffac2a555ec in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#10 0x00007ffac2a54343 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#11 0x00007ffac2a54775 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#12 0x00007ffac2a561c2 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#13 0x00007ffac2a56440 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#14 0x00007ffac2a54343 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#15 0x00007ffac2a54775 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#16 0x00007ffac2a39b53 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#17 0x00007ffac2a54343 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#18 0x00007ffac2a329c8 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#19 0x00007ffac2a2a218 in ?? () from target:/usr/lib/nginx/modules/ngx_http_js_module.so
#20 0x0000556030cef6a5 in ngx_http_get_indexed_variable ()
#21 0x0000556030cf0695 in ngx_http_script_copy_var_len_code ()
#22 0x0000556030cf269d in ngx_http_script_complex_value_code ()
#23 0x0000556030d26ec5 in ?? ()
#24 0x0000556030cdefbc in ngx_http_core_rewrite_phase ()
#25 0x0000556030cdaa3d in ngx_http_core_run_phases ()
#26 0x0000556030ce5b3f in ?? ()
#27 0x0000556030ce5f14 in ?? ()
#28 0x0000556030ccd6ae in ?? ()
#29 0x0000556030cc3bf6 in ngx_process_events_and_timers ()
#30 0x0000556030ccb951 in ?? ()
#31 0x0000556030cc9e7b in ngx_spawn_process ()
#32 0x0000556030ccb010 in ?? ()
#33 0x0000556030ccc327 in ngx_master_process_cycle ()
#34 0x0000556030ca330e in main ()

в общем, так мы исследовали каждого жруна — везде примерно одна и та же картина

когда они все пердохли нажравшись как комары, сервер отпустило

выкинули NJS куски — перезагрузились для чистоты эксперимента
20 минут — полёт нормальный

и вот что это было? как эти 2 детские функции сожрали всю память?.. вопрос

то что проблема с модулем NJS есть — факт

но самое главное, мы не знаем точно как выпилить этот артефакт, или чем его заменить в идеале…
чем может грозить его выпиливание
явно же это что-то древнее, может и не нужное уже

можно пропатчить всю многомилионную нашу хранилку, но чего там ожидать, чего ждёт nginx в каком виде пути?

но на всякий случай, может есть версия как-то это нативно переписать для конфига без всяких языков и модулей?
какие есть рекомендации? (совсем выкидывать всё же стрёмно…)


> On 31 Aug 2020, at 19:41, Maxim Dounin <mdounin на mdounin.ru> wrote:
> 
> Hello!
> 
> On Mon, Aug 31, 2020 at 04:48:36PM +0300, Alexey Galygin wrote:
> 
>> мы запросили у организации, которая занимается DDoS Protection
>> список всех запросов за интервал теста
>> 
>> пытаемся по этим ссылкам ходить скриптом…
>> 
>> на штатный resize пришлось не более 800 запросов за всё время эксперимента, вряд ли бы это забило всю память
>> (файлики jpg они маленькие, ну допустим текло по 1 Мб на запрос, ну утёк бы 1 Гб за 5 минут, а не 300…)
>> 
>> ну и точно такой же nginx 1.18.0 на эталонном сервере так не утекает
>> 
>> изменилось в стенде только — Ubuntu — была 16.04 стала 20.04 (тут я подозреваю, сменился аллокатор памяти, что-то с FS подкрутили, может дескрипторы если не утекают, то кэш избыточный накапливается в ОЗУ)
>> память — было 192 — стало 256
>> FS как была ext4 так и осталась ext4…
>> ЦОД — было нормальное железо — стала платформа VMWare Cloud Director… на вид работает даже шустрее
> 
> Это называется "сменилось примерно всё".
> Я бы начал с простого:
> 
> 0. Внимательно изучил конфигурацию.
> 
> Простая оценка максимального потребления памяти рабочим процессом: 
> worker_connections * (сумма всех буферов в конфиге).  Стандартные 
> размеры буферов невелики, и сумму всех можно смело считать как 
> "меньше одного мегабайта", если в конфиге задано что-то иное - 
> соответственно прибавлять.  Относительно большие размерыы буферов 
> встречаются только в image-фильтре (image_filter_buffer 1m) и mp4 
> (mp4_max_buffer_size 10m).
> 
> Нюанс: простая оценка не работает, если используются подзапросы 
> (SSI, cache background update, и так далее - каждый подзапрос 
> может иметь свои буфера, соответственно надо умножать на 
> количество подзапросов в одном соединении) и/или HTTP/2 (умножать 
> на http2_max_concurrent_streams + http2_max_concurrent_pushes).
> 
> Если результат больше или сравним с наблюдаемым потреблением 
> памяти - то чинить конфигурацию, если заметно больше - то искать 
> дальше.
> 
> Если я правильно помню приведённые фрагменты конфига, то там 4096 
> worker_connections, буферов мегабайта на 2 минимум, используется 
> background update.  Если HTTP/2 не используется, то общее 
> потребление памяти в пределе будет 4096 * 2m * 2 == 16 гигабайт.  
> Это меньше, чем наблюдается, но не сильно.  Что уже наводит на 
> всяческие мысли.  Если же ещё и HTTP/2 используется - то один 
> рабочий процесс может занимать до пары терабайт, что явно не 
> соответствует возможностям машины.
> 
> То есть в принципе все наблюдаемые эффекты могут просто 
> объясняться конфигурацией и характером нагрузки, без всяких 
> утечек.  Можно попробовать отключить HTTP/2, если вдруг 
> используется, и/или покрутить размеры буферов вниз.  Ну и 
> количество рабочих процессов тоже.
> 
> Отдельный вопрос - почему не наблюдаются такие же или близкие 
> размеры рабочих процессов на старом сервере.  Если конфигурации 
> полностью совпадают - возможно, причина в несколько другом 
> характере нагрузки, в частности - из-за смены ядра и платформы.  
> Меня, в частности, сильно смущает, что все рабочие процессы в 
> состоянии "D", смотреть стоит на дисковую подсистему.
> 
> 1. Если есть какие-то сторонние модули - исключил их из конфига 
> (или сборки, если они собраны статически), и убедился, что 
> проблема воспроизводится.  Если модули очень нужны - то можно 
> попробовать переписать конфиг так, чтобы вынести их в отдельный 
> инстанс nginx'а.
> 
> 2. Если в конфиге используется скриптовый код - perl, njs, 
> whatever - то этот код может потреблять произвольный объём памяти, 
> даже если код кажется простым.  Опять же, лучше всего попробовать 
> воспроизвести проблему без этого кода.
> 
> Ну и логи таки имеет смысл почитать, дабы точно понимать, что 
> происходит, а не строить предположения.
> 
> [...]
> 
> -- 
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200901/7e6b5af2/attachment-0001.htm>