From konstantin на symbi.org  Fri Jun  2 02:47:44 2017
From: konstantin на symbi.org (Konstantin Baryshnikov)
Date: Fri, 2 Jun 2017 05:47:44 +0300
Subject: client_body_temp_path - permissions
In-Reply-To: <05065dac6ac84393441b953568b67578.NginxMailingListRussian@forum.nginx.org>
References: <aed3b273247f091ac8c47ce34df66536.NginxMailingListRussian@forum.nginx.org>
 <05065dac6ac84393441b953568b67578.NginxMailingListRussian@forum.nginx.org>
Message-ID: <52E82A0C-B962-43F8-8FFF-29DA5911FA2D@symbi.org>

> 
> On May 31, 2017, at 12:35 AM, S.A.N <nginx-forum на forum.nginx.org> wrote:
> 
> Я конечно извиняюсь, за настойчивость, но неужели пермишен 0600, на файл
> который должен быть обработан в другом процессе, это нормально и это никак
> нельзя настроить в конфиге Nginx?

Нельзя.

Я по большой нужде обходился вот таким патчем:

diff --git a/src/http/ngx_http_core_module.c b/src/http/ngx_http_core_module.c
--- a/src/http/ngx_http_core_module.c
+++ b/src/http/ngx_http_core_module.c
@@ -386,6 +386,13 @@
       offsetof(ngx_http_core_loc_conf_t, client_body_in_single_buffer),
       NULL },

+    { ngx_string("client_body_file_group_access"),
+      NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_CONF_FLAG,
+      ngx_conf_set_flag_slot,
+      NGX_HTTP_LOC_CONF_OFFSET,
+      offsetof(ngx_http_core_loc_conf_t, client_body_file_group_access),
+      NULL },
+
     { ngx_string("sendfile"),
       NGX_HTTP_MAIN_CONF|NGX_HTTP_SRV_CONF|NGX_HTTP_LOC_CONF|NGX_HTTP_LIF_CONF
                         |NGX_CONF_FLAG,
@@ -1462,6 +1469,7 @@
     }

     r->request_body_in_single_buf = clcf->client_body_in_single_buffer;
+    r->request_body_file_group_access = clcf->client_body_file_group_access;

     if (r->keepalive) {
         if (clcf->keepalive_timeout == 0) {
@@ -3571,6 +3579,7 @@
     clcf->max_ranges = NGX_CONF_UNSET_UINT;
     clcf->client_body_in_file_only = NGX_CONF_UNSET_UINT;
     clcf->client_body_in_single_buffer = NGX_CONF_UNSET;
+    clcf->client_body_file_group_access = NGX_CONF_UNSET;
     clcf->internal = NGX_CONF_UNSET;
     clcf->sendfile = NGX_CONF_UNSET;
     clcf->sendfile_max_chunk = NGX_CONF_UNSET_SIZE;
@@ -3792,6 +3801,8 @@
                               NGX_HTTP_REQUEST_BODY_FILE_OFF);
     ngx_conf_merge_value(conf->client_body_in_single_buffer,
                               prev->client_body_in_single_buffer, 0);
+    ngx_conf_merge_value(conf->client_body_file_group_access,
+                              prev->client_body_file_group_access, 0);
     ngx_conf_merge_value(conf->internal, prev->internal, 0);
     ngx_conf_merge_value(conf->sendfile, prev->sendfile, 0);
     ngx_conf_merge_size_value(conf->sendfile_max_chunk,
diff --git a/src/http/ngx_http_core_module.h b/src/http/ngx_http_core_module.h
--- a/src/http/ngx_http_core_module.h
+++ b/src/http/ngx_http_core_module.h
@@ -402,6 +402,7 @@
     ngx_uint_t    server_tokens;           /* server_tokens */
     ngx_flag_t    chunked_transfer_encoding; /* chunked_transfer_encoding */
     ngx_flag_t    etag;                    /* etag */
+    ngx_flag_t    client_body_file_group_access; /* client_body_file_group_access */

 #if (NGX_HTTP_GZIP)
     ngx_flag_t    gzip_vary;               /* gzip_vary */

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


From nginx-forum на forum.nginx.org  Fri Jun  2 07:06:08 2017
From: nginx-forum на forum.nginx.org (ingtar)
Date: Fri, 02 Jun 2017 03:06:08 -0400
Subject: =?UTF-8?B?0J3QtSDQv9C+0LvQvdC+0YHRgtGM0Y4g0L7RgtC00LDQtdGC0YHRjyDRhNCw0Lk=?=
 =?UTF-8?B?0Lsg0LrQu9C40LXQvdGC0YM=?=
Message-ID: <c2e12e428f128ea2aa917c2235d030a6.NginxMailingListRussian@forum.nginx.org>

Добрый день!
Столкнулся с непонятной проблемой. Имеется сервер для раздачи файлов
клиентам. При большом кол-ве запросов иногда начинают происходить следующие
вещи на стороне клиента - скачиваемый файл (через curl) отдается меньшего
размера но ответ 200
В утилите siege при 100 конкурентных пользователях выглядит так:

HTTP/1.1 200    26.85 secs: 13925686 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    27.62 secs: 13925686 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    28.38 secs: 13925686 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    29.20 secs: 13925686 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    29.96 secs: 13925686 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    30.79 secs: 13925686 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    31.54 secs: 13925686 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    91.80 secs: 11313152 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    91.82 secs:  249483 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    91.84 secs:  270971 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    91.86 secs:  257541 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    91.88 secs:  265599 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml
HTTP/1.1 200    91.89 secs:  262913 bytes ==> GET 
/test/212879312926726118532324622460834138521.xml

Как видно из времени ответа - он начинает держать клиента и потом закрывает
коннект с 200 кодом. 
Дебаг лог мне не помог, могу его приложить но он очень большой и найти
именно проблемный коннект не получилось

Конфиг очень большой, но вот урезанный вариант с локейшеном
server {
    listen 80 default_server;
    listen 443 ssl http2;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH
EDH+aRSA !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

    keepalive_timeout 40 40;
    keepalive_requests 500;

    ssl_certificate_key example.key;
    ssl_certificate example.crt;

    error_log   /var/log/nginx/error.log debug;
    access_log  /var/log/nginx/access.log;


    add_header Cache-Control  'public, max-age=315360000';
    add_header Expires   'Tue, 15 Nov 2986 11:00:00 GMT';


    location /test/ {
        error_log /var/log/nginx/test-error.log;
        access_log off;
        root /var/local/storage/ru;
        rewrite '^/test/([0-9]*)(\d{2})(\d{2})(\d{2})\.(xml|xls|xlsx|xlsm)'
/test/$4/$3/$2/$1$2$3$4.$5 break;
    }
}

В какую сторону можно посмотреть?..

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


From nginx-forum на forum.nginx.org  Fri Jun  2 10:04:12 2017
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Fri, 02 Jun 2017 06:04:12 -0400
Subject: client_body_temp_path - permissions
In-Reply-To: <52E82A0C-B962-43F8-8FFF-29DA5911FA2D@symbi.org>
References: <52E82A0C-B962-43F8-8FFF-29DA5911FA2D@symbi.org>
Message-ID: <e08eb50fd19146fc36ad8cdbe8095830.NginxMailingListRussian@forum.nginx.org>

Konstantin Baryshnikov Wrote:
-------------------------------------------------------
> > 
> > On May 31, 2017, at 12:35 AM, S.A.N <nginx-forum на forum.nginx.org>
> wrote:
> > 
> > Я конечно извиняюсь, за настойчивость, но неужели пермишен 0600, на
> файл
> > который должен быть обработан в другом процессе, это нормально и это
> никак
> > нельзя настроить в конфиге Nginx?
> 
> Нельзя.
> 
> Я по большой нужде обходился вот таким патчем:
> 

Спасибо, но проблема ручных патчей в будущей поддержке, нужно не забывать
всегда патчить новые версии Nginx, и потом тестировать...
Будет очень хорошо если его закомитят и будет работать из коробки.

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


From mdounin на mdounin.ru  Fri Jun  2 11:14:31 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 2 Jun 2017 14:14:31 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC70L3QvtGB0YLRjNGOINC+0YLQtNCw0LXRgtGB0Y8g0YQ=?=
 =?UTF-8?B?0LDQudC7INC60LvQuNC10L3RgtGD?=
In-Reply-To: <c2e12e428f128ea2aa917c2235d030a6.NginxMailingListRussian@forum.nginx.org>
References: <c2e12e428f128ea2aa917c2235d030a6.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170602111431.GQ55433@mdounin.ru>

Hello!

On Fri, Jun 02, 2017 at 03:06:08AM -0400, ingtar wrote:

> Добрый день!
> Столкнулся с непонятной проблемой. Имеется сервер для раздачи файлов
> клиентам. При большом кол-ве запросов иногда начинают происходить следующие
> вещи на стороне клиента - скачиваемый файл (через curl) отдается меньшего
> размера но ответ 200
> В утилите siege при 100 конкурентных пользователях выглядит так:
> 
> HTTP/1.1 200    26.85 secs: 13925686 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    27.62 secs: 13925686 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    28.38 secs: 13925686 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    29.20 secs: 13925686 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    29.96 secs: 13925686 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    30.79 secs: 13925686 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    31.54 secs: 13925686 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    91.80 secs: 11313152 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    91.82 secs:  249483 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    91.84 secs:  270971 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    91.86 secs:  257541 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    91.88 secs:  265599 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> HTTP/1.1 200    91.89 secs:  262913 bytes ==> GET 
> /test/212879312926726118532324622460834138521.xml
> 
> Как видно из времени ответа - он начинает держать клиента и потом закрывает
> коннект с 200 кодом. 
> Дебаг лог мне не помог, могу его приложить но он очень большой и найти
> именно проблемный коннект не получилось

Для начала отмечу, что 200 - это код ответа, который отправляется 
клиенту в самом начале, вместе с заголовками ответа.  Любые 
ошибки, которые происходят после этого, на код ответа не влияют.  
Чтобы узнать, были они или нет, нужно смотреть в лог ошибок.

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

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

From pavel2000 на ngs.ru  Fri Jun  2 12:23:12 2017
From: pavel2000 на ngs.ru (Pavel V.)
Date: Fri, 2 Jun 2017 19:23:12 +0700
Subject: client_body_temp_path - permissions
In-Reply-To: <e08eb50fd19146fc36ad8cdbe8095830.NginxMailingListRussian@forum.nginx.org>
References: <52E82A0C-B962-43F8-8FFF-29DA5911FA2D@symbi.org>
 <e08eb50fd19146fc36ad8cdbe8095830.NginxMailingListRussian@forum.nginx.org>
Message-ID: <176253693.20170602192312@ngs.ru>

Здравствуйте

> Спасибо, но проблема ручных патчей в будущей поддержке, нужно не забывать
> всегда патчить новые версии Nginx, и потом тестировать...
> Будет очень хорошо если его закомитят и будет работать из коробки.

Как-то не вполне ясно, почему вы считаете, что файл в client_body_temp_path

>должен быть обработан в другом процессе

Это временный файл процесса nginx, и, насколько я понимаю, никакая обработка в
других процессах не предусматривается. В силу этого же права выставлены в 0600 и
другого быть не может.


-- 
С уважением,
 Pavel                          mailto:pavel2000 на ngs.ru


From nginx-forum на forum.nginx.org  Fri Jun  2 14:49:04 2017
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Fri, 02 Jun 2017 10:49:04 -0400
Subject: client_body_temp_path - permissions
In-Reply-To: <176253693.20170602192312@ngs.ru>
References: <176253693.20170602192312@ngs.ru>
Message-ID: <d4f79df71c5d9a1d738cd12aa656ba25.NginxMailingListRussian@forum.nginx.org>

> Это временный файл процесса nginx, и, насколько я понимаю, никакая
> обработка в
> других процессах не предусматривается. В силу этого же права
> выставлены в 0600 и
> другого быть не может.

Временный файлы процесса Nginx, создаются без директивы
client_body_temp_path.

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

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


From nginx-forum на forum.nginx.org  Fri Jun  2 15:02:46 2017
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Fri, 02 Jun 2017 11:02:46 -0400
Subject: client_body_temp_path - permissions
In-Reply-To: <d4f79df71c5d9a1d738cd12aa656ba25.NginxMailingListRussian@forum.nginx.org>
References: <176253693.20170602192312@ngs.ru>
 <d4f79df71c5d9a1d738cd12aa656ba25.NginxMailingListRussian@forum.nginx.org>
Message-ID: <966904ceac3952a678b1712ac3cf944e.NginxMailingListRussian@forum.nginx.org>

Я уточню чтобы меня понимали.

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

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


From pavel2000 на ngs.ru  Fri Jun  2 15:52:16 2017
From: pavel2000 на ngs.ru (Pavel V.)
Date: Fri, 2 Jun 2017 22:52:16 +0700
Subject: client_body_temp_path - permissions
In-Reply-To: <966904ceac3952a678b1712ac3cf944e.NginxMailingListRussian@forum.nginx.org>
References: <176253693.20170602192312@ngs.ru>
 <d4f79df71c5d9a1d738cd12aa656ba25.NginxMailingListRussian@forum.nginx.org>
 <966904ceac3952a678b1712ac3cf944e.NginxMailingListRussian@forum.nginx.org>
Message-ID: <591201432.20170602225216@ngs.ru>

Здравствуйте.

> Я уточню чтобы меня понимали.

> Мы используем директиву - client_body_in_file_only clean; для получения
> файлов от клиента при аплодинге, указываем директорию в директиве
> client_body_temp_path, все работает хорошо, только пермишены файлов в этой
> папке 0600.

Да, теперь увидел информацию об этой возможности.

В описании директивы "client_body_temp_path" про такую возможность не сказано ни
слова. 

При наличии директивы "client_body_in_file_only" и переменной
"request_body_file" ограничение 0600 конечно излишне жесткое и вот это шаманство
в коде nginx:

  if (r->request_body_file_group_access) {
      tf->access = 0660;
  }

выглядит несколько забавно.

Т.е. директиву client_body_in_file_only и переменную $request_body_file добавили, а
прав на файлы - добавить забыли.

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

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

> Спасибо, но проблема ручных патчей в будущей поддержке, нужно не забывать
> всегда патчить новые версии Nginx, и потом тестировать...
> Будет очень хорошо если его закомитят и будет работать из коробки.

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


-- 
С уважением,
 Pavel                          mailto:pavel2000 на ngs.ru


From nginx-forum на forum.nginx.org  Fri Jun  2 16:26:34 2017
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Fri, 02 Jun 2017 12:26:34 -0400
Subject: client_body_temp_path - permissions
In-Reply-To: <591201432.20170602225216@ngs.ru>
References: <591201432.20170602225216@ngs.ru>
Message-ID: <1b115132817f75d77690b56c84426a9f.NginxMailingListRussian@forum.nginx.org>

> Т.е. директиву client_body_in_file_only и переменную
> $request_body_file добавили, а
> прав на файлы - добавить забыли.

Да, в интернете многие задаются вопросом почему сделано это так, похоже что
просто забыли учитывать client_body_in_file_only.

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


From konstantin на symbi.org  Sat Jun  3 00:33:16 2017
From: konstantin на symbi.org (Konstantin Baryshnikov)
Date: Sat, 3 Jun 2017 03:33:16 +0300
Subject: client_body_temp_path - permissions
In-Reply-To: <e08eb50fd19146fc36ad8cdbe8095830.NginxMailingListRussian@forum.nginx.org>
References: <52E82A0C-B962-43F8-8FFF-29DA5911FA2D@symbi.org>
 <e08eb50fd19146fc36ad8cdbe8095830.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CA6FD3C8-F09C-48B5-BAD7-698212182969@symbi.org>

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

> On Jun 2, 2017, at 1:04 PM, S.A.N <nginx-forum на forum.nginx.org> wrote:
> 
> Konstantin Baryshnikov Wrote:
> -------------------------------------------------------
>>> 
>>> On May 31, 2017, at 12:35 AM, S.A.N <nginx-forum на forum.nginx.org>
>> wrote:
>>> 
>>> Я конечно извиняюсь, за настойчивость, но неужели пермишен 0600, на
>> файл
>>> который должен быть обработан в другом процессе, это нормально и это
>> никак
>>> нельзя настроить в конфиге Nginx?
>> 
>> Нельзя.
>> 
>> Я по большой нужде обходился вот таким патчем:
>> 
> 
> Спасибо, но проблема ручных патчей в будущей поддержке, нужно не забывать
> всегда патчить новые версии Nginx, и потом тестировать...
> Будет очень хорошо если его закомитят и будет работать из коробки.
> 
> Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274059,274602#msg-274602
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


From nginx-forum на forum.nginx.org  Sat Jun  3 10:51:31 2017
From: nginx-forum на forum.nginx.org (S.A.N)
Date: Sat, 03 Jun 2017 06:51:31 -0400
Subject: client_body_temp_path - permissions
In-Reply-To: <CA6FD3C8-F09C-48B5-BAD7-698212182969@symbi.org>
References: <CA6FD3C8-F09C-48B5-BAD7-698212182969@symbi.org>
Message-ID: <24bb463c134227315a92c9c21c2bf6fb.NginxMailingListRussian@forum.nginx.org>

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

Спасибо за патч, но мы не можем прописывать в требования нашего ПО,
установку патча для Nginx, клиенты этого не поймут.

Сейчас мы запускаем бекенд под пользователем Nginx, чтобы иметь доступ к
файлам 0600, но это тоже не очень хорошо.

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


From vbart на nginx.com  Mon Jun  5 13:51:27 2017
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Mon, 05 Jun 2017 16:51:27 +0300
Subject: =?UTF-8?B?UmU6INCc0LDRgdGB0LjRgNC+0LLQsNC90L3Ri9C5IHJld3JpdGUg0LjQu9C4IG1h?=
 =?UTF-8?B?cCA/?=
In-Reply-To: <3c712a7ee752f1fad7f925f9a96b298a.NginxMailingListRussian@forum.nginx.org>
References: <3c712a7ee752f1fad7f925f9a96b298a.NginxMailingListRussian@forum.nginx.org>
Message-ID: <2144497.30tVUxAHVL@vbart-workstation>

On Tuesday 30 May 2017 10:53:32 Dee Dee wrote:
> Добрый день всем.
> 
> У меня возникла проблема на, казалось бы, простой задаче. У меня есть
> порядка 300 штук редиректов в разделе блог вида:
> 
> /blog?page=post&blog=blog_EN&id=298  
> /blog/topic1-theme-for-russian-speakers/	
> /blog?page=post&blog=blog_RU&id=300   /blog/webinar-new-staff/
> 
> Как я понимаю, тут location это "blog" а далее пошли уже $args. 
> У меня получилось сделать это через map вида:
> 
> map $args $link {
>         "blog?page=post&blog=blog_EN&id=300" "/blog/webinar-new-staff/";
>          ....
>         default "/blog/";
> }
> 
> и 
> 
> if ($args) {
>                 return 301 $scheme://$host$link;
> }
> 
> Всё работает. Но map из трёхсот записей кажется мне громоздким. 
> Есть ли какие-либо варианты решения задачи, которые более элегантны, чем мой
> ?
> 
> Заранее большое спасибо!
> 

Порядок следования параметров может быть любым, например данные запросы
эквивалентны:

 /blog?page=post&blog=blog_EN&id=298

 /blog?id=298&blog=blog_EN&page=post

 /blog?blog=blog_EN&page=post&id=298 

 /blog?id=298&page=post&blog=blog_EN

 /blog?blog=blog_EN&id=298&page=post

 /blog?page=post&id=298&blog=blog_EN

так что map из 300 записей тут будет мало.

Лучше делать это в приложении.

--
Валентин Бартенев

From vladget на gmail.com  Mon Jun  5 15:36:45 2017
From: vladget на gmail.com (Vladimir Getmanshchuk)
Date: Mon, 05 Jun 2017 15:36:45 +0000
Subject: =?UTF-8?B?UmU6INCc0LDRgdGB0LjRgNC+0LLQsNC90L3Ri9C5IHJld3JpdGUg0LjQu9C4IG1h?=
 =?UTF-8?B?cCA/?=
In-Reply-To: <1828881496157317@web6o.yandex.ru>
References: <3c712a7ee752f1fad7f925f9a96b298a.NginxMailingListRussian@forum.nginx.org>
 <1828881496157317@web6o.yandex.ru>
Message-ID: <CAMxcU5JQAhoHGJ7j4Aih1NA=rH5B6xC0YmAW2V3JYXw10nRmFw@mail.gmail.com>

На бэкенде дорого, это форки и tcp оверхед, плюс наверно нагрузка на базу..

Я бы оставил map

вт, 30 трав. 2017 о 18:15 Konstantin Tokarev <annulen на yandex.ru> пише:

>
>
> 30.05.2017, 17:53, "Dee Dee" <nginx-forum на forum.nginx.org>:
> > Добрый день всем.
> >
> > У меня возникла проблема на, казалось бы, простой задаче. У меня есть
> > порядка 300 штук редиректов в разделе блог вида:
> >
> > /blog?page=post&blog=blog_EN&id=298
> > /blog/topic1-theme-for-russian-speakers/
> > /blog?page=post&blog=blog_RU&id=300 /blog/webinar-new-staff/
> >
> > Как я понимаю, тут location это "blog" а далее пошли уже $args.
> > У меня получилось сделать это через map вида:
> >
> > map $args $link {
> >         "blog?page=post&blog=blog_EN&id=300" "/blog/webinar-new-staff/";
> >          ....
> >         default "/blog/";
> > }
> >
> > и
> >
> > if ($args) {
> >                 return 301 $scheme://$host$link;
> > }
> >
> > Всё работает. Но map из трёхсот записей кажется мне громоздким.
> > Есть ли какие-либо варианты решения задачи, которые более элегантны, чем
> мой
> > ?
>
> В бэкэнде это делать
>
> >
> > Заранее большое спасибо!
> >
> > Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,274512,274512#msg-274512
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> --
> Regards,
> Konstantin
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Yours sincerely,
Vladimir Getmanshchuk
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170605/c8c6820a/attachment.html>

From sergeyk на jfrog.com  Tue Jun  6 13:12:20 2017
From: sergeyk на jfrog.com (Sergey Kagansky)
Date: Tue, 6 Jun 2017 16:12:20 +0300
Subject: real_ip on Azure Cloud + Application Gateway
Message-ID: <CAJLdeebdXwb1cvweOW4jt=iOra6JcmJsxjEhq526Hi9eknHGfg@mail.gmail.com>

Добрый день!
Пользуемся Nginx в облаке Azure
В качестве лоадбалансера перед несколькими Nginx серверами используем
Application Gateway.
Проблема в том, что он в заголовке X-Forwarded-For передаёт IP:PORT (пример
ниже)
Вопрос: можно это как то излечить и получить в логах Nginx правильный адрес
клиента, потому как в данной ситуации Nginx подставляет адрес балансера
который передается без порта

X-FORWARDED-PROTO: https
X-FORWARDED-PORT: 443
*X-Forwarded-For: 13.93.225.14:1217 <http://13.93.225.14:1217>*

Заранее всем благодарен

-- 
 <https://goo.gl/iqC1cD>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170606/ddac1c5b/attachment.html>

From mdounin на mdounin.ru  Tue Jun  6 13:33:52 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 6 Jun 2017 16:33:52 +0300
Subject: real_ip on Azure Cloud + Application Gateway
In-Reply-To: <CAJLdeebdXwb1cvweOW4jt=iOra6JcmJsxjEhq526Hi9eknHGfg@mail.gmail.com>
References: <CAJLdeebdXwb1cvweOW4jt=iOra6JcmJsxjEhq526Hi9eknHGfg@mail.gmail.com>
Message-ID: <20170606133352.GG55433@mdounin.ru>

Hello!

On Tue, Jun 06, 2017 at 04:12:20PM +0300, Sergey Kagansky wrote:

> Добрый день!
> Пользуемся Nginx в облаке Azure
> В качестве лоадбалансера перед несколькими Nginx серверами используем
> Application Gateway.
> Проблема в том, что он в заголовке X-Forwarded-For передаёт IP:PORT (пример
> ниже)
> Вопрос: можно это как то излечить и получить в логах Nginx правильный адрес
> клиента, потому как в данной ситуации Nginx подставляет адрес балансера
> который передается без порта
> 
> X-FORWARDED-PROTO: https
> X-FORWARDED-PORT: 443
> *X-Forwarded-For: 13.93.225.14:1217 <http://13.93.225.14:1217>*

Если вы используете актуальную версию nginx'а, то всё должно 
работать со штатным модулем realip.  Порты в X-Forwarded-For 
поддерживаются начиная с nginx 1.11.0, см.  
http://nginx.org/ru/docs/http/ngx_http_realip_module.html.

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

From yorick на ya.ru  Tue Jun  6 13:42:27 2017
From: yorick на ya.ru (Yury Lyakh)
Date: Tue, 6 Jun 2017 15:42:27 +0200
Subject: =?UTF-8?B?bmdpbngg0LrQsNGH0LDQtdGCINC+0LTQuNC9INC4INGC0L7RgiDQttC1INGE0LA=?=
 =?UTF-8?B?0LnQuyDQsiDQvdC10YHQutC+0LvRjNC60L4g0LrQvtC90L3QtdC60YLQvtCy?=
 =?UTF-8?B?INGBINCx0Y3QutC10L3QtNCw?=
Message-ID: <A4C5CCB7-598B-43A5-BDF0-FD5455C14A1B@ya.ru>

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

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

применили:
proxy_cache_lock on;
и
proxy_cache_use_stale updating;
но ситуация не изменилась, все равно качается в множество нитей

Почистили полностью машину от временных файлов (temp файлы закачки находятся в кеше use_temp_path=off).
Запустили трафик, буквально через 10 секунд прошелся по кешу в поиске временных файлов, чтобы посмотреть их KEY в заголовке, видим что одновременно создались и качаются 177 временных файлов для одного по сути файла:

[root на upload-3 cache]# find -L ./ -type f -iname '*\.[0-9]*' | xargs head -n2 | grep -a ^KEY | sort | uniq -c
    177 KEY: /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001

самы файлы выглядят как:
...
-rw------- 1 nginx nginx  205168640 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000253
-rw------- 1 nginx nginx  209281024 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000254
-rw------- 1 nginx nginx  286048256 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000255
-rw------- 1 nginx nginx  671723520 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000257
-rw------- 1 nginx nginx  217743360 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000258
-rw------- 1 nginx nginx  239915008 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000259
-rw------- 1 nginx nginx  635768832 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000261
....


версия nginx-1.13.1

конфиг:
proxy_cache_path /var/lib/nginx/cache/wop  levels=2:2 keys_zone=wop:20m inactive=2d use_temp_path=off;

server {
    listen 80;
    listen [::]:80;
    server_name dl-share.wop.net <http://dl-share.wop.net/>;

    proxy_cache wop;
    proxy_ignore_client_abort on;

    location / {
        proxy_pass http://dl.wop.net <http://dl.wop.net/>;
        proxy_set_header Host       $proxy_host;
        proxy_cache_lock on;
        proxy_cache_lock_age 1d;
        proxy_cache_lock_timeout 1d;
        proxy_cache_use_stale error updating;
        proxy_cache_key "$uri";
        proxy_cache_revalidate on;
        proxy_cache_valid 404 10s;
        proxy_cache_valid 200 1h;
    }
}

запросы с которыми идут пользователи:

"195.242.151.17" "-" "-" "[06/Jun/2017:13:03:28 +0000]" "GET /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1" "206" "0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" "dl-share.wop.net <http://dl-share.wop.net/>" "81.114" "81.114" "235" "bytes=1744977920-1745043455" "[gn]" "MISS" "42008576" "91.213.124.60:80" "0" "0" "-" "-"
"195.242.151.17" "-" "-" "[06/Jun/2017:13:03:26 +0000]" "GET /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1" "206" "0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" "dl-share.wop.net <http://dl-share.wop.net/>" "121.167" "121.167" "235" "bytes=2059403264-2059468799" "[gn]" "MISS" "42008576" "91.213.124.60:80" "0" "0" "-" "-"

Ткните пожалуйста в документацию где я не дочитал, что вообще происходит?..
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170606/9eeaa53b/attachment-0001.html>

From mdounin на mdounin.ru  Wed Jun  7 19:37:28 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 7 Jun 2017 22:37:28 +0300
Subject: =?UTF-8?B?UmU6IG5naW54INC60LDRh9Cw0LXRgiDQvtC00LjQvSDQuCDRgtC+0YIg0LbQtSA=?=
 =?UTF-8?B?0YTQsNC50Lsg0LIg0L3QtdGB0LrQvtC70YzQutC+INC60L7QvdC90LXQutGC?=
 =?UTF-8?B?0L7QsiDRgSDQsdGN0LrQtdC90LTQsA==?=
In-Reply-To: <A4C5CCB7-598B-43A5-BDF0-FD5455C14A1B@ya.ru>
References: <A4C5CCB7-598B-43A5-BDF0-FD5455C14A1B@ya.ru>
Message-ID: <20170607193728.GT55433@mdounin.ru>

Hello!

On Tue, Jun 06, 2017 at 03:42:27PM +0200, Yury Lyakh wrote:

> День добрый, может кто сталкивался с проблемой закачки файлов с бэкенда параллельно в несколько потоков.
> 
> Есть мелкий конфиг ниже.
> Клиенты приходят с запросами ренжовыми и обычными, если файл отсутствует в кеше он начинает качаться с бэкенда, но качается во столько нитей сколько клиентов запросило файл. В итоге трафик на бэкенде растет в прогрессии и все закономерно встает через пару минут.
> 
> применили:
> proxy_cache_lock on;
> и
> proxy_cache_use_stale updating;
> но ситуация не изменилась, все равно качается в множество нитей
> 
> Почистили полностью машину от временных файлов (temp файлы закачки находятся в кеше use_temp_path=off).
> Запустили трафик, буквально через 10 секунд прошелся по кешу в поиске временных файлов, чтобы посмотреть их KEY в заголовке, видим что одновременно создались и качаются 177 временных файлов для одного по сути файла:
> 
> [root на upload-3 cache]# find -L ./ -type f -iname '*\.[0-9]*' | xargs head -n2 | grep -a ^KEY | sort | uniq -c
>     177 KEY: /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001
> 
> самы файлы выглядят как:
> ...
> -rw------- 1 nginx nginx  205168640 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000253
> -rw------- 1 nginx nginx  209281024 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000254
> -rw------- 1 nginx nginx  286048256 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000255
> -rw------- 1 nginx nginx  671723520 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000257
> -rw------- 1 nginx nginx  217743360 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000258
> -rw------- 1 nginx nginx  239915008 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000259
> -rw------- 1 nginx nginx  635768832 Jun  6 13:15 ./wop/1f/51/006afe023b4083e96128680af13b511f.0000000261
> ....
> 
> 
> версия nginx-1.13.1
> 
> конфиг:
> proxy_cache_path /var/lib/nginx/cache/wop  levels=2:2 keys_zone=wop:20m inactive=2d use_temp_path=off;
> 
> server {
>     listen 80;
>     listen [::]:80;
>     server_name dl-share.wop.net <http://dl-share.wop.net/>;
> 
>     proxy_cache wop;
>     proxy_ignore_client_abort on;
> 
>     location / {
>         proxy_pass http://dl.wop.net <http://dl.wop.net/>;
>         proxy_set_header Host       $proxy_host;
>         proxy_cache_lock on;
>         proxy_cache_lock_age 1d;
>         proxy_cache_lock_timeout 1d;
>         proxy_cache_use_stale error updating;
>         proxy_cache_key "$uri";
>         proxy_cache_revalidate on;
>         proxy_cache_valid 404 10s;
>         proxy_cache_valid 200 1h;
>     }
> }
> 
> запросы с которыми идут пользователи:
> 
> "195.242.151.17" "-" "-" "[06/Jun/2017:13:03:28 +0000]" "GET /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1" "206" "0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" "dl-share.wop.net <http://dl-share.wop.net/>" "81.114" "81.114" "235" "bytes=1744977920-1745043455" "[gn]" "MISS" "42008576" "91.213.124.60:80" "0" "0" "-" "-"
> "195.242.151.17" "-" "-" "[06/Jun/2017:13:03:26 +0000]" "GET /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1" "206" "0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" "dl-share.wop.net <http://dl-share.wop.net/>" "121.167" "121.167" "235" "bytes=2059403264-2059468799" "[gn]" "MISS" "42008576" "91.213.124.60:80" "0" "0" "-" "-"
> 
> Ткните пожалуйста в документацию где я не дочитал, что вообще происходит?..

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

В этом случае nginx обнаруживает проблему позже, чем возможно 
использование proxy_cache_lock.  Однако и вернуть клиенту 
существующий в кеше ответ в соответствии с "proxy_cache_use_stale 
updating" тоже нельзя, так как кеш-файл невозможно использовать.  В 
результате все запросы просто проксируются на бекенд, как если бы 
proxy_cache_lock не использовался.

В логе ошибок при этом будут сообщения про "cache file ..." на 
уровне crit в случае повреждённых кеш-файлов, и на уровне info в 
случае файлов устаревшего формата.

Если дело в этом, то очистка кеша от старых / повреждённых файлов 
должна помочь.  Рано или поздно это произойдёт само - если, 
конечно, что-то не портит файлы.

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

From basil на vpm.net.ua  Wed Jun  7 19:47:41 2017
From: basil на vpm.net.ua (Vasiliy P. Melnik)
Date: Wed, 7 Jun 2017 22:47:41 +0300
Subject: =?UTF-8?B?UmU6IG5naW54INC60LDRh9Cw0LXRgiDQvtC00LjQvSDQuCDRgtC+0YIg0LbQtSA=?=
 =?UTF-8?B?0YTQsNC50Lsg0LIg0L3QtdGB0LrQvtC70YzQutC+INC60L7QvdC90LXQutGC?=
 =?UTF-8?B?0L7QsiDRgSDQsdGN0LrQtdC90LTQsA==?=
In-Reply-To: <20170607193728.GT55433@mdounin.ru>
References: <A4C5CCB7-598B-43A5-BDF0-FD5455C14A1B@ya.ru>
 <20170607193728.GT55433@mdounin.ru>
Message-ID: <CAMPJU7D+GFo525k3hx0W0ecqJ4OboYJC-iXRHiV1wKdaG3UVuA@mail.gmail.com>

Похожая ситуация, только у меня скрипт картинки ресайзит. Если не менять
логику приложения и не писать очереди, то кроме как ограничить количество
сессий на бекэнд ничего умнее не придумал. Тогда клиент просто ждет, когда
ему отдадут картинку, но надо таймауты поднять, чтобы кеш разгонять
получалось.

7 июня 2017 г., 22:37 пользователь Maxim Dounin <mdounin на mdounin.ru>
написал:

> Hello!
>
> On Tue, Jun 06, 2017 at 03:42:27PM +0200, Yury Lyakh wrote:
>
> > День добрый, может кто сталкивался с проблемой закачки файлов с бэкенда
> параллельно в несколько потоков.
> >
> > Есть мелкий конфиг ниже.
> > Клиенты приходят с запросами ренжовыми и обычными, если файл отсутствует
> в кеше он начинает качаться с бэкенда, но качается во столько нитей сколько
> клиентов запросило файл. В итоге трафик на бэкенде растет в прогрессии и
> все закономерно встает через пару минут.
> >
> > применили:
> > proxy_cache_lock on;
> > и
> > proxy_cache_use_stale updating;
> > но ситуация не изменилась, все равно качается в множество нитей
> >
> > Почистили полностью машину от временных файлов (temp файлы закачки
> находятся в кеше use_temp_path=off).
> > Запустили трафик, буквально через 10 секунд прошелся по кешу в поиске
> временных файлов, чтобы посмотреть их KEY в заголовке, видим что
> одновременно создались и качаются 177 временных файлов для одного по сути
> файла:
> >
> > [root на upload-3 cache]# find -L ./ -type f -iname '*\.[0-9]*' | xargs
> head -n2 | grep -a ^KEY | sort | uniq -c
> >     177 KEY: /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.
> 001
> >
> > самы файлы выглядят как:
> > ...
> > -rw------- 1 nginx nginx  205168640 Jun  6 13:15 ./wop/1f/51/
> 006afe023b4083e96128680af13b511f.0000000253
> > -rw------- 1 nginx nginx  209281024 Jun  6 13:15 ./wop/1f/51/
> 006afe023b4083e96128680af13b511f.0000000254
> > -rw------- 1 nginx nginx  286048256 Jun  6 13:15 ./wop/1f/51/
> 006afe023b4083e96128680af13b511f.0000000255
> > -rw------- 1 nginx nginx  671723520 Jun  6 13:15 ./wop/1f/51/
> 006afe023b4083e96128680af13b511f.0000000257
> > -rw------- 1 nginx nginx  217743360 Jun  6 13:15 ./wop/1f/51/
> 006afe023b4083e96128680af13b511f.0000000258
> > -rw------- 1 nginx nginx  239915008 Jun  6 13:15 ./wop/1f/51/
> 006afe023b4083e96128680af13b511f.0000000259
> > -rw------- 1 nginx nginx  635768832 Jun  6 13:15 ./wop/1f/51/
> 006afe023b4083e96128680af13b511f.0000000261
> > ....
> >
> >
> > версия nginx-1.13.1
> >
> > конфиг:
> > proxy_cache_path /var/lib/nginx/cache/wop  levels=2:2 keys_zone=wop:20m
> inactive=2d use_temp_path=off;
> >
> > server {
> >     listen 80;
> >     listen [::]:80;
> >     server_name dl-share.wop.net <http://dl-share.wop.net/>;
> >
> >     proxy_cache wop;
> >     proxy_ignore_client_abort on;
> >
> >     location / {
> >         proxy_pass http://dl.wop.net <http://dl.wop.net/>;
> >         proxy_set_header Host       $proxy_host;
> >         proxy_cache_lock on;
> >         proxy_cache_lock_age 1d;
> >         proxy_cache_lock_timeout 1d;
> >         proxy_cache_use_stale error updating;
> >         proxy_cache_key "$uri";
> >         proxy_cache_revalidate on;
> >         proxy_cache_valid 404 10s;
> >         proxy_cache_valid 200 1h;
> >     }
> > }
> >
> > запросы с которыми идут пользователи:
> >
> > "195.242.151.17" "-" "-" "[06/Jun/2017:13:03:28 +0000]" "GET
> /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1"
> "206" "0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" "
> dl-share.wop.net <http://dl-share.wop.net/>" "81.114" "81.114" "235"
> "bytes=1744977920-1745043455" "[gn]" "MISS" "42008576" "91.213.124.60:80"
> "0" "0" "-" "-"
> > "195.242.151.17" "-" "-" "[06/Jun/2017:13:03:26 +0000]" "GET
> /ct/patches/wop_1.9.77.310044_ct/wop.ct_1.9.77.310044.pkg.001 HTTP/1.1"
> "206" "0" "-" "wdsa::Torrents/1.1 libtorrent/1.1.3.0" "0" "-" "http" "
> dl-share.wop.net <http://dl-share.wop.net/>" "121.167" "121.167" "235"
> "bytes=2059403264-2059468799" "[gn]" "MISS" "42008576" "91.213.124.60:80"
> "0" "0" "-" "-"
> >
> > Ткните пожалуйста в документацию где я не дочитал, что вообще
> происходит?..
>
> Такая картина - множество запросов к одному и тому же ресурсу на
> бекенде, не смотря на включённый proxy_cache_lock - может
> наблюдаться, если в кеше лежит повреждённый кеш-файл и/или
> кеш-файл со старым форматом заголовка.
>
> В этом случае nginx обнаруживает проблему позже, чем возможно
> использование proxy_cache_lock.  Однако и вернуть клиенту
> существующий в кеше ответ в соответствии с "proxy_cache_use_stale
> updating" тоже нельзя, так как кеш-файл невозможно использовать.  В
> результате все запросы просто проксируются на бекенд, как если бы
> proxy_cache_lock не использовался.
>
> В логе ошибок при этом будут сообщения про "cache file ..." на
> уровне crit в случае повреждённых кеш-файлов, и на уровне info в
> случае файлов устаревшего формата.
>
> Если дело в этом, то очистка кеша от старых / повреждённых файлов
> должна помочь.  Рано или поздно это произойдёт само - если,
> конечно, что-то не портит файлы.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> 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/20170607/8abce521/attachment-0001.html>

From simplebox66 на gmail.com  Fri Jun  9 13:26:09 2017
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Fri, 9 Jun 2017 16:26:09 +0300
Subject: =?UTF-8?B?0KDQsNGB0YLQtdGCINC60L7Quy3QstC+IGlub2RlINC40Lct0LfQsCDQutC10Yg=?=
 =?UTF-8?B?0LA=?=
Message-ID: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>

Всем привет.
Столкнулся со следующей проблемой:
nginx последней стабильной версии
ОС CentsOS 6.9
кеш в ramfs на 28Гб со следующими настройками:

> proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m
> max_size=28000m inactive=1440m;
>         proxy_temp_path /tmp/cache/nginx/proxy_temp;
>         proxy_cache_key $server_name$request_uri;


Довольно активно растет кол-во inode на ramfs. Стал изучать ситуацию,
оказалось в кеше лежит куча файлов нулевого размера при чем среди них есть
и очень старые (месячной давности например). На 28Гб кеша, оказалось более
6млн Inode задействовано, при этом после удаления нулевых файлов осталось
всего около 200к inode.
Вопрос зачем nginx хранит до бесконечности нулевые файлы? Как от этого
избавиться?
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170609/b89ab1e2/attachment.html>

From mdounin на mdounin.ru  Fri Jun  9 15:38:50 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 9 Jun 2017 18:38:50 +0300
Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviBpbm9kZSDQuNC3LdC30LAg0Lo=?=
 =?UTF-8?B?0LXRiNCw?=
In-Reply-To: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
References: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
Message-ID: <20170609153850.GB55433@mdounin.ru>

Hello!

On Fri, Jun 09, 2017 at 04:26:09PM +0300, Иван Мишин wrote:

> Всем привет.
> Столкнулся со следующей проблемой:
> nginx последней стабильной версии
> ОС CentsOS 6.9
> кеш в ramfs на 28Гб со следующими настройками:
> 
> > proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m
> > max_size=28000m inactive=1440m;
> >         proxy_temp_path /tmp/cache/nginx/proxy_temp;
> >         proxy_cache_key $server_name$request_uri;
> 
> 
> Довольно активно растет кол-во inode на ramfs. Стал изучать ситуацию,
> оказалось в кеше лежит куча файлов нулевого размера при чем среди них есть
> и очень старые (месячной давности например). На 28Гб кеша, оказалось более
> 6млн Inode задействовано, при этом после удаления нулевых файлов осталось
> всего около 200к inode.
> Вопрос зачем nginx хранит до бесконечности нулевые файлы? Как от этого
> избавиться?

Файлы нулевого размера в кеше - это не nginx, по крайней мере не 
его штатная работа, он просто не умеет ничего подобного создавать.  
Либо это последствия каких-то ошибок (кончилось место при 
копировании из каталога со временными файлами?), либо просто 
результат краха файловой системы.

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

From nginx-forum на forum.nginx.org  Sat Jun 10 16:15:51 2017
From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?=
 =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=)
Date: Sat, 10 Jun 2017 12:15:51 -0400
Subject: =?UTF-8?B?bmdpblNjcmlwdCByZXNwb25zZS5zdGF0dXMg0YDQsNCy0LXQvSAw?=
Message-ID: <326d8c730e68e697d2cacecc832e6c63.NginxMailingListRussian@forum.nginx.org>

Всем доброго дня. Вопрос по сути в названии темы -
https://nginx.org/ru/docs/http/ngx_http_js_module.html

"Объект ответа имеет следующие свойства:

status
статус ответа, доступно для записи"

Понадобилось мне при условии response['status'] === 200 добавить заголовок и
оказалось, что он равен 0. Это так и задумывалось или ошибка? Ну и как в
этом случае задать условие?

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


From nginx-forum на forum.nginx.org  Mon Jun 12 08:32:24 2017
From: nginx-forum на forum.nginx.org (Saytik)
Date: Mon, 12 Jun 2017 04:32:24 -0400
Subject: =?UTF-8?B?bmdpbnggIFNTTCDQv9GA0L7QutGB0LjRgNC+0LLQsNC90LjQtSDQvdCwIGFwYWNo?=
 =?UTF-8?B?ZSBTU0wgICDQsdC10YHQutC+0L3QtdGH0L3Ri9C5ICDRhtC40LrQuyAg0Lg=?=
 =?UTF-8?B?0LcgSXBob25lICDQsdGA0LDRg9C30LXRgNCwICBzYWZhcmk=?=
Message-ID: <dc803257aafe8a829ae9368d128f4ea3.NginxMailingListRussian@forum.nginx.org>

Добрый  день.

Centos  6
# nginx -V 
nginx version: nginx/1.12.0
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC) 
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled

При  заходе  на  сайт  из  iphone страница  не  грузится зависат  и  потом
ошибка  что  соединение  прервано. 
Скорее  всего  проблема  какая-то  из  safari. 

На  стороне  сервера  настроено  проксирование  nginx + ssl   все  запросы
php   на  apache + ssl.
В  логах apache   видно  только  один  запрос появляется  с кодом  ответа 
200, а  в  логах  nginx   создается бесконечный  цикл  запросов  и 
постоянно  пишет  ответ  200, хотя  в браузере  страница  грузится   и  в
итоге  обрывается,  за  это  время  в  логе  nginx   более  1000  запросов 
однаковых  с  кодом  200.


настройки  проксирования  в  nginx:
listen       443 ssl http2;
location / {
            proxy_pass https://IP:1443;
            add_header                 Front-End-Https   on;
            proxy_redirect  off;
            proxy_set_header   Host   $host;
            proxy_set_header   X-Real-IP  $remote_addr;
            proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header   X-Forwarded-Proto $scheme;
        }

на  1443  apache + ssl:
<IfModule ssl_module>
    SSLEngine on
    
    SSLCertificateFile
/var/cpanel/ssl/installed/certs/DOMEN_c41bd_e4c65_1501981920_1ca1a783b6521a51e5df7b0a2d5ef4a1.crt
    SSLCertificateKeyFile
/var/cpanel/ssl/installed/keys/c41bd_e4c65_059ba8190becba1d10ebc8f4492ae695.key
    SSLCACertificateFile
/var/cpanel/ssl/installed/cabundles/Let_s_Encrypt_d5a69d0f2effae8513e08eaced2ccf28_1615999246.cabundle
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
  </IfModule>

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


From chmind на yandex.ru  Mon Jun 12 13:42:18 2017
From: chmind на yandex.ru (chmind на yandex.ru)
Date: Mon, 12 Jun 2017 16:42:18 +0300
Subject: check file existence on multiple backends 
Message-ID: <D5FA1331-F041-4A21-821D-E44B1E076AEB@yandex.ru>

Добрый день. 

Подскажите пожалуйста, можно ли используя nginx реализовать подобную схему 

                     /  -     backend1 
nginx proxy /
                     \ -     backend2 —  /imgs/static1.png

на nginx приходит запрос domain.com/imgs/static1.png <http://domain.com/imgs/static1.png>

nginx проверяет наличие static1.png на N backend’ах и отдает первый попавшийся, на некоторых бэкендах файла может и не быть, в этом случае надо проверять дальше. 

Спасибо. 

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

From skobolo на gmail.com  Mon Jun 12 13:54:16 2017
From: skobolo на gmail.com (SK)
Date: Mon, 12 Jun 2017 16:54:16 +0300
Subject: check file existence on multiple backends
In-Reply-To: <D5FA1331-F041-4A21-821D-E44B1E076AEB@yandex.ru>
References: <D5FA1331-F041-4A21-821D-E44B1E076AEB@yandex.ru>
Message-ID: <BB8B5642-3C42-4470-A407-39FA35809074@gmail.com>

Посмотрите в сторону proxy_next_upstream

SK

> 12 июня 2017 г., в 16:42, chmind на yandex.ru написал(а):
> 
> Добрый день. 
> 
> Подскажите пожалуйста, можно ли используя nginx реализовать подобную схему 
> 
>                      /  -     backend1 
> nginx proxy /
>                      \ -     backend2 —  /imgs/static1.png
> 
> на nginx приходит запрос domain.com/imgs/static1.png
> 
> nginx проверяет наличие static1.png на N backend’ах и отдает первый попавшийся, на некоторых бэкендах файла может и не быть, в этом случае надо проверять дальше. 
> 
> Спасибо. 
> 
> _______________________________________________
> 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/20170612/9847b45b/attachment.html>

From chmind на yandex.ru  Mon Jun 12 14:11:16 2017
From: chmind на yandex.ru (chmind на yandex.ru)
Date: Mon, 12 Jun 2017 17:11:16 +0300
Subject: check file existence on multiple backends 
In-Reply-To: <BB8B5642-3C42-4470-A407-39FA35809074@gmail.com>
References: <D5FA1331-F041-4A21-821D-E44B1E076AEB@yandex.ru>
 <BB8B5642-3C42-4470-A407-39FA35809074@gmail.com>
Message-ID: <8AE4A05B-DAB8-443A-B44D-DF146580949D@yandex.ru>

Спасибо. Похоже то что надо. 

> On 12 Jun 2017, at 16:54, SK <skobolo на gmail.com> wrote:
> 
> Посмотрите в сторону proxy_next_upstream
> 
> SK
> 
> 12 июня 2017 г., в 16:42, chmind на yandex.ru <mailto:chmind на yandex.ru> написал(а):
> 
>> Добрый день. 
>> 
>> Подскажите пожалуйста, можно ли используя nginx реализовать подобную схему 
>> 
>>                      /  -     backend1 
>> nginx proxy /
>>                      \ -     backend2 —  /imgs/static1.png
>> 
>> на nginx приходит запрос domain.com/imgs/static1.png <http://domain.com/imgs/static1.png>
>> 
>> nginx проверяет наличие static1.png на N backend’ах и отдает первый попавшийся, на некоторых бэкендах файла может и не быть, в этом случае надо проверять дальше. 
>> 
>> Спасибо. 
>> 
>> _______________________________________________
>> 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/20170612/2b6397b4/attachment.html>

From igor на sysoev.ru  Tue Jun 13 12:41:43 2017
From: igor на sysoev.ru (Igor Sysoev)
Date: Tue, 13 Jun 2017 15:41:43 +0300
Subject: =?UTF-8?B?UmU6IG5naW5TY3JpcHQgcmVzcG9uc2Uuc3RhdHVzINGA0LDQstC10L0gMA==?=
In-Reply-To: <326d8c730e68e697d2cacecc832e6c63.NginxMailingListRussian@forum.nginx.org>
References: <326d8c730e68e697d2cacecc832e6c63.NginxMailingListRussian@forum.nginx.org>
Message-ID: <887C6073-055D-44C9-810D-83EBE5DA3107@sysoev.ru>

On 10 Jun 2017, at 19:15, Дмитрий Герасимов <nginx-forum на forum.nginx.org> wrote:

> Всем доброго дня. Вопрос по сути в названии темы -
> https://nginx.org/ru/docs/http/ngx_http_js_module.html
> 
> "Объект ответа имеет следующие свойства:
> 
> status
> статус ответа, доступно для записи"
> 
> Понадобилось мне при условии response['status'] === 200 добавить заголовок и
> оказалось, что он равен 0. Это так и задумывалось или ошибка? Ну и как в
> этом случае задать условие?

nginScript - пока не умеет фильтровать ответы, а может только создавать.
Он должен сам поставить нужный response.status. До этого момента статус равен нулю.


-- 
Igor Sysoev
http://nginx.com


From domrachev.ivan на gmail.com  Wed Jun 14 11:52:58 2017
From: domrachev.ivan на gmail.com (Domrachev Ivan)
Date: Wed, 14 Jun 2017 14:52:58 +0300
Subject: proxy_cache_background_update
Message-ID: <1324553948.20170614145258@gmail.com>

приветствую

если одновременно использовать
sendfile on;
tcp_nopush on;
proxy_cache_background_update on;

то ломается логика работы proxy_cache_background_update: иногда возвращается часть закэщированного варианта,
потом енджайникс ждёт секунд 5 и досылает остаток.
если спрашивать раз в секунду, а proxy_cache_valid any 2s то в логах получается так:
127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:46 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" MISS 5.123
127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:47 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:48 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:54 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" STALE -
127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:55 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:56 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
127.0.0.1 127.0.0.1 - [14/Jun/2017:14:28:03 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" STALE -
127.0.0.1 127.0.0.1 - [14/Jun/2017:14:28:04 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
127.0.0.1 127.0.0.1 - [14/Jun/2017:14:28:05 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
тайминги запросов
        5.12 real         0.00 user         0.00 sys
        0.10 real         0.00 user         0.00 sys
        0.10 real         0.00 user         0.00 sys
        5.14 real         0.00 user         0.00 sys
        0.10 real         0.00 user         0.00 sys
        0.10 real         0.00 user         0.00 sys
        5.14 real         0.00 user         0.00 sys
        0.10 real         0.00 user         0.00 sys
        0.10 real         0.00 user         0.00 sys

если любую из этих опций отключить:
sendfile on;
tcp_nopush on;
то всё нормализуется

конфиг:
worker_processes 2;
pid shared/nginx/pid;
error_log shared/nginx/logs-raw/e.current warn;

events{worker_connections 1024;}

http {
 include mime.types;

 sendfile on;
 tcp_nopush on;

 log_format main '$remote_addr $host - [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $upstream_cache_status $upstream_response_time';

 access_log shared/nginx/logs-raw/a.current main;

 proxy_cache_path shared/nginx/temp/cache levels=1:2 keys_zone=cache:10m;

 proxy_cache_use_stale updating;
 proxy_cache_valid any 2s;
 proxy_cache_background_update on;
 proxy_cache cache;

 server {
  listen *:80;
  location / {proxy_pass http://127.0.0.1:1500;}
 }

}

запрашивалка
while true;do time wget -q http://127.0.0.1/ -O /dev/null;sleep 1;done

запрашивалка, что бы видить, что часть запроса таки приходит
while true;do time wget -q http://127.0.0.1/ -O -;sleep 1;done

лагающий вебсервер
perl -MIO::All -e 'io(":1500")->fork->accept->(sub{if(/^GET/){sleep(5);$_[0]<"HTTP/1.1 200 OK\nContent-Length: 65536\n\n"."x"x65536}})'

ОС: freebsd 10.1
nginx: 1.13.1


From m_nikita на bk.ru  Wed Jun 14 12:17:47 2017
From: m_nikita на bk.ru (=?UTF-8?B?0J3QuNC60LjRgtCw?=)
Date: Wed, 14 Jun 2017 15:17:47 +0300
Subject: =?UTF-8?B?0J3QtSDQv9C10YDQtdC00LDQtdGC0YHRjyByZXNwb25zZSBoZWFkZXIg0L/RgNC4?=
 =?UTF-8?B?INC40YHQv9C+0LvQt9C+0LLQsNC90LjQuCBYLUFjY2VsLVJlZGlyZWN0?=
Message-ID: <1497442667.682866615@f463.i.mail.ru>


Добрый день !

Проблема: 
Не передаются некоторые response хедеры которые отдает uwsgi в ответе при  использовании X-Accel-Redirect

location / {
include uwsgi_params;
uwsgi_pass unix:/var/run/uwsgi/app/django/socket;
uwsgi_param HTTP_X_ORIGINAL_URL $request_uri;
}
location ~ ^/_internal/redirect-location/(.*)$ {
internal;
proxy_set_header Host $host;
proxy_set_header X-Subdomain $http_x_subdomain;
proxy_pass http://consul-frontend-mobile-website/$1$is_args$args;
}

Вот дебаг лог

https://gist.github.com/anonymous/e18aa7ebb5e717fada9a45affc9623f6


Искомый хедер который не передается - X-Flavour

Пробовали:

location ~ ^/_internal/redirect-location/(.*)$ {
internal;
proxy_set_header X-Flavour $upstream_http_x_flavour ;
proxy_set_header Host $host;
proxy_set_header X-Subdomain $http_x_subdomain;
proxy_pass http://consul-frontend-mobile-website/$1$is_args$args;
}

Куда еще копнуть ?

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

From mdounin на mdounin.ru  Wed Jun 14 13:24:13 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 14 Jun 2017 16:24:13 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QtdGA0LXQtNCw0LXRgtGB0Y8gcmVzcG9uc2UgaGVhZGVyINC/?=
 =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70LfQvtCy0LDQvdC40LggWC1BY2NlbC1SZWRpcmVj?=
 =?UTF-8?B?dA==?=
In-Reply-To: <1497442667.682866615@f463.i.mail.ru>
References: <1497442667.682866615@f463.i.mail.ru>
Message-ID: <20170614132413.GN55433@mdounin.ru>

Hello!

On Wed, Jun 14, 2017 at 03:17:47PM +0300, Никита wrote:

> 
> Добрый день !
> 
> Проблема: 
> Не передаются некоторые response хедеры которые отдает uwsgi в ответе при  использовании X-Accel-Redirect
> 
> location / {
> include uwsgi_params;
> uwsgi_pass unix:/var/run/uwsgi/app/django/socket;
> uwsgi_param HTTP_X_ORIGINAL_URL $request_uri;
> }
> location ~ ^/_internal/redirect-location/(.*)$ {
> internal;
> proxy_set_header Host $host;
> proxy_set_header X-Subdomain $http_x_subdomain;
> proxy_pass http://consul-frontend-mobile-website/$1$is_args$args;
> }
> 
> Вот дебаг лог
> 
> https://gist.github.com/anonymous/e18aa7ebb5e717fada9a45affc9623f6
> 
> 
> Искомый хедер который не передается - X-Flavour

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

> Пробовали:
> 
> location ~ ^/_internal/redirect-location/(.*)$ {
> internal;
> proxy_set_header X-Flavour $upstream_http_x_flavour ;
> proxy_set_header Host $host;
> proxy_set_header X-Subdomain $http_x_subdomain;
> proxy_pass http://consul-frontend-mobile-website/$1$is_args$args;
> }
> 
> Куда еще копнуть ?

Переменные $upstream_* очищаются при начале работы с новым 
upsteam'ом, так что в момент формирования заголовков нового 
запроса переменная $upstream_http_x_flavour будет пустой.

Если нужно использовать значение, полученное от бекенда в рамках 
предыдущего обращения, можно сохранить его в промеждуточную 
переменную с помощью директивы set, как-то так:

    set $foo $upstream_http_x_flavour;
    proxy_pass http://...;
    proxy_set_header X-Flavour $upstream_http_x_flavour;
    ...

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

From mdounin на mdounin.ru  Wed Jun 14 13:53:49 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 14 Jun 2017 16:53:49 +0300
Subject: proxy_cache_background_update
In-Reply-To: <1324553948.20170614145258@gmail.com>
References: <1324553948.20170614145258@gmail.com>
Message-ID: <20170614135349.GP55433@mdounin.ru>

Hello!

On Wed, Jun 14, 2017 at 02:52:58PM +0300, Domrachev Ivan wrote:

> приветствую
> 
> если одновременно использовать
> sendfile on;
> tcp_nopush on;
> proxy_cache_background_update on;
> 
> то ломается логика работы proxy_cache_background_update: иногда возвращается часть закэщированного варианта,
> потом енджайникс ждёт секунд 5 и досылает остаток.
> если спрашивать раз в секунду, а proxy_cache_valid any 2s то в логах получается так:
> 127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:46 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" MISS 5.123
> 127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:47 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
> 127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:48 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
> 127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:54 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" STALE -
> 127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:55 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
> 127.0.0.1 127.0.0.1 - [14/Jun/2017:14:27:56 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
> 127.0.0.1 127.0.0.1 - [14/Jun/2017:14:28:03 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" STALE -
> 127.0.0.1 127.0.0.1 - [14/Jun/2017:14:28:04 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
> 127.0.0.1 127.0.0.1 - [14/Jun/2017:14:28:05 +0300] "GET / HTTP/1.1" 200 65536 "-" "Wget/1.16.3 (freebsd10.1)" HIT -
> тайминги запросов
>         5.12 real         0.00 user         0.00 sys
>         0.10 real         0.00 user         0.00 sys
>         0.10 real         0.00 user         0.00 sys
>         5.14 real         0.00 user         0.00 sys
>         0.10 real         0.00 user         0.00 sys
>         0.10 real         0.00 user         0.00 sys
>         5.14 real         0.00 user         0.00 sys
>         0.10 real         0.00 user         0.00 sys
>         0.10 real         0.00 user         0.00 sys
> 
> если любую из этих опций отключить:
> sendfile on;
> tcp_nopush on;
> то всё нормализуется

Проблема понятная: TCP_NOPUSH задерживает отправку неполных 
пакетов клиенту до снятия соответствующего флага, а флаг снимается 
только при переходе в keepalive, т.е. после того, как отработает 
background-подзапрос.  Простейший workaround - отключить 
tcp_nopush.

Как именно это править, и стоит ли вообще править - пока не совсем 
понятно.  Возможно, стоит снимать TCP_NOPUSH чуть раньше.

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

From m_nikita на bk.ru  Wed Jun 14 14:53:39 2017
From: m_nikita на bk.ru (=?UTF-8?B?0J3QuNC60LjRgtCw?=)
Date: Wed, 14 Jun 2017 17:53:39 +0300
Subject: =?UTF-8?B?UmVbMl06INCd0LUg0L/QtdGA0LXQtNCw0LXRgtGB0Y8gcmVzcG9uc2UgaGVhZGVy?=
 =?UTF-8?B?INC/0YDQuCDQuNGB0L/QvtC70LfQvtCy0LDQvdC40LggWC1BY2NlbC1SZWRp?=
 =?UTF-8?B?cmVjdA==?=
In-Reply-To: <20170614132413.GN55433@mdounin.ru>
References: <1497442667.682866615@f463.i.mail.ru>
 <20170614132413.GN55433@mdounin.ru>
Message-ID: <1497452019.524966238@f466.i.mail.ru>


Вот так не работает. 

location / {
ssi off;
include uwsgi_params;
uwsgi_pass unix:/var/run/uwsgi/app/beta1/socket; ### вот этот бекенд создает этот хедер и отдает в ответ. 
uwsgi_param HTTP_X_ORIGINAL_URL $request_uri;
uwsgi_connect_timeout 300;
uwsgi_pass_header HTTP_X_FLAVOUR; ## пробовали подобное в разных вариациях
uwsgi_pass_header UPSTREAM_HTTP_X_FLAVOUR; ## пробовали подобное в разных вариациях
set $flavour $upstream_http_x_flavour; ## Расчитываем вот в этом месте завернуть хедер из ответа в переменную $flavour но судя по логу $upstream_http_X_Flavour пуст при том что в дебаг логе видно что бекенд его возвращает. 
}
location ~ ^/_internal/redirect-mobile-website/(.*)$ {
proxy_set_header Host $host;
proxy_set_header X-Subdomain $x_subdomain;
proxy_pass_header X-Flavour;
proxy_set_header X-Flavour $flavour; ### А вот тут передать ее в подзапрос. 
proxy_pass http://consul-frontend-mobile-website--beta1/$1$is_args$args;
}


>Среда, 14 июня 2017, 16:24 +03:00 от Maxim Dounin <mdounin на mdounin.ru>:
>
>Hello!
>
>On Wed, Jun 14, 2017 at 03:17:47PM +0300, Никита wrote:
>
>> 
>> Добрый день !
>> 
>> Проблема: 
>> Не передаются некоторые response хедеры которые отдает uwsgi в ответе при  использовании X-Accel-Redirect
>> 
>> location / {
>> include uwsgi_params;
>> uwsgi_pass unix:/var/run/uwsgi/app/django/socket;
>> uwsgi_param HTTP_X_ORIGINAL_URL $request_uri;
>> }
>> location ~ ^/_internal/redirect-location/(.*)$ {
>> internal;
>> proxy_set_header Host $host;
>> proxy_set_header X-Subdomain $http_x_subdomain;
>> proxy_pass http://consul-frontend-mobile-website/$1$is_args$args;
>> }
>> 
>> Вот дебаг лог
>> 
>>  https://gist.github.com/anonymous/e18aa7ebb5e717fada9a45affc9623f6
>> 
>> 
>> Искомый хедер который не передается - X-Flavour
>
>В такой конфигурации и не должен.  После перенаправления на бекенд 
>передаются заголовки исходного запроса пользователя, аналогично 
>тому, что происходит просто при обычном проксировании.
>
>> Пробовали:
>> 
>> location ~ ^/_internal/redirect-location/(.*)$ {
>> internal;
>> proxy_set_header X-Flavour $upstream_http_x_flavour ;
>> proxy_set_header Host $host;
>> proxy_set_header X-Subdomain $http_x_subdomain;
>> proxy_pass http://consul-frontend-mobile-website/$1$is_args$args;
>> }
>> 
>> Куда еще копнуть ?
>
>Переменные $upstream_* очищаются при начале работы с новым 
>upsteam'ом, так что в момент формирования заголовков нового 
>запроса переменная $upstream_http_x_flavour будет пустой.
>
>Если нужно использовать значение, полученное от бекенда в рамках 
>предыдущего обращения, можно сохранить его в промеждуточную 
>переменную с помощью директивы set, как-то так:
>
>    set $foo $upstream_http_x_flavour;
>    proxy_pass  http://...;
>    proxy_set_header X-Flavour $upstream_http_x_flavour;
>    ...
>
>-- 
>Maxim Dounin
>http://nginx.org/
>_______________________________________________
>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/20170614/84a7eec8/attachment.html>

From mdounin на mdounin.ru  Wed Jun 14 15:05:10 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 14 Jun 2017 18:05:10 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QtdGA0LXQtNCw0LXRgtGB0Y8gcmVzcG9uc2UgaGVhZGVyINC/?=
 =?UTF-8?B?0YDQuCDQuNGB0L/QvtC70LfQvtCy0LDQvdC40LggWC1BY2NlbC1SZWRpcmVj?=
 =?UTF-8?B?dA==?=
In-Reply-To: <1497452019.524966238@f466.i.mail.ru>
References: <1497442667.682866615@f463.i.mail.ru>
 <20170614132413.GN55433@mdounin.ru>
 <1497452019.524966238@f466.i.mail.ru>
Message-ID: <20170614150509.GQ55433@mdounin.ru>

Hello!

On Wed, Jun 14, 2017 at 05:53:39PM +0300, Никита wrote:

> 
> Вот так не работает. 
> 
> location / {
> ssi off;
> include uwsgi_params;
> uwsgi_pass unix:/var/run/uwsgi/app/beta1/socket; ### вот этот бекенд создает этот хедер и отдает в ответ. 
> uwsgi_param HTTP_X_ORIGINAL_URL $request_uri;
> uwsgi_connect_timeout 300;
> uwsgi_pass_header HTTP_X_FLAVOUR; ## пробовали подобное в разных вариациях
> uwsgi_pass_header UPSTREAM_HTTP_X_FLAVOUR; ## пробовали подобное в разных вариациях
> set $flavour $upstream_http_x_flavour; ## Расчитываем вот в этом месте завернуть хедер из ответа в переменную $flavour но судя по логу $upstream_http_X_Flavour пуст при том что в дебаг логе видно что бекенд его возвращает. 
> }
> location ~ ^/_internal/redirect-mobile-website/(.*)$ {
> proxy_set_header Host $host;
> proxy_set_header X-Subdomain $x_subdomain;
> proxy_pass_header X-Flavour;
> proxy_set_header X-Flavour $flavour; ### А вот тут передать ее в подзапрос. 
> proxy_pass http://consul-frontend-mobile-website--beta1/$1$is_args$args;
> }

Вы неправильно понимаете, как работают директивы в nginx'е.  
Директивы не выполняются последовательно, они задают конфигурацию 
для кокретного location'а.  Соответственно, директива set 
внутри "location /" будут выполнена на этапе поиска конфигурации, 
до отправки запроса на бекенд.  Подробнее о том, как выполняются 
директивы модуля rewrite, можно почитать в документации, 
http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html.

Чтобы сохранилось значение, полученное от бекенда, надо 
использовать директиву set уже после перенаправления, в том же 
location'е, где вы собираетесь это значение использовать в 
proxy_set_header, что и было показано в приведённом ранее примере.   
Тот же пример, слегка расширенный, чтобы исключить 
неоднозначность:

    location / {
        proxy_pass http://backend-to-return-redirect;
        ...
    }

    location /redirected/ {
        set $foo $upstream_http_x_flavour;
        proxy_pass  http://...;
        proxy_set_header X-Flavour $upstream_http_x_flavour;
        ...
    }

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

From al.al.platonov на gmail.com  Thu Jun 15 14:21:38 2017
From: al.al.platonov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3RgCDQn9C70LDRgtC+0L3QvtCy?=)
Date: Thu, 15 Jun 2017 17:21:38 +0300
Subject: =?UTF-8?B?0J3QtSDQv9C+0L3QuNC80LDRjiDQsiDRh9C10Lwg0L/RgNC40YfQuNC90LAg0Lo=?=
 =?UTF-8?B?0L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0LkgQ29u?=
 =?UTF-8?B?bmVjdGlvbiB0aW1lZCBvdXQ=?=
Message-ID: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>

Добрый день.

У меня есть ~30 хостов в 3-х разных ДЦ. Nginx принимает нагрузку и
распределяет её по алгоритму WRR на php-fpm пулы, расположенные на этих же
хостах.

Периодически, примерно 1/5000 (ошибка к общему кол-ву запросов)  на
случайном хосте получает ошибку:
front14 2017/06/15 15:37:40 [error] 13063#13063: *2446289 upstream timed
out (110: Connection timed out) while connecting to upstream, client:
217.69.135.0, server: site, request: "GET
/files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg
HTTP/1.0", upstream: "fastcgi://217.69.137.52:8081", host: "site"

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

front14 217.69.135.0 - - [15/Jun/2017:15:37:41 +0300] "GET
/files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg HTTP/1.0" 200
139517 "-" "okhttp/3.4.1" "-" request_time: 1.660 upstream_addr:
217.69.137.52:8081, 217.69.137.51:8081 upstream_response_time: 0.677, 0.981
upstream_status: 504, 200 upstream_cache_status: - "tid:"
13063-1497530259.494-217.69.135.0-163-2446289

Меня волнует это так как увеличивается время ответа и всегда есть некий
фоновый поток 504 ошибок. Подскажите, пожалуйста почему возникает таймаут и
как его избежать?

Файл nginx-debug с одной проблемной сессией: https://uploadfiles.io/eokgp
Файл конфигурации nginx: https://ufile.io/w8x56
Список upstream: https://ufile.io/3tt84
Cписок параметров fastcgi: https://ufile.io/gdzaa
Sysctl: https://ufile.io/cdboz

Снимал несколько раз tcpdump и наблюдал следующую картину:
1) хост с nginx послылает FIN на бэкенд сразу после своего же ACK бэкенду
через 13ms, не пересылая данные вообще.
2) хост с nginx посылает RST через 10 мкс после получения SYN, ACK от
бэкенда и через ~ 780 мкс от своего SYN.

типовой ss -i
ESTAB      0      0          217.69.134.124:40538        217.69.137.52:tproxy

     cubic wscale:7,7 rto:202 rtt:2.75/1.5 cwnd:10 bytes_acked:865
segs_out:3 segs_in:2 send 42.1Mbps rcv_space:14600

Не понятно почему при настройке nginx fastcgi_connect_timeout 300ms; в логе
вижу upstream_response_time: 0.677 секунды. Есть этому объяснение?

Спасибо всем,
Александр
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170615/473bd0af/attachment.html>

From nginx на mva.name  Thu Jun 15 14:38:36 2017
From: nginx на mva.name (Vadim A. Misbakh-Soloviov)
Date: Thu, 15 Jun 2017 21:38:36 +0700
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
Message-ID: <2943533.gaKiWn5x0h@note>

Возможно просто попадаете на рестарт воркера

From chipitsine на gmail.com  Thu Jun 15 14:44:48 2017
From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=)
Date: Thu, 15 Jun 2017 19:44:48 +0500
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
Message-ID: <CAFHpkQEsKiFO39fGGCfb33qf6Gop1XWsgw_PCnTf2hPk8DHWjw@mail.gmail.com>

"GET /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg" - по
fastcgi запрос отправляете ?

(просто в моем представлении fastcgi это php, а тут похоже на статику)

15 июня 2017 г., 19:21 пользователь Алексанр Платонов <
al.al.platonov на gmail.com> написал:

> Добрый день.
>
> У меня есть ~30 хостов в 3-х разных ДЦ. Nginx принимает нагрузку и
> распределяет её по алгоритму WRR на php-fpm пулы, расположенные на этих же
> хостах.
>
> Периодически, примерно 1/5000 (ошибка к общему кол-ву запросов)  на
> случайном хосте получает ошибку:
> front14 2017/06/15 15:37:40 [error] 13063#13063: *2446289 upstream timed
> out (110: Connection timed out) while connecting to upstream, client:
> 217.69.135.0, server: site, request: "GET /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg
> HTTP/1.0", upstream: "fastcgi://217.69.137.52:8081", host: "site"
>
> после получения ошибки nginx проксирует запрос на другой сервер и там все
> отрабатывает нормально.
>
> front14 217.69.135.0 - - [15/Jun/2017:15:37:41 +0300] "GET
> /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg HTTP/1.0" 200
> 139517 "-" "okhttp/3.4.1" "-" request_time: 1.660 upstream_addr:
> 217.69.137.52:8081, 217.69.137.51:8081 upstream_response_time: 0.677,
> 0.981 upstream_status: 504, 200 upstream_cache_status: - "tid:"
> 13063-1497530259.494-217.69.135.0-163-2446289
>
> Меня волнует это так как увеличивается время ответа и всегда есть некий
> фоновый поток 504 ошибок. Подскажите, пожалуйста почему возникает таймаут и
> как его избежать?
>
> Файл nginx-debug с одной проблемной сессией: https://uploadfiles.io/eokgp
> Файл конфигурации nginx: https://ufile.io/w8x56
> Список upstream: https://ufile.io/3tt84
> Cписок параметров fastcgi: https://ufile.io/gdzaa
> Sysctl: https://ufile.io/cdboz
>
> Снимал несколько раз tcpdump и наблюдал следующую картину:
> 1) хост с nginx послылает FIN на бэкенд сразу после своего же ACK бэкенду
> через 13ms, не пересылая данные вообще.
> 2) хост с nginx посылает RST через 10 мкс после получения SYN, ACK от
> бэкенда и через ~ 780 мкс от своего SYN.
>
> типовой ss -i
> ESTAB      0      0          217.69.134.124:40538        217.69.137.52:tproxy
>
>      cubic wscale:7,7 rto:202 rtt:2.75/1.5 cwnd:10 bytes_acked:865
> segs_out:3 segs_in:2 send 42.1Mbps rcv_space:14600
>
> Не понятно почему при настройке nginx fastcgi_connect_timeout 300ms; в
> логе вижу upstream_response_time: 0.677 секунды. Есть этому объяснение?
>
> Спасибо всем,
> Александр
>
> _______________________________________________
> 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/20170615/a57a48cb/attachment-0001.html>

From bgx на protva.ru  Thu Jun 15 15:13:01 2017
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Thu, 15 Jun 2017 18:13:01 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
Message-ID: <20170615151301.d4vezsum6pfklj7f@protva.ru>

On Thu, Jun 15, 2017 at 05:21:38PM +0300, Алексанр Платонов wrote:
> У меня есть ~30 хостов в 3-х разных ДЦ. Nginx принимает нагрузку и
> распределяет её по алгоритму WRR на php-fpm пулы, расположенные на этих же
> хостах.
> 
> Периодически, примерно 1/5000 (ошибка к общему кол-ву запросов)  на
> случайном хосте получает ошибку:
> front14 2017/06/15 15:37:40 [error] 13063#13063: *2446289 upstream timed
> out (110: Connection timed out) while connecting to upstream, client:
> 217.69.135.0, server: site, request: "GET
> /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg
> HTTP/1.0", upstream: "fastcgi://217.69.137.52:8081", host: "site"
> 
> после получения ошибки nginx проксирует запрос на другой сервер и там все
> отрабатывает нормально.
> 
> front14 217.69.135.0 - - [15/Jun/2017:15:37:41 +0300] "GET
> /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg HTTP/1.0" 200
> 139517 "-" "okhttp/3.4.1" "-" request_time: 1.660 upstream_addr:
> 217.69.137.52:8081, 217.69.137.51:8081 upstream_response_time: 0.677, 0.981
> upstream_status: 504, 200 upstream_cache_status: - "tid:"
> 13063-1497530259.494-217.69.135.0-163-2446289
...
> Снимал несколько раз tcpdump и наблюдал следующую картину:
> 1) хост с nginx послылает FIN на бэкенд сразу после своего же ACK бэкенду
> через 13ms, не пересылая данные вообще.

 Это совсем не похоже на таймаут. Возможно, перепутаны коннекции в дампе,
 проверьте номера портов и tcp seq.

> 2) хост с nginx посылает RST через 10 мкс после получения SYN, ACK от
> бэкенда и через ~ 780 мкс от своего SYN.

 А это похоже на таймаут коннекта. Вопрос в том, почему SYN+ACK от бэкенда
 пришёл с такой задержкой. Возможно, бэкенд перегружен.
 Возможно, свитчи по пути перегружены трафиком.
 
> Не понятно почему при настройке nginx fastcgi_connect_timeout 300ms; в логе
> вижу upstream_response_time: 0.677 секунды. Есть этому объяснение?

 Коннект это одно, а ожидание ответа бэкенда ПОСЛЕ завершения коннекта
 это другое. Можно сконнектиться, послать запрос и долго ждать ответа.
-- 
 Eugene Berdnikov

From mdounin на mdounin.ru  Thu Jun 15 15:24:25 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 15 Jun 2017 18:24:25 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
Message-ID: <20170615152424.GZ55433@mdounin.ru>

Hello!

On Thu, Jun 15, 2017 at 05:21:38PM +0300, Алексанр Платонов wrote:

> Добрый день.
> 
> У меня есть ~30 хостов в 3-х разных ДЦ. Nginx принимает нагрузку и
> распределяет её по алгоритму WRR на php-fpm пулы, расположенные на этих же
> хостах.
> 
> Периодически, примерно 1/5000 (ошибка к общему кол-ву запросов)  на
> случайном хосте получает ошибку:
> front14 2017/06/15 15:37:40 [error] 13063#13063: *2446289 upstream timed
> out (110: Connection timed out) while connecting to upstream, client:
> 217.69.135.0, server: site, request: "GET
> /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg
> HTTP/1.0", upstream: "fastcgi://217.69.137.52:8081", host: "site"
> 
> после получения ошибки nginx проксирует запрос на другой сервер и там все
> отрабатывает нормально.
> 
> front14 217.69.135.0 - - [15/Jun/2017:15:37:41 +0300] "GET
> /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg HTTP/1.0" 200
> 139517 "-" "okhttp/3.4.1" "-" request_time: 1.660 upstream_addr:
> 217.69.137.52:8081, 217.69.137.51:8081 upstream_response_time: 0.677, 0.981
> upstream_status: 504, 200 upstream_cache_status: - "tid:"
> 13063-1497530259.494-217.69.135.0-163-2446289
> 
> Меня волнует это так как увеличивается время ответа и всегда есть некий
> фоновый поток 504 ошибок. Подскажите, пожалуйста почему возникает таймаут и
> как его избежать?
> 
> Файл nginx-debug с одной проблемной сессией: https://uploadfiles.io/eokgp
> Файл конфигурации nginx: https://ufile.io/w8x56
> Список upstream: https://ufile.io/3tt84
> Cписок параметров fastcgi: https://ufile.io/gdzaa
> Sysctl: https://ufile.io/cdboz
> 
> Снимал несколько раз tcpdump и наблюдал следующую картину:
> 1) хост с nginx послылает FIN на бэкенд сразу после своего же ACK бэкенду
> через 13ms, не пересылая данные вообще.
> 2) хост с nginx посылает RST через 10 мкс после получения SYN, ACK от
> бэкенда и через ~ 780 мкс от своего SYN.
> 
> типовой ss -i
> ESTAB      0      0          217.69.134.124:40538        217.69.137.52:tproxy
> 
>      cubic wscale:7,7 rto:202 rtt:2.75/1.5 cwnd:10 bytes_acked:865
> segs_out:3 segs_in:2 send 42.1Mbps rcv_space:14600
> 
> Не понятно почему при настройке nginx fastcgi_connect_timeout 300ms; в логе
> вижу upstream_response_time: 0.677 секунды. Есть этому объяснение?

При connect-таймауте в 300 миллисекунд любой потерянный пакет 
будет приводить к таймауту.  А какой-то процент потерянных пакетов - это 
нормальное состояние любой сети, так что нет причин удивляться 
тому, что часть соединений при таких настройках таймаутится.

Кроме того, следует понимать, что время внутри nginx'а обновляется 
единожды за итерацию цикла обработки событий.  В результате если 
обработка какого-то события занимает существенное время и/или 
таких событий много, это может сказаться как на latency операций в 
целом, так и на точности работы отдельных таймаутов.  Поскольку 
300 миллисекунд - время достаточно малое, это может быть заметно, 
если сервер сильно нагружен и/или где-то блокируется.

В связи с вышеизложенным не могу не отметить, что в вашем конфиге 
видны следы стороннего модуля отправки статистики в graphite.  
Судя по коду[1], в tcp-режиме этот модуль блокирует рабочий процесс 
при отправке накопленной статистики на сервер.  Это, скажем мягко, 
малопригодное для production-использования решение, так что стоит 
начать с простого - убрать модуль совсем, и посмотреть на 
результат.

[1] https://github.com/mailru/graphite-nginx-module/blob/master/src/ngx_http_graphite_module.c#L2204

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

From al.al.platonov на gmail.com  Thu Jun 15 17:28:54 2017
From: al.al.platonov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3RgCDQn9C70LDRgtC+0L3QvtCy?=)
Date: Thu, 15 Jun 2017 20:28:54 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <2943533.gaKiWn5x0h@note>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
 <2943533.gaKiWn5x0h@note>
Message-ID: <CAEB8VFJbLrBPmE0qOqk65bVwOVrtJR0hCBN1QWHgSjhxzeMqxg@mail.gmail.com>

Возможно, но тогда я ожидаю FIN, RST от приложения, а его нет.

Александр

15 июня 2017 г., 17:38 пользователь Vadim A. Misbakh-Soloviov <
nginx на mva.name> написал:

> Возможно просто попадаете на рестарт воркера
> _______________________________________________
> 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/20170615/d86c3d34/attachment.html>

From al.al.platonov на gmail.com  Thu Jun 15 17:30:20 2017
From: al.al.platonov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3RgCDQn9C70LDRgtC+0L3QvtCy?=)
Date: Thu, 15 Jun 2017 20:30:20 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <CAFHpkQEsKiFO39fGGCfb33qf6Gop1XWsgw_PCnTf2hPk8DHWjw@mail.gmail.com>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
 <CAFHpkQEsKiFO39fGGCfb33qf6Gop1XWsgw_PCnTf2hPk8DHWjw@mail.gmail.com>
Message-ID: <CAEB8VF+WqeNe7b2Uouy=_Jp6PaNAi2kJOZtPrUa=XL2WeY677w@mail.gmail.com>

Да, отправляю. location и dst тут не принципиален, картина аналогичная.

Александр

15 июня 2017 г., 17:44 пользователь Илья Шипицин <chipitsine на gmail.com>
написал:

> "GET /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg" - по
> fastcgi запрос отправляете ?
>
> (просто в моем представлении fastcgi это php, а тут похоже на статику)
>
> 15 июня 2017 г., 19:21 пользователь Алексанр Платонов <
> al.al.platonov на gmail.com> написал:
>
>> Добрый день.
>>
>> У меня есть ~30 хостов в 3-х разных ДЦ. Nginx принимает нагрузку и
>> распределяет её по алгоритму WRR на php-fpm пулы, расположенные на этих же
>> хостах.
>>
>> Периодически, примерно 1/5000 (ошибка к общему кол-ву запросов)  на
>> случайном хосте получает ошибку:
>> front14 2017/06/15 15:37:40 [error] 13063#13063: *2446289 upstream timed
>> out (110: Connection timed out) while connecting to upstream, client:
>> 217.69.135.0, server: site, request: "GET /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg
>> HTTP/1.0", upstream: "fastcgi://217.69.137.52:8081", host: "site"
>>
>> после получения ошибки nginx проксирует запрос на другой сервер и там все
>> отрабатывает нормально.
>>
>> front14 217.69.135.0 - - [15/Jun/2017:15:37:41 +0300] "GET
>> /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg HTTP/1.0" 200
>> 139517 "-" "okhttp/3.4.1" "-" request_time: 1.660 upstream_addr:
>> 217.69.137.52:8081, 217.69.137.51:8081 upstream_response_time: 0.677,
>> 0.981 upstream_status: 504, 200 upstream_cache_status: - "tid:"
>> 13063-1497530259.494-217.69.135.0-163-2446289
>>
>> Меня волнует это так как увеличивается время ответа и всегда есть некий
>> фоновый поток 504 ошибок. Подскажите, пожалуйста почему возникает таймаут и
>> как его избежать?
>>
>> Файл nginx-debug с одной проблемной сессией: https://uploadfiles.io/eokgp
>> Файл конфигурации nginx: https://ufile.io/w8x56
>> Список upstream: https://ufile.io/3tt84
>> Cписок параметров fastcgi: https://ufile.io/gdzaa
>> Sysctl: https://ufile.io/cdboz
>>
>> Снимал несколько раз tcpdump и наблюдал следующую картину:
>> 1) хост с nginx послылает FIN на бэкенд сразу после своего же ACK бэкенду
>> через 13ms, не пересылая данные вообще.
>> 2) хост с nginx посылает RST через 10 мкс после получения SYN, ACK от
>> бэкенда и через ~ 780 мкс от своего SYN.
>>
>> типовой ss -i
>> ESTAB      0      0          217.69.134.124:40538        217.69.137.52:tproxy
>>
>>      cubic wscale:7,7 rto:202 rtt:2.75/1.5 cwnd:10 bytes_acked:865
>> segs_out:3 segs_in:2 send 42.1Mbps rcv_space:14600
>>
>> Не понятно почему при настройке nginx fastcgi_connect_timeout 300ms; в
>> логе вижу upstream_response_time: 0.677 секунды. Есть этому объяснение?
>>
>> Спасибо всем,
>> Александр
>>
>> _______________________________________________
>> 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/20170615/bde5fdb5/attachment-0001.html>

From al.al.platonov на gmail.com  Thu Jun 15 18:07:39 2017
From: al.al.platonov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3RgCDQn9C70LDRgtC+0L3QvtCy?=)
Date: Thu, 15 Jun 2017 21:07:39 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <20170615151301.d4vezsum6pfklj7f@protva.ru>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
 <20170615151301.d4vezsum6pfklj7f@protva.ru>
Message-ID: <CAEB8VFKSCxw2WzCq=Uw-5xh8GiSgEbDDiV8DgCMGdG8QrtnVuQ@mail.gmail.com>

>
>  Это совсем не похоже на таймаут. Возможно, перепутаны коннекции в дампе,
>  проверьте номера портов и tcp seq
>
>  А это похоже на таймаут коннекта. Вопрос в том, почему SYN+ACK от бэкенда
>  пришёл с такой задержкой. Возможно, бэкенд перегружен.
>  Возможно, свитчи по пути перегружены трафиком.


Дампы:
RST: https://ufile.io/09s7w
FIN: https://ufile.io/0bkq5

это вот эти два запроса
2017/06/15 13:12:43 [error] 8449#8449: *729923 upstream timed out (110:
Connection timed out) while connecting to upstream, client: 128.74.129.198,
server: site, request: "GET /api/v1/product/58a2ed54d53f3d224a6b05c5
HTTP/1.1", upstream: "fastcgi://217.69.137.168:8080", host: "api.site"
2017/06/15 13:12:43 [error] 8471#8471: *734373 upstream timed out (110:
Connection timed out) while connecting to upstream, client: 31.173.243.12,
server: site, request: "GET
/api/v1/counters/5730243396ad843510595f43?adv_id=D5D4F8D7-DEB7-4FE0-807E-143651398124&app_id=iphone%2F3782&timestamp=1497521562&uid=uid&usr_latitude=55.0252283782156&usr_longitude=82.93059721079625
HTTP/1.1", upstream: "fastcgi://217.69.137.73:8080", host: "api.site"

rtt порядка 1-2 миллисекунд, таймаут 300 миллисекунд. Время до посылки FIN
и RST это величина до десятков миллисекунд. Я ожидал увидеть RST через ~
300 миллисекунд.
Возможно  с RST это вторая попытка отправить пакет через RTO + некоторое
время, но из debug log nginx я не понял сколько было попыток, вроде одна.
FIN объяснить не могу. Так как запросов мало, примерно один запрос на один
ip:port в секунду, то проблемые сессии легко видны в tcpdump.

Возможно, бэкенд перегружен.
> Возможно, свитчи по пути перегружены трафиком. Бэкенд создал 50% от max
> кол-ва воркеров, там динамический пул. По остальным ресурсам тоже ок.
>
> Сеть на портах загружена на 5-7%, за всю сеть не скажу, но хосты раскиданы
по трем ДЦ ~ хаотично и закономерности я не вижу.
Если бы воспроизводилась в одном месте, то я бы видел максимумы ошибок,
связанные с одним хостом/дц. Ситуация была бы и на других проектах, но пока
такого не замечали.

> > Не понятно почему при настройке nginx fastcgi_connect_timeout 300ms; в
> логе
> > вижу upstream_response_time: 0.677 секунды. Есть этому объяснение?
>
>  Коннект это одно, а ожидание ответа бэкенда ПОСЛЕ завершения коннекта
>  это другое. Можно сконнектиться, послать запрос и долго ждать ответа.
>
> Можно, но это в моем понимание будет уже таймаут на получение ответа после
установления соединения и он равен ~ 2 мин.
Разве в это поле не должен подставиться +- таймаут, ведь код ответа уже
есть?

Александр

15 июня 2017 г., 18:13 пользователь Evgeniy Berdnikov <bgx на protva.ru>
написал:

> On Thu, Jun 15, 2017 at 05:21:38PM +0300, Алексанр Платонов wrote:
> > У меня есть ~30 хостов в 3-х разных ДЦ. Nginx принимает нагрузку и
> > распределяет её по алгоритму WRR на php-fpm пулы, расположенные на этих
> же
> > хостах.
> >
> > Периодически, примерно 1/5000 (ошибка к общему кол-ву запросов)  на
> > случайном хосте получает ошибку:
> > front14 2017/06/15 15:37:40 [error] 13063#13063: *2446289 upstream timed
> > out (110: Connection timed out) while connecting to upstream, client:
> > 217.69.135.0, server: site, request: "GET
> > /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg
> > HTTP/1.0", upstream: "fastcgi://217.69.137.52:8081", host: "site"
> >
> > после получения ошибки nginx проксирует запрос на другой сервер и там все
> > отрабатывает нормально.
> >
> > front14 217.69.135.0 - - [15/Jun/2017:15:37:41 +0300] "GET
> > /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg HTTP/1.0" 200
> > 139517 "-" "okhttp/3.4.1" "-" request_time: 1.660 upstream_addr:
> > 217.69.137.52:8081, 217.69.137.51:8081 upstream_response_time: 0.677,
> 0.981
> > upstream_status: 504, 200 upstream_cache_status: - "tid:"
> > 13063-1497530259.494-217.69.135.0-163-2446289
> ...
> > Снимал несколько раз tcpdump и наблюдал следующую картину:
> > 1) хост с nginx послылает FIN на бэкенд сразу после своего же ACK бэкенду
> > через 13ms, не пересылая данные вообще.
>
>  Это совсем не похоже на таймаут. Возможно, перепутаны коннекции в дампе,
>  проверьте номера портов и tcp seq
>
>
> > 2) хост с nginx посылает RST через 10 мкс после получения SYN, ACK от
> > бэкенда и через ~ 780 мкс от своего SYN.
>
>  А это похоже на таймаут коннекта. Вопрос в том, почему SYN+ACK от бэкенда
>  пришёл с такой задержкой. Возможно, бэкенд перегружен.
>  Возможно, свитчи по пути перегружены трафиком.
>
> > Не понятно почему при настройке nginx fastcgi_connect_timeout 300ms; в
> логе
> > вижу upstream_response_time: 0.677 секунды. Есть этому объяснение?
>
>  Коннект это одно, а ожидание ответа бэкенда ПОСЛЕ завершения коннекта
>  это другое. Можно сконнектиться, послать запрос и долго ждать ответа.
> --
>  Eugene Berdnikov
> _______________________________________________
> 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/20170615/60254e5b/attachment.html>

From al.al.platonov на gmail.com  Thu Jun 15 18:38:08 2017
From: al.al.platonov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3RgCDQn9C70LDRgtC+0L3QvtCy?=)
Date: Thu, 15 Jun 2017 21:38:08 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <20170615152424.GZ55433@mdounin.ru>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
 <20170615152424.GZ55433@mdounin.ru>
Message-ID: <CAEB8VFLR6Tzox7pUr-9EcpSNiZFXHwEQW70VdnJvDcVwUS6Adg@mail.gmail.com>

>
> При connect-таймауте в 300 миллисекунд любой потерянный пакет
> будет приводить к таймауту.  А какой-то процент потерянных пакетов - это
> нормальное состояние любой сети, так что нет причин удивляться
> тому, что часть соединений при таких настройках таймаутится.
>
Да, какая-то часть таймаутиться будет, это нормально. Я ожидал другого
времени в логе +- 300мс.
Если таймаут поднять и умрет ДЦ, то 1/3  запросов в api будет с сильно
увеличенным временем ответа, а это приведет к тормозам всего сервиса.
Локально обрабатывать трафик - железо разное.
Завтра подниму до 700, посмотрим на результат.

Кроме того, следует понимать, что время внутри nginx'а обновляется
> единожды за итерацию цикла обработки событий.  В результате если
> обработка какого-то события занимает существенное время и/или
> таких событий много, это может сказаться как на latency операций в
> целом, так и на точности работы отдельных таймаутов.  Поскольку
> 300 миллисекунд - время достаточно малое, это может быть заметно,
> если сервер сильно нагружен и/или где-то блокируется.
>

Сейчас ~ 150 rps на хост, машина не нагружена более чем на 40%. ~ в каких
временных пределах может быть погрешность?

В связи с вышеизложенным не могу не отметить, что в вашем конфиге
> видны следы стороннего модуля отправки статистики в graphite.
> Судя по коду[1], в tcp-режиме этот модуль блокирует рабочий процесс
> при отправке накопленной статистики на сервер.  Это, скажем мягко,
> малопригодное для production-использования решение, так что стоит
> начать с простого - убрать модуль совсем, и посмотреть на
> результат.


Большое спасибо, отправил замечание. У нас UDP.
nginx.conf: https://ufile.io/w25u7

Александр

15 июня 2017 г., 18:24 пользователь Maxim Dounin <mdounin на mdounin.ru>
написал:

> Hello!
>
> On Thu, Jun 15, 2017 at 05:21:38PM +0300, Алексанр Платонов wrote:
>
> > Добрый день.
> >
> > У меня есть ~30 хостов в 3-х разных ДЦ. Nginx принимает нагрузку и
> > распределяет её по алгоритму WRR на php-fpm пулы, расположенные на этих
> же
> > хостах.
> >
> > Периодически, примерно 1/5000 (ошибка к общему кол-ву запросов)  на
> > случайном хосте получает ошибку:
> > front14 2017/06/15 15:37:40 [error] 13063#13063: *2446289 upstream timed
> > out (110: Connection timed out) while connecting to upstream, client:
> > 217.69.135.0, server: site, request: "GET
> > /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg
> > HTTP/1.0", upstream: "fastcgi://217.69.137.52:8081", host: "site"
> >
> > после получения ошибки nginx проксирует запрос на другой сервер и там все
> > отрабатывает нормально.
> >
> > front14 217.69.135.0 - - [15/Jun/2017:15:37:41 +0300] "GET
> > /files/images/1284_1284/58/b4/58b455be4b559395714059e5.jpg HTTP/1.0" 200
> > 139517 "-" "okhttp/3.4.1" "-" request_time: 1.660 upstream_addr:
> > 217.69.137.52:8081, 217.69.137.51:8081 upstream_response_time: 0.677,
> 0.981
> > upstream_status: 504, 200 upstream_cache_status: - "tid:"
> > 13063-1497530259.494-217.69.135.0-163-2446289
> >
> > Меня волнует это так как увеличивается время ответа и всегда есть некий
> > фоновый поток 504 ошибок. Подскажите, пожалуйста почему возникает
> таймаут и
> > как его избежать?
> >
> > Файл nginx-debug с одной проблемной сессией:
> https://uploadfiles.io/eokgp
> > Файл конфигурации nginx: https://ufile.io/w8x56
> > Список upstream: https://ufile.io/3tt84
> > Cписок параметров fastcgi: https://ufile.io/gdzaa
> > Sysctl: https://ufile.io/cdboz
> >
> > Снимал несколько раз tcpdump и наблюдал следующую картину:
> > 1) хост с nginx послылает FIN на бэкенд сразу после своего же ACK бэкенду
> > через 13ms, не пересылая данные вообще.
> > 2) хост с nginx посылает RST через 10 мкс после получения SYN, ACK от
> > бэкенда и через ~ 780 мкс от своего SYN.
> >
> > типовой ss -i
> > ESTAB      0      0          217.69.134.124:40538        217.69.137.52:
> tproxy
> >
> >      cubic wscale:7,7 rto:202 rtt:2.75/1.5 cwnd:10 bytes_acked:865
> > segs_out:3 segs_in:2 send 42.1Mbps rcv_space:14600
> >
> > Не понятно почему при настройке nginx fastcgi_connect_timeout 300ms; в
> логе
> > вижу upstream_response_time: 0.677 секунды. Есть этому объяснение?
>
> При connect-таймауте в 300 миллисекунд любой потерянный пакет
> будет приводить к таймауту.  А какой-то процент потерянных пакетов - это
> нормальное состояние любой сети, так что нет причин удивляться
> тому, что часть соединений при таких настройках таймаутится.
>
> Кроме того, следует понимать, что время внутри nginx'а обновляется
> единожды за итерацию цикла обработки событий.  В результате если
> обработка какого-то события занимает существенное время и/или
> таких событий много, это может сказаться как на latency операций в
> целом, так и на точности работы отдельных таймаутов.  Поскольку
> 300 миллисекунд - время достаточно малое, это может быть заметно,
> если сервер сильно нагружен и/или где-то блокируется.
>
> В связи с вышеизложенным не могу не отметить, что в вашем конфиге
> видны следы стороннего модуля отправки статистики в graphite.
> Судя по коду[1], в tcp-режиме этот модуль блокирует рабочий процесс
> при отправке накопленной статистики на сервер.  Это, скажем мягко,
> малопригодное для production-использования решение, так что стоит
> начать с простого - убрать модуль совсем, и посмотреть на
> результат.
>
> [1] https://github.com/mailru/graphite-nginx-module/blob/
> master/src/ngx_http_graphite_module.c#L2204
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> 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/20170615/8a822146/attachment-0001.html>

From mdounin на mdounin.ru  Thu Jun 15 20:44:14 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 15 Jun 2017 23:44:14 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <CAEB8VFLR6Tzox7pUr-9EcpSNiZFXHwEQW70VdnJvDcVwUS6Adg@mail.gmail.com>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
 <20170615152424.GZ55433@mdounin.ru>
 <CAEB8VFLR6Tzox7pUr-9EcpSNiZFXHwEQW70VdnJvDcVwUS6Adg@mail.gmail.com>
Message-ID: <20170615204414.GC55433@mdounin.ru>

Hello!

On Thu, Jun 15, 2017 at 09:38:08PM +0300, Алексанр Платонов wrote:

> > При connect-таймауте в 300 миллисекунд любой потерянный пакет
> > будет приводить к таймауту.  А какой-то процент потерянных пакетов - это
> > нормальное состояние любой сети, так что нет причин удивляться
> > тому, что часть соединений при таких настройках таймаутится.
>
> Да, какая-то часть таймаутиться будет, это нормально. Я ожидал другого
> времени в логе +- 300мс.
> Если таймаут поднять и умрет ДЦ, то 1/3  запросов в api будет с сильно
> увеличенным временем ответа, а это приведет к тормозам всего сервиса.
> Локально обрабатывать трафик - железо разное.
> Завтра подниму до 700, посмотрим на результат.

Время в логе - следствие ровно того же самого, время обновляется 
единожды за итерацию.  Если таймаут 300 миллисекунд, а время 677 - 
значит, в течении "лишних" 377 миллисекунд nginx был занят 
обработкой других запросов в рамках одной итерации цикла обработки 
событий.

> > Кроме того, следует понимать, что время внутри nginx'а обновляется
> > единожды за итерацию цикла обработки событий.  В результате если
> > обработка какого-то события занимает существенное время и/или
> > таких событий много, это может сказаться как на latency операций в
> > целом, так и на точности работы отдельных таймаутов.  Поскольку
> > 300 миллисекунд - время достаточно малое, это может быть заметно,
> > если сервер сильно нагружен и/или где-то блокируется.
> 
> Сейчас ~ 150 rps на хост, машина не нагружена более чем на 40%. ~ в каких
> временных пределах может быть погрешность?

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

За какое время отрабатывает одна итерация цикла обработки 
соединений - можно грубо оценить по debug log'у, смотреть строки 
"timer delta".  Там выводится время с начала предыдущей итерации, 
для нагруженного сервера - это фактически время выполнения всей 
предыдущей итерации.

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

From bgx на protva.ru  Thu Jun 15 21:42:43 2017
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Fri, 16 Jun 2017 00:42:43 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <CAEB8VFKSCxw2WzCq=Uw-5xh8GiSgEbDDiV8DgCMGdG8QrtnVuQ@mail.gmail.com>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
 <20170615151301.d4vezsum6pfklj7f@protva.ru>
 <CAEB8VFKSCxw2WzCq=Uw-5xh8GiSgEbDDiV8DgCMGdG8QrtnVuQ@mail.gmail.com>
Message-ID: <20170615214243.olp4x7z32vckt2fp@protva.ru>

On Thu, Jun 15, 2017 at 09:07:39PM +0300, Алексанр Платонов wrote:
> >  А это похоже на таймаут коннекта. Вопрос в том, почему SYN+ACK от бэкенда
> >  пришёл с такой задержкой. Возможно, бэкенд перегружен.
> >  Возможно, свитчи по пути перегружены трафиком.
> 
> Дампы:
> RST: https://ufile.io/09s7w
> FIN: https://ufile.io/0bkq5

 В обоих дампах время около 2017-06-14 20:41:12, т.е. вчерашний день.

> это вот эти два запроса
> 2017/06/15 13:12:43 [error] 8449#8449: *729923 upstream timed out (110:
> Connection timed out) while connecting to upstream, client: 128.74.129.198,
> server: site, request: "GET /api/v1/product/58a2ed54d53f3d224a6b05c5
> HTTP/1.1", upstream: "fastcgi://217.69.137.168:8080", host: "api.site"
> 2017/06/15 13:12:43 [error] 8471#8471: *734373 upstream timed out (110:
> Connection timed out) while connecting to upstream, client: 31.173.243.12,
> server: site, request: "GET
> /api/v1/counters/5730243396ad843510595f43?adv_id=D5D4F8D7-DEB7-4FE0-807E-143651398124&app_id=iphone%2F3782&timestamp=1497521562&uid=uid&usr_latitude=55.0252283782156&usr_longitude=82.93059721079625
> HTTP/1.1", upstream: "fastcgi://217.69.137.73:8080", host: "api.site"

 А здесь другое время, и другой день. Логи с дампами не стыкуются.

> Возможно  с RST это вторая попытка отправить пакет через RTO + некоторое
> время, но из debug log nginx я не понял сколько было попыток, вроде одна.

 Nginx не может знать, сколько было ретрансмиссий, эта информация из ядра
 ему не передаётся. Но потерять в pcap-е пакеты практически невозможно.

 Да, дампы странные. Однако желательна привязка к логам.

> по трем ДЦ ~ хаотично и закономерности я не вижу.
> Если бы воспроизводилась в одном месте, то я бы видел максимумы ошибок,
> связанные с одним хостом/дц. Ситуация была бы и на других проектах, но пока
> такого не замечали.

 Это может быть отражением того, что проблема как-то связана с конфигурацией
 nginx для конкретного проекта, возможно, с "левыми" модулями.
-- 
 Eugene Berdnikov

From simplebox66 на gmail.com  Fri Jun 16 13:57:04 2017
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Fri, 16 Jun 2017 16:57:04 +0300
Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviBpbm9kZSDQuNC3LdC30LAg0Lo=?=
 =?UTF-8?B?0LXRiNCw?=
In-Reply-To: <20170609153850.GB55433@mdounin.ru>
References: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
 <20170609153850.GB55433@mdounin.ru>
Message-ID: <CA+ksgAD6FU58QVtL75oW=XBgn_b4WQOjYic_VJYmF=jfjs40QQ@mail.gmail.com>

Крахов файловой системы не было, каталог /tmp/ram отдан исключительно под
кеш nginx. За последнюю неделю набежало 5941794 файлов нулевого размера в
кеш каталоге.
В общем эта проблема очень актуальна для меня и преследует уже не первый
месяц, есть у кого-нибудь идеи как я могу отдиагностировать ситуацию?
Максим, можно подробнее про "кончилось место при копировании из каталога со
временными файлами", не совсем понимаю что ты имеешь ввиду?

9 июня 2017 г., 18:38 пользователь Maxim Dounin <mdounin на mdounin.ru>
написал:

> Hello!
>
> On Fri, Jun 09, 2017 at 04:26:09PM +0300, Иван Мишин wrote:
>
> > Всем привет.
> > Столкнулся со следующей проблемой:
> > nginx последней стабильной версии
> > ОС CentsOS 6.9
> > кеш в ramfs на 28Гб со следующими настройками:
> >
> > > proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m
> > > max_size=28000m inactive=1440m;
> > >         proxy_temp_path /tmp/cache/nginx/proxy_temp;
> > >         proxy_cache_key $server_name$request_uri;
> >
> >
> > Довольно активно растет кол-во inode на ramfs. Стал изучать ситуацию,
> > оказалось в кеше лежит куча файлов нулевого размера при чем среди них
> есть
> > и очень старые (месячной давности например). На 28Гб кеша, оказалось
> более
> > 6млн Inode задействовано, при этом после удаления нулевых файлов осталось
> > всего около 200к inode.
> > Вопрос зачем nginx хранит до бесконечности нулевые файлы? Как от этого
> > избавиться?
>
> Файлы нулевого размера в кеше - это не nginx, по крайней мере не
> его штатная работа, он просто не умеет ничего подобного создавать.
> Либо это последствия каких-то ошибок (кончилось место при
> копировании из каталога со временными файлами?), либо просто
> результат краха файловой системы.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> 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/20170616/b91a873d/attachment.html>

From mdounin на mdounin.ru  Fri Jun 16 14:25:24 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Fri, 16 Jun 2017 17:25:24 +0300
Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviBpbm9kZSDQuNC3LdC30LAg0Lo=?=
 =?UTF-8?B?0LXRiNCw?=
In-Reply-To: <CA+ksgAD6FU58QVtL75oW=XBgn_b4WQOjYic_VJYmF=jfjs40QQ@mail.gmail.com>
References: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
 <20170609153850.GB55433@mdounin.ru>
 <CA+ksgAD6FU58QVtL75oW=XBgn_b4WQOjYic_VJYmF=jfjs40QQ@mail.gmail.com>
Message-ID: <20170616142524.GF55433@mdounin.ru>

Hello!

On Fri, Jun 16, 2017 at 04:57:04PM +0300, Иван Мишин wrote:

> Крахов файловой системы не было, каталог /tmp/ram отдан исключительно под
> кеш nginx. За последнюю неделю набежало 5941794 файлов нулевого размера в
> кеш каталоге.
> В общем эта проблема очень актуальна для меня и преследует уже не первый
> месяц, есть у кого-нибудь идеи как я могу отдиагностировать ситуацию?
> Максим, можно подробнее про "кончилось место при копировании из каталога со
> временными файлами", не совсем понимаю что ты имеешь ввиду?

Если proxy_temp_path и proxy_cache_path находятся на разных 
файловых системах, то просто переместить временный файл в кеш 
нельзя, приходится его копировать, создав новый файл.  Подробнее 
про это рассказывается в описании директивы proxy_cache_path:

http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path

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

Отмечу в скобках, что если вот это:

> > > кеш в ramfs на 28Гб со следующими настройками:
> > >
> > > > proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m
> > > > max_size=28000m inactive=1440m;

и правда озаначает, что размер ramfs - 28 гигабайт, то результат 
ожидаем.

Вы сказали nginx'у, что начинать чистить кеш надо при превышении 
размера в 28 гигабайт.  Если cache manager отвлечётся хоть немного 
на другие задачи (а он может заниматься другими кешами, если они 
есть, или просто уйти спать на 10 секунд, почистив всё) - файловая 
система переполнится, и будут ошибки.  Вам надо менять настройки.

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

From basil на vpm.net.ua  Fri Jun 16 19:21:13 2017
From: basil на vpm.net.ua (Vasiliy P. Melnik)
Date: Fri, 16 Jun 2017 22:21:13 +0300
Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviBpbm9kZSDQuNC3LdC30LAg0Lo=?=
 =?UTF-8?B?0LXRiNCw?=
In-Reply-To: <20170616142524.GF55433@mdounin.ru>
References: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
 <20170609153850.GB55433@mdounin.ru>
 <CA+ksgAD6FU58QVtL75oW=XBgn_b4WQOjYic_VJYmF=jfjs40QQ@mail.gmail.com>
 <20170616142524.GF55433@mdounin.ru>
Message-ID: <CAMPJU7AWxEL=hqRx5TVpzw+HRL1Ts-qjsSWShfKE_GUGb2f0VA@mail.gmail.com>

Здравствуйте

Раз уж пошла такая пьянка, то может подскажете, есть какие-то
противопоказания насчет использования use_temp_path=off


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

> Hello!
>
> On Fri, Jun 16, 2017 at 04:57:04PM +0300, Иван Мишин wrote:
>
> > Крахов файловой системы не было, каталог /tmp/ram отдан исключительно под
> > кеш nginx. За последнюю неделю набежало 5941794 файлов нулевого размера в
> > кеш каталоге.
> > В общем эта проблема очень актуальна для меня и преследует уже не первый
> > месяц, есть у кого-нибудь идеи как я могу отдиагностировать ситуацию?
> > Максим, можно подробнее про "кончилось место при копировании из каталога
> со
> > временными файлами", не совсем понимаю что ты имеешь ввиду?
>
> Если proxy_temp_path и proxy_cache_path находятся на разных
> файловых системах, то просто переместить временный файл в кеш
> нельзя, приходится его копировать, создав новый файл.  Подробнее
> про это рассказывается в описании директивы proxy_cache_path:
>
> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path
>
> Если в процессе копирования произойдёт ошибка, например из-за
> того, что файловая система, на которой располагается кеш,
> переполнена, то в логе будет ошибка уровня alert, а в кеше
> останется лежать недописанный файл.
>
> Отмечу в скобках, что если вот это:
>
> > > > кеш в ramfs на 28Гб со следующими настройками:
> > > >
> > > > > proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m
> > > > > max_size=28000m inactive=1440m;
>
> и правда озаначает, что размер ramfs - 28 гигабайт, то результат
> ожидаем.
>
> Вы сказали nginx'у, что начинать чистить кеш надо при превышении
> размера в 28 гигабайт.  Если cache manager отвлечётся хоть немного
> на другие задачи (а он может заниматься другими кешами, если они
> есть, или просто уйти спать на 10 секунд, почистив всё) - файловая
> система переполнится, и будут ошибки.  Вам надо менять настройки.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> 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/20170616/f6c8b5f6/attachment-0001.html>

From nginx на kinetiksoft.com  Sun Jun 18 04:31:05 2017
From: nginx на kinetiksoft.com (=?utf-8?B?0JjQstCw0L0=?=)
Date: Sun, 18 Jun 2017 07:31:05 +0300
Subject: =?UTF-8?B?0J3QtSDRgdGA0LDQsdCw0YLRi9Cy0LDQtdGCIHJlYWxpcCDQsiDQsdC70L7QutC1?=
 =?UTF-8?B?IGlm?=
Message-ID: <1908289.vW82DkHVpK@cybernote>

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

В конструкции

location /login/
	set_real_ip_from proxy_IP;
	if ($block_agent) {
		return 403;
    }
}

Всё, что попадает в блок if ($block_agent == 1), в логи пишется с $remote_addr 
проксирующего сервера (proxy_IP), то есть set_real_ip_from не отрабатывает. 
set_real_ip_from поместить в блок include nginx не дает. Пока что решил 
проблему меняя формат логов для в блоке if, но что это, баг\фича? И можно ли 
исправить?

# nginx -V
nginx version: nginx/1.12.0
built by gcc 4.9.2 (Debian 4.9.2-10) 
built with OpenSSL 1.0.1t  3 May 2016
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --
modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-
log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --
pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --
with-file-aio --with-threads --with-http_addition_module --with-
http_auth_request_module --with-http_dav_module --with-http_flv_module --with-
http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --
with-http_random_index_module --with-http_realip_module --with-
http_secure_link_module --with-http_slice_module --with-http_ssl_module --
with-http_stub_status_module --with-http_sub_module --with-http_v2_module --
with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --
with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 
-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'

С уважением, Иван.

From simplebox66 на gmail.com  Mon Jun 19 07:40:04 2017
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Mon, 19 Jun 2017 10:40:04 +0300
Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviBpbm9kZSDQuNC3LdC30LAg0Lo=?=
 =?UTF-8?B?0LXRiNCw?=
In-Reply-To: <CAMPJU7AWxEL=hqRx5TVpzw+HRL1Ts-qjsSWShfKE_GUGb2f0VA@mail.gmail.com>
References: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
 <20170609153850.GB55433@mdounin.ru>
 <CA+ksgAD6FU58QVtL75oW=XBgn_b4WQOjYic_VJYmF=jfjs40QQ@mail.gmail.com>
 <20170616142524.GF55433@mdounin.ru>
 <CAMPJU7AWxEL=hqRx5TVpzw+HRL1Ts-qjsSWShfKE_GUGb2f0VA@mail.gmail.com>
Message-ID: <CA+ksgAAMP=dgA7+xybnseBwUjKvEdctpsdhHkoTgrOoQraTvXw@mail.gmail.com>

Максим, спасибо за детальное объяснение, на днях буду внедрять изменения и
наблюдать, по происшествии времени отпишусь о результате.

16 июня 2017 г., 22:21 пользователь Vasiliy P. Melnik <basil на vpm.net.ua>
написал:

> Здравствуйте
>
> Раз уж пошла такая пьянка, то может подскажете, есть какие-то
> противопоказания насчет использования use_temp_path=off
>
>
> 16 июня 2017 г., 17:25 пользователь Maxim Dounin <mdounin на mdounin.ru>
> написал:
>
> Hello!
>>
>> On Fri, Jun 16, 2017 at 04:57:04PM +0300, Иван Мишин wrote:
>>
>> > Крахов файловой системы не было, каталог /tmp/ram отдан исключительно
>> под
>> > кеш nginx. За последнюю неделю набежало 5941794 файлов нулевого размера
>> в
>> > кеш каталоге.
>> > В общем эта проблема очень актуальна для меня и преследует уже не первый
>> > месяц, есть у кого-нибудь идеи как я могу отдиагностировать ситуацию?
>> > Максим, можно подробнее про "кончилось место при копировании из
>> каталога со
>> > временными файлами", не совсем понимаю что ты имеешь ввиду?
>>
>> Если proxy_temp_path и proxy_cache_path находятся на разных
>> файловых системах, то просто переместить временный файл в кеш
>> нельзя, приходится его копировать, создав новый файл.  Подробнее
>> про это рассказывается в описании директивы proxy_cache_path:
>>
>> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_path
>>
>> Если в процессе копирования произойдёт ошибка, например из-за
>> того, что файловая система, на которой располагается кеш,
>> переполнена, то в логе будет ошибка уровня alert, а в кеше
>> останется лежать недописанный файл.
>>
>> Отмечу в скобках, что если вот это:
>>
>> > > > кеш в ramfs на 28Гб со следующими настройками:
>> > > >
>> > > > > proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m
>> > > > > max_size=28000m inactive=1440m;
>>
>> и правда озаначает, что размер ramfs - 28 гигабайт, то результат
>> ожидаем.
>>
>> Вы сказали nginx'у, что начинать чистить кеш надо при превышении
>> размера в 28 гигабайт.  Если cache manager отвлечётся хоть немного
>> на другие задачи (а он может заниматься другими кешами, если они
>> есть, или просто уйти спать на 10 секунд, почистив всё) - файловая
>> система переполнится, и будут ошибки.  Вам надо менять настройки.
>>
>> --
>> Maxim Dounin
>> http://nginx.org/
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170619/d82d6066/attachment.html>

From mdounin на mdounin.ru  Mon Jun 19 12:15:10 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 19 Jun 2017 15:15:10 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiByZWFsaXAg0LIg0LHQu9C+?=
 =?UTF-8?B?0LrQtSBpZg==?=
In-Reply-To: <1908289.vW82DkHVpK@cybernote>
References: <1908289.vW82DkHVpK@cybernote>
Message-ID: <20170619121510.GH55433@mdounin.ru>

Hello!

On Sun, Jun 18, 2017 at 07:31:05AM +0300, Иван wrote:

> Здравствуйте!
> 
> В конструкции
> 
> location /login/
> 	set_real_ip_from proxy_IP;
> 	if ($block_agent) {
> 		return 403;
>     }
> }
> 
> Всё, что попадает в блок if ($block_agent == 1), в логи пишется с $remote_addr 
> проксирующего сервера (proxy_IP), то есть set_real_ip_from не отрабатывает. 
> set_real_ip_from поместить в блок include nginx не дает. Пока что решил 
> проблему меняя формат логов для в блоке if, но что это, баг\фича? И можно ли 
> исправить?

Это фича.  Если директива set_real_ip_from задана на уровне 
location, то замена адреса происходит после выбора конфигурации, в 
котором будет обрабатываться запрос, перед работой модулей контроля 
доступа.  А в конфигурации выше - ошибка возвращается с помощью 
директив модуля rewrite, на этапе "выбора конфигурации по 
условию" (см. http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html). 
В результате ошибка 403 случается до того, как адрес клиента 
заменён модулем realip, и в логи попадает исходный ip.

Чтобы подобных сюрпризов не было - правильнее всего задать 
set_real_ip_from на уровне server, тогда замена ip-адреса клиента 
будет происходить сразу после чтения запроса.

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

From alexander.moskalenko на gmail.com  Mon Jun 19 14:00:59 2017
From: alexander.moskalenko на gmail.com (Alexander Moskalenko)
Date: Mon, 19 Jun 2017 16:00:59 +0200
Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiByZWFsaXAg0LIg0LHQu9C+?=
 =?UTF-8?B?0LrQtSBpZg==?=
In-Reply-To: <20170619121510.GH55433@mdounin.ru>
References: <1908289.vW82DkHVpK@cybernote> <20170619121510.GH55433@mdounin.ru>
Message-ID: <CACVfVFtBvCj3T8giVg=YyeQyttNmX0tt3T6TXCd5-66-zjVfUA@mail.gmail.com>

Раз уж зашел разговор о realip....

Максим, а возможно ли указать 2 заголовка realip_header ?

2017-06-19 14:15 GMT+02:00 Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Sun, Jun 18, 2017 at 07:31:05AM +0300, Иван wrote:
>
> > Здравствуйте!
> >
> > В конструкции
> >
> > location /login/
> >       set_real_ip_from proxy_IP;
> >       if ($block_agent) {
> >               return 403;
> >     }
> > }
> >
> > Всё, что попадает в блок if ($block_agent == 1), в логи пишется с
> $remote_addr
> > проксирующего сервера (proxy_IP), то есть set_real_ip_from не
> отрабатывает.
> > set_real_ip_from поместить в блок include nginx не дает. Пока что решил
> > проблему меняя формат логов для в блоке if, но что это, баг\фича? И
> можно ли
> > исправить?
>
> Это фича.  Если директива set_real_ip_from задана на уровне
> location, то замена адреса происходит после выбора конфигурации, в
> котором будет обрабатываться запрос, перед работой модулей контроля
> доступа.  А в конфигурации выше - ошибка возвращается с помощью
> директив модуля rewrite, на этапе "выбора конфигурации по
> условию" (см. http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html).
> В результате ошибка 403 случается до того, как адрес клиента
> заменён модулем realip, и в логи попадает исходный ip.
>
> Чтобы подобных сюрпризов не было - правильнее всего задать
> set_real_ip_from на уровне server, тогда замена ip-адреса клиента
> будет происходить сразу после чтения запроса.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170619/ede1e890/attachment.html>

From bgx на protva.ru  Mon Jun 19 14:05:40 2017
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Mon, 19 Jun 2017 17:05:40 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiByZWFsaXAg0LIg0LHQu9C+?=
 =?UTF-8?B?0LrQtSBpZg==?=
In-Reply-To: <CACVfVFtBvCj3T8giVg=YyeQyttNmX0tt3T6TXCd5-66-zjVfUA@mail.gmail.com>
References: <1908289.vW82DkHVpK@cybernote> <20170619121510.GH55433@mdounin.ru>
 <CACVfVFtBvCj3T8giVg=YyeQyttNmX0tt3T6TXCd5-66-zjVfUA@mail.gmail.com>
Message-ID: <20170619140540.wolys5th5y2ejlkp@protva.ru>

On Mon, Jun 19, 2017 at 04:00:59PM +0200, Alexander Moskalenko wrote:
> 
> Максим, а возможно ли указать 2 заголовка realip_header ?

 А что это будет означать?
-- 
 Eugene Berdnikov

From alexander.moskalenko на gmail.com  Mon Jun 19 14:26:59 2017
From: alexander.moskalenko на gmail.com (Alexander Moskalenko)
Date: Mon, 19 Jun 2017 16:26:59 +0200
Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiByZWFsaXAg0LIg0LHQu9C+?=
 =?UTF-8?B?0LrQtSBpZg==?=
In-Reply-To: <20170619140540.wolys5th5y2ejlkp@protva.ru>
References: <1908289.vW82DkHVpK@cybernote> <20170619121510.GH55433@mdounin.ru>
 <CACVfVFtBvCj3T8giVg=YyeQyttNmX0tt3T6TXCd5-66-zjVfUA@mail.gmail.com>
 <20170619140540.wolys5th5y2ejlkp@protva.ru>
Message-ID: <CACVfVFvy4xamxaESyYeLO+VvLvb2TUQeAYyLw3i+-LQqvtbMfQ@mail.gmail.com>

Кейс такой:

Есть 2 CDN, которые передают разные заголовки.
Есть список их IP, хочется получать Real_IP от обоих без танцев

2017-06-19 16:05 GMT+02:00 Evgeniy Berdnikov <bgx на protva.ru>:

> On Mon, Jun 19, 2017 at 04:00:59PM +0200, Alexander Moskalenko wrote:
> >
> > Максим, а возможно ли указать 2 заголовка realip_header ?
>
>  А что это будет означать?
> --
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170619/0c32a16e/attachment.html>

From bgx на protva.ru  Mon Jun 19 15:00:37 2017
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Mon, 19 Jun 2017 18:00:37 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiByZWFsaXAg0LIg0LHQu9C+?=
 =?UTF-8?B?0LrQtSBpZg==?=
In-Reply-To: <CACVfVFvy4xamxaESyYeLO+VvLvb2TUQeAYyLw3i+-LQqvtbMfQ@mail.gmail.com>
References: <1908289.vW82DkHVpK@cybernote> <20170619121510.GH55433@mdounin.ru>
 <CACVfVFtBvCj3T8giVg=YyeQyttNmX0tt3T6TXCd5-66-zjVfUA@mail.gmail.com>
 <20170619140540.wolys5th5y2ejlkp@protva.ru>
 <CACVfVFvy4xamxaESyYeLO+VvLvb2TUQeAYyLw3i+-LQqvtbMfQ@mail.gmail.com>
Message-ID: <20170619150037.nkoahhmjgd3cjj5c@protva.ru>

On Mon, Jun 19, 2017 at 04:26:59PM +0200, Alexander Moskalenko wrote:
> Кейс такой:
> 
> Есть 2 CDN, которые передают разные заголовки.
> Есть список их IP, хочется получать Real_IP от обоих без танцев

 Что значит "обоих"? Вложенные CDN, что ли? Как это? Непонятно.

 При запросе есть один клиент. Стало быть, его rial_ip тоже один.
 Бывает, получателей пакета много (multicast, broadcast, anycast).
 Но отправитель всегда один.

 Возможно, Вы хотите назвать термином "Real_IP" какую-то сущность,
 отличную от привычного для всех rial_ip. В таком случае нужно ввести
 для неё иной термин, иначе получается вынос мозга себе и другим.

 Если речь о каскаде прокси-серверов, есть стандартный заголовок Via:.

> 2017-06-19 16:05 GMT+02:00 Evgeniy Berdnikov <bgx на protva.ru>:
> 
> > On Mon, Jun 19, 2017 at 04:00:59PM +0200, Alexander Moskalenko wrote:
> > >
> > > Максим, а возможно ли указать 2 заголовка realip_header ?
> >
> >  А что это будет означать?

 PS. Top quoting considered harmful.
-- 
 Eugene Berdnikov

From alexander.moskalenko на gmail.com  Mon Jun 19 15:17:18 2017
From: alexander.moskalenko на gmail.com (Alexander Moskalenko)
Date: Mon, 19 Jun 2017 17:17:18 +0200
Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiByZWFsaXAg0LIg0LHQu9C+?=
 =?UTF-8?B?0LrQtSBpZg==?=
In-Reply-To: <20170619150037.nkoahhmjgd3cjj5c@protva.ru>
References: <1908289.vW82DkHVpK@cybernote> <20170619121510.GH55433@mdounin.ru>
 <CACVfVFtBvCj3T8giVg=YyeQyttNmX0tt3T6TXCd5-66-zjVfUA@mail.gmail.com>
 <20170619140540.wolys5th5y2ejlkp@protva.ru>
 <CACVfVFvy4xamxaESyYeLO+VvLvb2TUQeAYyLw3i+-LQqvtbMfQ@mail.gmail.com>
 <20170619150037.nkoahhmjgd3cjj5c@protva.ru>
Message-ID: <CACVfVFtp9vQBb8o_=4p11jhErJ7cwutnw5O1o5K-6XpXP_L+yA@mail.gmail.com>

2017-06-19 17:00 GMT+02:00 Evgeniy Berdnikov <bgx на protva.ru>:

> On Mon, Jun 19, 2017 at 04:26:59PM +0200, Alexander Moskalenko wrote:
> > Кейс такой:
> >
> > Есть 2 CDN, которые передают разные заголовки.
> > Есть список их IP, хочется получать Real_IP от обоих без танцев
>
>  Что значит "обоих"? Вложенные CDN, что ли? Как это? Непонятно.
>

2 _разных_ CDN, часть сайтов висит на одном, часть на другом
Конфигурация realip модуля вынесена в блок http
CDN_1 шлет IP клиента в HTTP_HEADER_1
CDN_2 шлет IP клиента в HTTP_HEADER_2

хочется прописать ОБА заголовка в realip_header


>  При запросе есть один клиент. Стало быть, его rial_ip тоже один.
>  Бывает, получателей пакета много (multicast, broadcast, anycast).
>  Но отправитель всегда один.
>
>  Возможно, Вы хотите назвать термином "Real_IP" какую-то сущность,
>  отличную от привычного для всех rial_ip. В таком случае нужно ввести
>  для неё иной термин, иначе получается вынос мозга себе и другим.
>

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


>
>  Если речь о каскаде прокси-серверов, есть стандартный заголовок Via:.


> > 2017-06-19 16:05 GMT+02:00 Evgeniy Berdnikov <bgx на protva.ru>:
> >
> > > On Mon, Jun 19, 2017 at 04:00:59PM +0200, Alexander Moskalenko wrote:
> > > >
> > > > Максим, а возможно ли указать 2 заголовка realip_header ?
> > >
> > >  А что это будет означать?
>
>  PS. Top quoting considered harmful.
> --
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170619/1ce2b6d4/attachment-0001.html>

From mdounin на mdounin.ru  Mon Jun 19 15:42:25 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 19 Jun 2017 18:42:25 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiByZWFsaXAg0LIg0LHQu9C+?=
 =?UTF-8?B?0LrQtSBpZg==?=
In-Reply-To: <CACVfVFtp9vQBb8o_=4p11jhErJ7cwutnw5O1o5K-6XpXP_L+yA@mail.gmail.com>
References: <1908289.vW82DkHVpK@cybernote> <20170619121510.GH55433@mdounin.ru>
 <CACVfVFtBvCj3T8giVg=YyeQyttNmX0tt3T6TXCd5-66-zjVfUA@mail.gmail.com>
 <20170619140540.wolys5th5y2ejlkp@protva.ru>
 <CACVfVFvy4xamxaESyYeLO+VvLvb2TUQeAYyLw3i+-LQqvtbMfQ@mail.gmail.com>
 <20170619150037.nkoahhmjgd3cjj5c@protva.ru>
 <CACVfVFtp9vQBb8o_=4p11jhErJ7cwutnw5O1o5K-6XpXP_L+yA@mail.gmail.com>
Message-ID: <20170619154225.GM55433@mdounin.ru>

Hello!

On Mon, Jun 19, 2017 at 05:17:18PM +0200, Alexander Moskalenko wrote:

> 2017-06-19 17:00 GMT+02:00 Evgeniy Berdnikov <bgx на protva.ru>:
> 
> > On Mon, Jun 19, 2017 at 04:26:59PM +0200, Alexander Moskalenko wrote:
> > > Кейс такой:
> > >
> > > Есть 2 CDN, которые передают разные заголовки.
> > > Есть список их IP, хочется получать Real_IP от обоих без танцев
> >
> >  Что значит "обоих"? Вложенные CDN, что ли? Как это? Непонятно.
> >
> 
> 2 _разных_ CDN, часть сайтов висит на одном, часть на другом
> Конфигурация realip модуля вынесена в блок http
> CDN_1 шлет IP клиента в HTTP_HEADER_1
> CDN_2 шлет IP клиента в HTTP_HEADER_2
> 
> хочется прописать ОБА заголовка в realip_header

Это приведёт к тому, что любой клиент сможет подделать IP, прислав 
запрос через CDN_1 с заголовком HTTP_HEADER_2 (или наоборот - 
через CDN_2 с заголовком HTTP_HEADER_1).  Потому что CDN'ы 
наверняка не фильтрует заголовки, которые сами не выставляют.

Чтобы работало хоть сколько-нибудь безопасно - нужно, фактически, 
делать отдельные конфигурации, с каких адресов принимать какой 
заголовок.  Такого realip-модуль сейчас не умеет, и в обозримой 
перспективе уметь, скорее всего, не будет.

Проще всего для подобных задач явно делать разные конфигурации, с 
разными блоками server{} для разных CDN.

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

From alexander.moskalenko на gmail.com  Mon Jun 19 15:48:59 2017
From: alexander.moskalenko на gmail.com (Alexander Moskalenko)
Date: Mon, 19 Jun 2017 17:48:59 +0200
Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiByZWFsaXAg0LIg0LHQu9C+?=
 =?UTF-8?B?0LrQtSBpZg==?=
In-Reply-To: <20170619154225.GM55433@mdounin.ru>
References: <1908289.vW82DkHVpK@cybernote> <20170619121510.GH55433@mdounin.ru>
 <CACVfVFtBvCj3T8giVg=YyeQyttNmX0tt3T6TXCd5-66-zjVfUA@mail.gmail.com>
 <20170619140540.wolys5th5y2ejlkp@protva.ru>
 <CACVfVFvy4xamxaESyYeLO+VvLvb2TUQeAYyLw3i+-LQqvtbMfQ@mail.gmail.com>
 <20170619150037.nkoahhmjgd3cjj5c@protva.ru>
 <CACVfVFtp9vQBb8o_=4p11jhErJ7cwutnw5O1o5K-6XpXP_L+yA@mail.gmail.com>
 <20170619154225.GM55433@mdounin.ru>
Message-ID: <CACVfVFucSiGesqVLYVP3khcQ=opKrvq93ZaMzrk455f55xegdw@mail.gmail.com>

2017-06-19 17:42 GMT+02:00 Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Mon, Jun 19, 2017 at 05:17:18PM +0200, Alexander Moskalenko wrote:
>
> > 2017-06-19 17:00 GMT+02:00 Evgeniy Berdnikov <bgx на protva.ru>:
> >
> > > On Mon, Jun 19, 2017 at 04:26:59PM +0200, Alexander Moskalenko wrote:
> > > > Кейс такой:
> > > >
> > > > Есть 2 CDN, которые передают разные заголовки.
> > > > Есть список их IP, хочется получать Real_IP от обоих без танцев
> > >
> > >  Что значит "обоих"? Вложенные CDN, что ли? Как это? Непонятно.
> > >
> >
> > 2 _разных_ CDN, часть сайтов висит на одном, часть на другом
> > Конфигурация realip модуля вынесена в блок http
> > CDN_1 шлет IP клиента в HTTP_HEADER_1
> > CDN_2 шлет IP клиента в HTTP_HEADER_2
> >
> > хочется прописать ОБА заголовка в realip_header
>
> Это приведёт к тому, что любой клиент сможет подделать IP, прислав
> запрос через CDN_1 с заголовком HTTP_HEADER_2 (или наоборот -
> через CDN_2 с заголовком HTTP_HEADER_1).  Потому что CDN'ы
> наверняка не фильтрует заголовки, которые сами не выставляют.
>
> Чтобы работало хоть сколько-нибудь безопасно - нужно, фактически,
> делать отдельные конфигурации, с каких адресов принимать какой
> заголовок.  Такого realip-модуль сейчас не умеет, и в обозримой
> перспективе уметь, скорее всего, не будет.
>
> Проще всего для подобных задач явно делать разные конфигурации, с
> разными блоками server{} для разных CDN.
>
> Как вариант что-то подобное вполне бы устроило.

Насчет безопасности - допустим я на стороне CDN могу удалить небезопасные
заголовки, а вот управлять названием realip-header - нет.

--
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170619/24321404/attachment.html>

From bgx на protva.ru  Mon Jun 19 15:50:28 2017
From: bgx на protva.ru (Evgeniy Berdnikov)
Date: Mon, 19 Jun 2017 18:50:28 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiByZWFsaXAg0LIg0LHQu9C+?=
 =?UTF-8?B?0LrQtSBpZg==?=
In-Reply-To: <CACVfVFtp9vQBb8o_=4p11jhErJ7cwutnw5O1o5K-6XpXP_L+yA@mail.gmail.com>
References: <1908289.vW82DkHVpK@cybernote> <20170619121510.GH55433@mdounin.ru>
 <CACVfVFtBvCj3T8giVg=YyeQyttNmX0tt3T6TXCd5-66-zjVfUA@mail.gmail.com>
 <20170619140540.wolys5th5y2ejlkp@protva.ru>
 <CACVfVFvy4xamxaESyYeLO+VvLvb2TUQeAYyLw3i+-LQqvtbMfQ@mail.gmail.com>
 <20170619150037.nkoahhmjgd3cjj5c@protva.ru>
 <CACVfVFtp9vQBb8o_=4p11jhErJ7cwutnw5O1o5K-6XpXP_L+yA@mail.gmail.com>
Message-ID: <20170619155028.2l5rf6ugzh33pgev@protva.ru>

On Mon, Jun 19, 2017 at 05:17:18PM +0200, Alexander Moskalenko wrote:
> 2017-06-19 17:00 GMT+02:00 Evgeniy Berdnikov <bgx на protva.ru>:
> 
> > On Mon, Jun 19, 2017 at 04:26:59PM +0200, Alexander Moskalenko wrote:
> > > Кейс такой:
> > >
> > > Есть 2 CDN, которые передают разные заголовки.
> > > Есть список их IP, хочется получать Real_IP от обоих без танцев
> >
> >  Что значит "обоих"? Вложенные CDN, что ли? Как это? Непонятно.
> 
> 2 _разных_ CDN, часть сайтов висит на одном, часть на другом
> Конфигурация realip модуля вынесена в блок http
> CDN_1 шлет IP клиента в HTTP_HEADER_1
> CDN_2 шлет IP клиента в HTTP_HEADER_2
> 
> хочется прописать ОБА заголовка в realip_header

 Если код бэкенда может разобрать один композитный заголовок, почему бы там
 не разобрать заголовки HTTP_HEADER_1 и HTTP_HEADER_2 по отдельности?

 Может быть, хочется определить, какой из заголовков не пуст, и записать
 его содержимое в третий? Раз присутствует лишь один из двух, можно просто
 конкатенировать значения этих заголовков, не нужно даже возиться
 с if(..){set..} или map{}.
-- 
 Eugene Berdnikov

From alexander.moskalenko на gmail.com  Mon Jun 19 16:12:12 2017
From: alexander.moskalenko на gmail.com (Alexander Moskalenko)
Date: Mon, 19 Jun 2017 18:12:12 +0200
Subject: =?UTF-8?B?UmU6INCd0LUg0YHRgNCw0LHQsNGC0YvQstCw0LXRgiByZWFsaXAg0LIg0LHQu9C+?=
 =?UTF-8?B?0LrQtSBpZg==?=
In-Reply-To: <20170619155028.2l5rf6ugzh33pgev@protva.ru>
References: <1908289.vW82DkHVpK@cybernote> <20170619121510.GH55433@mdounin.ru>
 <CACVfVFtBvCj3T8giVg=YyeQyttNmX0tt3T6TXCd5-66-zjVfUA@mail.gmail.com>
 <20170619140540.wolys5th5y2ejlkp@protva.ru>
 <CACVfVFvy4xamxaESyYeLO+VvLvb2TUQeAYyLw3i+-LQqvtbMfQ@mail.gmail.com>
 <20170619150037.nkoahhmjgd3cjj5c@protva.ru>
 <CACVfVFtp9vQBb8o_=4p11jhErJ7cwutnw5O1o5K-6XpXP_L+yA@mail.gmail.com>
 <20170619155028.2l5rf6ugzh33pgev@protva.ru>
Message-ID: <CACVfVFuTHXHF2tO1=6nsqEO0DdbCC8s=_GfYwVFFDn-XHPuWWg@mail.gmail.com>

2017-06-19 17:50 GMT+02:00 Evgeniy Berdnikov <bgx на protva.ru>:

> On Mon, Jun 19, 2017 at 05:17:18PM +0200, Alexander Moskalenko wrote:
> > 2017-06-19 17:00 GMT+02:00 Evgeniy Berdnikov <bgx на protva.ru>:
> >
> > > On Mon, Jun 19, 2017 at 04:26:59PM +0200, Alexander Moskalenko wrote:
> > > > Кейс такой:
> > > >
> > > > Есть 2 CDN, которые передают разные заголовки.
> > > > Есть список их IP, хочется получать Real_IP от обоих без танцев
> > >
> > >  Что значит "обоих"? Вложенные CDN, что ли? Как это? Непонятно.
> >
> > 2 _разных_ CDN, часть сайтов висит на одном, часть на другом
> > Конфигурация realip модуля вынесена в блок http
> > CDN_1 шлет IP клиента в HTTP_HEADER_1
> > CDN_2 шлет IP клиента в HTTP_HEADER_2
> >
> > хочется прописать ОБА заголовка в realip_header
>
>  Если код бэкенда может разобрать один композитный заголовок, почему бы там
>  не разобрать заголовки HTTP_HEADER_1 и HTTP_HEADER_2 по отдельности?
>
>  Может быть, хочется определить, какой из заголовков не пуст, и записать
>  его содержимое в третий? Раз присутствует лишь один из двух, можно просто
>  конкатенировать значения этих заголовков, не нужно даже возиться
>  с if(..){set..} или map{}.
>

Вариантов как поступить я и сам могу предложить множество, спасибо.

Вопрос был задан именно в такой формулировке, о какой функциональности
хотелось получить ответ :)

--
>  Eugene Berdnikov
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170619/01193d85/attachment-0001.html>

From nginx-forum на forum.nginx.org  Mon Jun 19 17:55:46 2017
From: nginx-forum на forum.nginx.org (Ilya Evseev)
Date: Mon, 19 Jun 2017 13:55:46 -0400
Subject: =?UTF-8?B?0JDQstGC0L7QvNCw0YLQuNGH0LXRgdC60L7QtSDRg9Cy0LXQu9C40YfQtdC90Lg=?=
 =?UTF-8?B?0LUgc25kYnVmINC/0YDQuCBFQUdBSU4=?=
Message-ID: <230808fe1ddc1a30ea2a9dbc0b1cf61d.NginxMailingListRussian@forum.nginx.org>

Написал небольшой патч, который автоматически увеличивает размер буфера
отправки, если sendfile вернул EAGAIN.

Вызывается из
https://trac.nginx.org/nginx/browser/nginx/src/os/unix/ngx_linux_sendfile_chain.c#L265

Вопросы:

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

2) если примут, то что ещё в нём обязано быть, кроме собственно кода
увеличения буфера для Линукса и обработки "listen ... maxsndbuf=..." в
конфиге?

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


From mdounin на mdounin.ru  Mon Jun 19 18:56:57 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Mon, 19 Jun 2017 21:56:57 +0300
Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0LzQsNGC0LjRh9C10YHQutC+0LUg0YPQstC10LvQuNGH0LU=?=
 =?UTF-8?B?0L3QuNC1IHNuZGJ1ZiDQv9GA0LggRUFHQUlO?=
In-Reply-To: <230808fe1ddc1a30ea2a9dbc0b1cf61d.NginxMailingListRussian@forum.nginx.org>
References: <230808fe1ddc1a30ea2a9dbc0b1cf61d.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170619185657.GP55433@mdounin.ru>

Hello!

On Mon, Jun 19, 2017 at 01:55:46PM -0400, Ilya Evseev wrote:

> Написал небольшой патч, который автоматически увеличивает размер буфера
> отправки, если sendfile вернул EAGAIN.
> 
> Вызывается из
> https://trac.nginx.org/nginx/browser/nginx/src/os/unix/ngx_linux_sendfile_chain.c#L265
> 
> Вопросы:
> 
> 1) имеет смысл доводить патч до такого вида, который примут в nginx? или
> такая функциональность не нужна в принципе?

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

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

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

> 2) если примут, то что ещё в нём обязано быть, кроме собственно кода
> увеличения буфера для Линукса и обработки "listen ... maxsndbuf=..." в
> конфиге?

Общие рекомендации по тому, как присылать патчи, можно почитать 
на странице http://nginx.org/ru/docs/contributing_changes.html.  

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

From nginx-forum на forum.nginx.org  Tue Jun 20 08:36:36 2017
From: nginx-forum на forum.nginx.org (Dothris)
Date: Tue, 20 Jun 2017 04:36:36 -0400
Subject: proxy_send_timeout 180; vs proxy_send_timeout 180s;
Message-ID: <bb67114678dc370790d535e0976673e7.NginxMailingListRussian@forum.nginx.org>

Добрый день!
Тут http://skeletor.org.ua/?p=2752 пишут что корректно писать
proxy_send_timeout 180s; Но я много вижу где пишут без буквы 's'.
В обоих случаях nginx ошибок не выдает
Так как правильно и корректно писать?

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


From gmm на csdoc.com  Tue Jun 20 09:24:43 2017
From: gmm на csdoc.com (Gena Makhomed)
Date: Tue, 20 Jun 2017 12:24:43 +0300
Subject: proxy_send_timeout 180; vs proxy_send_timeout 180s;
In-Reply-To: <bb67114678dc370790d535e0976673e7.NginxMailingListRussian@forum.nginx.org>
References: <bb67114678dc370790d535e0976673e7.NginxMailingListRussian@forum.nginx.org>
Message-ID: <80506b60-8f97-2ce2-0d78-8b86e369ed53@csdoc.com>

On 20.06.2017 11:36, Dothris wrote:

> Тут http://skeletor.org.ua/?p=2752 пишут что корректно писать
> proxy_send_timeout 180s; Но я много вижу где пишут без буквы 's'.
> В обоих случаях nginx ошибок не выдает
> Так как правильно и корректно писать?

Можно и так и так писать.

"Значение без суффикса задаёт секунды. Рекомендуется всегда указывать 
суффикс" - http://nginx.org/ru/docs/syntax.html

-- 
Best regards,
  Gena


From nginx-forum на forum.nginx.org  Tue Jun 20 14:31:52 2017
From: nginx-forum на forum.nginx.org (Ilya Evseev)
Date: Tue, 20 Jun 2017 10:31:52 -0400
Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0LzQsNGC0LjRh9C10YHQutC+0LUg0YPQstC10LvQuNGH0LU=?=
 =?UTF-8?B?0L3QuNC1IHNuZGJ1ZiDQv9GA0LggRUFHQUlO?=
In-Reply-To: <20170619185657.GP55433@mdounin.ru>
References: <20170619185657.GP55433@mdounin.ru>
Message-ID: <315c914705854fb6b4720e3eec8e7c09.NginxMailingListRussian@forum.nginx.org>

>
> В данном случае хороший ответ на этот вопрос не прослеживается,
> так как автотюнинг буферов сейчас во всех популярных операционных
> системах есть, в том числе на линуксе.
>

Автотюнинг буферов - это что именно?

Есть sysctl net.ipv4.tcp_wmem с тремя значениями:
минимально разрешенное, по умолчанию, максимально разрешенное.

Но устанавливать значение, отличное от дефолтного, всё равно должен
пользовательский
процесс через setsockopt(SO_SNDBUF), ядро его никогда не пытается менять
автоматически.

>
> И не совсем понятно, зачем пытаться изобретать свой собственный.
>

Сейчас получается два цикла отправки - внутри ядра, и когда\если ядерный
буфер переполнен, то внутри Nginx'a вокруг EAGAIN.

Когда Nginx попадает в такой цикл, резко взлетают CPU Usage и Load Average.

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

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


From mdounin на mdounin.ru  Tue Jun 20 15:12:35 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 20 Jun 2017 18:12:35 +0300
Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0LzQsNGC0LjRh9C10YHQutC+0LUg0YPQstC10LvQuNGH0LU=?=
 =?UTF-8?B?0L3QuNC1IHNuZGJ1ZiDQv9GA0LggRUFHQUlO?=
In-Reply-To: <315c914705854fb6b4720e3eec8e7c09.NginxMailingListRussian@forum.nginx.org>
References: <20170619185657.GP55433@mdounin.ru>
 <315c914705854fb6b4720e3eec8e7c09.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170620151235.GT55433@mdounin.ru>

Hello!

On Tue, Jun 20, 2017 at 10:31:52AM -0400, Ilya Evseev wrote:

> >
> > В данном случае хороший ответ на этот вопрос не прослеживается,
> > так как автотюнинг буферов сейчас во всех популярных операционных
> > системах есть, в том числе на линуксе.
> >
> 
> Автотюнинг буферов - это что именно?
> 
> Есть sysctl net.ipv4.tcp_wmem с тремя значениями:
> минимально разрешенное, по умолчанию, максимально разрешенное.
> 
> Но устанавливать значение, отличное от дефолтного, всё равно должен
> пользовательский
> процесс через setsockopt(SO_SNDBUF), ядро его никогда не пытается менять
> автоматически.

Нет. (c) Farid Vagapov

tcp_wmem - vector of 3 INTEGERs: min, default, max
	min: Amount of memory reserved for send buffers for TCP sockets.
	Each TCP socket has rights to use it due to fact of its birth.
	Default: 1 page

	default: initial size of send buffer used by TCP sockets.  This
	value overrides net.core.wmem_default used by other protocols.
	It is usually lower than net.core.wmem_default.
	Default: 16K

	max: Maximal amount of memory allowed for automatically tuned
	send buffers for TCP sockets. This value does not override
	net.core.wmem_max.  Calling setsockopt() with SO_SNDBUF disables
	automatic tuning of that socket's send buffer size, in which case
	this value is ignored.
	Default: between 64K and 4MB, depending on RAM size.

(https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt)

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

From nginx-forum на forum.nginx.org  Tue Jun 20 16:36:26 2017
From: nginx-forum на forum.nginx.org (Ilya Evseev)
Date: Tue, 20 Jun 2017 12:36:26 -0400
Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0LzQsNGC0LjRh9C10YHQutC+0LUg0YPQstC10LvQuNGH0LU=?=
 =?UTF-8?B?0L3QuNC1IHNuZGJ1ZiDQv9GA0LggRUFHQUlO?=
In-Reply-To: <20170620151235.GT55433@mdounin.ru>
References: <20170620151235.GT55433@mdounin.ru>
Message-ID: <f677a971ec314ea562b1bb088eb86092.NginxMailingListRussian@forum.nginx.org>

То есть получается, что лучше всего использовать только net.ipv4.tcp_wmem
и вообще никогда не указывать "listen ... sndbuf=..." в nginx.conf,
чтобы он не вызвал setsockopt и не отключал автонастройку в ядре?

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


From mdounin на mdounin.ru  Tue Jun 20 17:41:04 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 20 Jun 2017 20:41:04 +0300
Subject: =?UTF-8?B?UmU6INCQ0LLRgtC+0LzQsNGC0LjRh9C10YHQutC+0LUg0YPQstC10LvQuNGH0LU=?=
 =?UTF-8?B?0L3QuNC1IHNuZGJ1ZiDQv9GA0LggRUFHQUlO?=
In-Reply-To: <f677a971ec314ea562b1bb088eb86092.NginxMailingListRussian@forum.nginx.org>
References: <20170620151235.GT55433@mdounin.ru>
 <f677a971ec314ea562b1bb088eb86092.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170620174103.GX55433@mdounin.ru>

Hello!

On Tue, Jun 20, 2017 at 12:36:26PM -0400, Ilya Evseev wrote:

> То есть получается, что лучше всего использовать только net.ipv4.tcp_wmem
> и вообще никогда не указывать "listen ... sndbuf=..." в nginx.conf,
> чтобы он не вызвал setsockopt и не отключал автонастройку в ядре?

Если нужен автотюнинг буферов - то да, sndbuf в конфиге nginx'а 
задавать не надо.

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

From simplebox66 на gmail.com  Wed Jun 21 08:09:00 2017
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Wed, 21 Jun 2017 11:09:00 +0300
Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviBpbm9kZSDQuNC3LdC30LAg0Lo=?=
 =?UTF-8?B?0LXRiNCw?=
In-Reply-To: <CA+ksgAAMP=dgA7+xybnseBwUjKvEdctpsdhHkoTgrOoQraTvXw@mail.gmail.com>
References: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
 <20170609153850.GB55433@mdounin.ru>
 <CA+ksgAD6FU58QVtL75oW=XBgn_b4WQOjYic_VJYmF=jfjs40QQ@mail.gmail.com>
 <20170616142524.GF55433@mdounin.ru>
 <CAMPJU7AWxEL=hqRx5TVpzw+HRL1Ts-qjsSWShfKE_GUGb2f0VA@mail.gmail.com>
 <CA+ksgAAMP=dgA7+xybnseBwUjKvEdctpsdhHkoTgrOoQraTvXw@mail.gmail.com>
Message-ID: <CA+ksgAC=V8ZOMnW=mZzvpjsXBXOz2Jx0qeO8hFMuF0Z3S=ijRw@mail.gmail.com>

Максим, кеш дира /tmp/ram/  была забита на 100% 28Гб из 28Гб. Сбросил часть
кеша, получилось 25Гб занято из 28Гб. Затем исправил то о чем ты говорил и
начальный конфиг (приведенный в первом письме) стал выглядеть вот так:

> proxy_cache_path /tmp/ram/ levels=1:2 use_temp_path=off
> keys_zone=level-1:20m max_size=26000m inactive=1440m;
>         proxy_temp_path /tmp/cache/nginx/proxy_temp;
>         proxy_cache_key $server_name$request_uri;


 Т.е. указал nginx что для кеша у него теперь 26Гб, тем самым оставив 2Гб
запас на отвлечение cache manager.
Но по истечении некоторого времени у меня /tmp/ram/ снова забился до 28Гб
из "28Гб. Почему так произошло? Нужен больший запас для cache manager ?


19 июня 2017 г., 10:40 пользователь Иван Мишин <simplebox66 на gmail.com>
написал:

> Максим, спасибо за детальное объяснение, на днях буду внедрять изменения и
> наблюдать, по происшествии времени отпишусь о результате.
>
> 16 июня 2017 г., 22:21 пользователь Vasiliy P. Melnik <basil на vpm.net.ua>
> написал:
>
> Здравствуйте
>>
>> Раз уж пошла такая пьянка, то может подскажете, есть какие-то
>> противопоказания насчет использования use_temp_path=off
>>
>>
>> 16 июня 2017 г., 17:25 пользователь Maxim Dounin <mdounin на mdounin.ru>
>> написал:
>>
>> Hello!
>>>
>>> On Fri, Jun 16, 2017 at 04:57:04PM +0300, Иван Мишин wrote:
>>>
>>> > Крахов файловой системы не было, каталог /tmp/ram отдан исключительно
>>> под
>>> > кеш nginx. За последнюю неделю набежало 5941794 файлов нулевого
>>> размера в
>>> > кеш каталоге.
>>> > В общем эта проблема очень актуальна для меня и преследует уже не
>>> первый
>>> > месяц, есть у кого-нибудь идеи как я могу отдиагностировать ситуацию?
>>> > Максим, можно подробнее про "кончилось место при копировании из
>>> каталога со
>>> > временными файлами", не совсем понимаю что ты имеешь ввиду?
>>>
>>> Если proxy_temp_path и proxy_cache_path находятся на разных
>>> файловых системах, то просто переместить временный файл в кеш
>>> нельзя, приходится его копировать, создав новый файл.  Подробнее
>>> про это рассказывается в описании директивы proxy_cache_path:
>>>
>>> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pro
>>> xy_cache_path
>>>
>>> Если в процессе копирования произойдёт ошибка, например из-за
>>> того, что файловая система, на которой располагается кеш,
>>> переполнена, то в логе будет ошибка уровня alert, а в кеше
>>> останется лежать недописанный файл.
>>>
>>> Отмечу в скобках, что если вот это:
>>>
>>> > > > кеш в ramfs на 28Гб со следующими настройками:
>>> > > >
>>> > > > > proxy_cache_path /tmp/ram/ levels=1:2 keys_zone=level-1:20m
>>> > > > > max_size=28000m inactive=1440m;
>>>
>>> и правда озаначает, что размер ramfs - 28 гигабайт, то результат
>>> ожидаем.
>>>
>>> Вы сказали nginx'у, что начинать чистить кеш надо при превышении
>>> размера в 28 гигабайт.  Если cache manager отвлечётся хоть немного
>>> на другие задачи (а он может заниматься другими кешами, если они
>>> есть, или просто уйти спать на 10 секунд, почистив всё) - файловая
>>> система переполнится, и будут ошибки.  Вам надо менять настройки.
>>>
>>> --
>>> Maxim Dounin
>>> http://nginx.org/
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru на nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>>
>>
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru на nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170621/c3b747fc/attachment-0001.html>

From basil на vpm.net.ua  Wed Jun 21 08:28:07 2017
From: basil на vpm.net.ua (Vasiliy P. Melnik)
Date: Wed, 21 Jun 2017 11:28:07 +0300
Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviBpbm9kZSDQuNC3LdC30LAg0Lo=?=
 =?UTF-8?B?0LXRiNCw?=
In-Reply-To: <CA+ksgAC=V8ZOMnW=mZzvpjsXBXOz2Jx0qeO8hFMuF0Z3S=ijRw@mail.gmail.com>
References: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
 <20170609153850.GB55433@mdounin.ru>
 <CA+ksgAD6FU58QVtL75oW=XBgn_b4WQOjYic_VJYmF=jfjs40QQ@mail.gmail.com>
 <20170616142524.GF55433@mdounin.ru>
 <CAMPJU7AWxEL=hqRx5TVpzw+HRL1Ts-qjsSWShfKE_GUGb2f0VA@mail.gmail.com>
 <CA+ksgAAMP=dgA7+xybnseBwUjKvEdctpsdhHkoTgrOoQraTvXw@mail.gmail.com>
 <CA+ksgAC=V8ZOMnW=mZzvpjsXBXOz2Jx0qeO8hFMuF0Z3S=ijRw@mail.gmail.com>
Message-ID: <CAMPJU7C=qdJ3xeS+bMSwJqbjgfLP9xxxxb=Ee6twMsGPAcQ-DA@mail.gmail.com>

21 июня 2017 г., 11:09 пользователь Иван Мишин <simplebox66 на gmail.com>
написал:

> Максим, кеш дира /tmp/ram/  была забита на 100% 28Гб из 28Гб. Сбросил
> часть кеша, получилось 25Гб занято из 28Гб. Затем исправил то о чем ты
> говорил и начальный конфиг (приведенный в первом письме) стал выглядеть вот
> так:
>
>> proxy_cache_path /tmp/ram/ levels=1:2 use_temp_path=off
>> keys_zone=level-1:20m max_size=26000m inactive=1440m;
>>         proxy_temp_path /tmp/cache/nginx/proxy_temp;
>>
>
Вам же порекомендовали не использовать proxy_temp_path на другом разделе.
Если Вам он очень нужен - переместите го в тот же раздел, что и основной
кеш, например в
proxy_temp_path  /tmp/ram/proxy_temp



>         proxy_cache_key $server_name$request_uri;
>
>
>  Т.е. указал nginx что для кеша у него теперь 26Гб, тем самым оставив 2Гб
> запас на отвлечение cache manager.
> Но по истечении некоторого времени у меня /tmp/ram/ снова забился до 28Гб
> из "28Гб. Почему так произошло? Нужен больший запас для cache manager ?
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170621/1e0df90e/attachment.html>

From simplebox66 на gmail.com  Wed Jun 21 08:38:35 2017
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Wed, 21 Jun 2017 11:38:35 +0300
Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviBpbm9kZSDQuNC3LdC30LAg0Lo=?=
 =?UTF-8?B?0LXRiNCw?=
In-Reply-To: <CAMPJU7C=qdJ3xeS+bMSwJqbjgfLP9xxxxb=Ee6twMsGPAcQ-DA@mail.gmail.com>
References: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
 <20170609153850.GB55433@mdounin.ru>
 <CA+ksgAD6FU58QVtL75oW=XBgn_b4WQOjYic_VJYmF=jfjs40QQ@mail.gmail.com>
 <20170616142524.GF55433@mdounin.ru>
 <CAMPJU7AWxEL=hqRx5TVpzw+HRL1Ts-qjsSWShfKE_GUGb2f0VA@mail.gmail.com>
 <CA+ksgAAMP=dgA7+xybnseBwUjKvEdctpsdhHkoTgrOoQraTvXw@mail.gmail.com>
 <CA+ksgAC=V8ZOMnW=mZzvpjsXBXOz2Jx0qeO8hFMuF0Z3S=ijRw@mail.gmail.com>
 <CAMPJU7C=qdJ3xeS+bMSwJqbjgfLP9xxxxb=Ee6twMsGPAcQ-DA@mail.gmail.com>
Message-ID: <CA+ksgAA_sL404wn5t+j+-Vv8h_z3ARi-VGGBzDk1UKztuXxw=Q@mail.gmail.com>

>
> Вам же порекомендовали не использовать proxy_temp_path на другом разделе


Так так и сделал, почитал доку и  приписал параметр use_temp_path=off к
своему конфигу.
Вот цитата из доки.

> Поэтому лучше, если кэш будет находиться на той же файловой системе, что и
> каталог с временными файлами. Какой из каталогов будет использоваться для
> временных файлов определяется параметром use_temp_path(1.7.10).  Если
> параметр не задан или установлен в значение “on”, то будет использоваться
> каталог, задаваемый директивой proxy_temp_path
> <http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_temp_path> для
> данного location. Если параметр установлен в значение “off”, то временные
> файлы будут располагаться непосредственно в каталоге кэша.


21 июня 2017 г., 11:28 пользователь Vasiliy P. Melnik <basil на vpm.net.ua>
написал:

>
>
> 21 июня 2017 г., 11:09 пользователь Иван Мишин <simplebox66 на gmail.com>
> написал:
>
>> Максим, кеш дира /tmp/ram/  была забита на 100% 28Гб из 28Гб. Сбросил
>> часть кеша, получилось 25Гб занято из 28Гб. Затем исправил то о чем ты
>> говорил и начальный конфиг (приведенный в первом письме) стал выглядеть вот
>> так:
>>
>>> proxy_cache_path /tmp/ram/ levels=1:2 use_temp_path=off
>>> keys_zone=level-1:20m max_size=26000m inactive=1440m;
>>>         proxy_temp_path /tmp/cache/nginx/proxy_temp;
>>>
>>
> Вам же порекомендовали не использовать proxy_temp_path на другом разделе.
> Если Вам он очень нужен - переместите го в тот же раздел, что и основной
> кеш, например в
> proxy_temp_path  /tmp/ram/proxy_temp
>
>
>
>>         proxy_cache_key $server_name$request_uri;
>>
>>
>>  Т.е. указал nginx что для кеша у него теперь 26Гб, тем самым оставив 2Гб
>> запас на отвлечение cache manager.
>> Но по истечении некоторого времени у меня /tmp/ram/ снова забился до
>> 28Гб из "28Гб. Почему так произошло? Нужен больший запас для cache
>> manager ?
>>
>
> _______________________________________________
> 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/20170621/f575bc39/attachment.html>

From ads на unix4all.com  Wed Jun 21 09:32:49 2017
From: ads на unix4all.com (=?UTF-8?B?0JTQvNC40YLRgNC40Lkg0JDQvdGB0LjQvNC+0LI=?=)
Date: Wed, 21 Jun 2017 12:32:49 +0300
Subject: =?UTF-8?B?TkdJTlgg0LrQsNC6INC60LvQuNC10L3RgiDQtNC70Y8gR29vZ2xlIENsb3VkIFB1?=
 =?UTF-8?B?Yi9TdWI=?=
Message-ID: <CAK-RTX3nRaui_5oUkKPtWNjbZmbquiP4M7X5CtyCZh=yFR1X5A@mail.gmail.com>

Добрый день, товарищи.

Не сведущ в теме, потому вопрос может звучать глупо.

Не сталкивался ли кто-то с примерами использования NGINX в виде клиента для
Google Cloud Pub/Sub? Как lua-resty-redis для pub/sub в Redis, к примеру.

Любая помощь приветствуется. Заранее спасибо.

-- 
Sincerely,
Dmitry Ansimov
freelance system administrator
skype: cardinal-gray
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170621/a04a7902/attachment-0001.html>

From mdounin на mdounin.ru  Wed Jun 21 12:46:00 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Wed, 21 Jun 2017 15:46:00 +0300
Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviBpbm9kZSDQuNC3LdC30LAg0Lo=?=
 =?UTF-8?B?0LXRiNCw?=
In-Reply-To: <CA+ksgAC=V8ZOMnW=mZzvpjsXBXOz2Jx0qeO8hFMuF0Z3S=ijRw@mail.gmail.com>
References: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
 <20170609153850.GB55433@mdounin.ru>
 <CA+ksgAD6FU58QVtL75oW=XBgn_b4WQOjYic_VJYmF=jfjs40QQ@mail.gmail.com>
 <20170616142524.GF55433@mdounin.ru>
 <CAMPJU7AWxEL=hqRx5TVpzw+HRL1Ts-qjsSWShfKE_GUGb2f0VA@mail.gmail.com>
 <CA+ksgAAMP=dgA7+xybnseBwUjKvEdctpsdhHkoTgrOoQraTvXw@mail.gmail.com>
 <CA+ksgAC=V8ZOMnW=mZzvpjsXBXOz2Jx0qeO8hFMuF0Z3S=ijRw@mail.gmail.com>
Message-ID: <20170621124600.GY55433@mdounin.ru>

Hello!

On Wed, Jun 21, 2017 at 11:09:00AM +0300, Иван Мишин wrote:

> Максим, кеш дира /tmp/ram/  была забита на 100% 28Гб из 28Гб. Сбросил часть
> кеша, получилось 25Гб занято из 28Гб. Затем исправил то о чем ты говорил и
> начальный конфиг (приведенный в первом письме) стал выглядеть вот так:
> 
> > proxy_cache_path /tmp/ram/ levels=1:2 use_temp_path=off
> > keys_zone=level-1:20m max_size=26000m inactive=1440m;
> >         proxy_temp_path /tmp/cache/nginx/proxy_temp;
> >         proxy_cache_key $server_name$request_uri;
> 
> 
>  Т.е. указал nginx что для кеша у него теперь 26Гб, тем самым оставив 2Гб
> запас на отвлечение cache manager.
> Но по истечении некоторого времени у меня /tmp/ram/ снова забился до 28Гб
> из "28Гб. Почему так произошло? Нужен больший запас для cache manager ?

Во-первых, если в кеше мусор по результатам старых ошибок, то 
cache manager не сможет за ним нормально следить: он ничего не 
знает про мусор, и соответственно не включает его в размер того, 
что занято кешом.  Чтобы привести всё к нормальному состоянию - 
стоит очистить кеш полностью.

Во-вторых, cache manager может не иметь возможности удалять файлы 
и по другим причинам, в частности - элементы кеша могут оказаться 
занятыми из-за падений рабочих процессов и/или утечек сокетов.  
При попытке очистки таких элементов по inactive в лог будут 
писаться сообщения "ignore long locked inactive cache entry" на 
уровне alert (в 1.13.1 то же будет происходить и при очистке по 
max_size).

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

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

From simplebox66 на gmail.com  Wed Jun 21 13:40:21 2017
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Wed, 21 Jun 2017 16:40:21 +0300
Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviBpbm9kZSDQuNC3LdC30LAg0Lo=?=
 =?UTF-8?B?0LXRiNCw?=
In-Reply-To: <20170621124600.GY55433@mdounin.ru>
References: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
 <20170609153850.GB55433@mdounin.ru>
 <CA+ksgAD6FU58QVtL75oW=XBgn_b4WQOjYic_VJYmF=jfjs40QQ@mail.gmail.com>
 <20170616142524.GF55433@mdounin.ru>
 <CAMPJU7AWxEL=hqRx5TVpzw+HRL1Ts-qjsSWShfKE_GUGb2f0VA@mail.gmail.com>
 <CA+ksgAAMP=dgA7+xybnseBwUjKvEdctpsdhHkoTgrOoQraTvXw@mail.gmail.com>
 <CA+ksgAC=V8ZOMnW=mZzvpjsXBXOz2Jx0qeO8hFMuF0Z3S=ijRw@mail.gmail.com>
 <20170621124600.GY55433@mdounin.ru>
Message-ID: <CA+ksgADqNCOMLO004NPBJqQyiOXLX0rPG3SvPQOnHruOuWnB_Q@mail.gmail.com>

В логи заглядывал еще до создания данной темы.
лог настроен следующим образом

> error_log  /var/log/nginx/error.log notice;

 При этом до недавнего времени в логе проскакивали только сообщения

> [alert] 5092#5092: send() failed (90: Message too long)

 А теперь еще появились

> [crit] 5093#5093: unlink()
> "/tmp/ram/1/52/201e725c28498b88055b145ac7253521" failed (2: No such file or
> directory)


Те сообщения о которых говорите вы, в моих логах отсутствуют.
Сегодня произведу плановый рестарт сервера, заодно и кеш сбросится. Буду
наблюдать

21 июня 2017 г., 15:46 пользователь Maxim Dounin <mdounin на mdounin.ru>
написал:

> Hello!
>
> On Wed, Jun 21, 2017 at 11:09:00AM +0300, Иван Мишин wrote:
>
> > Максим, кеш дира /tmp/ram/  была забита на 100% 28Гб из 28Гб. Сбросил
> часть
> > кеша, получилось 25Гб занято из 28Гб. Затем исправил то о чем ты говорил
> и
> > начальный конфиг (приведенный в первом письме) стал выглядеть вот так:
> >
> > > proxy_cache_path /tmp/ram/ levels=1:2 use_temp_path=off
> > > keys_zone=level-1:20m max_size=26000m inactive=1440m;
> > >         proxy_temp_path /tmp/cache/nginx/proxy_temp;
> > >         proxy_cache_key $server_name$request_uri;
> >
> >
> >  Т.е. указал nginx что для кеша у него теперь 26Гб, тем самым оставив 2Гб
> > запас на отвлечение cache manager.
> > Но по истечении некоторого времени у меня /tmp/ram/ снова забился до 28Гб
> > из "28Гб. Почему так произошло? Нужен больший запас для cache manager ?
>
> Во-первых, если в кеше мусор по результатам старых ошибок, то
> cache manager не сможет за ним нормально следить: он ничего не
> знает про мусор, и соответственно не включает его в размер того,
> что занято кешом.  Чтобы привести всё к нормальному состоянию -
> стоит очистить кеш полностью.
>
> Во-вторых, cache manager может не иметь возможности удалять файлы
> и по другим причинам, в частности - элементы кеша могут оказаться
> занятыми из-за падений рабочих процессов и/или утечек сокетов.
> При попытке очистки таких элементов по inactive в лог будут
> писаться сообщения "ignore long locked inactive cache entry" на
> уровне alert (в 1.13.1 то же будет происходить и при очистке по
> max_size).
>
> Основное, что бы я рекомендовал сделать в первую очередь - это
> начать таки заглядывать в логи.  Все ваши проблемы наверняка были
> обозначены там неоднократно и на критических уровнях логгирования.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> 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/20170621/15339899/attachment.html>

From sergeyk на jfrog.com  Thu Jun 22 08:20:53 2017
From: sergeyk на jfrog.com (Sergey Kagansky)
Date: Thu, 22 Jun 2017 11:20:53 +0300
Subject: =?UTF-8?B?cHJveHlfY2FjaGVfdmFsaWQgYW55IDA7INC40LPQvdC+0YDQuNGA0YPQtdGC0YE=?=
 =?UTF-8?B?0Y8=?=
Message-ID: <CAJLdeeaTXhPoNYNVKcy0_aqFD8+-=Rd1ujeVbN5RnktOJzoJXg@mail.gmail.com>

Добрый день.
Столкнулся с непонятной ситуацией.
Есть такой конфиг:

proxy_cache_path /data/cache/nginx/cache levels=1:2 keys_zone=all:32m
max_size=1g;
 location / {
   proxy_cache          all;
   proxy_cache_valid 404 5m;
   proxy_cache_valid any 0;
  ....
 }

Требуется кешировать ТОЛЬКО 404 ответы, но нгинкс игнорирует строку
 proxy_cache_valid any 0;
Что может приводить к этому? Или как это отловить?
Больше в конфигах ничего про кэш нигде не указано.
Пробовал с разными версиями нгинкс: 1.7.12, 1.11.1, 1.11.5, 1.12.0

-- 
 <https://goo.gl/iqC1cD>
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170622/cdec0a27/attachment.html>

From andrey на kopeyko.ru  Thu Jun 22 11:27:26 2017
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Thu, 22 Jun 2017 14:27:26 +0300
Subject: =?UTF-8?B?UmU6IHByb3h5X2NhY2hlX3ZhbGlkIGFueSAwOyDQuNCz0L3QvtGA0LjRgNGD0LU=?=
 =?UTF-8?B?0YLRgdGP?=
In-Reply-To: <CAJLdeeaTXhPoNYNVKcy0_aqFD8+-=Rd1ujeVbN5RnktOJzoJXg@mail.gmail.com>
References: <CAJLdeeaTXhPoNYNVKcy0_aqFD8+-=Rd1ujeVbN5RnktOJzoJXg@mail.gmail.com>
Message-ID: <b2415e40b4d1eddb54dc5a8b97b665c1@kopeyko.ru>

Sergey Kagansky писал 2017-06-22 11:20:
> Добрый день.

Добрый день, Сергей!

> Столкнулся с непонятной ситуацией.
> Есть такой конфиг:
> 
> proxy_cache_path /data/cache/nginx/cache levels=1:2 keys_zone=all:32m
> max_size=1g;
> 
>  location / {
>    proxy_cache          all;
>    proxy_cache_valid 404 5m;
>    proxy_cache_valid any 0;
>   ....
>  }
> 
> Требуется кешировать ТОЛЬКО 404 ответы,
> но нгинкс игнорирует строку
> proxy_cache_valid any 0;
> Что может приводить к этому? Или как это отловить?

У вас формат директивы неверный - последний параметр должен быть иметь 
размерность времени, а у вас - просто число.
Об этом наверняка была ругань в error.log


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

proxy_cache_valid 404 5m;


-- 
Best regards,
Andrey A. Kopeyko <andrey на kopeyko.ru>

From alex.hha на gmail.com  Thu Jun 22 12:25:03 2017
From: alex.hha на gmail.com (Alex Domoradov)
Date: Thu, 22 Jun 2017 15:25:03 +0300
Subject: =?UTF-8?B?UmU6IHByb3h5X2NhY2hlX3ZhbGlkIGFueSAwOyDQuNCz0L3QvtGA0LjRgNGD0LU=?=
 =?UTF-8?B?0YLRgdGP?=
In-Reply-To: <b2415e40b4d1eddb54dc5a8b97b665c1@kopeyko.ru>
References: <CAJLdeeaTXhPoNYNVKcy0_aqFD8+-=Rd1ujeVbN5RnktOJzoJXg@mail.gmail.com>
 <b2415e40b4d1eddb54dc5a8b97b665c1@kopeyko.ru>
Message-ID: <CAK90gp7NDzwyvKbd76hTOO+K0dUTLfyTGXz2WSVdXeA16+-AQw@mail.gmail.com>

> У вас формат директивы неверный - последний параметр должен быть иметь
размерность времени, а у вас - просто число.
а разве в таких случаях не подразумеваются секунды по дефолту? Как в случае
с тем же proxy_send_timeout 180s == proxy_send_timeout 180.

Хотя в офф доке и советуют явно задавать суффиксы - "Значение без суффикса
задаёт секунды. Рекомендуется всегда указывать суффикс."

2017-06-22 14:27 GMT+03:00 Andrey Kopeyko <andrey на kopeyko.ru>:

> Sergey Kagansky писал 2017-06-22 11:20:
>
>> Добрый день.
>>
>
> Добрый день, Сергей!
>
> Столкнулся с непонятной ситуацией.
>> Есть такой конфиг:
>>
>> proxy_cache_path /data/cache/nginx/cache levels=1:2 keys_zone=all:32m
>> max_size=1g;
>>
>>  location / {
>>    proxy_cache          all;
>>    proxy_cache_valid 404 5m;
>>    proxy_cache_valid any 0;
>>   ....
>>  }
>>
>> Требуется кешировать ТОЛЬКО 404 ответы,
>> но нгинкс игнорирует строку
>> proxy_cache_valid any 0;
>> Что может приводить к этому? Или как это отловить?
>>
>
> У вас формат директивы неверный - последний параметр должен быть иметь
> размерность времени, а у вас - просто число.
> Об этом наверняка была ругань в error.log
>
>
> Не совсем понятно что именно вы хотите этой директивой сказать? если вам
> надо кешировать только 404-е ответы, то достаточно будет одной директивы
>
> proxy_cache_valid 404 5m;
>
>
> --
> Best regards,
> Andrey A. Kopeyko <andrey на kopeyko.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/20170622/ab0421ba/attachment.html>

From arut на nginx.com  Thu Jun 22 12:59:04 2017
From: arut на nginx.com (Roman Arutyunyan)
Date: Thu, 22 Jun 2017 15:59:04 +0300
Subject: =?UTF-8?B?UmU6IHByb3h5X2NhY2hlX3ZhbGlkIGFueSAwOyDQuNCz0L3QvtGA0LjRgNGD0LU=?=
 =?UTF-8?B?0YLRgdGP?=
In-Reply-To: <CAJLdeeaTXhPoNYNVKcy0_aqFD8+-=Rd1ujeVbN5RnktOJzoJXg@mail.gmail.com>
References: <CAJLdeeaTXhPoNYNVKcy0_aqFD8+-=Rd1ujeVbN5RnktOJzoJXg@mail.gmail.com>
Message-ID: <20170622125904.GL470@Romans-MacBook-Air.local>

Добрый день,

On Thu, Jun 22, 2017 at 11:20:53AM +0300, Sergey Kagansky wrote: > Добрый день.
> Столкнулся с непонятной ситуацией.
> Есть такой конфиг:
> 
> proxy_cache_path /data/cache/nginx/cache levels=1:2 keys_zone=all:32m
> max_size=1g;
>  location / {
>    proxy_cache          all;
>    proxy_cache_valid 404 5m;
>    proxy_cache_valid any 0;
>   ....
>  }
> 
> Требуется кешировать ТОЛЬКО 404 ответы, но нгинкс игнорирует строку
>  proxy_cache_valid any 0;
> Что может приводить к этому? Или как это отловить?
> Больше в конфигах ничего про кэш нигде не указано.
> Пробовал с разными версиями нгинкс: 1.7.12, 1.11.1, 1.11.5, 1.12.0

Приводить к этому может то, что в самом ответе задано другое время.

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

http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache_valid

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

-- 
Roman Arutyunyan

From simplebox66 на gmail.com  Thu Jun 22 13:02:13 2017
From: simplebox66 на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGI0LjQvQ==?=)
Date: Thu, 22 Jun 2017 16:02:13 +0300
Subject: =?UTF-8?B?UmU6INCg0LDRgdGC0LXRgiDQutC+0Lst0LLQviBpbm9kZSDQuNC3LdC30LAg0Lo=?=
 =?UTF-8?B?0LXRiNCw?=
In-Reply-To: <CA+ksgADqNCOMLO004NPBJqQyiOXLX0rPG3SvPQOnHruOuWnB_Q@mail.gmail.com>
References: <CA+ksgABdMzdsbDOfoVXf77ug=qspMHxYT7Ne6kzhxMDuTj68aA@mail.gmail.com>
 <20170609153850.GB55433@mdounin.ru>
 <CA+ksgAD6FU58QVtL75oW=XBgn_b4WQOjYic_VJYmF=jfjs40QQ@mail.gmail.com>
 <20170616142524.GF55433@mdounin.ru>
 <CAMPJU7AWxEL=hqRx5TVpzw+HRL1Ts-qjsSWShfKE_GUGb2f0VA@mail.gmail.com>
 <CA+ksgAAMP=dgA7+xybnseBwUjKvEdctpsdhHkoTgrOoQraTvXw@mail.gmail.com>
 <CA+ksgAC=V8ZOMnW=mZzvpjsXBXOz2Jx0qeO8hFMuF0Z3S=ijRw@mail.gmail.com>
 <20170621124600.GY55433@mdounin.ru>
 <CA+ksgADqNCOMLO004NPBJqQyiOXLX0rPG3SvPQOnHruOuWnB_Q@mail.gmail.com>
Message-ID: <CA+ksgAAF1t+bVq1nZp=c6c4-BkLetebTRf67n_D8ptDWwRNiSg@mail.gmail.com>

Произвел полный сброс кеша, теперь все работает как надо. Спасибо Максим!

21 июня 2017 г., 16:40 пользователь Иван Мишин <simplebox66 на gmail.com>
написал:

> В логи заглядывал еще до создания данной темы.
> лог настроен следующим образом
>
>> error_log  /var/log/nginx/error.log notice;
>
>  При этом до недавнего времени в логе проскакивали только сообщения
>
>> [alert] 5092#5092: send() failed (90: Message too long)
>
>  А теперь еще появились
>
>> [crit] 5093#5093: unlink() "/tmp/ram/1/52/201e725c28498b88055b145ac7253521"
>> failed (2: No such file or directory)
>
>
> Те сообщения о которых говорите вы, в моих логах отсутствуют.
> Сегодня произведу плановый рестарт сервера, заодно и кеш сбросится. Буду
> наблюдать
>
> 21 июня 2017 г., 15:46 пользователь Maxim Dounin <mdounin на mdounin.ru>
> написал:
>
> Hello!
>>
>> On Wed, Jun 21, 2017 at 11:09:00AM +0300, Иван Мишин wrote:
>>
>> > Максим, кеш дира /tmp/ram/  была забита на 100% 28Гб из 28Гб. Сбросил
>> часть
>> > кеша, получилось 25Гб занято из 28Гб. Затем исправил то о чем ты
>> говорил и
>> > начальный конфиг (приведенный в первом письме) стал выглядеть вот так:
>> >
>> > > proxy_cache_path /tmp/ram/ levels=1:2 use_temp_path=off
>> > > keys_zone=level-1:20m max_size=26000m inactive=1440m;
>> > >         proxy_temp_path /tmp/cache/nginx/proxy_temp;
>> > >         proxy_cache_key $server_name$request_uri;
>> >
>> >
>> >  Т.е. указал nginx что для кеша у него теперь 26Гб, тем самым оставив
>> 2Гб
>> > запас на отвлечение cache manager.
>> > Но по истечении некоторого времени у меня /tmp/ram/ снова забился до
>> 28Гб
>> > из "28Гб. Почему так произошло? Нужен больший запас для cache manager ?
>>
>> Во-первых, если в кеше мусор по результатам старых ошибок, то
>> cache manager не сможет за ним нормально следить: он ничего не
>> знает про мусор, и соответственно не включает его в размер того,
>> что занято кешом.  Чтобы привести всё к нормальному состоянию -
>> стоит очистить кеш полностью.
>>
>> Во-вторых, cache manager может не иметь возможности удалять файлы
>> и по другим причинам, в частности - элементы кеша могут оказаться
>> занятыми из-за падений рабочих процессов и/или утечек сокетов.
>> При попытке очистки таких элементов по inactive в лог будут
>> писаться сообщения "ignore long locked inactive cache entry" на
>> уровне alert (в 1.13.1 то же будет происходить и при очистке по
>> max_size).
>>
>> Основное, что бы я рекомендовал сделать в первую очередь - это
>> начать таки заглядывать в логи.  Все ваши проблемы наверняка были
>> обозначены там неоднократно и на критических уровнях логгирования.
>>
>> --
>> Maxim Dounin
>> http://nginx.org/
>> _______________________________________________
>> 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/20170622/b1e5f89b/attachment-0001.html>

From al.al.platonov на gmail.com  Thu Jun 22 13:30:39 2017
From: al.al.platonov на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3RgCDQn9C70LDRgtC+0L3QvtCy?=)
Date: Thu, 22 Jun 2017 16:30:39 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <20170615214243.olp4x7z32vckt2fp@protva.ru>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
 <20170615151301.d4vezsum6pfklj7f@protva.ru>
 <CAEB8VFKSCxw2WzCq=Uw-5xh8GiSgEbDDiV8DgCMGdG8QrtnVuQ@mail.gmail.com>
 <20170615214243.olp4x7z32vckt2fp@protva.ru>
Message-ID: <CAEB8VFLrDsTfsiYmCJP8m6FJccR9iQtQU_j5-ydwc=jUVxcU=g@mail.gmail.com>

Пожалуйста, новые дампы и логи.
https://ufile.io/0ony2
https://ufile.io/bgt1i

2017/06/22 15:53:55 [error] 45615#45615: *89748123 upstream timed out (110:
Connection timed out) while connecting to upstream, client: 176.59.44.27,
server: server, request: "POST
/api/events/batch?app_id=311&uid=uid&usr_latitude=55.50582&adv_id=b309f032e4-4516-8950-cc01093bb398&usr_longitude=37.3288475&timestamp=1492954855
HTTP/1.1", upstream: "fastcgi://217.69.137.58:8086", host: "server"
2017/06/22 15:53:55 [error] 45611#45611: *89788909 upstream timed out (110:
Connection timed out) while connecting to upstream, client: 46.146.189.93,
server: server, request: "POST
/api/events/batch?app_id=311&uid=uid&usr_latitude=0.0&adv_id=f341a189-59573f-a520-9c76b003d6c4&usr_longitude=0.0&timestamp=1498136049
HTTP/1.1", upstream: "fastcgi://217.69.137.35:8086", host: "server"

Есть идеи почему так может быть?

Таймаут поднимаю до 700, посмотрю на результат.

Левый модуль графита и на остальных проектах )

Александр

16 июня 2017 г., 0:42 пользователь Evgeniy Berdnikov <bgx на protva.ru>
написал:

> On Thu, Jun 15, 2017 at 09:07:39PM +0300, Алексанр Платонов wrote:
> > >  А это похоже на таймаут коннекта. Вопрос в том, почему SYN+ACK от
> бэкенда
> > >  пришёл с такой задержкой. Возможно, бэкенд перегружен.
> > >  Возможно, свитчи по пути перегружены трафиком.
> >
> > Дампы:
> > RST: https://ufile.io/09s7w
> > FIN: https://ufile.io/0bkq5
>
>  В обоих дампах время около 2017-06-14 20:41:12, т.е. вчерашний день.
>
> > это вот эти два запроса
> > 2017/06/15 13:12:43 [error] 8449#8449: *729923 upstream timed out (110:
> > Connection timed out) while connecting to upstream, client:
> 128.74.129.198,
> > server: site, request: "GET /api/v1/product/58a2ed54d53f3d224a6b05c5
> > HTTP/1.1", upstream: "fastcgi://217.69.137.168:8080", host: "api.site"
> > 2017/06/15 13:12:43 [error] 8471#8471: *734373 upstream timed out (110:
> > Connection timed out) while connecting to upstream, client:
> 31.173.243.12,
> > server: site, request: "GET
> > /api/v1/counters/5730243396ad843510595f43?adv_
> id=D5D4F8D7-DEB7-4FE0-807E-143651398124&app_id=iphone%
> 2F3782&timestamp=1497521562&uid=uid&usr_latitude=55.
> 0252283782156&usr_longitude=82.93059721079625
> > HTTP/1.1", upstream: "fastcgi://217.69.137.73:8080", host: "api.site"
>
>  А здесь другое время, и другой день. Логи с дампами не стыкуются.
>
> > Возможно  с RST это вторая попытка отправить пакет через RTO + некоторое
> > время, но из debug log nginx я не понял сколько было попыток, вроде одна.
>
>  Nginx не может знать, сколько было ретрансмиссий, эта информация из ядра
>  ему не передаётся. Но потерять в pcap-е пакеты практически невозможно.
>
>  Да, дампы странные. Однако желательна привязка к логам.
>
> > по трем ДЦ ~ хаотично и закономерности я не вижу.
> > Если бы воспроизводилась в одном месте, то я бы видел максимумы ошибок,
> > связанные с одним хостом/дц. Ситуация была бы и на других проектах, но
> пока
> > такого не замечали.
>
>  Это может быть отражением того, что проблема как-то связана с
> конфигурацией
>  nginx для конкретного проекта, возможно, с "левыми" модулями.
> --
>  Eugene Berdnikov
> _______________________________________________
> 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/20170622/f6627a00/attachment.html>

From mdounin на mdounin.ru  Thu Jun 22 15:30:35 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Thu, 22 Jun 2017 18:30:35 +0300
Subject: =?UTF-8?B?UmU6INCd0LUg0L/QvtC90LjQvNCw0Y4g0LIg0YfQtdC8INC/0YDQuNGH0LjQvdCw?=
 =?UTF-8?B?INC60L7QtNCwINC+0YLQstC10YLQsCA1MDQg0YEg0L7RiNC40LHQutC+0Lkg?=
 =?UTF-8?B?Q29ubmVjdGlvbiB0aW1lZCBvdXQ=?=
In-Reply-To: <CAEB8VFLrDsTfsiYmCJP8m6FJccR9iQtQU_j5-ydwc=jUVxcU=g@mail.gmail.com>
References: <CAEB8VFJc1ReLfdth342uqw+7rQU0ZDK6aE8EJ=CuF1q3Ye1djA@mail.gmail.com>
 <20170615151301.d4vezsum6pfklj7f@protva.ru>
 <CAEB8VFKSCxw2WzCq=Uw-5xh8GiSgEbDDiV8DgCMGdG8QrtnVuQ@mail.gmail.com>
 <20170615214243.olp4x7z32vckt2fp@protva.ru>
 <CAEB8VFLrDsTfsiYmCJP8m6FJccR9iQtQU_j5-ydwc=jUVxcU=g@mail.gmail.com>
Message-ID: <20170622153035.GJ55433@mdounin.ru>

Hello!

On Thu, Jun 22, 2017 at 04:30:39PM +0300, Алексанр Платонов wrote:

> Пожалуйста, новые дампы и логи.
> https://ufile.io/0ony2
> https://ufile.io/bgt1i
> 
> 2017/06/22 15:53:55 [error] 45615#45615: *89748123 upstream timed out (110:
> Connection timed out) while connecting to upstream, client: 176.59.44.27,
> server: server, request: "POST
> /api/events/batch?app_id=311&uid=uid&usr_latitude=55.50582&adv_id=b309f032e4-4516-8950-cc01093bb398&usr_longitude=37.3288475&timestamp=1492954855
> HTTP/1.1", upstream: "fastcgi://217.69.137.58:8086", host: "server"
> 2017/06/22 15:53:55 [error] 45611#45611: *89788909 upstream timed out (110:
> Connection timed out) while connecting to upstream, client: 46.146.189.93,
> server: server, request: "POST
> /api/events/batch?app_id=311&uid=uid&usr_latitude=0.0&adv_id=f341a189-59573f-a520-9c76b003d6c4&usr_longitude=0.0&timestamp=1498136049
> HTTP/1.1", upstream: "fastcgi://217.69.137.35:8086", host: "server"
> 
> Есть идеи почему так может быть?

Судя по тому, что происходит всё в рамках одной миллисекунды:

15:53:51.936803 IP 217.69.137.60.45391 > 217.69.137.58.8086: Flags [S], seq 1264135273, win 14600, options [mss 1460,sackOK,TS val 70412504 ecr 0,nop,wscale 7], length 0
15:53:51.937189 IP 217.69.137.58.8086 > 217.69.137.60.45391: Flags [S.], seq 1137150422, ack 1264135274, win 14480, options [mss 1460,sackOK,TS val 70430564 ecr 70412504,nop,wscale 7], length 0
15:53:51.937194 IP 217.69.137.60.45391 > 217.69.137.58.8086: Flags [R], seq 1264135274, win 0, length 0

15:53:55.846481 IP 217.69.137.60.60107 > 217.69.137.58.8086: Flags [S], seq 694406592, win 14600, options [mss 1460,sackOK,TS val 70416414 ecr 0,nop,wscale 7]
15:53:55.846833 IP 217.69.137.58.8086 > 217.69.137.60.60107: Flags [S.], seq 104810584, ack 694406593, win 14480, options [mss 1460,sackOK,TS val 70434474 ecr
15:53:55.846841 IP 217.69.137.60.60107 > 217.69.137.58.8086: Flags [.], ack 1, win 115, options [nop,nop,TS val 70416414 ecr 70434474], length 0
15:53:55.846938 IP 217.69.137.60.60107 > 217.69.137.58.8086: Flags [F.], seq 1, ack 1, win 115, options [nop,nop,TS val 70416414 ecr 70434474], length 0
15:53:55.847081 IP 217.69.137.58.8086 > 217.69.137.60.60107: Flags [F.], seq 1, ack 2, win 114, options [nop,nop,TS val 70434474 ecr 70416414], length 0
15:53:55.847092 IP 217.69.137.60.60107 > 217.69.137.58.8086: Flags [.], ack 2, win 115, options [nop,nop,TS val 70416414 ecr 70434474], length 0

15:53:55.846491 IP 217.69.137.60.41780 > 217.69.137.35.8086: Flags [S], seq 2302129673, win 14600, options [mss 1460,sackOK,TS val 70416414 ecr 0,nop,wscale 7], length 0
15:53:55.847537 IP 217.69.137.35.8086 > 217.69.137.60.41780: Flags [S.], seq 410704669, ack 2302129674, win 14480, options [mss 1460,sackOK,TS val 4234532892 ecr 70416414,nop,wscale 7], length 0
15:53:55.847543 IP 217.69.137.60.41780 > 217.69.137.35.8086: Flags [R], seq 2302129674, win 0, length 0

и в двух случаях из трёх речь идёт о том, что соединение было 
закрыто раньше, чем установлено (RST в ответ на SYN-ACK).  Это всё 
выглядит как-то совсем подозрительно.  Было бы интересно увидеть 
debug log'и.

Кроме того, я бы рекомендовал посмотреть, что происходит со 
временем на сервере.  Коллеги ранее наблюдали нечто подобное, 
когда время в виртуальной машине с одной стороны выставлялось 
средствами системы виртуализации, а с другой - его пытался править 
timesyncd.  Борьба шла с переменным успехом, и продолжалась долго.  
Стало заметно, когда разница времён превысила минуту, и при каждом 
сдвиге времени вперёд стали срабатывать таймауты в nginx'е.

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

From andrey на kopeyko.ru  Thu Jun 22 15:41:20 2017
From: andrey на kopeyko.ru (Andrey Kopeyko)
Date: Thu, 22 Jun 2017 18:41:20 +0300
Subject: =?UTF-8?B?UmU6IHByb3h5X2NhY2hlX3ZhbGlkIGFueSAwOyDQuNCz0L3QvtGA0LjRgNGD0LU=?=
 =?UTF-8?B?0YLRgdGP?=
In-Reply-To: <CAK90gp7NDzwyvKbd76hTOO+K0dUTLfyTGXz2WSVdXeA16+-AQw@mail.gmail.com>
References: <CAJLdeeaTXhPoNYNVKcy0_aqFD8+-=Rd1ujeVbN5RnktOJzoJXg@mail.gmail.com>
 <b2415e40b4d1eddb54dc5a8b97b665c1@kopeyko.ru>
 <CAK90gp7NDzwyvKbd76hTOO+K0dUTLfyTGXz2WSVdXeA16+-AQw@mail.gmail.com>
Message-ID: <f5656e04fd6572085fda5dc8f8f2aa92@kopeyko.ru>

Alex Domoradov писал 2017-06-22 15:25:
>> У вас формат директивы неверный -
> последний параметр должен быть иметь
> размерность времени, а у вас - просто
> число.
> 
> а разве в таких случаях не
> подразумеваются секунды по дефолту?
> Как в случае с тем же proxy_send_timeout 180s ==
> proxy_send_timeout 180.

Да, Вы правы - это я подзабыл.

Сам я всегда задаю единицы измерения - вот и обратил внимание на 
"неверность формата" ;-(


-- 
Best regards,
Andrey A. Kopeyko <andrey на kopeyko.ru>

From skubriev на cvisionlab.com  Fri Jun 23 11:32:06 2017
From: skubriev на cvisionlab.com (Vladimir Skubriev)
Date: Fri, 23 Jun 2017 14:32:06 +0300
Subject: =?UTF-8?B?0JLQutC70Y7Rh9C10L3QuNC1INCw0LLRgtC+0YDQuNC30LDRhtC40Lgg0YLQvtC7?=
 =?UTF-8?B?0YzQutC+INC00LvRjyDQv9C+0LvRjNC30L7QstCw0YLQtdC70LXQuSDQuNC3?=
 =?UTF-8?B?INCY0L3RgtC10YDQvdC10YIu?=
Message-ID: <CAGgnAKpTpXZtc8pdaE7LTqLs=HaxrYc=YhBCyT=xbX6AsKSntA@mail.gmail.com>

Есть сервер nginx запущенный на шлюзе, локальная сеть и два провайдера (два
public ip).

Есть сайт вида:

server {
  listen 80;
  server_name site.example.com;
  return 301 https://$server_name$request_uri;
}

server {
  listen 443 ssl;
  server_name site.example.com;
  ...
}

Хочу добавить авторизацию, но только для тех кто приходит через Интернет.
Для внутренней сети всё должно работать без авториазции.

Самый простой вариант это использовать listen, и описать один и тот же сайт
(конечно с использованием include - дабы не дублировать одно и тоже) два
раза. Добавить авторизацию туда где сервер будет слушать на внешних IP.

Но если внутренний ip - статичен. То внешние pub_ip периодически всё таки
меняются. И при смене внешнего ip мне нужно будет не забыть о конфигах
nginx. А я не хочу об этом помнить.

Как решить эту задачу ?

Спасибо.

-- 
Faithfully yours,

CVision Lab System Administrator
Vladimir Skubriev
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170623/4f5b11b9/attachment-0001.html>

From alexander.moskalenko на gmail.com  Fri Jun 23 11:38:20 2017
From: alexander.moskalenko на gmail.com (Alexander Moskalenko)
Date: Fri, 23 Jun 2017 13:38:20 +0200
Subject: =?UTF-8?B?UmU6INCS0LrQu9GO0YfQtdC90LjQtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4INGC?=
 =?UTF-8?B?0L7Qu9GM0LrQviDQtNC70Y8g0L/QvtC70YzQt9C+0LLQsNGC0LXQu9C10Lkg?=
 =?UTF-8?B?0LjQtyDQmNC90YLQtdGA0L3QtdGCLg==?=
In-Reply-To: <CAGgnAKpTpXZtc8pdaE7LTqLs=HaxrYc=YhBCyT=xbX6AsKSntA@mail.gmail.com>
References: <CAGgnAKpTpXZtc8pdaE7LTqLs=HaxrYc=YhBCyT=xbX6AsKSntA@mail.gmail.com>
Message-ID: <CACVfVFvCuQ=0b8PXnUPOkd+RPgMz9PiPYVbD8rUKaBFyb7Hd2w@mail.gmail.com>

как-то так:

satisfy any;
allow 172.16.0.0/12
allow 127.0.0.1;
deny all;

auth_basic            "Restricted";
auth_basic_user_file  .htpasswd;


2017-06-23 13:32 GMT+02:00 Vladimir Skubriev <skubriev на cvisionlab.com>:

> Есть сервер nginx запущенный на шлюзе, локальная сеть и два провайдера
> (два public ip).
>
> Есть сайт вида:
>
> server {
>   listen 80;
>   server_name site.example.com;
>   return 301 https://$server_name$request_uri;
> }
>
> server {
>   listen 443 ssl;
>   server_name site.example.com;
>   ...
> }
>
> Хочу добавить авторизацию, но только для тех кто приходит через Интернет.
> Для внутренней сети всё должно работать без авториазции.
>
> Самый простой вариант это использовать listen, и описать один и тот же
> сайт (конечно с использованием include - дабы не дублировать одно и тоже)
> два раза. Добавить авторизацию туда где сервер будет слушать на внешних IP.
>
> Но если внутренний ip - статичен. То внешние pub_ip периодически всё таки
> меняются. И при смене внешнего ip мне нужно будет не забыть о конфигах
> nginx. А я не хочу об этом помнить.
>
> Как решить эту задачу ?
>
> Спасибо.
>
> --
> Faithfully yours,
>
> CVision Lab System Administrator
> Vladimir Skubriev
>
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170623/6b898759/attachment.html>

From skubriev на cvisionlab.com  Fri Jun 23 13:17:46 2017
From: skubriev на cvisionlab.com (Vladimir Skubriev)
Date: Fri, 23 Jun 2017 16:17:46 +0300
Subject: =?UTF-8?B?UmU6INCS0LrQu9GO0YfQtdC90LjQtSDQsNCy0YLQvtGA0LjQt9Cw0YbQuNC4INGC?=
 =?UTF-8?B?0L7Qu9GM0LrQviDQtNC70Y8g0L/QvtC70YzQt9C+0LLQsNGC0LXQu9C10Lkg?=
 =?UTF-8?B?0LjQtyDQmNC90YLQtdGA0L3QtdGCLg==?=
In-Reply-To: <CACVfVFvCuQ=0b8PXnUPOkd+RPgMz9PiPYVbD8rUKaBFyb7Hd2w@mail.gmail.com>
References: <CAGgnAKpTpXZtc8pdaE7LTqLs=HaxrYc=YhBCyT=xbX6AsKSntA@mail.gmail.com>
 <CACVfVFvCuQ=0b8PXnUPOkd+RPgMz9PiPYVbD8rUKaBFyb7Hd2w@mail.gmail.com>
Message-ID: <CAGgnAKpM04foX7kuWz4aTmP1AJSnAxAptWhoG+ak-83kOjzauw@mail.gmail.com>

Спасибо большое.

23 июня 2017 г., 14:38 пользователь Alexander Moskalenko <
alexander.moskalenko на gmail.com> написал:

> как-то так:
>
> satisfy any;
> allow 172.16.0.0/12
> allow 127.0.0.1;
> deny all;
>
> auth_basic            "Restricted";
> auth_basic_user_file  .htpasswd;
>
>
> 2017-06-23 13:32 GMT+02:00 Vladimir Skubriev <skubriev на cvisionlab.com>:
>
>> Есть сервер nginx запущенный на шлюзе, локальная сеть и два провайдера
>> (два public ip).
>>
>> Есть сайт вида:
>>
>> server {
>>   listen 80;
>>   server_name site.example.com;
>>   return 301 https://$server_name$request_uri;
>> }
>>
>> server {
>>   listen 443 ssl;
>>   server_name site.example.com;
>>   ...
>> }
>>
>> Хочу добавить авторизацию, но только для тех кто приходит через Интернет.
>> Для внутренней сети всё должно работать без авториазции.
>>
>> Самый простой вариант это использовать listen, и описать один и тот же
>> сайт (конечно с использованием include - дабы не дублировать одно и тоже)
>> два раза. Добавить авторизацию туда где сервер будет слушать на внешних IP.
>>
>> Но если внутренний ip - статичен. То внешние pub_ip периодически всё таки
>> меняются. И при смене внешнего ip мне нужно будет не забыть о конфигах
>> nginx. А я не хочу об этом помнить.
>>
>> Как решить эту задачу ?
>>
>> Спасибо.
>>
>> --
>> Faithfully yours,
>>
>> CVision Lab System Administrator
>> Vladimir Skubriev
>>
>>
>> _______________________________________________
>> 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
>



-- 
Faithfully yours,

CVision Lab System Administrator
Vladimir Skubriev
----------- следущая часть -----------
Вложение в формате HTML было извлечено&hellip;
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170623/1d232c57/attachment.html>

From nginx-forum на forum.nginx.org  Sun Jun 25 06:26:42 2017
From: nginx-forum на forum.nginx.org (bassay)
Date: Sun, 25 Jun 2017 02:26:42 -0400
Subject: =?UTF-8?B?0J/QvtC80L7Qs9C40YLQtSDQvdCw0YHRgtGA0L7QuNGC0Ywg0LrQvtC90YTQuNCz?=
 =?UTF-8?B?IG5naW54INC/0L4g0LLRgNC10LzQtdC90Lg=?=
Message-ID: <cf662a5860cc82d300b5035eeb68d133.NginxMailingListRussian@forum.nginx.org>

Всем привет!

хочу потестировать одну фишку(эксперимент над ПС), но не получается
настроить конфиг

суть: у меня есть основной домен и зеркало (не основной домен)

мне нужно сделать чтобы основной домен работал ночью, а зеркало днем

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

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

Заранее всем спс )

---
в общем пока остановился на этом:

# 301 редирект на основной домен
set $main_host 'site1.ru';
if ($host != $main_host) {
	rewrite ^(.*)$ http://$main_host$1 permanent;
	break;
}

# 301 редирект на доп. домен
set $main_host 'site2.ru';
if ($host != $main_host) {
	rewrite ^(.*)$ http://$main_host$1 permanent;
	break;
}

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


From basil на vpm.net.ua  Sun Jun 25 08:51:11 2017
From: basil на vpm.net.ua (Vasiliy P. Melnik)
Date: Sun, 25 Jun 2017 11:51:11 +0300
Subject: =?UTF-8?B?UmU6INCf0L7QvNC+0LPQuNGC0LUg0L3QsNGB0YLRgNC+0LjRgtGMINC60L7QvdGE?=
 =?UTF-8?B?0LjQsyBuZ2lueCDQv9C+INCy0YDQtdC80LXQvdC4?=
In-Reply-To: <cf662a5860cc82d300b5035eeb68d133.NginxMailingListRussian@forum.nginx.org>
References: <cf662a5860cc82d300b5035eeb68d133.NginxMailingListRussian@forum.nginx.org>
Message-ID: <CAMPJU7D7yuECtcyQC_B7JwsJuW+9pSi7ZzoHbiy00kVL1Z2_GQ@mail.gmail.com>

моет все таки proxy_pass и убрать два разных домена, а оставить один
настроенный на двух серверах

25 июня 2017 г., 9:26 пользователь bassay <nginx-forum на forum.nginx.org>
написал:

> Всем привет!
>
> хочу потестировать одну фишку(эксперимент над ПС), но не получается
> настроить конфиг
>
> суть: у меня есть основной домен и зеркало (не основной домен)
>
> мне нужно сделать чтобы основной домен работал ночью, а зеркало днем
>
> я так понял в конфиге nginx можно задавать различные условия, помогите это
> всё реализовать )
>
> либо может посоветует лучшее решение, как это сделать
>
> Заранее всем спс )
>
> ---
> в общем пока остановился на этом:
>
> # 301 редирект на основной домен
> set $main_host 'site1.ru';
> if ($host != $main_host) {
>         rewrite ^(.*)$ http://$main_host$1 permanent;
>         break;
> }
>
> # 301 редирект на доп. домен
> set $main_host 'site2.ru';
> if ($host != $main_host) {
>         rewrite ^(.*)$ http://$main_host$1 permanent;
>         break;
> }
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,275125,275125#msg-275125
>
> _______________________________________________
> 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/20170625/2db0115e/attachment.html>

From nginx-forum на forum.nginx.org  Tue Jun 27 11:18:57 2017
From: nginx-forum на forum.nginx.org (2D77rus)
Date: Tue, 27 Jun 2017 07:18:57 -0400
Subject: =?UTF-8?B?0Jgg0YHQvdC+0LLQsCDQv9C+IFRMUyDQuCDQsNGD0YLQtdC90YLQuNGE0LjQutCw?=
 =?UTF-8?B?0YbQuNC4?=
Message-ID: <3061a4905926de49aee56e4136d929ab.NginxMailingListRussian@forum.nginx.org>

Здравствуйте, коллеги.

Никак не могу побороть авторизацию по сертификатам, получаю ошибку "client
SSL certificate verify error: (3:unable to get certificate CRL)". Этот и
другие форумы пересмотрел, всё не то.

Конфиг:
==================
        ssl    on;
        ssl_certificate      /etc/pki/tls/certs/mail2.local.cer;
        ssl_certificate_key  /etc/pki/tls/private/private.key;
        ssl_session_timeout  5m;
        ssl_protocols  SSLv2 SSLv3 TLSv1;
        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers   on;

        ssl_trusted_certificate /etc/pki/tls/certs/chain.cer; # сертификаты
CA1 и CA0
        ssl_client_certificate /etc/pki/tls/certs/ca1.cer; # только
сертификат CA1
        ssl_crl /etc/pki/tls/certs/ca1.crl; # только CRL от CA1
        ssl_verify_client on;
        ssl_verify_depth 1;
==================
Сертификаты, CRL - всё живое:

openssl crl -CAfile CA1.cer -in CA1.crl
verify OK

openssl verify -CAfile CA0.cer CA1.cer
verify OK

openssl verify -CAfile chain.cer client1.cer
verify OK

- и всё равно неизменно ошибка. 

Если убрать параметр ssl_crl, получаю "client SSL certificate verify error:
(27:certificate not trusted)"

CA0 - корневой ЦС, CA1 - промежуточный ЦС, который выдал сертификат клиенту
(виндовый, AD 2012). 
Сертификаты CA0 и CA1 добавлены в доверенные на сервере.
CentOS 6.8, nginx/1.8.1, OpenSSL 1.0.1e-fips
SMTP и IMAP на этом же сервере с тем же набором сертификатов - клиенты по
сертификатам прекрасно авторизуются.

Куда ещё копнуть, подскажите? Спасибо.

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


From mdounin на mdounin.ru  Tue Jun 27 12:18:14 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 27 Jun 2017 15:18:14 +0300
Subject: =?UTF-8?B?UmU6INCYINGB0L3QvtCy0LAg0L/QviBUTFMg0Lgg0LDRg9GC0LXQvdGC0LjRhNC4?=
 =?UTF-8?B?0LrQsNGG0LjQuA==?=
In-Reply-To: <3061a4905926de49aee56e4136d929ab.NginxMailingListRussian@forum.nginx.org>
References: <3061a4905926de49aee56e4136d929ab.NginxMailingListRussian@forum.nginx.org>
Message-ID: <20170627121814.GX55433@mdounin.ru>

Hello!

On Tue, Jun 27, 2017 at 07:18:57AM -0400, 2D77rus wrote:

> Здравствуйте, коллеги.
> 
> Никак не могу побороть авторизацию по сертификатам, получаю ошибку "client
> SSL certificate verify error: (3:unable to get certificate CRL)". Этот и
> другие форумы пересмотрел, всё не то.
> 
> Конфиг:
> ==================
>         ssl    on;
>         ssl_certificate      /etc/pki/tls/certs/mail2.local.cer;
>         ssl_certificate_key  /etc/pki/tls/private/private.key;
>         ssl_session_timeout  5m;
>         ssl_protocols  SSLv2 SSLv3 TLSv1;
>         ssl_ciphers  HIGH:!aNULL:!MD5;
>         ssl_prefer_server_ciphers   on;
> 
>         ssl_trusted_certificate /etc/pki/tls/certs/chain.cer; # сертификаты
> CA1 и CA0
>         ssl_client_certificate /etc/pki/tls/certs/ca1.cer; # только
> сертификат CA1
>         ssl_crl /etc/pki/tls/certs/ca1.crl; # только CRL от CA1
>         ssl_verify_client on;
>         ssl_verify_depth 1;
> ==================
> Сертификаты, CRL - всё живое:
> 
> openssl crl -CAfile CA1.cer -in CA1.crl
> verify OK
> 
> openssl verify -CAfile CA0.cer CA1.cer
> verify OK
> 
> openssl verify -CAfile chain.cer client1.cer
> verify OK
> 
> - и всё равно неизменно ошибка. 
> 
> Если убрать параметр ssl_crl, получаю "client SSL certificate verify error:
> (27:certificate not trusted)"
> 
> CA0 - корневой ЦС, CA1 - промежуточный ЦС, который выдал сертификат клиенту
> (виндовый, AD 2012). 
> Сертификаты CA0 и CA1 добавлены в доверенные на сервере.
> CentOS 6.8, nginx/1.8.1, OpenSSL 1.0.1e-fips
> SMTP и IMAP на этом же сервере с тем же набором сертификатов - клиенты по
> сертификатам прекрасно авторизуются.
> 
> Куда ещё копнуть, подскажите? Спасибо.

Во-первых, "ssl_verify_depth 1" при использовании промежуточного 
CA не годится, т.к. ssl_verify_depth ограничивает глубину проверки 
до корневого CA.  Соответственно значение 1 означает, что 
предъявленный клиентом сертификат должен быть подписан 
непосредственно корневым CA.  В случае использования промежуточных 
CA - нужно выставить ssl_verify_depth 2 и более.

Во-вторых, для работы ssl_crl необходимо, чтобы списки отзыва были 
для всех используемых CA.  Если для какого-то из сертификатов 
списков отзыва в указанном CRL-файле не будет, то ошибка "unable 
to get certificate CRL" - ожидаема.  В openssl verify 
соответствующий ключ называется -crl_check_all".

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

From mdounin на mdounin.ru  Tue Jun 27 15:04:26 2017
From: mdounin на mdounin.ru (Maxim Dounin)
Date: Tue, 27 Jun 2017 18:04:26 +0300
Subject: nginx-1.13.2
Message-ID: <20170627150426.GG55433@mdounin.ru>

Изменения в nginx 1.13.2                                          27.06.2017

    *) Изменение: теперь при запросе диапазона, начинающегося с 0, из
       пустого файла nginx возвращает ответ 200 вместо 416.

    *) Добавление: директива add_trailer.
       Спасибо Piotr Sikora.

    *) Исправление: nginx не собирался под Cygwin и NetBSD; ошибка появилась
       в 1.13.0.

    *) Исправление: nginx не собирался под MSYS2 / MinGW 64-bit.
       Спасибо Orgad Shaneh.

    *) Исправление: при использовании SSI с большим количеством подзапросов
       и proxy_pass с переменными в рабочем процессе мог произойти
       segmentation fault.

    *) Исправление: в модуле ngx_http_v2_module.
       Спасибо Piotr Sikora.


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

From nginx-forum на forum.nginx.org  Tue Jun 27 15:25:57 2017
From: nginx-forum на forum.nginx.org (2D77rus)
Date: Tue, 27 Jun 2017 11:25:57 -0400
Subject: =?UTF-8?B?UmU6INCYINGB0L3QvtCy0LAg0L/QviBUTFMg0Lgg0LDRg9GC0LXQvdGC0LjRhNC4?=
 =?UTF-8?B?0LrQsNGG0LjQuA==?=
In-Reply-To: <20170627121814.GX55433@mdounin.ru>
References: <20170627121814.GX55433@mdounin.ru>
Message-ID: <23eb4baaed355f13796ceaa44f526382.NginxMailingListRussian@forum.nginx.org>

Во! -crl_check_all не хватало, теперь всё встало на места. Не хватало CRL от
CA0.
При этом, добавлять его в файл ssl_crl нельзя, будет вылезать ошибка подписи
CRL.
Итак, всё требуемое для проверки сертификата нужно класть в
ssl_client_certificate. 
Imho, не мешало бы упомянуть такую фичу в мануале или в faq.
===================
 ssl_client_certificate /etc/pki/tls/certs/all-certs-and-crls.pem; 
   # CA1.cer + CA1.crl + CA0.cer + CA0.crl
 ssl_crl /etc/pki/tls/certs/ca1.crl;
   # только CRL от CA1
 ssl_verify_client on;
 ssl_verify_depth 2;
===================

Спасибо, всё работает.

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


From nginx-forum на forum.nginx.org  Fri Jun 30 11:51:39 2017
From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?=
 =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=)
Date: Fri, 30 Jun 2017 07:51:39 -0400
Subject: =?UTF-8?B?RVJSIFNQRFkgUFJPVE9DT0wgRVJST1Ig0L/RgNC4IFNTSSDQsiDRhdGA0L7QvNC1?=
Message-ID: <fe602f62df2ad7571e22096bca67d983.NginxMailingListRussian@forum.nginx.org>

Всем доброго дня/вечера. Есть страница https://viparenda.ru/arenda_ofisa/ .
Не так давно на ней в хроме периодически начала появляться данная ошибка
(только на ней и только в хромоподобных браузерах. В FF и Edge сколько не
пытался, так и не получилось её добиться). В логах при этом было пусто,
только в access_log $body_bytes_sent был равен 0. Единственное что сильно
отличает её от подобных страниц это "плашка" внизу страницы с 8 рандомными
объектами, которая подгружалась при помощи ssi + fastcgi_cache, т.к. все
страницы с результатами поиска также кешируются. Проблема решилась
выставлением wait="yes", так что вопросов нет. Хотелось просто донести
информацию и таки разобраться. Ведь иногда она таки отрабатывалась
нормально, также у основной страницы и ssi разное время кеширования (1 час и
1 день соответственно). Nginx 1.13.2, но появилось гораздо раньше. На
странице суммарно 3 ssi запроса, на остальных по 2

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


From vbart на nginx.com  Fri Jun 30 13:02:13 2017
From: vbart на nginx.com (=?utf-8?B?0JLQsNC70LXQvdGC0LjQvSDQkdCw0YDRgtC10L3QtdCy?=)
Date: Fri, 30 Jun 2017 16:02:13 +0300
Subject: =?UTF-8?B?UmU6IEVSUiBTUERZIFBST1RPQ09MIEVSUk9SINC/0YDQuCBTU0kg0LIg0YXRgNC+?=
 =?UTF-8?B?0LzQtQ==?=
In-Reply-To: <fe602f62df2ad7571e22096bca67d983.NginxMailingListRussian@forum.nginx.org>
References: <fe602f62df2ad7571e22096bca67d983.NginxMailingListRussian@forum.nginx.org>
Message-ID: <9255206.ieq65QOJcb@vbart-laptop>

On Friday 30 June 2017 07:51:39 Дмитрий Герасимов wrote:
> Всем доброго дня/вечера. Есть страница https://viparenda.ru/arenda_ofisa/ .
> Не так давно на ней в хроме периодически начала появляться данная ошибка
> (только на ней и только в хромоподобных браузерах. В FF и Edge сколько не
> пытался, так и не получилось её добиться). В логах при этом было пусто,
> только в access_log $body_bytes_sent был равен 0. Единственное что сильно
> отличает её от подобных страниц это "плашка" внизу страницы с 8 рандомными
> объектами, которая подгружалась при помощи ssi + fastcgi_cache, т.к. все
> страницы с результатами поиска также кешируются. Проблема решилась
> выставлением wait="yes", так что вопросов нет. Хотелось просто донести
> информацию и таки разобраться. Ведь иногда она таки отрабатывалась
> нормально, также у основной страницы и ssi разное время кеширования (1 час и
> 1 день соответственно). Nginx 1.13.2, но появилось гораздо раньше. На
> странице суммарно 3 ssi запроса, на остальных по 2
> 
[..]

Нужен дебаг лог с nginx и из Хрома (вкладка chrome://net-internals)
при появлении такой ошибки.

Без этого искать проблему можно вечность, протокол SPDY, он же HTTP/2, 
невероятно сложен для дебага, а тут ещё накладываются факторы в виде
кэша и асинхронного SSI.

--
Валентин Бартенев

From nginx-forum на forum.nginx.org  Fri Jun 30 15:12:40 2017
From: nginx-forum на forum.nginx.org (=?UTF-8?Q? =D0=94=D0=BC=D0=B8=D1=82=D1=80=D0=B8=D0=B9=20=D0=93=D0=B5?=
 =?UTF-8?Q?=D1=80=D0=B0=D1=81=D0=B8=D0=BC=D0=BE=D0=B2 ?=)
Date: Fri, 30 Jun 2017 11:12:40 -0400
Subject: =?UTF-8?B?UmU6IEVSUiBTUERZIFBST1RPQ09MIEVSUk9SINC/0YDQuCBTU0kg0LIg0YXRgNC+?=
 =?UTF-8?B?0LzQtQ==?=
In-Reply-To: <9255206.ieq65QOJcb@vbart-laptop>
References: <9255206.ieq65QOJcb@vbart-laptop>
Message-ID: <7fc5b55fe7140cdcc39cc99118e0d27a.NginxMailingListRussian@forum.nginx.org>

Валентин Бартенев Wrote:
-------------------------------------------------------
> Нужен дебаг лог с nginx и из Хрома (вкладка chrome://net-internals)
> при появлении такой ошибки.
> 
> Без этого искать проблему можно вечность, протокол SPDY, он же HTTP/2,
> 
> невероятно сложен для дебага, а тут ещё накладываются факторы в виде
> кэша и асинхронного SSI.
> 
> --
> Валентин Бартенев
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Про хром можно проверить здесь https://viparenda.ru/test.html - статичная
копия той страницы, соотв. "убивающий" ssi wait заменён на no. Про nginx не
очень понятно, что именно нужно?

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