Re: Почему не применются заголоки для locations, определенные в server?

2021-05-12 Пенетрантность Alexey 

12.05.2021 22:38, budarin пишет:

не очень понятно >> на данном уровне не описаны свои директивы add_header.

не описаны любые или такие же???
речь как раз о случае когда я описываю в server и не описываю в location  -
заголовки не появляются в запросах к location



Скореее всего они (add_header) есть в /etc/nginx/config/system/security.conf 
или если там тоже есть инклюды, то там.

Считайте тчо содердимое include файла просто вставлено на месте  комманды 
include. команда расположена на уровне какого то include, соотв если во 
включаемом файле есть любые команды add_header, то всё что было описано выше не 
существует.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: запись ответа от сервиса в лог файл nginx

2021-03-25 Пенетрантность Alexey 

Както так ?
proxy_store /data/www/$uri/$request_id ?

25.03.2021 16:07, Vitaliy Okulov пишет:
Я так понимаю что возникнут проблемы с уникальностью данных в 
зависимости от пользователя, запроса который он создает и т.д.


чт, 25 мар. 2021 г. в 14:30, Илья Шипицин >:


proxy_store ?

чт, 25 мар. 2021 г. в 14:50, Vitaliy Okulov
mailto:vitaliy.oku...@gmail.com>>:

Добрый день.
Подскажите что можно сделать в ситуации когда требуется писать
в файл тело ответа сервиса, попробовал вариант с обработкой в
body_filter_by_lua, но при больших телах ответа воркер
блокируется и потребляет 100% CPU
Какие еще варианты реализовать задачу на уровне nginx возможны?
___
nginx-ru mailing list
nginx-ru@nginx.org 
http://mailman.nginx.org/mailman/listinfo/nginx-ru


___
nginx-ru mailing list
nginx-ru@nginx.org 
http://mailman.nginx.org/mailman/listinfo/nginx-ru



___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru



___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2020-12-24 Пенетрантность Alexey 

25.12.2020 1:34, Nikolay Grebnev пишет:

Не выдержал, поискал форум и зарегистрировался.
Мне на гмейл письмо дошло без каких-либо проблем.
Если не придираться к странному w...@teresa.liquidhost.co то все работает.

гугл не пытается проверить адрес путём соединения обратно. многие 
пытаются. ответ на такой адрес отправить невозможно. соотв "анонимки не 
берем". принимать или нет такую почту, вопрос возможно спорный, но что 
писать с неработающих в принципе доменов не надо, это точно. postmaster@ 
в любом домене, откуда ходит почта, должен быть рабочим. а тут на 25 
порту никого нет. Ктото (не будем тыкать пальцем во владельца форума) не 
удосужился настроить сервис.


да и как уже писали

teresa.liquidhost.co.   7200    IN  MX  10 69.46.5.194.
это не валидная запись. и много кто по этому признаку тоже не примет. МХ 
должен указывать на FQDN а не на IP. уж лучше бы не писал вообще MX,


___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

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

2020-12-24 Пенетрантность Alexey 

24.12.2020 1:33, pavlusha23 пишет:

(Почините этот форум, невозможно зарегистрироваться если почта расположена
на серверах с современными строгими антиспам настройками.)

Добрый день, несколько моих коллег хотел ли бы тут зарегистрироваться, но не
могут. Я проверил сам, действительно невозможно. Они мне скинули логи своей
почты тоже. У всех ситуация примерно одинакова:

sender verify fail for : all relevant MX records
point to non-existent hosts or (invalidly) to IP addresses.
F= rejected RCPT : Sender verify
failed

Т.е. этот форум для служебной рассылки использует какой-то левый
несуществующий адрес отправителя w...@teresa.liquidhost.co то ли DNS неверно
настроен, и естественно такие письма сразу отсекаются почтовыми серверами
(по крайней мере всеми на базе ispmanager последних версий) на этапе
приёмки, даже в спам не попадают. Прошу администрацию уделить этому
внимание, вроде айтишники жеж.

У меня старый аккаунт тут, поэтому пишу по просьбе трудящихся. Всем спасибо
и с наступающим рождеством!




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



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



ниже не единственный ответ по проблеме с форумом


27.02.2020 15:09, Maxim Dounin пишет:
Hello!

On Thu, Feb 27, 2020 at 12:08:42AM +0300, Dmitry Ivanov wrote:


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


@Dmitry - форум это просто веб-морда к почтовой рассылке - можно
подписаться на странице -
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Я  в  рассылке  и  читаю. А с форума тяну RSS

Форум - поддерживается не нами, его держит Jim Ohlstein.
Соответственно писать о проблемах форума в русскую рассылку -
приблизительно полностью бесполезно.

Мы со своей стороны - в связи с неоднократными проблемами уже
давно выпилили все ссылки с nginx.org на форум.  Можем и DNS
убрать, но наверное это не совсем то, что хотят люди, использующие
форум хоть как-то.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблема при проксировании на nginx с ssl reject handshake on

2020-12-22 Пенетрантность Alexey Koscheev 
Сам себе отвечу :)

На Сервер1 не хватало строки:
proxy_ssl_name $host;

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

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Проблема при проксировании на nginx с ssl reject handshake on

2020-12-22 Пенетрантность Alexey Koscheev 
Сервер1 (принимает запросы и проксирует на сервер 2):

server {
listen a.b.c.d:443 ssl;
server_name
abcd.example
;
access_log off;
ssl_certificate path_to.crt;
ssl_certificate_key path_to.key;
location / {
proxy_pass https://b.c.d.e:443;
proxy_ssl_server_name on;
proxy_set_header Host $host;
}
}

Сервер2
server {
listen b.c.d.e:443 ssl default_server;
server_name _;

access_log off;
ssl_certificate /usr/local/nginx/conf/cert.pem;
ssl_certificate_key /usr/local/nginx/conf/key.pem;
ssl_reject_handshake on;

location / {
return 444;
}
}

server {
listen b.c.d.e:443 ssl http2;
server_name abcd.example
;
access_log access.log combined;
root /home2/xyz/abcd.example/WWW;
ssl_certificate path_to.crt;
ssl_certificate_key path_to.key;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate path_to.trusted;
location / {
proxy_pass http://127.0.0.1:80;
}

}


Если на Сервер2 ssl_reject_handshake on;, то запросы к Сервер 1 завершаются
502 ошибкой. В error лог такое:
2020/12/22 11:05:13 [crit] 57654#0: *13192673 SSL_do_handshake() failed
(SSL: error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized
name:SSL alert number 112) while SSL handshaking to upstream, client:
192.168.10.250, server: abcd.example, request: "GET / HTTP/2.0", upstream:
"https://b.c.d.e:443/;, host: "xn--b1aghahdtcfeb2aifj5e.xn--p1ai"

Наличие строк 
proxy_ssl_server_name on;
proxy_set_header Host $host;
в конфиге server на Сервер1 никак не влияет на проблему.

В чем может быть дело?

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

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Непонятна работа limit_rate

2020-10-05 Пенетрантность Alexey 

День добрый!

Вы качаете файл, получаемых от прокси апстрима?
https://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_max_temp_file_size

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



05.10.2020 20:16, Иван Мишин пишет:
Забыл уточнить, что при обрыве в акцес логах все равно значится 200 
код, а в ерор логах пусто.


пн, 5 окт. 2020 г. в 19:47, Иван Мишин >:


Добрый день!
Есть локейшн с настроенными вот такими директивами:
  limit_rate_after 15k; #150Mb
  limit_rate 2048k;

Пробую качать с помощью wget большой файл, и примерно через 7
минут 49-55 секунд закачка обрывается ну и соответственно объем
(1.1Гб) скачанных данных в зависимости от времени слегка разный.
Как только убирают указанные выше две директивы, так все логично
быстро качается и самое главное без обрыва , качается целиком.
А проблема заключается в том что указанными директивами я лишь
хотел подрезать скорость, но не понятно почему при этом файл не
скачивается до конца! До 1.1Гб файлы скачиваются нормально, а
больше уже нет. Хотел было грешить на таймауты какие-нибудь, но
время обрыва хоть и примерно одинаковое, но все же не постоянное,
поэтому идею с таймаутами отбросил.

Прошу подсказать как решить проблему?


___
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

Re: Почему пустой if ломает работу try files?

2020-09-30 Пенетрантность Alexey Galygin 
да, примеры были из habr, но и там к статье были претензии к map-решению
+ я специально усложнил пример регулярными выражениями

поэтому указанный map это не эквивалент

во вторых плохо читаемый хак и издевательство над линейной логикой
зачем такие костыли, если можно доделать нормальный if?



> On 30 Sep 2020, at 05:14, fox  wrote:
> 
> Троллишь?
> 
> map "$http_user_agent:$method:$uri" $block {
>"HackYou:POST:/admin/some/url"  "1";
> }
> 
> if ($block) {
>return 403;
> }
> 
> 
> 30.09.2020 02:24, Alexey Galygin пишет:
>> не вкусовщина
>> часто очень не хватает простейших and/&& и or/||
>> 
>> вот чтобы такое не писать:
>> 
>> if($http_user_agent~ "HackYou"){ set$block"A"; } if($method= "POST") {
>> set$block"${block}B"; } if($uri~ “^/admin/some/url") {
>> set$block"${block}C"; } if($block= "ABC") { return403; }
>> 
>> vs условно:
>> 
>> if/eif ($http_user_agent~ “HackYou” && $method= “POST” && $uri~
>> “^/admin/some/url”) {
>> return403;
>> }
>> 
>> 
>>> On 29 Sep 2020, at 21:49, Илья Шипицин >> <mailto:chipits...@gmail.com <mailto:chipits...@gmail.com>>> wrote:
>>> 
>>> это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в
>>> определенном синтаксисе.
>>> сейчас вы точно так же выражаете свою мысль через map-ы.
>>> 
>>> по сути просто диалекты языка
>>> 
>>> вт, 29 сент. 2020 г. в 22:41, Alexey Galygin >> <mailto:m...@me.com>
>>> <mailto:m...@me.com <mailto:m...@me.com>>>:
>>> 
>>>иногда трудно обойтись без дополнительной логики,
>>>которую ради такой мелочи отдавать на backend грустно
>>> 
>>>    и речь про улучшение поведения исключительно с обратной совместимостью
>>> 
>>>если совсем никак, то можно добавить условно extended if — eif
>>> 
>>> 
>>>> On 29 Sep 2020, at 19:47, fox mailto:red-f...@ya.ru>
>>><mailto:red-f...@ya.ru <mailto:red-f...@ya.ru>>> wrote:
>>>> 
>>>> 1) может, потому что конфиг - это не язык программирования?
>>>> 
>>>> 2) изменение поведения сломает тысячи существующих систем.
>>>> 
>>>> 
>>>> 29.09.2020 23:31, Alexey Galygin пишет:
>>>>> присоединяюсь к вопросу:
>>>>> 
>>>>> почему бы не сделать if нормальным? чтобы без артефактов… и
>>>немного мощнее
>>>>> 
>>>>> нам вот тоже приходится делать по несколько map, чтобы логику
>>>чуть более сложную построить…
>>>>> и это ужас
>>>>> 
>>>>>> On 29 Sep 2020, at 19:29, Sergey Kandaurov >>>>> <mailto:pluk...@nginx.com>
>>><mailto:pluk...@nginx.com <mailto:pluk...@nginx.com>>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 29 Sep 2020, at 17:12, Ilya Evseev
>>>mailto:nginx-fo...@forum.nginx.org> 
>>> <mailto:nginx-fo...@forum.nginx.org <mailto:nginx-fo...@forum.nginx.org>>>
>>>wrote:
>>>>>>> 
>>>>>>> Имеется nginx 1.19.2 со следующей настройкой:
>>>>>>> 
>>>>>>>   server {
>>>>>>>   location / {
>>>>>>>   if ($http_user_agent ~ "TestAgent") { }
>>>>>>>   try_files $uri $uri/ /index.html;
>>>>>>>   }
>>>>>>>   }
>>>>>>> 
>>>>>>> Почему попадание в if меняет логику работы последующего
>>>try_files?
>>>>>> 
>>>>>> https://wiki.nginx.org/IfIsEvil <https://wiki.nginx.org/IfIsEvil>
>>>>>> 
>>>>>> --
>>>>>> Sergey Kandaurov
>>>>>> 
>>>>>> ___
>>>>>> nginx-ru mailing list
>>>>>> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org> 
>>>>>> <mailto: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>
>>>>> 
>>>>> ___
>>>>> ngin

Re: Почему пустой if ломает работу try files?

2020-09-29 Пенетрантность Alexey Galygin 
не вкусовщина
часто очень не хватает простейших and/&& и or/||

вот чтобы такое не писать:

if ($http_user_agent ~ "HackYou") {
set $block "A";
}

if ($method = "POST") {
set $block "${block}B";
}

if ($uri ~ “^/admin/some/url") {
set $block "${block}C";
}

if ($block = "ABC") {
return 403;
}

vs условно:

if/eif ($http_user_agent ~ “HackYou” && $method = “POST” && $uri ~ 
“^/admin/some/url”) {
return 403;
}


> On 29 Sep 2020, at 21:49, Илья Шипицин  wrote:
> 
> это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в 
> определенном синтаксисе.
> сейчас вы точно так же выражаете свою мысль через map-ы.
> 
> по сути просто диалекты языка
> 
> вт, 29 сент. 2020 г. в 22:41, Alexey Galygin  <mailto:m...@me.com>>:
> иногда трудно обойтись без дополнительной логики,
> которую ради такой мелочи отдавать на backend грустно
> 
> и речь про улучшение поведения исключительно с обратной совместимостью
> 
> если совсем никак, то можно добавить условно extended if — eif
> 
> 
> > On 29 Sep 2020, at 19:47, fox mailto:red-f...@ya.ru>> 
> > wrote:
> > 
> > 1) может, потому что конфиг - это не язык программирования?
> > 
> > 2) изменение поведения сломает тысячи существующих систем.
> > 
> > 
> > 29.09.2020 23:31, Alexey Galygin пишет:
> >> присоединяюсь к вопросу:
> >> 
> >> почему бы не сделать if нормальным? чтобы без артефактов… и немного мощнее
> >> 
> >> нам вот тоже приходится делать по несколько map, чтобы логику чуть более 
> >> сложную построить…
> >> и это ужас
> >> 
> >>> On 29 Sep 2020, at 19:29, Sergey Kandaurov  >>> <mailto:pluk...@nginx.com>> wrote:
> >>> 
> >>> 
> >>>> On 29 Sep 2020, at 17:12, Ilya Evseev  >>>> <mailto:nginx-fo...@forum.nginx.org>> wrote:
> >>>> 
> >>>> Имеется nginx 1.19.2 со следующей настройкой:
> >>>> 
> >>>>  server {
> >>>>  location / {
> >>>>  if ($http_user_agent ~ "TestAgent") { }
> >>>>  try_files $uri $uri/ /index.html;
> >>>>  }
> >>>>  }
> >>>> 
> >>>> Почему попадание в if меняет логику работы последующего try_files?
> >>> 
> >>> https://wiki.nginx.org/IfIsEvil <https://wiki.nginx.org/IfIsEvil>
> >>> 
> >>> -- 
> >>> Sergey Kandaurov
> >>> 
> >>> ___
> >>> nginx-ru mailing list
> >>> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru 
> >>> <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
> >> 
> >> ___
> >> nginx-ru mailing list
> >> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> >> http://mailman.nginx.org/mailman/listinfo/nginx-ru 
> >> <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
> >> 
> > 
> > ___
> > nginx-ru mailing list
> > nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru 
> > <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru 
> <http://mailman.nginx.org/mailman/listinfo/nginx-ru>___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Почему пустой if ломает работу try files?

2020-09-29 Пенетрантность Alexey Galygin 
иногда трудно обойтись без дополнительной логики,
которую ради такой мелочи отдавать на backend грустно

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

если совсем никак, то можно добавить условно extended if — eif


> On 29 Sep 2020, at 19:47, fox  wrote:
> 
> 1) может, потому что конфиг - это не язык программирования?
> 
> 2) изменение поведения сломает тысячи существующих систем.
> 
> 
> 29.09.2020 23:31, Alexey Galygin пишет:
>> присоединяюсь к вопросу:
>> 
>> почему бы не сделать if нормальным? чтобы без артефактов… и немного мощнее
>> 
>> нам вот тоже приходится делать по несколько map, чтобы логику чуть более 
>> сложную построить…
>> и это ужас
>> 
>>> On 29 Sep 2020, at 19:29, Sergey Kandaurov  wrote:
>>> 
>>> 
>>>> On 29 Sep 2020, at 17:12, Ilya Evseev  wrote:
>>>> 
>>>> Имеется nginx 1.19.2 со следующей настройкой:
>>>> 
>>>>  server {
>>>>  location / {
>>>>  if ($http_user_agent ~ "TestAgent") { }
>>>>  try_files $uri $uri/ /index.html;
>>>>  }
>>>>  }
>>>> 
>>>> Почему попадание в if меняет логику работы последующего try_files?
>>> 
>>> https://wiki.nginx.org/IfIsEvil
>>> 
>>> -- 
>>> Sergey Kandaurov
>>> 
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> 
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> 
> 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Почему пустой if ломает работу try files?

2020-09-29 Пенетрантность Alexey Galygin 
присоединяюсь к вопросу:

почему бы не сделать if нормальным? чтобы без артефактов… и немного мощнее

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

> On 29 Sep 2020, at 19:29, Sergey Kandaurov  wrote:
> 
> 
>> On 29 Sep 2020, at 17:12, Ilya Evseev  wrote:
>> 
>> Имеется nginx 1.19.2 со следующей настройкой:
>> 
>>   server {
>>   location / {
>>   if ($http_user_agent ~ "TestAgent") { }
>>   try_files $uri $uri/ /index.html;
>>   }
>>   }
>> 
>> Почему попадание в if меняет логику работы последующего try_files?
> 
> https://wiki.nginx.org/IfIsEvil
> 
> -- 
> Sergey Kandaurov
> 
> ___
> 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

Re: статический контент и NodeJS Express

2020-09-28 Пенетрантность Alexey Galygin 
Express действительно любит кэшировать состояния (правда это больше касается 
шаблонов — он их компилирует и больше не проверяет, но слышать про файлы такое 
удивительно, возможно используемое раздающее middleware придерживается другой 
политики)

обычная практика в таких случаях:

выделение «датахранилки» — папки, которую через настроенный location раздаёт 
nginx напрямую
с кэшами (заголовки и настройки добавить по вкусу)
https://nginx.org/ru/docs/beginners_guide.html#static 


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

если каким-то файлам требуется авторизация, можно сделать дополнительный 
internal location и с backend после проверки кидать туда (через 
x-accel-redirect — 
https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/)
и nginx опять таки отдаст статику напрямую и быстрее любой backend логики

более того, можно сделать, чтобы правильна работала отдача частичного контента 
(bytes range) и эффективная раздача с диска

всё что не попадает под пути хранилки проксировать на Express

> On 28 Sep 2020, at 20:08, Cyril Zlachevsky  wrote:
> 
> Есть приложение на NodeJS, которое прекрасно работает в
> developer-режиме. В качестве http-сервера используется ExpressJS.
> В production-режиме появляется проблема - http GET запросы возвращают
> 404-ю ошибку для всех новых файлов, загруженных после старта приложения
> в каталог public.
> 
> Пример: если до старта файл public/static/old.jpg существовал, GET
> запрос вернет его с кодом 200.
> Если мы загрузили через nodejs-приложение файл public/static/new.jpg
> GET-запрос будет возвращать ошибку 404. Если перезапустить приложение,
> GET на public/static/new.jpg будет возвращать 200.
> 
> Гугление проблемы привело к пониманию, что это не ошибка, а особенность
> Express-сервера и для production рекомендуется использовать связку
> nginx+express. Как мне настроить работу этой связки, я не вполне
> представляю, поэтому прошу помощи здесь.
> ___
> 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

Re: резолвятся не все имена host-файла

2020-09-10 Пенетрантность Alexey Galygin 
действительно

создал синтетический стенд

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

error_log  /dev/stderr;

events {
use epoll;
}

http {
server {
server_name _;
listen 80;

location /srv_a {
add_header Host ifconfig.co;
proxy_pass http://docker_srv_a;
}

location /srv_b {
add_header Host ifconfig.co;
proxy_pass http://docker_srv_b;
}

location /srv_c {
add_header Host ifconfig.co;
proxy_pass http://docker_srv_c?$args;
}
}
}

> On 10 Sep 2020, at 16:15, Maxim Dounin  wrote:
> 
> Hello!
> 
> On Thu, Sep 10, 2020 at 02:48:22PM +0300, Alexey Galygin wrote:
> 
>> доброго дня
>> 
>> хотелось бы всё таки разобраться с вопросом резолвинга имён
>> 
>> у нас есть докер-контейнер с nginx 1.18.0 с Docker Hub
>> в него мы подкладываем в /etc/hosts файл свои несколько записей (условно):
>> 
>> 10.0.3.4 docker_srv_a
>> 10.0.3.5 docker_srv_b
>> 10.0.3.6 docker_srv_c
>> 
>> никакой разницы нет в дальнейшем использовании docker_srv_[a,b,c] в 
>> nginx.conf, при этом, srv_a и srv_b работают, а srv_c нет
>> 
>> проверяли всё до знаков пунктуации — нет разницы в описании, но имя 
>> docker_srv_c nginx не видит
>> 
>> пересборка, дублирование в родительской машинке в /etc/hosts, перезапуски 
>> nginx — ничего не помогает
>> сам контейнер видит записи (через ping), nginx не видит одну из них — 
>> docker_srv_c
>> 
>> все записи, но в особенности последняя резолвится (ping) в контейнере 
>> (docker exec -it nginx ping docker_srv_c), но последняя не резолвится в nginx
>> 
>> в error log ошибка:
>> 
>> 2020/09/10 13:24:58 [error] 22#22: *40 no resolver defined to resolve 
>> docker_srv_c, client: …, server: …, request: "GET /srv_c/api HTTP/1.1", 
>> host: "…"
> 
> Ошибка "no resolver defined" как бы говорит нам, что у вас 
> конфигурация требует динамического резолвинга адресов (то есть имя 
> используется вместе с переменными в proxy_pass).  При динамичеком 
> резолвинге невозможно использовать системный резолвер, и 
> соответственно не используется файл /etc/hosts.  Вместо этого надо 
> либо использовать IP-адреса непосредственно в конфиге nginx'а, 
> либо поднять DNS-сервер и указать его с помощью директивы 
> resolver.
> 
>> перевод строки ещё один на всякий случай добавлял в конец /etc/hosts — не 
>> помогло
>> 
>> далее, поверх этих имён я просто повесил upstream'ы и, все три записи стали 
>> видны!
>> убираю апстримы, пишу напрямую в proxy_pass http://docker_srv_c 
>> <http://docker_srv_c/> — не может разрешить имя
> 
> Цитата из документации (http://nginx.org/r/proxy_pass/ru 
> <http://nginx.org/r/proxy_pass/ru>):
> 
> : В значении параметра можно использовать переменные. В этом случае, если 
> адрес
> : указан в виде доменного имени, имя ищется среди описанных групп серверов и 
> если
> : не найдено, то определяется с помощью resolver’а.
> 
>> всё же какой-то глюк тут явно есть…
>> что за внутренняя процедура в nginx relover по умолчанию и почему она не 
>> полностью следует hosts-файлу?
>> 
>> почему резолвится только часть имён? да и что за чудеса, чем upstream так 
>> помогает резолвингу?
> 
> По умолчанию resolver не определён, и при динамическом резолвинге 
> будут работать только IP-адреса, имена upstream'ов и имена, 
> используемые в других частях конфига статически (так как для них 
> создаются неявные upstream'ы).
> 
> -- 
> Maxim Dounin
> http://mdounin.ru/ <http://mdounin.ru/>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org <mailto:nginx-ru@nginx.org>
> http://mailman.nginx.org/mailman/listinfo/nginx-ru 
> <http://mailman.nginx.org/mailman/listinfo/nginx-ru>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: резолвятся не все имена host-файла

2020-09-10 Пенетрантность Alexey Galygin 
не, grep'ом с нуля набивал

‘c’ могла бы быть проблемой

но до того как сервис srv_c стал последним, проблемы были с srv_b …
это что-то эфемерное, и от того так неприятно

> On 10 Sep 2020, at 15:01, Evgeniy Berdnikov  wrote:
> 
> On Thu, Sep 10, 2020 at 02:48:22PM +0300, Alexey Galygin wrote:
>> почему резолвится только часть имён? да и что за чудеса, чем upstream так 
>> помогает резолвингу?
> 
> Проверьте на стандартную ошибку: где-то имя написано с символом в кириллице
> (скорее всего в конфиге nginx), а при проверках копи-пастилась откуда-то
> без кириллицы. Обычным грепом легко это выявить, и hd помогает.
> -- 
> Eugene Berdnikov
> ___
> 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

резолвятся не все имена host-файла

2020-09-10 Пенетрантность Alexey Galygin 
доброго дня

хотелось бы всё таки разобраться с вопросом резолвинга имён

у нас есть докер-контейнер с nginx 1.18.0 с Docker Hub
в него мы подкладываем в /etc/hosts файл свои несколько записей (условно):

10.0.3.4 docker_srv_a
10.0.3.5 docker_srv_b
10.0.3.6 docker_srv_c

никакой разницы нет в дальнейшем использовании docker_srv_[a,b,c] в nginx.conf, 
при этом, srv_a и srv_b работают, а srv_c нет

проверяли всё до знаков пунктуации — нет разницы в описании, но имя 
docker_srv_c nginx не видит

пересборка, дублирование в родительской машинке в /etc/hosts, перезапуски nginx 
— ничего не помогает
сам контейнер видит записи (через ping), nginx не видит одну из них — 
docker_srv_c

все записи, но в особенности последняя резолвится (ping) в контейнере (docker 
exec -it nginx ping docker_srv_c), но последняя не резолвится в nginx

в error log ошибка:

2020/09/10 13:24:58 [error] 22#22: *40 no resolver defined to resolve 
docker_srv_c, client: …, server: …, request: "GET /srv_c/api HTTP/1.1", host: 
"…"

перевод строки ещё один на всякий случай добавлял в конец /etc/hosts — не 
помогло

далее, поверх этих имён я просто повесил upstream'ы и, все три записи стали 
видны!
убираю апстримы, пишу напрямую в proxy_pass http://docker_srv_c — не может 
разрешить имя

всё же какой-то глюк тут явно есть…
что за внутренняя процедура в nginx relover по умолчанию и почему она не 
полностью следует hosts-файлу?

почему резолвится только часть имён? да и что за чудеса, чем upstream так 
помогает резолвингу?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

2020-09-01 Пенетрантность Alexey Galygin 
действительно

Dockerfile обновился, но docker оказывается сам его не отслеживает и не 
перекачивает
обновление с той же версией можно обновить — docker pull nginx:1.18.0

и тогда пришёл новый докерфайл/image — иначе всё из кэша бралось
ENV NJS_VERSION 0.4.2

бэст-практика для прода фиксировать версию, а не использовать latest тут не 
сработала:
кто бы мог предположить, что возможны правки в том, чего вроде как и не 
ожидаешь (в Dockerfile привязанном тегом к конкретной версии), что может тихо 
измениться (то что вроде бы должно намертво фиксироваться)

docker history было:

IMAGE   CREATED CREATED BY  
SIZECOMMENT
…
   3 months ago/bin/sh -c #(nop)  ENV 
PKG_RELEASE=1~buster 0B
   3 months ago/bin/sh -c #(nop)  ENV 
NJS_VERSION=0.4.00B
   3 months ago/bin/sh -c #(nop)  ENV 
NGINX_VERSION=1.18.0 0B
   3 months ago/bin/sh -c #(nop)  LABEL 
maintainer=NGINX Do…   0B
   3 months ago/bin/sh -c #(nop)  CMD ["bash"] 
0B
   3 months ago/bin/sh -c #(nop) ADD 
file:7780c81c33e6cc5b6…   69.2MB

стало после docker pull nginx:1.18.0 

IMAGE   CREATED CREATED BY  
SIZECOMMENT
…
   3 months ago/bin/sh -c #(nop)  ENV 
PKG_RELEASE=1~buster 0B
   3 weeks ago /bin/sh -c #(nop)  ENV 
NJS_VERSION=0.4.20B
   3 weeks ago /bin/sh -c #(nop)  ENV 
NGINX_VERSION=1.18.0 0B
   3 weeks ago /bin/sh -c #(nop)  LABEL 
maintainer=NGINX Do…   0B
   4 weeks ago /bin/sh -c #(nop)  CMD ["bash"] 
0B
   4 weeks ago /bin/sh -c #(nop) ADD 
file:3af3091e7d2bb40bc…   69.2MB

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

> On 1 Sep 2020, at 21:07, Alexey Galygin  wrote:
> 
> да, спасибо за внимание и поддержку!
> 
> удивительно, но на старом сервере действительно NJS младше: 0.4.0
> хотя ставятся из одного докерфайла (и сегодня я даже пересобирал контейнер)
> 
> мы также пришли к выводу, что пара переменных точно будет похожа (к тому же 
> править частично — это странная практика)
> в итоге нашлось решение без NJS
> 
> использовать $uri как unescaped-форму
> и вот такую конструкцию для получения исходной формы:
> 
> map $request_uri $escaped_uri {
>   "~^(?P[^?]*)(\?.*)?$" $path;
> }
> 
> в итоге… мы поизучали свои данные и вообще это всё выкинули, оставив $uri — 
> нечего баловать пользователей ;-)
> 
> 
> 
> 
>> On 1 Sep 2020, at 20:51, Dmitry Volyntsev  wrote:
>> 
>> 
>> On 01.09.2020 08:59, Alexey Galygin wrote:
>>> nginx из официального докер образа 1.18.0
>>> njs шла в комплекте и отдельно не ставилась — 0.4.2
>>> вообще никак не вмешивались…
>>> 
>>> за альтернативу кода спасибо!
>>> сейчас думаем, как бы аккуратно выпилить эти артефакты совсем
>>> 
>>> 
>> Спасибо за баг-репорт. Могу подтвердить что проблема в NJS и появилась в 
>> версии 0.4.2 (вероятно обновилась вместе деплоем нового образа?).
>> 
>> Удалось воспроизвести проблему самостоятельно. Она действительно оказалась 
>> связана с регулярными выражениями, а точнее с глобальным реплейсом 
>> replace(/_/g, "%5F"). При определенных условиях код мог уходить в 
>> endless-loop при этом поглощая всю доступную память. Исправленная версия 
>> приедет в 0.4.4.
>> 
>> Уточнее касательно исходных сниппетов:
>> 
>> function unescapeURI(r) { return r.uri.replace(/%20/g, ' '); }
>> 
>> r.uri уже возвращает unescaped версию URI, и replace(/%20/g, ' ') вернет 
>> исходный URI.
>> Как результат $uri $unescaped_uri должны быть идентичными.
>> 
>>>> On 1 Sep 2020, at 07:56, Dmitry Volyntsev  wrote:
>>>> 
>>>> 
>>>> On 01.09.2020 00:42, Alexey Galygin wrote:
>>>>> но на всякий случай, может есть версия как-то это нативно переписать для 
>>>>> конфига без всяких языков и модулей?
>>>>> какие есть рекомендации? (совсем выкидывать всё же стрёмно…)
>>>> А подскажите свою версию njs (Если njs ставился из официальных пакетов, 
>>>> будет доступен бинарник njs, и тогда версию можно узнать так `njs -v`).
>>>> 
>>>>> оказалось проблема в NJS части, какой-то баг там именно в связке 1.18.0 + 
>>>>> Ubuntu 20.04
>>>> менялась ли версия njs при апгрейде? Если нет, единственное что пока 
>>>> приходит на ум это изменения в версии libpcre между дистрибутивами.
>>>> 
>>&

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

2020-09-01 Пенетрантность Alexey Galygin 
да, спасибо за внимание и поддержку!

удивительно, но на старом сервере действительно NJS младше: 0.4.0
хотя ставятся из одного докерфайла (и сегодня я даже пересобирал контейнер)

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

использовать $uri как unescaped-форму
и вот такую конструкцию для получения исходной формы:

map $request_uri $escaped_uri {
   "~^(?P[^?]*)(\?.*)?$" $path;
}

в итоге… мы поизучали свои данные и вообще это всё выкинули, оставив $uri — 
нечего баловать пользователей ;-)




> On 1 Sep 2020, at 20:51, Dmitry Volyntsev  wrote:
> 
> 
> On 01.09.2020 08:59, Alexey Galygin wrote:
>> nginx из официального докер образа 1.18.0
>> njs шла в комплекте и отдельно не ставилась — 0.4.2
>> вообще никак не вмешивались…
>> 
>> за альтернативу кода спасибо!
>> сейчас думаем, как бы аккуратно выпилить эти артефакты совсем
>> 
>> 
> Спасибо за баг-репорт. Могу подтвердить что проблема в NJS и появилась в 
> версии 0.4.2 (вероятно обновилась вместе деплоем нового образа?).
> 
> Удалось воспроизвести проблему самостоятельно. Она действительно оказалась 
> связана с регулярными выражениями, а точнее с глобальным реплейсом 
> replace(/_/g, "%5F"). При определенных условиях код мог уходить в 
> endless-loop при этом поглощая всю доступную память. Исправленная версия 
> приедет в 0.4.4.
> 
> Уточнее касательно исходных сниппетов:
> 
> function unescapeURI(r) { return r.uri.replace(/%20/g, ' '); }
> 
> r.uri уже возвращает unescaped версию URI, и replace(/%20/g, ' ') вернет 
> исходный URI.
> Как результат $uri $unescaped_uri должны быть идентичными.
> 
>>> On 1 Sep 2020, at 07:56, Dmitry Volyntsev  wrote:
>>> 
>>> 
>>> On 01.09.2020 00:42, Alexey Galygin wrote:
>>>> но на всякий случай, может есть версия как-то это нативно переписать для 
>>>> конфига без всяких языков и модулей?
>>>> какие есть рекомендации? (совсем выкидывать всё же стрёмно…)
>>> А подскажите свою версию njs (Если njs ставился из официальных пакетов, 
>>> будет доступен бинарник njs, и тогда версию можно узнать так `njs -v`).
>>> 
>>>> оказалось проблема в NJS части, какой-то баг там именно в связке 1.18.0 + 
>>>> Ubuntu 20.04
>>> менялась ли версия njs при апгрейде? Если нет, единственное что пока 
>>> приходит на ум это изменения в версии libpcre между дистрибутивами.
>>> 
>>> Как воркараунд можно попробовать переписать эти функции без использования 
>>> глобальных регулярок (наиболее вероятное место проблемы).
>>> 
>>> function unescapeURI(r) {
>>> return r.uri.replace(/%20/g, " ");
>>> }
>>> 
>>> ->
>>> 
>>> 1)
>>> // идентична по поведению исходной функции
>>> function unescapeURI(r) {
>>> return r.uri.split(/%20/).join(" ");
>>> }
>>> 
>>> 2)
>>> // более стандартный метод, но заменит все %-encoded комбинации
>>> https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/decodeURI
>>> function unescapeURI(r) {
>>> return decodeURI(r.uri);
>>> }
>>> 
>>> 
>>> function escapeURI(r) {
>>> return r.uri.replace(/\s/g, "%20").replace(/_/g, "%5F");
>>> }
>>> 
>>> ->
>>> 
>>> 1)
>>> // идентична по поведению исходной функции
>>> function escapeURI(r) {
>>> return r.uri.split(" ").join("%20").split("_").join("%5F");
>>> }
>>> 
>>> 2)
>>> // более стандартный метод, но заменит все %-encoded комбинации
>>> https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/encodeURI
>>> function escapeURI(r) {
>>> return encodeURI(r.uri);
>>> }
>>> 

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

2020-09-01 Пенетрантность Alexey Galygin 
nginx из официального докер образа 1.18.0
njs шла в комплекте и отдельно не ставилась — 0.4.2
вообще никак не вмешивались…

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

> On 1 Sep 2020, at 07:56, Dmitry Volyntsev  wrote:
> 
> 
> On 01.09.2020 00:42, Alexey Galygin wrote:
>> 
>> но на всякий случай, может есть версия как-то это нативно переписать для 
>> конфига без всяких языков и модулей?
>> какие есть рекомендации? (совсем выкидывать всё же стрёмно…)
> 
> А подскажите свою версию njs (Если njs ставился из официальных пакетов, будет 
> доступен бинарник njs, и тогда версию можно узнать так `njs -v`).
> 
> > оказалось проблема в NJS части, какой-то баг там именно в связке 1.18.0 + 
> > Ubuntu 20.04
> 
> менялась ли версия njs при апгрейде? Если нет, единственное что пока приходит 
> на ум это изменения в версии libpcre между дистрибутивами.
> 
> Как воркараунд можно попробовать переписать эти функции без использования 
> глобальных регулярок (наиболее вероятное место проблемы).
> 
> function unescapeURI(r) {
> return r.uri.replace(/%20/g, " ");
> }
> 
> ->
> 
> 1)
> // идентична по поведению исходной функции
> function unescapeURI(r) {
> return r.uri.split(/%20/).join(" ");
> }
> 
> 2)
> // более стандартный метод, но заменит все %-encoded комбинации
> https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/decodeURI
> function unescapeURI(r) {
> return decodeURI(r.uri);
> }
> 
> 
> function escapeURI(r) {
> return r.uri.replace(/\s/g, "%20").replace(/_/g, "%5F");
> }
> 
> ->
> 
> 1)
> // идентична по поведению исходной функции
> function escapeURI(r) {
> return r.uri.split(" ").join("%20").split("_").join("%5F");
> }
> 
> 2)
> // более стандартный метод, но заменит все %-encoded комбинации
> https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/encodeURI
> function escapeURI(r) {
> return encodeURI(r.uri);
> }
> 

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

2020-08-31 Пенетрантность Alexey Galygin 
/x86_64-linux-gnu/libc.so.6
#4  0x7ffac2a8ad85 in njs_memalign () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#5  0x7ffac2a7f735 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#6  0x7ffac2a7fa06 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#7  0x7ffac2a42aeb in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#8  0x7ffac2a5520b in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#9  0x7ffac2a555ec in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#10 0x7ffac2a54343 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#11 0x7ffac2a54775 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#12 0x7ffac2a561c2 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#13 0x7ffac2a56440 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#14 0x7ffac2a54343 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#15 0x7ffac2a54775 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#16 0x7ffac2a39b53 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#17 0x7ffac2a54343 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#18 0x7ffac2a329c8 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#19 0x7ffac2a2a218 in ?? () from 
target:/usr/lib/nginx/modules/ngx_http_js_module.so
#20 0x556030cef6a5 in ngx_http_get_indexed_variable ()
#21 0x556030cf0695 in ngx_http_script_copy_var_len_code ()
#22 0x556030cf269d in ngx_http_script_complex_value_code ()
#23 0x556030d26ec5 in ?? ()
#24 0x556030cdefbc in ngx_http_core_rewrite_phase ()
#25 0x556030cdaa3d in ngx_http_core_run_phases ()
#26 0x556030ce5b3f in ?? ()
#27 0x556030ce5f14 in ?? ()
#28 0x556030ccd6ae in ?? ()
#29 0x556030cc3bf6 in ngx_process_events_and_timers ()
#30 0x556030ccb951 in ?? ()
#31 0x556030cc9e7b in ngx_spawn_process ()
#32 0x556030ccb010 in ?? ()
#33 0x556030ccc327 in ngx_master_process_cycle ()
#34 0x556030ca330e in main ()

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

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

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

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

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

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

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

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


> On 31 Aug 2020, at 19:41, Maxim Dounin  wrote:
> 
> Hello!
> 
> On Mon, Aug 31, 2020 at 04:48:36PM +0300, Alexey Galygin wrote:
> 
>> мы запросили у организации, которая занимается DDoS Protection
>> список всех запросов за интервал теста
>> 
>> пытаемся по этим ссылкам ходить скриптом…
>> 
>> на штатный resize пришлось не более 800 запросов за всё время эксперимента, 
>> вряд ли бы это забило всю память
>> (файлики jpg они маленькие, ну допустим текло по 1 Мб на запрос, ну утёк бы 
>> 1 Гб за 5 минут, а не 300…)
>> 
>> ну и точно такой же nginx 1.18.0 на эталонном сервере так не утекает
>> 
>> изменилось в стенде только — Ubuntu — была 16.04 стала 20.04 (тут я 
>> подозреваю, сменился аллокатор памяти, что-то с FS подкрутили, может 
>> дескрипторы если не утекают, то кэш избыточный накапливается в ОЗУ)
>> память — было 192 — стало 256
>> FS как была ext4 так и осталась ext4…
>> ЦОД — было нормальное железо — стала платформа VMWare Cloud Director… на вид 
>> работает даже шустрее
> 
> Это называется "сменилось примерно всё".
> Я бы начал с простого:
> 
> 0. Внимательно изучил конфигурацию.
> 
> Простая оценка максимального потребления памяти рабочим процессом: 
> worker_connections * (сумма всех буферов в конфиге).  Стандартные 
> размеры буферов невелики, и сумму всех можно смело считать как 
> "меньше одного мегабайта", если в конфиге задано что-то иное - 
> соответственно прибавлять.  Относительно большие размерыы буферов 
> встречаются только в image-фильтре (image_filter_buffer 1m) и mp4 
> (mp4_max_buffer_size 10m).
> 
> Нюанс: простая оценка не работает, если используются подзапросы 
> (SSI, cache background update, и так далее - каждый подзапрос 
> может иметь свои буфера, соответственно надо умножать на 
> количество подзапросов в одном соединении) и/или HTTP/2 (умножать 
&g

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

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

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

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

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

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

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

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

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


> On 31 Aug 2020, at 14:38, Alexey Galygin  wrote:
> 
> стандартная сборка из docker hub nginx:1.18.0
> 
> 
> worker_processesauto;
> 
> events {
> worker_connections  4096;
> multi_accept on;
> use epoll;
> }
> worker_rlimit_nofile10240;
> 
> http {
>   client_max_body_size2000m;
> sendfileon;
> tcp_nopush  on;
> tcp_nodelay on;
> server_tokens   off;
> keepalive_timeout   60;
> reset_timedout_connection   on;
> if_modified_since   before;
> 
>   proxy_buffer_size   128k;
> proxy_buffers   24 32k;
> proxy_busy_buffers_size 256k;
> proxy_temp_file_write_size  4m;
> 
>  client_header_buffer_size   8k;
> large_client_header_buffers 8 128k;
> client_body_buffer_size 256K;
> 
>   server_names_hash_max_size  4096;
> server_names_hash_bucket_size   128;
> map_hash_max_size   8500;
> proxy_headers_hash_bucket_size  128;
> 
>gzipon;
> gzip_types  text/plain text/css text/xml application/xml 
> application/x-javascript application/javascript application/json 
> application/rss+xml application/rss application/x-rss+xml;
> gzip_http_version   1.1;
> gzip_min_length 900;
> gzip_comp_level 7;
> gzip_proxiedany;
> gzip_buffers32 8k;
> gzip_disablemsie6;
> 
>   proxy_cache_path/var/lib/nginx/cache  levels=1:2  
> keys_zone=C1:20m inactive=24h max_size=2m;
> proxy_cache_use_stale   updating error timeout invalid_header 
> http_500 http_502 http_503 http_504;
> proxy_cache_background_update on;
> proxy_temp_path /var/run/nginx/proxy;
> proxy_cache_lockon;
> proxy_cache_lock_timeout25s;
> proxy_cache_methods GET HEAD;
> proxy_cache_valid   404 1m;
> 
>   open_file_cache max=1024 inactive=30s;
> open_file_cache_valid   60s;
> open_file_cache_min_uses2;
> open_file_cache_errors  on;
> open_log_file_cache max=100 inactive=30s valid=1m 
> min_uses=2;
> }
> 
> 
> к слову, на новом стенде cache выел всего 300 Мб из 10-20 Гб разрешённых (а 
> на рабочем старом стенде вообще пишется в RAM /var/run — и всё там ок)
> нюанс в том, что эта конфигурация отлично работает на старом сервере рядом, 
> где только Ubuntu более старая
> 
>> On 31 Aug 2020, at 14:19, Илья Шипицин > <mailto:chipits...@gmail.com>> wrote:
>> 
>> Посмотрите, не увеличивается ли у вас число воркеров.
>> 
>> Ещё поможет вывод nginx -V
>> 
>> И поможет конфиг
>> 
>> On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin > <mailto:m...@me.com>> wrote:
>> привет всем
>>  
>> случилось странное, переехали на сервера по параметрам в разы большие, чем 
>> сейчас (с нескромными 256 Гб RAM+ 100 Гб swap (из всех параметров влияния на 
>> штатные параметры sysctl осталось отключение ipv6 и swapness выставленный в 
>> 10%))
>>  
>> через 5 минут после старта nginx ест всю память и весь swap! (см. 
>> https://prnt.sc/u8nia0 <https://prnt.sc/u8nia0>)
>> в итоге сервер умирает, никогда такого не видели, это же кэширующий прокси, 
>> а не БД!…
>>  
>> пускаем на Ubuntu 20.04 Server LTS (5.4.0-42-generic #46-Ubuntu SMP Fri Jul 
>> 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)
>> нагруженный nginx 1.18 (пробова

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

2020-08-31 Пенетрантность Alexey Galygin 
мы запросили у организации, которая занимается DDoS Protection
список всех запросов за интервал теста

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

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

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

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

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

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

2020-08-31 Пенетрантность Alexey Galygin 
что в принципе логично и вряд ли изменится под нагрузкой — там 32 честных ядра
auto выбрал по одному воркеру на ядро

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

> On 31 Aug 2020, at 16:19, Alexey Galygin  wrote:
> 
> сервер сейчас не под нагрузкой
> в ночи проверю
> 
> сейчас 32 воркера
> 
>> On 31 Aug 2020, at 16:07, Илья Шипицин > <mailto:chipits...@gmail.com>> wrote:
>> 
>> Количество воркеров можно посмотреть
>> 
>>  ps auxw | grep nginx | grep worker | wc -l
>> 
>> 
>> Это безопасно
>> 
>> On Mon, Aug 31, 2020, 2:38 PM Alexey Galygin > <mailto:m...@me.com>> wrote:
>> стандартная сборка из docker hub nginx:1.18.0
>> 
>> docker exec nginx nginx -V
>> 
>> TLS SNI support enabled
>> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx 
>> --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf 
>> --error-log-path=/var/log/nginx/error.log 
>> --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid 
>> --lock-path=/var/run/nginx.lock 
>> --http-client-body-temp-path=/var/cache/nginx/client_temp 
>> --http-proxy-temp-path=/var/cache/nginx/proxy_temp 
>> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 
>> --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp 
>> --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx 
>> --with-compat --with-file-aio --with-threads --with-http_addition_module 
>> --with-http_auth_request_module --with-http_dav_module 
>> --with-http_flv_module --with-http_gunzip_module 
>> --with-http_gzip_static_module --with-http_mp4_module 
>> --with-http_random_index_module --with-http_realip_module 
>> --with-http_secure_link_module --with-http_slice_module 
>> --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module 
>> --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream 
>> --with-stream_realip_module --with-stream_ssl_module 
>> --with-stream_ssl_preread_module --with-cc-opt='-g -O2 
>> -fdebug-prefix-map=/data/builder/debuild/nginx-1.18.0/debian/debuild-base/nginx-1.18.0=.
>>  -fstack-protector-strong -Wformat -Werror=format-security 
>> -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now 
>> -Wl,--as-needed -pie’
>> 
>> тестировать можем только по ночам, днём пользователи работают
>> поэтому посмотреть рост воркеров сейчас не представляется возможным + 
>> требуется именно получить нагрузку (пока сервер не трогают там штиль и 
>> спокойствие)
>> 
>> хочу собрать идеи, что крутить ночью
>> 
>> возможно дело и не в количестве воркеров: по скриншоту видно, что всего 5-10 
>> воркеров набрали всю память
>> 
>> конфиг большой, светить бы его прод версию не хотелось
>> 
>> могу точечно надёргать:
>> 
>> worker_processesauto;
>> 
>> events {
>> worker_connections  4096;
>> multi_accept on;
>> use epoll;
>> }
>> worker_rlimit_nofile10240;
>> 
>> http {
>>   client_max_body_size2000m;
>> sendfileon;
>> tcp_nopush  on;
>> tcp_nodelay on;
>> server_tokens   off;
>> keepalive_timeout   60;
>> reset_timedout_connection   on;
>> if_modified_since   before;
>> 
>>   proxy_buffer_size   128k;
>> proxy_buffers   24 32k;
>> proxy_busy_buffers_size 256k;
>> proxy_temp_file_write_size  4m;
>> 
>>  client_header_buffer_size   8k;
>> large_client_header_buffers 8 128k;
>> client_body_buffer_size 256K;
>> 
>>   server_names_hash_max_size  4096;
>> server_names_hash_bucket_size   128;
>> map_hash_max_size   8500;
>> proxy_headers_hash_bucket_size  128;
>> 
>>gzipon;
>> gzip_types  text/plain text/css text/xml application/xml 
>> application/x-javascript application/javascript application/json 
>> application/rss+xml application/rss application/x-rss+xml;
>> gzip_http_version   1.1;
>> gzip_min_length 900;
>> gzip_comp_level 7;
>> gzip_proxiedany;
>> gzip_buffers32

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

2020-08-31 Пенетрантность Alexey Galygin 
сервер сейчас не под нагрузкой
в ночи проверю

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

> On 31 Aug 2020, at 16:07, Илья Шипицин  wrote:
> 
> Количество воркеров можно посмотреть
> 
>  ps auxw | grep nginx | grep worker | wc -l
> 
> 
> Это безопасно
> 
> On Mon, Aug 31, 2020, 2:38 PM Alexey Galygin  <mailto:m...@me.com>> wrote:
> стандартная сборка из docker hub nginx:1.18.0
> 
> docker exec nginx nginx -V
> 
> TLS SNI support enabled
> configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx 
> --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf 
> --error-log-path=/var/log/nginx/error.log 
> --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid 
> --lock-path=/var/run/nginx.lock 
> --http-client-body-temp-path=/var/cache/nginx/client_temp 
> --http-proxy-temp-path=/var/cache/nginx/proxy_temp 
> --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 
> --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp 
> --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx 
> --with-compat --with-file-aio --with-threads --with-http_addition_module 
> --with-http_auth_request_module --with-http_dav_module --with-http_flv_module 
> --with-http_gunzip_module --with-http_gzip_static_module 
> --with-http_mp4_module --with-http_random_index_module 
> --with-http_realip_module --with-http_secure_link_module 
> --with-http_slice_module --with-http_ssl_module 
> --with-http_stub_status_module --with-http_sub_module --with-http_v2_module 
> --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module 
> --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g 
> -O2 
> -fdebug-prefix-map=/data/builder/debuild/nginx-1.18.0/debian/debuild-base/nginx-1.18.0=.
>  -fstack-protector-strong -Wformat -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now 
> -Wl,--as-needed -pie’
> 
> тестировать можем только по ночам, днём пользователи работают
> поэтому посмотреть рост воркеров сейчас не представляется возможным + 
> требуется именно получить нагрузку (пока сервер не трогают там штиль и 
> спокойствие)
> 
> хочу собрать идеи, что крутить ночью
> 
> возможно дело и не в количестве воркеров: по скриншоту видно, что всего 5-10 
> воркеров набрали всю память
> 
> конфиг большой, светить бы его прод версию не хотелось
> 
> могу точечно надёргать:
> 
> worker_processesauto;
> 
> events {
> worker_connections  4096;
> multi_accept on;
> use epoll;
> }
> worker_rlimit_nofile10240;
> 
> http {
>   client_max_body_size2000m;
> sendfileon;
> tcp_nopush  on;
> tcp_nodelay on;
> server_tokens   off;
> keepalive_timeout   60;
> reset_timedout_connection   on;
> if_modified_since   before;
> 
>   proxy_buffer_size   128k;
> proxy_buffers   24 32k;
> proxy_busy_buffers_size 256k;
> proxy_temp_file_write_size  4m;
> 
>  client_header_buffer_size   8k;
> large_client_header_buffers 8 128k;
> client_body_buffer_size 256K;
> 
>   server_names_hash_max_size  4096;
> server_names_hash_bucket_size   128;
> map_hash_max_size   8500;
> proxy_headers_hash_bucket_size  128;
> 
>gzipon;
> gzip_types  text/plain text/css text/xml application/xml 
> application/x-javascript application/javascript application/json 
> application/rss+xml application/rss application/x-rss+xml;
> gzip_http_version   1.1;
> gzip_min_length 900;
> gzip_comp_level 7;
> gzip_proxiedany;
> gzip_buffers32 8k;
> gzip_disablemsie6;
> 
>   proxy_cache_path/var/lib/nginx/cache  levels=1:2  
> keys_zone=C1:20m inactive=24h max_size=2m;
> proxy_cache_use_stale   updating error timeout invalid_header 
> http_500 http_502 http_503 http_504;
> proxy_cache_background_update on;
> proxy_temp_path /var/run/nginx/proxy;
> proxy_cache_lockon;
> proxy_cache_lock_timeout25s;
> proxy_cache_methods GET HEAD;
> proxy_cache_valid   404 1m;
> 
>   open_file_cache max=1024 inactive=30s;
> ope

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

2020-08-31 Пенетрантность Alexey Galygin 
мы за DDoS Protection
к нам ходит один и тот же сервис, пользователи напрямую не ходят

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

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

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

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

2020-08-31 Пенетрантность Alexey Galygin 
стандартная сборка из docker hub nginx:1.18.0

docker exec nginx nginx -V

TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx 
--modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf 
--error-log-path=/var/log/nginx/error.log 
--http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid 
--lock-path=/var/run/nginx.lock 
--http-client-body-temp-path=/var/cache/nginx/client_temp 
--http-proxy-temp-path=/var/cache/nginx/proxy_temp 
--http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp 
--http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp 
--http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx 
--with-compat --with-file-aio --with-threads --with-http_addition_module 
--with-http_auth_request_module --with-http_dav_module --with-http_flv_module 
--with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module 
--with-http_random_index_module --with-http_realip_module 
--with-http_secure_link_module --with-http_slice_module --with-http_ssl_module 
--with-http_stub_status_module --with-http_sub_module --with-http_v2_module 
--with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module 
--with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 
-fdebug-prefix-map=/data/builder/debuild/nginx-1.18.0/debian/debuild-base/nginx-1.18.0=.
 -fstack-protector-strong -Wformat -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now 
-Wl,--as-needed -pie’

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

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

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

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

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

worker_processesauto;

events {
worker_connections  4096;
multi_accept on;
use epoll;
}
worker_rlimit_nofile10240;

http {
  client_max_body_size2000m;
sendfileon;
tcp_nopush  on;
tcp_nodelay on;
server_tokens   off;
keepalive_timeout   60;
reset_timedout_connection   on;
if_modified_since   before;

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

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

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

   gzipon;
gzip_types  text/plain text/css text/xml application/xml 
application/x-javascript application/javascript application/json 
application/rss+xml application/rss application/x-rss+xml;
gzip_http_version   1.1;
gzip_min_length 900;
gzip_comp_level 7;
gzip_proxiedany;
gzip_buffers32 8k;
gzip_disablemsie6;

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

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


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

> On 31 Aug 2020, at 14:19, Илья Шипицин  wrote:
> 
> Посмотрите, не увеличивается ли у вас число воркеров.
> 
> Ещё поможет вывод nginx -V
> 
> И поможет конфиг
> 
> On Mon, Aug 31, 2020, 1:51 PM Alexey Galygin  <mailto:m...@me.com>> wrote:
> привет всем
>  
> случилось странное, переехали на сервера по параметрам в разы большие, чем 
> с

Re: nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

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

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

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

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

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

nginx 1.18.0 ест всю память и swap на Ubuntu Server 20.04.1 LTS

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

Re: nginx + php-fpm = баг?

2020-04-27 Пенетрантность Alexey 

27.04.2020 16:38, grey пишет:

Приветствую всех!

Прежде чем создавать топик, перепроверил всё несколько раз, но объяснения
такого поведения nginx найти не смог.

Суть проблемы: если из php-скрипта со своего сервера я обращаюсь посредством
curl или fopen к своему же сайту, то получаю ошибку "504 Gateway Time-out".
Если выполнить в консоли сервера "php /www/test.ru/1.php", то скрипт вернет
html-страницу сервера. Если открыть в браузере адрес test.ru/1.php, то сайт
будет какое-то время думать, а по прошествию таймаута вернет "504 Gateway
Time-out" (пока сайт будет думать, в лог будут сыпаться ошибки
2020/04/27 15:02:09 [error] 6540#6968: *960636 connect() failed (10061: No
connection could be made because the target machine actively refused it)
while connecting to upstream, client: 5.34.*.*, server: test.ru, request:
"GET / HTTP/2.0", upstream: "fastcgi://127.0.0.1:9123", host: "test.ru",
referrer: "http://***.ru/;). Если в скрипте заменить адрес сервера test.ru
на любой другой внешний, пусть будет ya.ru, то и в консоли и в браузере все
открывает без ошибок. Из чего я делаю вывод, php тут не при чем, затык
именно в nginx. nginx не самой последней версии - 1.17.3 и обновить пока не
могу, php 7.3.х - тоже самая последняя версия.


А почему в нгинксе, а не в php. сделайте запрос за статичным файлом к 
тому же нгинксу, который отдаётся не  через php.


Воркеров php сколько ? точно >1?

/А
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: переменные $1

2020-04-22 Пенетрантность Alexey 

День добрый.

23.04.2020 0:35, Slawa Olhovchenkov пишет:

On Thu, Apr 23, 2020 at 12:03:16AM +0300, Maxim Dounin wrote:


Ну да, одно из возможных решений - отучить регулярные выражения в
map'е трогать $1..$N.  С другой стороны - конфигурации вида

 map $uri $foo {
 ~(.+) $1;
 }

тоже никто не отменял.

не понимаю возражения.
я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
$foo сформировался и никому ничего больше от этого map не требуется.

Тут есть два нюанса:

1. Механизм формирования $1..$N - общий, и если map не трогает
$1..$N - то конструкция выше работать не будет.  А делать так,
чтобы $1..$N использовали результат выполнения конкретного
регулярного выражения, а не просто последнего - логично как раз в
рамках rewrite'а, где это конкретное регулярное выражение
очевидно.  (Ну то есть в рамках map'а следом тоже встанет вопрос,
когда в правой части будет $bar$1, где $bar - ещё один map с
регулярным выражением.  Но это, очевидно, надо будет решать так
же.)

2. Вообще говоря, побочные эффекты от регулярных выражений в map'е
быть должны, те же именованные captures - вполне логично
использовать и много кто использует на практике.  Использовать
побочные эффекты в виде $1..$N - с моей точки зрения странно, но
теоретически и это вполне может быть.

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


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

Patches are welcome.

6 лет...

Да, за 6 лет никто не сподобился даже попытаться прислать патч.
Что как бы позволяет предложить, что - не жмёт.

или никто не может разобраться.

Это не "или", это именно что "не жмёт".  Затраты на попытаться
разобраться - превышают количество проблем, которые создаёт
текущее поведение.

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



А что, кроме лени, мешает не пользоваться $1$2$3 вообще, а использовать

1. поименованные переменные (?...)

$uniqvar

2. везде, где переменные не нужны или не использовать скобки, а если не 
возможно или не удобно, использовать  отказ от создания переменной (?:...) ?


и тогда точно будем знать что


map $... {

  ~^start(?)end$  '1';

}


location /(?.+)/$ {

  rewrite ^(?:.+)$ /$mapvar/$locvar/? break;

приведет к тому, что хочется.


нет ?

/А


___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Проблема с перезапуском в centos 8

2020-02-29 Пенетрантность Alexey 
Запускаем пинг на шлюз, вынимаем провод, пинг, понятно, пропадает, 
вставляем.. сколько проходит до появления пинга ?

Какойнить portfast не включен ?

29.02.2020 6:53, windos321 пишет:

systemctl daemon-reload
делал

на centos 8 управление сетью заменено на network manager, но разве
systemd-networkd-wait-online.service и подобный не относятся к
network-online.target?

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

___
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

Re: Проблема с перезапуском в centos 8

2020-02-28 Пенетрантность Alexey 

cat /etc/systemd/system/multi-user.target.wants/nginx.service

там точно есть
After= ... network-online.target ... nss-lookup.target ...
Wants= network-online.target

?

systemctl daemon-reload
после правки /usr/lib/systemd/system/nginx.service делался ?

точно эта же проблемы была на 7 центоси пускаемой в контейнере, и жалобы 
на чтото типы юбунты тоже были. Проблема в том, что systemd сильна 
асинхронно пускает все сервисы, и нгинкс успевает стартануть до сети, и 
обламывается потому, что до ресловера достутчаться нельзя.. при 
network-online.target и nss-lookup.target ресолв должен работать бы... у 
вас часом адреса не по DHCP ?


если DHCP,  можно затычку вида
https://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.service.html
и зависимость от него...


/А


28.02.2020 16:07, windos321 пишет:

Спасибо! Ну думал теперь точно решена проблема, а нефига...

Вот же зараза, не помогает создание:
Create the file /etc/systemd/system/nginx.service.d/dependency.conf with
After=network-online.target
Requires=network-online.target

И использование этого и множества других юнитов:
http://hg.nginx.org/pkg-oss/file/tip/rpm/SOURCES/nginx.service

Подчеркну - centos 8 - голая, сразу после установки оси ставлю nginx...
На centos 7 такой ошибки нет...

Напомню ошибку:
nginx: [emerg] host not found in upstream "ЛЮБОЙ домен из upstream"
только после ребута, потом нормально стартует

Что делать блин? Варианты сменить OS и веб-сервер не предлагать...

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

___
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

Re: Вечный UPDATING для рандомных страниц портала

2019-06-01 Пенетрантность Alexey Galygin via nginx-ru 
там на самом деле 6 точек
и ни в одной нет проверок

я посмотрел по другим модулям – там хоть как-то проверяют

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

я пока такие правки внёс

~/work/nginx-1.16.0/src/http/modules/perl # diff nginx.xs nginx.xs.bak
75,76d74
< if (!ctx)
< return NGX_ERROR;
384,385d381
< if (!ctx)
< XSRETURN_UNDEF;
554,555d549
< if (!ctx)
< XSRETURN_UNDEF;
797,798d790
< if (!ctx)
< XSRETURN_EMPTY;
929,930d920
< if (!ctx)
< XSRETURN_UNDEF;
1013,1014d1002
< if (!ctx)
< XSRETURN_UNDEF;

я не разработчик nginx и не знаю насколько это корректно

буду наблюдать дальше за падениями
On 1 Jun 2019, 01:19 +0300, Илья Шипицин , wrote:
> а попробуйте вот так
>
> if (ctx && ctx->ssi) {
>
> > сб, 1 июн. 2019 г. в 01:58, Alexey Galygin via nginx-ru 
> > :
> > > понятно, спасибо
> > > подумаем над отдельным инстансом
> > >
> > > на всякий случай я тикет завёл
> > >
> > > https://trac.nginx.org/nginx/ticket/1786#ticket
> > >
> > > в идеале бы, конечно кэш как-то пересчитывать бы надо после падения 
> > > воркеров…
> > > On 31 May 2019, 23:50 +0300, ngnx8810773a83 
> > > , wrote:
> > > > Если воркер отваливается по сигналу, то все что им было залочено в кеше
> > > > остается залоченым навечно (до перезапуска мастера). Мастер запускает 
> > > > нового
> > > > воркера поэтому внешне все продолжает работать,, но если в момент 
> > > > падения
> > > > были залочены элементы кеша то ой.. они залочены. снять лок некому, 
> > > > джругие
> > > > воркеры подождут сняти лока да и дальше пойдут в соотв с настройками... 
> > > > Судя
> > > > по всему такое поведение было всегда. Покрайней мере мы это проходили 
> > > > много
> > > > лет назад. нет падений - нет проблем с кешом. есть падения - надо из 
> > > > лечить
> > > > и тогда уходят проблемы с кешоми.
> > > >
> > > > Перловый модуль вообще падучий, если нет возможности от него отказаться
> > > > совсем, то я бы на вашем месте поппробовал вынести его в отдельный 
> > > > инстанс,
> > > > чтобы падения перлового модуля не отражались на остальном хотябы.. Хотя 
> > > > бы
> > > > даже если не из за падений, а из за того что рерл модуль лочит весь 
> > > > воркер,
> > > > пока перл работает воркер более запросов не обрабатывает (вот где
> > > > остановлись запросы, там и висят, ждут перла)..
> > > >
> > > > Posted at Nginx Forum: 
> > > > https://forum.nginx.org/read.php?21,284370,284386#msg-284386
> > > >
> > > > ___
> > > > nginx-ru mailing list
> > > > nginx-ru@nginx.org
> > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> > > ___
> > > nginx-ru mailing list
> > > nginx-ru@nginx.org
> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вечный UPDATING для рандомных страниц портала

2019-05-31 Пенетрантность Alexey Galygin via nginx-ru 
понятно, спасибо
подумаем над отдельным инстансом

на всякий случай я тикет завёл

https://trac.nginx.org/nginx/ticket/1786#ticket

в идеале бы, конечно кэш как-то пересчитывать бы надо после падения воркеров…
On 31 May 2019, 23:50 +0300, ngnx8810773a83 , 
wrote:
> Если воркер отваливается по сигналу, то все что им было залочено в кеше
> остается залоченым навечно (до перезапуска мастера). Мастер запускает нового
> воркера поэтому внешне все продолжает работать,, но если в момент падения
> были залочены элементы кеша то ой.. они залочены. снять лок некому, джругие
> воркеры подождут сняти лока да и дальше пойдут в соотв с настройками... Судя
> по всему такое поведение было всегда. Покрайней мере мы это проходили много
> лет назад. нет падений - нет проблем с кешом. есть падения - надо из лечить
> и тогда уходят проблемы с кешоми.
>
> Перловый модуль вообще падучий, если нет возможности от него отказаться
> совсем, то я бы на вашем месте поппробовал вынести его в отдельный инстанс,
> чтобы падения перлового модуля не отражались на остальном хотябы.. Хотя бы
> даже если не из за падений, а из за того что рерл модуль лочит весь воркер,
> пока перл работает воркер более запросов не обрабатывает (вот где
> остановлись запросы, там и висят, ждут перла)..
>
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,284370,284386#msg-284386
>
> ___
> 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

Re: Вечный UPDATING для рандомных страниц портала

2019-05-31 Пенетрантность Alexey Galygin via nginx-ru 
с тестами попробовал на (тавтология) тестовой среде
худо бедно шло, в целом даже хорошо, но на одном это всё подвисло…

удалось разобрать корки всё же (доставить символы и правильно всё скормить gdb)

как я и предполагал – падает в наших кастомных Perl модулях на уровне nginx при 
отправке данных файлов:


#0 ngx_http_perl_output (r=r@entry=0x19b9960, b=b@entry=0x19bb520) at 
nginx.xs:76
out = {buf = 0x0, next = 0x19b9960}
cl = 
ctx = 0x0

#1 0x7f8512e2fc91 in XS_nginx_sendfile (my_perl=0xc7b700, cv=) at nginx.xs:751
bytes = 1397297
clcf = 0x13d5378
r = 0x19b9960
filename = 
offset = 0
path = {len = 122, …


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

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


> >
> > если пальцем в небо, можно попробовать в вашей конфигурации прогнать тесты 
> > https://github.com/nginx/nginx-tests, возможно это покажет
> > на какую-то проблему в контейнере
> >
> > (хотя, если честно, самое интересное, это конечно, получить бектрейс)
> >
> >
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Вечный UPDATING для рандомных страниц портала

2019-05-31 Пенетрантность Alexey Galygin via nginx-ru 
пересобрал с -ggdb

NXD1.HK0/mif: ~/work/nginx-1.16.0/objs # ./nginx -V
nginx version: nginx/1.16.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
built with OpenSSL 1.1.1b 26 Feb 2019
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -ggdb -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' 
--with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx 
--sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf 
--http-log-path=/var/log/nginx/access.log 
--error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock 
--pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body 
--http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot 
--with-http_ssl_module --with-http_realip_module --with-http_sub_module 
--with-http_flv_module --with-http_mp4_module --with-http_stub_status_module 
--with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module 
--with-http_image_filter_module --with-http_perl_module 
--without-http_fastcgi_module --without-http_uwsgi_module 
--without-http_scgi_module --without-http_memcached_module 
--with-openssl=../openssl-1.1.1b --with-debug

NXD1.HK0/mif: ~/work/nginx-1.16.0/objs # file nginx
nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked 
(uses shared libs), for GNU/Linux 2.6.32, 
BuildID[sha1]=f8e9db46a969468c67841dec62402c989797d188, not stripped

но про debug ничего действительно

у меня тестовый падающий пример собранный с -g:

int main()
{
int * a = 0x11122;
*a = 42;
}

тоже выдаёт

# file demo
demo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked 
(uses shared libs), for GNU/Linux 2.6.32, 
BuildID[sha1]=a363cfe37d2fd364fb092ff07e8333fc26e2f9a5, not stripped

генерирует корку

(gdb) bt full
#0 0x004004dd in ?? ()
No symbol table info available.
#1 0x in ?? ()
No symbol table info available.

хотя днём удавалось его заставить писать хотя бы main() …

может дело в LXD-контейнере, ядро Ubuntu 16, гость CentOS 7 …
On 31 May 2019, 22:26 +0300, Илья Шипицин , wrote:
> судя по официальному сборщику (и мы похожим образом делали), отладочные 
> символы добавляются через --with-debug
>
> http://hg.nginx.org/pkg-oss/file/tip/rpm/SPECS/nginx.spec.in#l116
>
> придумаю, что у вас - расскажу)) нет идей
>
> > сб, 1 июн. 2019 г. в 00:21, Илья Шипицин :
> > > у программы, собранной с отладочными символами должно быть вот так (with 
> > > debug_info, not stripped)
> > >
> > > [ilia@localhost ~]$ gcc -g 1.c
> > > [ilia@localhost ~]$ file a.out
> > > a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
> > > linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, 
> > > BuildID[sha1]=a767b5ee04499077d7685c5d353759d33184, with debug_info, 
> > > not stripped
> > > [ilia@localhost ~]$
> > >
> > > > сб, 1 июн. 2019 г. в 00:16, Alexey Galygin :
> > > > > на CentOS /sbin – симлинк на /usr/sbin
> > > > > which nginx даёт /sbin/nginx
> > > > >
> > > > > но файл тот же
> > > > >
> > > > > $ file `which nginx`
> > > > > /sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
> > > > > dynamically linked (uses shared libs), for GNU/Linux 2.6.32, 
> > > > > BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
> > > > >
> > > > > а)
> > > > >
> > > > > nginx version: nginx/1.16.0
> > > > > built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
> > > > > built with OpenSSL 1.1.1b 26 Feb 2019
> > > > > TLS SNI support enabled
> > > > > configure arguments: --with-cc-opt='-g -O2 -fstack-protector 
> > > > > --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
> > > > > -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions 
> > > > > -Wl,-z,relro' --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx 
> > > > > --conf-path=/etc/nginx/nginx.conf 
> > > > > --http-log-path=/var/log/nginx/access.log 
> > > > > --error-log-path=/var/log/nginx/error.log 
> > > > > --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid 
> > > > > --http-client-body-temp-path=/var/lib/nginx/body 
> > > > > --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd 
> > > > > --group=robot --with-http_ssl_module --with-http_realip_module 
> > > > > --with-http_sub_module --with-http_flv_module --with-http_mp4_module 
> > > > > --with-http_stub_status_module --with

Re: Вечный UPDATING для рандомных страниц портала

2019-05-31 Пенетрантность Alexey Galygin via nginx-ru 
на CentOS /sbin – симлинк на /usr/sbin
which nginx даёт /sbin/nginx

но файл тот же

$ file `which nginx`
/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically 
linked (uses shared libs), for GNU/Linux 2.6.32, 
BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped

а)

nginx version: nginx/1.16.0
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
built with OpenSSL 1.1.1b 26 Feb 2019
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' 
--with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx 
--sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf 
--http-log-path=/var/log/nginx/access.log 
--error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock 
--pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body 
--http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot 
--with-http_ssl_module --with-http_realip_module --with-http_sub_module 
--with-http_flv_module --with-http_mp4_module --with-http_stub_status_module 
--with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module 
--with-http_image_filter_module --with-http_perl_module 
--without-http_fastcgi_module --without-http_uwsgi_module 
--without-http_scgi_module --without-http_memcached_module 
--with-openssl=../openssl-1.1.1b --with-debug

б)

уже днём так и сделал

в)

make install вполне себе сделал дело
файл тот же

~/work/nginx-1.16.0/objs # sha1sum nginx
29fe68716422bbc1b77f2769e39c3a02f8ce55a7 nginx

~/work/nginx-1.16.0/objs # ls -la nginx
-rwxr-xr-x 1 root root 9169120 май 31 15:15 nginx

~/work/nginx-1.16.0/objs # ls -la /sbin/nginx
-rwxr-xr-x 1 root root 9169120 май 31 15:15 /sbin/nginx

~/work/nginx-1.16.0/objs # sha1sum /sbin/nginx
29fe68716422bbc1b77f2769e39c3a02f8ce55a7 /sbin/nginx

On 31 May 2019, 22:08 +0300, Илья Шипицин , wrote:
> покажите вывод
>
> file `which nginx`
>
> ?
>
> и такой момент. как можно с минимальным риском подменить бинарник
> а) смотрим "nginx -V"
> б) берем исходники, компилируем их с всем, что есть в пункте "a)" и добавляем 
> --with-debug
> в) смотрим на вывод "file objs/nginx", если нам все нравится, то копируем 
> руками этот бинарник вместо nginx, который в путях (ни в коем случае не "make 
> install")
>
> > сб, 1 июн. 2019 г. в 00:01, Alexey Galygin :
> > > получил плоды ожидания корок
> > >
> > > $ file /usr/sbin/nginx
> > > /usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
> > > dynamically linked (uses shared libs), for GNU/Linux 2.6.32, 
> > > BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped
> > >
> > > $ nm -g /usr/sbin/nginx | grep main
> > > U __libc_start_main@@GLIBC_2.2.5
> > > 0045a4c0 T main
> > > 0048fdb0 T ngx_ssl_get_client_v_remain
> > > 005c9cf0 T rand_pool_bytes_remaining
> > >
> > >
> > >
> > > нападало две группы корок (то есть, осыпается сразу аж группами):
> > >
> > > -rw--- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434
> > > … всего порядка 20 штук за раз
> > > -rw--- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635
> > >
> > > и через пол часа:
> > >
> > > -rw--- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426
> > > … ешё 30 штук за раз
> > > -rw--- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302
> > >
> > >
> > > падает стабильно в точке 0x7f8512e2ea1e (и странный предыдущий адрес 
> > > 0x0…0)
> > > но gdb символов в точке падения не видит:
> > >
> > > # gdb core.nginx.11620
> > > GNU gdb (GDB) …
> > > Missing separate debuginfo for the main executable file
> > > Try: yum --enablerepo='*debug*' install 
> > > /usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой 
> > > штуки нет)
> > > Core was generated by `nginx: worker pr'.
> > > Program terminated with signal 11, Segmentation fault.
> > > #0 0x7f8512e2ea1e in ?? ()
> > > "/tmp/core.nginx.11620" is a core file.
> > > Please specify an executable to debug.
> > > (gdb) bt full
> > > #0 0x7f8512e2ea1e in ?? ()
> > > No symbol table info available.
> > > #1 0x in ?? ()
> > > No symbol table info available.
> > > (gdb)
> > >
> > >
> > > куда копать?
> > >
> > > On 31 May 2019, 15:32 +0300, Илья Шипицин , wrote:
> > > > В error_log ничего на с

Re: Вечный UPDATING для рандомных страниц портала

2019-05-31 Пенетрантность Alexey Galygin via nginx-ru 
получил плоды ожидания корок

$ file /usr/sbin/nginx
/usr/sbin/nginx: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, 
BuildID[sha1]=4d0f52094f7acaa1c4b08de27913eb50815bbdfe, not stripped

$ nm -g /usr/sbin/nginx | grep main
U __libc_start_main@@GLIBC_2.2.5
0045a4c0 T main
0048fdb0 T ngx_ssl_get_client_v_remain
005c9cf0 T rand_pool_bytes_remaining



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

-rw--- 1 httpd www-data 105082880 май 31 20:29 core.nginx.8434
… всего порядка 20 штук за раз
-rw--- 1 httpd www-data 64528384 май 31 20:29 core.nginx.11635

и через пол часа:

-rw--- 1 httpd www-data 66285568 май 31 21:11 core.nginx.8426
… ешё 30 штук за раз
-rw--- 1 httpd www-data 64516096 май 31 21:11 core.nginx.12302


падает стабильно в точке 0x7f8512e2ea1e (и странный предыдущий адрес 0x0…0)
но gdb символов в точке падения не видит:

# gdb core.nginx.11620
GNU gdb (GDB) …
Missing separate debuginfo for the main executable file
Try: yum --enablerepo='*debug*' install 
/usr/lib/debug/.build-id/4d/0f52094f7acaa1c4b08de27913eb50815bbdfe (этой штуки 
нет)
Core was generated by `nginx: worker pr'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f8512e2ea1e in ?? ()
"/tmp/core.nginx.11620" is a core file.
Please specify an executable to debug.
(gdb) bt full
#0 0x7f8512e2ea1e in ?? ()
No symbol table info available.
#1 0x in ?? ()
No symbol table info available.
(gdb)


куда копать?

On 31 May 2019, 15:32 +0300, Илья Шипицин , wrote:
> В error_log ничего на сегфолте не может записаться, нет особого смысла его 
> включать в debug
>
> По bt full больше инфы будет
>
> > On Fri, May 31, 2019, 5:26 PM Alexey Galygin  wrote:
> > > Илья, модули все из коробки
> > >
> > > ничего лишнего не доливаем
> > >
> > > из экстрима, пожалуй, только perl-модуль для ряда мелких задачек
> > >
> > > --with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 
> > > -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' 
> > > --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' 
> > > --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx 
> > > --conf-path=/etc/nginx/nginx.conf 
> > > --http-log-path=/var/log/nginx/access.log 
> > > --error-log-path=/var/log/nginx/error.log 
> > > --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid 
> > > --http-client-body-temp-path=/var/lib/nginx/body 
> > > --http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot 
> > > --with-http_ssl_module --with-http_realip_module --with-http_sub_module 
> > > --with-http_flv_module --with-http_mp4_module 
> > > --with-http_stub_status_module --with-file-aio --with-threads 
> > > --with-http_v2_module --with-http_geoip_module 
> > > --with-http_image_filter_module --with-http_perl_module 
> > > --without-http_fastcgi_module --without-http_uwsgi_module 
> > > --without-http_scgi_module --without-http_memcached_module 
> > > --with-openssl=../openssl-1.1.1b --with-debug
> > >
> > > --with-debug ещё добавил только что на время теста… и уровень отладки 
> > > error_log включил debug
> > > но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)
> > >
> > > корки сейчас включу и буду ловить
> > > но это ещё умудриться словить момент и дождаться, когда упадёт, может за 
> > > час несколько раз свалится
> > >
> > >
> > > On 31 May 2019, 14:48 +0300, Илья Шипицин , wrote:
> > > > привет!
> > > >
> > > > segfault - с очень-очень-очень большой вероятностью из-за сторонних 
> > > > модулей nginx.
> > > >  можете показать вывод "nginx -V" ?
> > > >
> > > > как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с 
> > > > отладкой, при это не strip-нуть ее в момент инсталяции
> > > > команда "file `which nginx`" должна показыват "not stripped"
> > > >
> > > > далее - в вашей операционной системе разрешаете сохранение core dump 
> > > > (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
> > > >
> > > > потом, берете сохраненный core dump, при помощи gdb открываете, делаете 
> > > > "bt full", смотрите на чем именно упало.
> > > >
> > > > если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
> > > >
> > > > > пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru 
> > > > > :
> > > > > >

Re: Вечный UPDATING для рандомных страниц портала

2019-05-31 Пенетрантность Alexey Galygin via nginx-ru 
Илья, модули все из коробки

ничего лишнего не доливаем

из экстрима, пожалуй, только perl-модуль для ряда мелких задачек

--with-cc-opt='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2' 
--with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro' --prefix=/usr/share/nginx 
--sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf 
--http-log-path=/var/log/nginx/access.log 
--error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock 
--pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body 
--http-proxy-temp-path=/var/lib/nginx/proxy --user=httpd --group=robot 
--with-http_ssl_module --with-http_realip_module --with-http_sub_module 
--with-http_flv_module --with-http_mp4_module --with-http_stub_status_module 
--with-file-aio --with-threads --with-http_v2_module --with-http_geoip_module 
--with-http_image_filter_module --with-http_perl_module 
--without-http_fastcgi_module --without-http_uwsgi_module 
--without-http_scgi_module --without-http_memcached_module 
--with-openssl=../openssl-1.1.1b --with-debug

--with-debug ещё добавил только что на время теста… и уровень отладки error_log 
включил debug
но у нас за пару минут лог в таком режиме достигает 40 Мб ;-)

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


On 31 May 2019, 14:48 +0300, Илья Шипицин , wrote:
> привет!
>
> segfault - с очень-очень-очень большой вероятностью из-за сторонних модулей 
> nginx.
>  можете показать вывод "nginx -V" ?
>
> как бороться с сегфолтами - весьма просто. надо скомпилировать nginx с 
> отладкой, при это не strip-нуть ее в момент инсталяции
> команда "file `which nginx`" должна показыват "not stripped"
>
> далее - в вашей операционной системе разрешаете сохранение core dump 
> (алгоритм варьируется в зависимости от наличия systemd и еще ряда вещей)
>
> потом, берете сохраненный core dump, при помощи gdb открываете, делаете "bt 
> full", смотрите на чем именно упало.
>
> если что, обращайтесь. тут в рассылке куча людей умеет такое делать ))
>
> > пт, 31 мая 2019 г. в 15:47, Alexey Galygin via nginx-ru 
> > :
> > > всем привет
> > >
> > > ПРОБЛЕМА
> > >
> > > давно (уже не первый год обновление за обновлением nginx и OpenSSL) 
> > > наблюдаем,
> > > что ряд страниц при обновлении кэша входят в вечный статус UPDATING
> > >
> > > см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)
> > >
> > > происходит это совершенно на рандомных страницах, и способа воспроизвести 
> > > нет – только по прецедентной жалобе от пользователей, что закешированный 
> > > контент не обновляется пол дня (ночью у нас рестарт nginx, который 
> > > приводи всё в норму, но ждать до утра никто не хочет)
> > >
> > > КОНФИГУРАЦИЯ
> > >
> > > релевантные настройки такие:
> > >
> > > proxy_cache_use_stale error timeout invalid_header updating http_500 
> > > http_502 http_503 http_504;
> > > proxy_cache_background_update on;
> > > proxy_cache_lock on;
> > > proxy_cache_lock_timeout 25s;
> > >
> > > недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка 
> > > кастомная):
> > >
> > > nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI 
> > > support enabled
> > >
> > > при этом:
> > >
> > > nginx -s reload # не помогает…
> > >
> > > а помогает только явный «мягкий» перезапуск сервера (процедура похожая на 
> > > обновление бинарника):
> > >
> > > #!/usr/bin/env bash
> > > # скрипт перезапуска или обновления бинарника:
> > > sudo kill -s USR2 `cat /run/nginx.pid`
> > > sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
> > > echo 'waiting for 5 minutes required for graceful reload'
> > > sleep 300
> > > sudo kill -s TERM `cat /run/nginx.pid.oldbin`
> > >
> > > ЛОГИ И ДЕМО
> > >
> > > есть предположение, что это из-за эпозодического падения worker'ов (таких 
> > > набирается несколько десятков за день, при сотнях тысяч запросов)
> > >
> > > dmesg:
> > >
> > > [4505268.063116] nginx[22951]: segfault at 48 ip 7f501a38682e sp 
> > > 7fff830e1470 error 4 in nginx.so[7f501a384000+5000]
> > > …
> > >
> > > error.log:
> > >
> > > 2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on 
> > > signal 11 (core dumped)
> > > …
> > >
> > > подобные пад

Вечный UPDATING для рандомных страниц портала

2019-05-31 Пенетрантность Alexey Galygin via nginx-ru 
всем привет

ПРОБЛЕМА

давно (уже не первый год обновление за обновлением nginx и OpenSSL) наблюдаем,
что ряд страниц при обновлении кэша входят в вечный статус UPDATING

см. curl вызовы ниже (ждали, что проблема уйдёт с обновлениями, но нет)

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

КОНФИГУРАЦИЯ

релевантные настройки такие:

proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 
http_503 http_504;
proxy_cache_background_update on;
proxy_cache_lock on;
proxy_cache_lock_timeout 25s;

недавно поставили последнюю стабильную версию nginx + OpenSSL (сборка 
кастомная):

nginx version: nginx/1.16.0 built with OpenSSL 1.1.1b 26 Feb 2019 TLS SNI 
support enabled

при этом:

nginx -s reload # не помогает…

а помогает только явный «мягкий» перезапуск сервера (процедура похожая на 
обновление бинарника):

#!/usr/bin/env bash
# скрипт перезапуска или обновления бинарника:
sudo kill -s USR2 `cat /run/nginx.pid`
sudo kill -s WINCH `cat /run/nginx.pid.oldbin`
echo 'waiting for 5 minutes required for graceful reload'
sleep 300
sudo kill -s TERM `cat /run/nginx.pid.oldbin`

ЛОГИ И ДЕМО

есть предположение, что это из-за эпозодического падения worker'ов (таких 
набирается несколько десятков за день, при сотнях тысяч запросов)

dmesg:

[4505268.063116] nginx[22951]: segfault at 48 ip 7f501a38682e sp 
7fff830e1470 error 4 in nginx.so[7f501a384000+5000]
…

error.log:

2019/05/31 10:35:23 [alert] 15685#15685: worker process 27862 exited on signal 
11 (core dumped)
…

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

наше предположение такое:

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

вот свежий пример (в заголовке x-ireland-cache-status выводим значение 
$upstream_cache_status):

H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:54:52 GMT
…
x-ireland-cache-status: UPDATING

… можно очень долго ждать – статус так и будет UPDATING …

H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:56:47 GMT
…
x-ireland-cache-status: UPDATING

после перезапуска nginx по SIGUSR2 скриптом (код перезапускатора был приведён 
выше):

H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:57:37 GMT
…
x-ireland-cache-status: STALE

H27: ~ $ curl -I https://www.hse.ru/our/
HTTP/2 200
server: nginx
date: Thu, 30 May 2019 14:57:39 GMT
…
x-ireland-cache-status: HIT

всё, кэш успешно обновлён после перезапуска nginx! мы победили и ждём 
следующего звоночка…

у нас нет инструмента по отслеживанию «застрявших UPDATING»,
и нет способа точечно их пнуть
(если только не отслеживать $upstream_cache_status по каждому ресурсу и 
переходы статусов со временем, которые в 99.99% переходят из UPDATING в 
правильные статусы);

приходится ждать только сигнала от недовольных пользователей…

РЕЗЮМИРУЕМ

ещё раз, сценарий, как мы видим откуда растёт проблема:

1. некоторая страница успешно кэшируется
2. в какой-то момент идёт запрос на её обновление, но исполняющий воркер падает 
по SIGSEGV (таких падений несколько десятков за день из сотен тысяч запросов)
3. никакой больше воркер это задание не получает до перезапуска nginx
4. недовольные клиенты получают устаревший контент

РЕШЕНИЕ?

перезапускать nginx раз в 30 минут по cron для её решения не хотелось бы.

какие варианты решения подобной проблемы существуют? в чём может быть возможная 
причина?

может есть рекомендации по дополнительным настройкам?

да, падения могут быть обусловлены нашим кодом, или кастомной сборкой, но их 
(падения воркеров) надо учитывать в работе nginx:

если это рассматривать как баг nginx – можно ли найти ему решение в будущих 
обновлениях, в виде отправки повторной задачи воркерам на обновление кэша, по 
таймауту?..
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Nginx и регулярные выражения

2019-04-08 Пенетрантность Alexey via nginx-ru 

08.04.2019 19:18, Sergey Kandaurov пишет:

On 8 Apr 2019, at 19:03, RuslanValitov  wrote:

Добрый день. Пишу conf файл для своего сайта.
Задача сделать Location который удовлетворяет следующим путям:
site.ru/catalog/
site.ru/catalog/?id=3
site.ru/catalog/1/
site.ru/catalog/1/?id=3
при этом необходимо получить значение $1 если оно есть.

Использую регулярное выражение:
location ~* catalog/(\w+)
--
site.ru/catalog/1/ -работает
site.ru/catalog/1/?id=3 -работает
site.ru/catalog/ - 404
--

Подскажите как изменить регулярное выражение что бы учитывался вариант
(site.ru/catalog/) ?

Используйте квантификатор "?":
location ~* catalog/(\w+)?

https://www.pcre.org/original/doc/html/pcrepattern.html#SEC17

и "?id=3" не часть uri и в проверку  регулярного выражения в location не 
попадает вообще...


и в приведенное выражение Вы поймаете еще и 
/Tratata/My/Super/TheCaTaLog/TheRE/AreMoRe/letters и в $1 будет TheRE


Но, возможно, оно Вам так и нужно., ну или

location ~ "^/catalog/(?:(?\d+)/)?$"

номер после id будет в $catalogid

наличие параметра id можно посмотреть в $arg_id внутри локешна.

Ну так.. :)

/Алексей

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: no live upstreams while connecting to upstream

2019-01-09 Пенетрантность Alexey via nginx-ru 

09.01.2019 0:47, Eugene Toropov пишет:

proxy_http_version 1.1; и proxy_set_header Connection '' помогли, по крайней 
мере 502 больше не вижу. Уточните, пожалуйста, можно ли еще как-то не 
прописывать явно “proxy_set_header Host tratutu” в конфиге, чтоб он правильный 
хост передавал на апстрим вместо tratata?


Ну можно, например,
proxy_set_header Host $host;
тогда дальше поедет тоже имя, что передано клиентом.

Вообще никто не мешает вместо

proxy_pass https://www.domain.ru;

написать

upstream www.domain.ru {
  server www.domain.ru:443 ...;

}
и строку proxy_pass вообще не менять, тогда ничего в плане переданных имен не 
поменяется.

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: no live upstreams while connecting to upstream

2019-01-08 Пенетрантность Alexey via nginx-ru 


09.01.2019 0:08, Eugene Toropov пишет:
С max_fails=0 получил ошибку "SSL_do_handshake() failed (SSL: 
error:1408F10B:SSL routines:ssl3_get_record:wrong version number) 
while SSL handshaking to upstream” (апстрим на httpS) - буду 
разбираться с SSL.



Это ошибка сразу же ? порт надо явно указать в upstream tra { server 
x.x.x.x:443 ...} и в проксипас уже proxy_pass https://tra ; секция 
upstream не в курсе откуда её будут звать и по умолчанию там :80, если 
её позвать потом https то будет как Вы написали.



апстрим умеет http/1.1 и он включен со стороны нгинкса (со сбросом 
proxy_set_header Connection '') ?
если нет, то новое ssl соединение устанавливается на каждое соединение с 
апстримом. Это дорого. если апстрим умеет http/1.1 и кипалайв, то ОЧЕНЬ 
рекомендуется их включить. (если конечно есть достаточно веские 
аргументы для вообще использования https для связи между nginx и 
апстримом. SSL дорог и хандшейк медленен, на новых процах и правильно 
собранном openssl несколько быстрее, но всеравно чертовски медленнен..., 
но кипалайв всеравно снизит нагрузку, даже без ssl, опять же количество 
соединений с 1 портом ограничено, и учитывая что по умолчапнию реюз 
запрещен, то порт остается занятым много дольше, чем он используется) Да 
и всякие лимиты nfile.


/Алексей
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: no live upstreams while connecting to upstream

2019-01-08 Пенетрантность Alexey via nginx-ru 

08.01.2019 23:50, Eugene Toropov пишет:

Зачем мне upstream, если я использую proxy_pass:

 location / {
 proxy_pass  xx;
 }
?


да, сорри, во второй случае должно было быть proxy_pass

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



On 8 Jan 2019, at 23:48, Alexey via nginx-ru  wrote:

08.01.2019 23:40, Eugene Toropov пишет:

Я не совсем понял, при чем здесь параметр max_fails - его на странице proxy 
модуля нет нигде - http://nginx.org/en/docs/http/ngx_http_proxy_module.html - я 
что-то пропустил?


ustream tratata {

server tratutu:80  max_fails=XXX;

}


server {

  location / {

   proxy_pass http://tratata;

...

}

}


если Вы явно не указали upstream, то это не значит что там нет никаких 
умолчаний... укажите явно, впишите туда max_fails=0

___
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

Re: no live upstreams while connecting to upstream

2019-01-08 Пенетрантность Alexey via nginx-ru 

08.01.2019 21:01, Eugene Toropov пишет:

Добрый вечер,

Тогда получается ситуация, при которой часть запросов файрвол пропускает, а 
часть режет. При чем ночью до 9 утра не режет ничего, а вечером почти все. Как 
nginx определяет, что апстрим живой? Любой статус, отличный от 200?




посмотрите описание proxy_next_upstream


Директива также определяет, что считается неудачной попыткой работы с 
сервером. Случаи error, timeout и invalid_header всегда считаются 
неудачными попытками, даже если они не указаны в директиве. Случаи 
http_500, http_502, http_503, http_504 и http_429 считаются неудачными 
попытками, только если они указаны в директиве. Случаи http_403 и 
http_404 никогда не считаются неудачными попытками.


и директиву server из секции описания upstream

max_fails=число
    задаёт число неудачных попыток работы с сервером, которые должны 
произойти в течение времени, заданного параметром fail_timeout, чтобы 
сервер считался недоступным на период времени, также заданный параметром 
fail_timeout. По умолчанию число попыток устанавливается равным 1. 
Нулевое значение отключает учёт попыток. Что считается неудачной 
попыткой, определяется  директивами proxy_next_upstream, 
fastcgi_next_upstream, uwsgi_next_upstream,scgi_next_upstream, 
memcached_next_upstream и grpc_next_upstream.



если апстрим реально один, то укажите ему max_fails=0

А вообще смотрите запросы рядом с первым 502. там скорее всего гдето 
случились таймауты, единственный апстрим отметился как фейл и на время 
fail_timeout(10с по умолчанию) выпадает из работы.


/Алексей

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy_store периодически сохраняет только часть ответа :(

2018-12-02 Пенетрантность Alexey via nginx-ru 

02.12.2018 23:18, Виктор Вислобоков пишет:

Схема такая: nginx(1) -> nginx(2) -> httpd
На nginx(1) пытаюсь сделать кастомный статик кэш через proxy_store. 
Почти работает, но в произвольный момент времени сохраняет на диск не 
всю страницу с ответом, а только её часть! Это именно происходит 
периодически и не зависит ни от IP адреса ни от клиента (тот же Zabbix 
у меня то получает фрагмент и ругается на малый размер страницы, то в 
следующий повтор всё получает нормально - стоит чистка файлов, 
сохранённых proxy_store каждую минуту).


А чем proxy_cache не устраивает ? прокси стор, это больше для "на века", 
а Вы трете его зачемто постоянно


У Вас proxy_temp_path и место куда сторится на одном разделе ? Если на 
разных, то, скорее всего, пока файл от одного запроса копируется, 
успевает прийти другой запрос и видя файл на месте его и отдает, ну 
сколько успело скопироваться на момент второго запроса столько и отдает.


___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: OCSP stapling in Nginx >=1.3.7

2018-09-19 Пенетрантность Alexey 

20.09.2018 1:53, Gena Makhomed пишет:


Эта проблема была исправлена еще в 2015 году:
https://trac.nginx.org/nginx/ticket/425#comment:4

Все конечно может быть :), и возможно оно и было исправлено, но..., тем 
не менее оно стрельнуло на 1.14... :/ на веб серверах жестко зарублены 
исходящие соединения. Для OCSP были дырки до сетей СА.  В один 
непрекрасный день CA сменил IP и как раз довольно скоро протухли OCSP в 
кеше ... но как выяснилось очень мало какие браузеры на это реагируют 
(может быть было бы хуже, если бы было Must Staple, но его там нет)



/Алексей

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: OCSP stapling in Nginx >=1.3.7

2018-09-18 Пенетрантность Alexey 

День добрый

18.09.2018 20:03, Maxim Dounin пишет:

Hello!

Проблема для начала в том, что в OpenSSL нет возможности подождать
получения OCSP-ответа, не блокируя рабочий процесс nginx'а.

Смотрели мы на реализацию получение  OCSP ответов нгинксом, во первых 
если у нас много воркеров, то в каждом воркере кеш свой и в каждом из 
воркеров после включения, или перегрузки конфигурации кеш, естественно, 
слетает. и  при достаточно большом трафике на https все воркеры сразу 
набрасываются на процедуру получения OCSP. Както малопродуктивно, 
учитывая что сам по себе ответ от ЦА меняется не часто. Первый (сколько 
то первых) ответ от воркера почти всегда в итоге улетает без OCSP.  В 
итоге в систему выкатки конфигурации было привнесено средство получения 
готовых ocsp файлов (через openssl ocsp) для каждого используемого 
сертификата и раскладывание их по серверам по мере появления изменений. 
В таком виде процесс получения контролируем, ЦА получает 1 запрос в, 
условно, сутки, а не по куче от всех воркеров с каждого сервера 
одновременно. Ответы можно перепроверить. И даже первый ответ от нгинкса 
с готовым файлом улетает с OCSP всегда. Ошибки получения, если такие 
случаются ловятся в одном месте, а не по куче еррор логов по всем 
серверам. Опять же единичные ошибки ни к чему страшному не приводят, 
всегда есть день-другой запаса по сроку действия прошлого ответа, а если 
конфигурацию у нгинкса перегрузили, то весь кеш сразу и слетел.


флаг Must Staple мы не используем,  но если кто то планирует, то 
отдавать на откуп получение ответов НГИНКСу, наверное совсем не стоит.


зы, кстати если у нгинкса проблемы с получением OCSP от ЦА, но в кеше 
чтото еще есть с прошлых разов, то, кажется, он отдает последний 
закешированный ответ и после окончания его действия, что хуже, чем его 
вообще не отдавать. некоторые браузеры таки начинают ругаться. (понятно, 
что если получать файл внешним скриптом, то это тоже надо бы 
обрабатывать и както реагировать. но тут свой скрипт, делай что хочешь. 
Можно просто выкинуть из конфига соотв команду, если нет достаточно 
свежего файла.)


/Алексей
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Доли секунд в логах

2018-01-18 Пенетрантность Alexey Remizov 
On 18.01.2018 13:03, Alexey Remizov wrote:
> On 18.01.2018 12:54, Иван Мишин wrote:
> 
>> я логи обрабатываю с помощью logstash и складываю в elastic, а затем
>> просматриваю их с помощью kibana.
>> Мне важно получить в кибане юзерфрендли временную метку с миллисекундами
> 
> Берите $msec и в logstash прогоняйте через фильтр date с форматом UNIX_MS

Ошибся, не UNIX_MS, а просто UNIX.

-- 
С уважением.   WBR.
Алексей.   Alexey.

mailto:ale...@remizov.org
jabber:remi...@jabber.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Доли секунд в логах

2018-01-18 Пенетрантность Alexey Remizov 
On 18.01.2018 12:54, Иван Мишин wrote:

> я логи обрабатываю с помощью logstash и складываю в elastic, а затем
> просматриваю их с помощью kibana.
> Мне важно получить в кибане юзерфрендли временную метку с миллисекундами

Берите $msec и в logstash прогоняйте через фильтр date с форматом UNIX_MS

https://www.elastic.co/guide/en/logstash/current/plugins-filters-date.html#plugins-filters-date-match


-- 
С уважением.   WBR.
Алексей.   Alexey.

mailto:ale...@remizov.org
jabber:remi...@jabber.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

1.12.2 под debian wheezy

2017-12-11 Пенетрантность Alexey Remizov 
Здравствуйте.

Сейчас последняя сборка под wheezy - 1.12.1.

1.12.2 забыли собрать или stable под wheezy больше официально не
поддерживается?

-- 
С уважением.   WBR.
Алексей.   Alexey.

mailto:ale...@remizov.org
jabber:remi...@jabber.ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Проблемы при написании модуля-замены TLS для NGINX (NoiseSocket)

2017-11-23 Пенетрантность Alexey Ermishkin 
Приветствую, меня зовут Алексей. Я работаю в компании VirgilSecurity и
являюсь разработчиком протокола NoiseSocket (noisesocket.com).
Так же наша компания занимается разработкой модуля для NGINX, реализующего
протокол NoiseSocket.
Я хотел бы описать цели, результаты и узнать мнение о решениях и спросить
совета о других путях решения задачи.
Протокол NoiseSocket позиционируется как более простая в реализации и
быстрая альтернатива TLS. Одной  из его главных фич является возможность
установки безопасного соединения без использования сертификатов, используя
лишь "сырые" приватные\публичные ключи. Это необходимо для IoT, бекендов,
p2p и многих других задач.
Основной целью создания модуля для NGINX - это обеспечение функциональности
reverse proxy и load balancing, где соединение между прокси-сервером и
backend серверами осуществляется по протоколу NoiseSocket. Второй целью
является возможность принимать входящие соединения по протоколу NoiseSocket,
то есть обеспечивать поддержку протокола на стороне backend с помощью NGINX.
Для обеспечения нужного функционала модуль должен обеспечить:
1 При создании соединения на стороне noise client инициировать и отработать
handshake phase по алгоритму noise initiator.
2 При входящем соединении на стороне noise server ответить на входящие
handshake сообщения и отработать handshake phase по алгоритму noise .
3 После успешного завершения handshake phase упаковывать/распаковывать
сетевой траффик в NoiseSocket transport messages.
Сначала была рассмотрена возможность создания модуля для контекста http,
однако здесь траффик для сторонних модулей предоставляется в виде
составляющих http, что не дает возможности для работы протокола, имеющего
более низкий уровень, чем http.
Затем был рассмотрен вариант для контекста stream. Однако предоставляемый
функционал для сторонних модулей здесь оказался весьма ограничен. Здесь для
работы протокола уровня представления есть возможность только на стороне
noise server, когда появляется входящее соединение и можно прицепить модуль
к одной из фаз обработки входящего запроса. На стороне noise client такой
возможности нет, потому что здесь имеется функционал только для custom load
balancing. Мы можем добавить свой обработчик:
 ngx_stream_session_t->peer.get(ngx_peer_connection_t *pc,void *data);
Однако его вызов осуществляется до создания соединения:
В файле  ngx_event_connect.c:
ngx_int_t ngx_event_connect_peer(ngx_peer_connection_t *pc)
{
:.
rc = pc->get(pc, pc->data);
:.
c = ngx_get_connection(s, pc->log);
:
}
Таким образом нет никакой возможности инициировать процедуру handshake и
назначить свои обработчики recv, send, recv_chain, send_chain для обработки
траффика средствами стороннего модуля.
В итоге было принято решение создать модуль, реализующий собственный
контекст по обработке траффика. За основу был взят код контекста stream, где
был убран TLS, и добавлен NoiseSocket. 
Для обработки траффика только по протоколу NoiseSocket приемлема следующая
конфигурация, которая наиболее оптимальна по быстродействию:

 https://i.imgur.com/fucb9J0.png

В итоге для сохранения существующего функционала NGINX по обработке http
контента определена следующая конфигурация:

https://i.imgur.com/6vnOdwd.png

или
https://i.imgur.com/WpMhdKh.png

Так как подобная конфигурация не оптимальна в плане быстродействия, то
хотелось бы узнать о более перспективных вариантах внедрения протокола
уровня представления для NGINX в качестве модуля.
Рабочий вариант спецификации для NoiseSocket:
http://noisesocket.com/spec/noisesocket/
 Репозиторий с кодом модуля
https://github.com/VirgilSecurity/virgil-NGINX-noise-socket
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Nginx не отвечает на запросы

2016-10-11 Пенетрантность Alexey Kuznetsov 

Добрый день!

Наша часть проблемы решилась, вчера закоммитили изменения в 11 и 10 
ветки. У меня полет нормальный.

Судя по СВНу в 11 релиз оно не вошло.

/Алексей

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Nginx не отвечает на запросы

2016-09-28 Пенетрантность Alexey Kuznetsov 



На трекере freebsd опубликовали патч. Посмотрите у себя, если есть 
возможность. Патч на 10=ку, возможно надо будет доработать напильником 
по месту для 11-й. Там в общем if добавляется. у меня 11-х нет и 
собирать стенд еще и на 11-ю ветку сейчас совсем нет возможности.


у меня работает с патчем.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212920

/Алексей

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Nginx не отвечает на запросы

2016-09-27 Пенетрантность Alexey Kuznetsov 

24.09.2016 11:41, Mikanoshi пишет:

Alexey Kuznetsov Wrote:
---

Помогает или откат кернела на старую версию (достаточно самого
ядра и модулей) ИЛИ выключение "accf_http" (и модуль не загружен и в
конфиге соотв выключено, отключать только в конфиге не пробовал).

Опция reset_timedout_connection включена? Если включить accf_http и
отключить её, то будет как у меня?
https://forum.nginx.org/read.php?21,269501,269715#msg-269715


Добрый день!

Да reset_timedout_connection включена, да ее выключение проблему 
снимает. Я локализовал ревизию в которой "сломалось", для 10-STABLE это 
r302995. Судя по всему на 11 это r261242 (но 11 у меня нет, соотв я не 
пробовал).
Я надеюсь Julien и Глеб смогут найти, что там так повлияло в тех 4-х 
измененных строках для 10, надеюсь оно будет починено и для 11 ветки.


/Алексей

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Re: Nginx не отвечает на запросы

2016-09-23 Пенетрантность Alexey Kuznetsov 

Добрый день!

Фиксируем подобную же проблему. FreeBSD 10.3 STABLE. В версии от конца 
мая все работало,  в версии собранной в конце августа уже нет, пробовал 
пересобрать вчера (обновив из svn), результат не меняется.. Бектрейс 
такой же. Помогает или откат кернела на старую версию (достаточно самого 
ядра и модулей) ИЛИ выключение "accf_http" (и модуль не загружен и в 
конфиге соотв выключено, отключать только в конфиге не пробовал). Без 
accf_http работает на любом из 3-х ядер на котором тестировалось. под 
небольшой нагрузкой не проявляется и с accf_http (есть где это работает 
с конца августа, но там от силы 1000 запросов в сутки). accf_datа не 
используется, соотв. и не загружен.


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212920

нгинс из ports с дефолными настройками. Кернел - генерик.

/Алексей

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

nginx monitoring with sparrow

2015-11-29 Пенетрантность Alexey Melezhik 
Всем привет!

Sparrow - система мониторинга различных web приложений.
Sparrow использует плагины написаные на perl.

http://blogs.perl.org/users/melezhik/2015/11/easy-nginx-monitoring-with-sparrow.html
- описание как с помощью sparrow мониторить nginx

Regards. Автор sparrow.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Не запускается PhpMyAdmin

2015-08-10 Пенетрантность Alexey Malov 
Попробуйте проанализировать core-dump'ы php-fpm.
Как анализировать написано тут по русски, но про апач:
http://habrahabr.ru/company/bitrix/blog/153001/

А тут - по-английски, но про php-fpm:
https://rtcamp.com/tutorials/php/core-dump-php5-fpm/

10 августа 2015 г., 8:48 пользователь Maksim Kulik kulm...@gmail.com
написал:

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

 2015-08-10 11:50 GMT+03:00 termit-200 nginx-fo...@nginx.us:

 В логе php-fpm сообщения вот такого вида:

 [10-Aug-2015 11:42:05] WARNING: [pool www] child 1627 exited on signal 11
 (SIGSEGV) after 0.944585 seconds from start
 [10-Aug-2015 11:42:05] NOTICE: [pool www] child 1629 started
 [10-Aug-2015 11:42:05] WARNING: [pool www] child 1628 exited on signal 11
 (SIGSEGV) after 1.275092 seconds from start
 [10-Aug-2015 11:42:05] NOTICE: [pool www] child 1631 started
 [10-Aug-2015 11:42:05] WARNING: [pool www] child 1629 exited on signal 11
 (SIGSEGV) after 0.484413 seconds from start
 [10-Aug-2015 11:42:05] NOTICE: [pool www] child 1632 started

 Posted at Nginx Forum:
 http://forum.nginx.org/read.php?21,260893,260896#msg-260896

 ___
 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




-- 
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx без причины перестал запускаться

2015-07-29 Пенетрантность Alexey Malov 
29 июля 2015 г., 14:56 пользователь tfox nginx-fo...@nginx.us написал:

 Всем привет.

 Вот такая ситуация.

 root@maxserver:/# sudo service nginx start
 root@maxserver:/# sudo service nginx stop
 root@maxserver:/# sudo service nginx restart
  * Restarting nginx nginx [fail]
 root@maxserver:/#

 Получается говоришь nginx старт он молчит. Говоришь стоп он тоже молчит.
 Говоришь рестарт он отвечает fail



 root@maxserver:/# sudo service nginx status
  * nginx is not running
 root@maxserver:/# grep -h '[n]ginx' (ps aux) (service --status-all 21)
 www-data 11700  0.0  0.3 3465836 31896 ?   SJul28   0:14 nginx:
 worker process
 www-data 11701  0.0  0.4 3465836 32364 ?   SJul28   0:13 nginx:
 worker process
 www-data 11702  0.0  0.3 3465836 31940 ?   SJul28   0:14 nginx:
 worker process
 www-data 11703  0.0  0.3 3465836 31916 ?   SJul28   0:15 nginx:
 worker process
 www-data 11704  0.0  0.3 3465836 25504 ?   SJul28   0:00 nginx:
 cache manager process
  [ - ]  nginx
 root@maxserver:/#

 Насколько я понимаю.
 Первая команда сообщает, что nginx не запущен. Но сайты при этом работают.
 Вторая команда сообщает, что какие то процессы nginx работают.

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


Попробуйте:
sudo killall -9 nginx
sudo service nginx start




 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Маршрутизация запросов

2015-07-29 Пенетрантность Alexey Malov 
29 июля 2015 г., 0:43 пользователь Budulianin nginx-fo...@nginx.us
написал:

 Но hash же не гарантирует равномерного распределения запросов по бэкендам,
 он как раз гарантирует, что запросы с одинаковым id будут идти на одну и
 ту
 же ноду.

 А где-то описывается алгоритм работы hash?


Вообще вот тут вот:-)
http://hg.nginx.org/nginx/file/341e4303d25b/src/http/modules/ngx_http_upstream_hash_module.c


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


Можно в debug-логах посмотреть, какой хеш получается у какого клиента и у
какого id, и посмотреть на какую ноду он уходит.


 Я конечно проверю, но ещё хотелось бы что-то в документации прочитать по
 этому поводу.

 Posted at Nginx Forum:
 http://forum.nginx.org/read.php?21,260591,260602#msg-260602

 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Добавление заголовка после upstream

2015-07-29 Пенетрантность Alexey Malov 
29 июля 2015 г., 0:34 пользователь Budulianin nginx-fo...@nginx.us
написал:

 В ответ клиенту добавить?
 Добавить в запрос, который перенаправится какой-то ноде, после того, как
 она
 будет выбрана в upstream.
 Т.е. upstream уже выбран, мы его только теперь знаем(адрес ноды) и тогда мы
 добавляем его в header и он отправляется в ноду.

 Если ставить proxy_set_header рядом с proxy_pass, то заголовок не
 добавляется, я так понимаю, что переменная ещё пустая, поэтому
 заголовок не ставится. Но где уже известна эта переменная? Только в блоке
 upstream? Но там нельзя устанавливать заголовок.


Она известна уже после получения конечного ответа от бэкендов.
А разве ноды бэкенда сами свои адреса не знают? Зачем им этот заголовок
посылать?



 map $http_upgrade $connection_upgrade {
 default upgrade;
 '' close;
 }

 upstream tornado {
 hash $arg_key;

 server 127.0.0.1:9995;
 server 127.0.0.1:9996;
 server 127.0.0.1:9997;
 server 127.0.0.1:9998;
 server 127.0.0.1:;

 }


 server {
 listen 8080 default_server;

 access_log /var/log/nginx/prototypes-nginx-access.log;
 error_log /var/log/nginx/prototypes-nginx-error.log;

 location /ws/ {
 proxy_pass http://tornado;
 proxy_set_header Test-Header1 123;
 proxy_set_header Test-Header2 $upstream_addr;
 proxy_set_header Test-Header3 $host;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 }

 }

 Posted at Nginx Forum:
 http://forum.nginx.org/read.php?21,260596,260601#msg-260601

 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Добавление заголовка после upstream

2015-07-28 Пенетрантность Alexey Malov 
28 июля 2015 г., 17:39 пользователь Budulianin nginx-fo...@nginx.us
написал:

 Можно ли как-то добавить заголовок c адресом, куда был отправлен запрос
 директивой upstream?


В ответ клиенту добавить?



 В upstream нельзя использовать add_header.


В upstream и не надо, надо там, где проксируете:

proxy_pass http://upstream_name;
add_header $upstream_addr;


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

 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Маршрутизация запросов

2015-07-28 Пенетрантность Alexey Malov 
2015-07-28 15:15 GMT-05:00 Budulianin nginx-fo...@nginx.us:

 Да, надо было вставить.


 map $http_upgrade $connection_upgrade {
 default upgrade;
 '' close;
 }

 upstream tornado {
 hash $arg_key;

 server 127.0.0.1:9995;
 server 127.0.0.1:9996;
 server 127.0.0.1:9997;
 server 127.0.0.1:9998;
 server 127.0.0.1:;
 }

 server {
 listen 8080 default_server;

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

 location /ws/ {
 proxy_pass http://tornado;
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection $connection_upgrade;
 }

 }


Вроде вы всё делаете правильно..
Но hash же не гарантирует равномерного распределения запросов по бэкендам,
он как раз гарантирует, что запросы с одинаковым id будут идти на одну и ту
же ноду. Попробуйте протестировать с большим разнообразием id, штук 20,
например. Тогда должны, скорее всего, все ноды задействоваться.

Если включите debug-лог, то там можно будет увидеть, какой hash у каждого
клиента посчитан будет, может, с ними нагляднее будет.




 Posted at Nginx Forum:
 http://forum.nginx.org/read.php?21,260591,260595#msg-260595

 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Кастомная сборка NGINX под Debian 7

2015-07-28 Пенетрантность Alexey Malov 
27 июля 2015 г., 17:40 пользователь Michael Kechinov s...@mkechinov.ru
написал:

 Возникла проблема на другом сервере.

 Собрал по инструкции, при обращении к бинарнику выпадает с такой ошибкой:

 # /etc/init.d/nginx start
 Invalid version format (non-numeric data) at
 /usr/lib/perl/5.14/DynaLoader.pm line 207.
 Compilation failed in require.
 BEGIN failed--compilation aborted.
 nginx: [alert] perl_parse() failed: 2

 Что может быть не так?


Баг в debian?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672356




 On Thu, Jul 16, 2015 at 11:41 AM, Michael Kechinov s...@mkechinov.ru
 wrote:

 Свершилось, благодарю.



 2015-07-15 13:29 GMT+03:00 Aleksandr Sytar sytar.a...@gmail.com:


 15 июля 2015 г., 10:10 пользователь Michael Kechinov s...@mkechinov.ru
 написал:

 Unable to locate package nignx


  ^^

 Опечатка - nginx

 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru




 --
 *Michael Kechinov http://linkedin.com/in/mkechinov* | s...@mkechinov.ru |
 +7 950 0099233
 Startups development studio: mkechinov.ru | en http://mkechinov.com
 Personalization for e-commerce: rees46.com
 HackDay: hackday.ru
 Twitter-wall: twijector.com




 --
 *Michael Kechinov http://linkedin.com/in/mkechinov* | s...@mkechinov.ru |
 +7 950 0099233
 Startups development studio: mkechinov.ru | en http://mkechinov.com
 Personalization for e-commerce: rees46.com
 HackDay: hackday.ru
 Twitter-wall: twijector.com

 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Маршрутизация запросов

2015-07-28 Пенетрантность Alexey Malov 
28 июля 2015 г., 13:42 пользователь Budulianin nginx-fo...@nginx.us
написал:

 Всем привет.

 Есть задача: каждого определённого пользователя всегда отправлять на
 определённую ноду.
 Пытаюсь решить её с помощью балансировки, через директиву upstream + hash.

 Задаю каждому пользователю уникальный id, передаю его в запросе
 и потом nginx делает из него hash и в соответствии с ним отправляет запрос
 на определённую ноду.
 Но не все запросы равномерно распределяются по нодам.
 Например: у меня 5 нод, отправляю 4 запроса с одним id, они приходят на 1
 ноду,
 отправляю следующие 4 запроса c новым id, они приходят на 2 ноду,
 отправляю следующие 4 запроса c новым id, они приходят на 3 ноду,
 повторяю те же действия с новыми id, но на ноду 4 и 5 ничего не приходит,
 запросы распределяются между 1, 2 и 3.

 Подскажите пожалуйста:
 Как происходит выбор ноды, когда upstream + hash?


А конфиг покажите, пожалуйста?



 Как решают подобные задачи? Может вообще по другому?
 Если nginx вычислил hash от id и отправил на ноду n, то он всегда будет
 отправлять с тем же id на ноду n?(если список нод не менялся)

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

 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru




-- 
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: nginx забивает все место в корневом разделе linux

2015-07-21 Пенетрантность Alexey Malov 
13 июля 2015 г., 9:11 пользователь Иван Мишин simplebo...@gmail.com
написал:

 это же тема прям из учебника...

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


sudo lsof | grep nginx

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



 13 июля 2015 г., 17:06 пользователь Daniel Podolsky onoko...@gmail.com
 написал:

  Помогите понять куда и чего пишет nginx в корневом разделе.
 это же тема прям из учебника...

 nginx пишет свой кеш. например - при заборе с бекенда больших файлов,
 или при приеме больших файлов от клиентов.

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

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

 если вам очень надо знать имена этих файлов - возьмите в руки программу
 lsof.
 ___
 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




-- 
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Высокий IO на серверах с nginx

2015-07-11 Пенетрантность Alexey Malov 
;
proxy_cache exe_cache;
proxy_cache_valid 200 48h;
proxy_ignore_headers Set-Cookie;
add_header Cache-Control public;
expires 36h;
}
location ~ ^/_(a|b|c|d|e|f|m|x|i|h)\.jsp$ {
proxy_pass http://127.0.0.1:5885/banners/ba/_$1.jsp$is_args$args;
proxy_cache_key
$http_host$scheme$proxy_host$uri$is_args$arg_tc$arg_t$arg_callback;
proxy_cache exe_cache;
proxy_cache_valid 200 8h;
proxy_ignore_headers Set-Cookie;
expires 8h;
deny all;
}
location /api/v1/stabucket {
proxy_pass
http://127.0.0.1:5885/adsnetto_backend/api/v1/stabucket$is_args$args;
proxy_cache_key
$http_host$scheme$proxy_host$uri$is_args$arg_tc$arg_t$arg_callback$arg_r;
proxy_cache exe_cache;
proxy_cache_valid 200 8h;
proxy_ignore_headers Set-Cookie;
expires 8h;
}
location /_.jsp {
proxy_pass http://127.0.0.1:5885/banners/ba/_.jsp;
proxy_cache_key
$http_host$scheme$proxy_host$uri$is_args$arg_tc$arg_t$arg_callback;
proxy_cache exe_cache;
proxy_cache_valid 200 12h;
proxy_ignore_headers Set-Cookie;
expires 12h;
}
location /tag_test.jsp {
proxy_pass http://127.0.0.1:5885/banners/ba/tag_test.jsp;
expires 36h;
}
location /clk.action {
proxy_pass http://search.utop.it;
proxy_set_header Host search.utop.it;
}
location /exe {
proxy_pass http://127.0.0.1:5885/banners/exe;
proxy_cache exe_cache;
proxy_cache_valid 200 24h;
}
location /ini.jsp {
proxy_pass http://127.0.0.1:5885/banners/loca/ini.jsp;
proxy_cache exe_cache;
proxy_cache_valid 4h;
expires 12h;
}
location /img/px.png {
alias /tomcat/webapps/banners##1.3/img/px.png;
userid on;
userid_nameuid;
userid_domain example.com; HttpOnly;
userid_expires max;
expires epoch;
}
access_log /var/log/nginx/example.com_access.log ub_cloudflare
buffer=10m flush=1m;
error_log /var/log/nginx/example.com_error.log error;
}

nginx -V:
# nginx -V
nginx version: nginx/1.6.2
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx
--conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log
--http-log-path=/var/log/nginx/access.log
--http-client-body-temp-path=/var/lib/nginx/tmp/client_body
--http-proxy-temp-path=/var/lib/nginx/tmp/proxy
--http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi
--http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi
--http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/nginx.pid
--lock-path=/var/lock/subsys/nginx --user=nginx --group=nginx
--with-file-aio --with-ipv6 --with-http_ssl_module
--with-http_realip_module --with-http_addition_module
--with-http_xslt_module --with-http_image_filter_module
--with-http_geoip_module --with-http_sub_module --with-http_dav_module
--with-http_flv_module --with-http_mp4_module
--with-http_gzip_static_module --with-http_random_index_module
--with-http_secure_link_module --with-http_degradation_module
--with-http_stub_status_module --with-debug --with-cc-opt='-O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic'

В sysctl подкручивали:
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.core.netdev_max_backlog = 65536
net.ipv4.tcp_max_syn_backlog = 262144
net.core.somaxconn = 262144
net.core.rmem_max = 8388608
net.core.wmem_max = 8388608
net.core.rmem_default = 65536
net.core.wmem_default = 65536
net.ipv4.tcp_rmem = 8192 873800 8388608
net.ipv4.tcp_wmem = 4096 655360 8388608
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries=2

Картина в netstat:
# netstat -ant | grep tcp | tr -s ' ' ' ' | awk '{print $6}' | sort | uniq
-c
  8 CLOSE_WAIT
  32970 ESTABLISHED
 22 FIN_WAIT1
  3 LAST_ACK
 17 LISTEN
 23 SYN_RECV
  27976 TIME_WAIT

-- 
Alexey Malov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Высокий IO на серверах с nginx

2015-07-11 Пенетрантность Alexey Malov 
11 июля 2015 г., 17:09 пользователь Alexey Malov scukon...@gmail.com
написал:

 Добрый день,
 Второй день наблюдаю проблему с высоким IO на серверах с nginx при не
 очень большой нагрузке.
 Схема такая - 11 серверов с nginx и tomcat. Nginx на каждому сервере
 принимает трафик от CloudFlare CDN, большую часть отдаёт из кеша, остальное
 балансирует на томкаты (и ещё один статический файлик отдаёт сам).
 Всё было замечательно до вчера, трафик в пике был до 40 мегабайтов в
 секунду, 40к параллельных соединений и ~1500 запросов в секунду на каждом
 из серверов.
 Вчера же трафик подскочил раза в полтора (сбрасывали кеш на CloudFlare и
 сами запросы тоже поменялись), резко выроз IO на сервере (раньше его вообще
 практически не было, а стало около 15-20%) и всё начало тупить.
 Изначально думали на диск, но отключение логов практически никак не
 повлияло.
 В dmesg стали вылезать сообщения про synflood, увеличили бэклоги как в
 nginx, так и в sysctl, сообщения про synflood пропали, но проблема с IO
 осталась.

 Немного помогло отключение лоад-балансинга в nginx, теперь каждый nginx
 проксирует на локальный томкат. Нагрузка на сеть понизилась, IO понизилось,
 но всё равно осталось.

 Трафик с тех пор понизился даже ниже, чем был до проблемы, сейчас около
 1100 запросов в секунду. Но IO осталось. Nginx даже иногда по нескольку
 секунд отвечает на запросы к странице stub_status.
 Пробовали разделять сервера с tomcat и nginx, IO оставалось на стороне
 nginx.

 Был бы очень признателен, если бы кто-нибудь подсказал хотя бы куда
 копать. Потому что уже вроде как чем только не пробовали. Спасибо заранее!

 Конфиги следующие:
 nginx.conf:
 user  nginx;
 worker_processes  8;
 worker_rlimit_nofile 512000;
 worker_rlimit_core  500M;

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

 pid/var/run/nginx.pid;

 events {
 worker_connections  256000;
 }

 http {
 include   /etc/nginx/mime.types;
 default_type  application/octet-stream;

 ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
 log_format  main  '$remote_addr - $remote_user [$time_local]
 $request '
   '$status $body_bytes_sent $http_referer '
   '$http_user_agent $http_x_forwarded_for';
 log_format upstream_balancing   '$remote_addr - $remote_user
 [$time_local] '
 '$request $status $bytes_sent '
 '$http_referer $http_user_agent '
 '$upstream_addr $upstream_response_time
 $geoip_country_code/$http_cf_ipcountry $http_host
 $upstream_cache_status '
 '$http_cf_connecting_ip';
 log_format ub_cloudflare   '$http_cf_connecting_ip - $remote_user
 [$time_local] '
 '$request $status $bytes_sent '
 '$http_referer $http_user_agent '
 '$upstream_addr $upstream_response_time
 $geoip_country_code/$http_cf_ipcountry $http_host
 $upstream_cache_status '
 '$remote_addr $cookie___cfduid $cookie_uid';
 access_log  /var/log/nginx/access.log  main;

 sendfileon;

 keepalive_timeout  65;

 proxy_cache_methods GET;

 include /etc/nginx/conf.d/*.conf;
 include /etc/nginx/sites-enabled/*;

 }

 virtual host:
 server {
 listen   1.1.1.1:80;
 listen   1.1.1.1:443 ssl;
 ssl_certificate /etc/nginx/ssl/cert.crt;
 ssl_certificate_key /etc/nginx/ssl/key.key;
 server_name  example.com;
 proxy_set_header clientCountryCode $http_cf_ipcountry ;
 proxy_ignore_headers Set-Cookie;
 proxy_hide_header Set-Cookie;
 proxy_next_upstream error timeout http_500;

 location / {
 deny all;
 }
 location /manager {
 proxy_pass http://127.0.0.1:5885;
 }
 location /crossdomain.xml {
 root /tomcat/static_xml;
 expires 31d;
 }
 location ~ ^(/display.htm)$ {
 proxy_pass http://127.0.0.1:5885/banners/$1$is_args$args;
 proxy_cache exe_cache;
 proxy_cache_valid 2h;

 expires 24h;
 }
 location ~ ^(/secure.jsp)$ {
 proxy_pass http://127.0.0.1:5885/banners/mojo/$1$is_args$args;
 proxy_cache exe_cache;
 proxy_cache_valid 2h;
 expires 12h;

 }
 location ~ ^(/hela.jsp)$ {
 proxy_pass http://127.0.0.1:5885/banners/hela$1$is_args$args;
 proxy_cache exe_cache;
 proxy_cache_valid 2h;
 expires 12h;

 }
 location ~ ^(/hela.exe)$ {
 proxy_pass http://127.0.0.1:5885/banners/hela$1$is_args$args;
 proxy_cache exe_cache;
 proxy_cache_valid 24h;

 }
 location /wl/ba.jsp {
 proxy_pass http://127.0.0.1:5885/banners/wl/ba.jsp;
 #proxy_cache_key proxy_cache_key;
 proxy_cache exe_cache;
 proxy_cache_valid 200 48h;
 expires 1w;
 }
 location /wl/po.jsp {
 proxy_pass http://127.0.0.1:5885/banners/wl/po.jsp;
 proxy_cache exe_cache;
 proxy_cache_valid 200 48h;
 expires 1w;
 }
 location

Re: Высокий IO на серверах с nginx

2015-07-11 Пенетрантность Alexey Malov 
Как выяснилось, IO было дисковое, перенос cache в RAM всё излечил. Странно
только, почему раньше работало. Сейчас вариантов URL стало даже меньше. И
трафик опустился.

11 июля 2015 г., 17:57 пользователь Alexey Malov scukon...@gmail.com
написал:



 11 июля 2015 г., 17:09 пользователь Alexey Malov scukon...@gmail.com
 написал:

 Добрый день,
 Второй день наблюдаю проблему с высоким IO на серверах с nginx при не
 очень большой нагрузке.
 Схема такая - 11 серверов с nginx и tomcat. Nginx на каждому сервере
 принимает трафик от CloudFlare CDN, большую часть отдаёт из кеша, остальное
 балансирует на томкаты (и ещё один статический файлик отдаёт сам).
 Всё было замечательно до вчера, трафик в пике был до 40 мегабайтов в
 секунду, 40к параллельных соединений и ~1500 запросов в секунду на каждом
 из серверов.
 Вчера же трафик подскочил раза в полтора (сбрасывали кеш на CloudFlare и
 сами запросы тоже поменялись), резко выроз IO на сервере (раньше его вообще
 практически не было, а стало около 15-20%) и всё начало тупить.
 Изначально думали на диск, но отключение логов практически никак не
 повлияло.
 В dmesg стали вылезать сообщения про synflood, увеличили бэклоги как в
 nginx, так и в sysctl, сообщения про synflood пропали, но проблема с IO
 осталась.

 Немного помогло отключение лоад-балансинга в nginx, теперь каждый nginx
 проксирует на локальный томкат. Нагрузка на сеть понизилась, IO понизилось,
 но всё равно осталось.

 Трафик с тех пор понизился даже ниже, чем был до проблемы, сейчас около
 1100 запросов в секунду. Но IO осталось. Nginx даже иногда по нескольку
 секунд отвечает на запросы к странице stub_status.
 Пробовали разделять сервера с tomcat и nginx, IO оставалось на стороне
 nginx.

 Был бы очень признателен, если бы кто-нибудь подсказал хотя бы куда
 копать. Потому что уже вроде как чем только не пробовали. Спасибо заранее!

 Конфиги следующие:
 nginx.conf:
 user  nginx;
 worker_processes  8;
 worker_rlimit_nofile 512000;
 worker_rlimit_core  500M;

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

 pid/var/run/nginx.pid;

 events {
 worker_connections  256000;
 }

 http {
 include   /etc/nginx/mime.types;
 default_type  application/octet-stream;

 ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
 log_format  main  '$remote_addr - $remote_user [$time_local]
 $request '
   '$status $body_bytes_sent $http_referer '
   '$http_user_agent $http_x_forwarded_for';
 log_format upstream_balancing   '$remote_addr - $remote_user
 [$time_local] '
 '$request $status $bytes_sent '
 '$http_referer $http_user_agent '
 '$upstream_addr $upstream_response_time
 $geoip_country_code/$http_cf_ipcountry $http_host
 $upstream_cache_status '
 '$http_cf_connecting_ip';
 log_format ub_cloudflare   '$http_cf_connecting_ip - $remote_user
 [$time_local] '
 '$request $status $bytes_sent '
 '$http_referer $http_user_agent '
 '$upstream_addr $upstream_response_time
 $geoip_country_code/$http_cf_ipcountry $http_host
 $upstream_cache_status '
 '$remote_addr $cookie___cfduid $cookie_uid';
 access_log  /var/log/nginx/access.log  main;

 sendfileon;

 keepalive_timeout  65;

 proxy_cache_methods GET;

 include /etc/nginx/conf.d/*.conf;
 include /etc/nginx/sites-enabled/*;

 }

 virtual host:
 server {
 listen   1.1.1.1:80;
 listen   1.1.1.1:443 ssl;
 ssl_certificate /etc/nginx/ssl/cert.crt;
 ssl_certificate_key /etc/nginx/ssl/key.key;
 server_name  example.com;
 proxy_set_header clientCountryCode $http_cf_ipcountry ;
 proxy_ignore_headers Set-Cookie;
 proxy_hide_header Set-Cookie;
 proxy_next_upstream error timeout http_500;

 location / {
 deny all;
 }
 location /manager {
 proxy_pass http://127.0.0.1:5885;
 }
 location /crossdomain.xml {
 root /tomcat/static_xml;
 expires 31d;
 }
 location ~ ^(/display.htm)$ {
 proxy_pass http://127.0.0.1:5885/banners/$1$is_args$args;
 proxy_cache exe_cache;
 proxy_cache_valid 2h;

 expires 24h;
 }
 location ~ ^(/secure.jsp)$ {
 proxy_pass http://127.0.0.1:5885/banners/mojo/$1$is_args$args;
 proxy_cache exe_cache;
 proxy_cache_valid 2h;
 expires 12h;

 }
 location ~ ^(/hela.jsp)$ {
 proxy_pass http://127.0.0.1:5885/banners/hela$1$is_args$args;
 proxy_cache exe_cache;
 proxy_cache_valid 2h;
 expires 12h;

 }
 location ~ ^(/hela.exe)$ {
 proxy_pass http://127.0.0.1:5885/banners/hela$1$is_args$args;
 proxy_cache exe_cache;
 proxy_cache_valid 24h;

 }
 location /wl/ba.jsp {
 proxy_pass http://127.0.0.1:5885/banners/wl/ba.jsp;
 #proxy_cache_key proxy_cache_key;
 proxy_cache exe_cache

Re: [SPAM]Re: Досрочное закрытие соединения по заголовкам браузера

2013-11-03 Пенетрантность Alexey V. Karagodov 
тут случаем не про PHP-FPM спрашивают? 

On 03 нояб. 2013 г., at 0:40, Sergey Smitienko hun...@comsys.com.ua wrote:

 Используйте http://pear.php.net/package/System_Daemon
 
 On 11/2/2013 10:02 PM, Romano wrote:
 В PHP под управлением Apache можно досрочно закрыть соединение, а затем
 продолжить выполнение скрипта в фоновом режиме, освободив при этом браузер
 пользователя:
 http://stackoverflow.com/questions/4806637/continue-processing-after-closing-connection.
 
 
 ___
 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

Re: Nginx reverse proxy и WebDav

2013-09-18 Пенетрантность Alexey V. Karagodov 
кто то ж делал доп-модуль к штатному дав-у nginx-а 
загуглите, там были реализованы недостающие методы 
 ! НО ! 
как то было сыровато и с мак-ами не очень дружило 

On 18.09.2013, at 11:30, usows us...@pomorsu.ru wrote:

 К сожалению, просто не получится. Бэкенд работает только по https
 
 Alex Domoradov писал 18.09.2013 10:53:
 Ну чтобы точно понять дело в SSL или где то еще, попробуй подключить
 просто по http
 
 2013/9/18 usows us...@pomorsu.ru:
 
 Здравствуйте
 
 Maxim Dounin писал 17.09.2013 20:08:
 
 Андрей, dav-модуль dav-модулем, а проксирование WebDav'а - это
 совершенно отдельная тема.  Должно работать.  Основная проблема,
 которая там обычно возникает - это заголовок Destination при
 всяких копированиях/перемещениях, если таковые используются.  Но
 это уже детали.
 
 Другой вопрос, что по престал работать WebDav многого не
 надиагностируешь, а единственный телепат в нашей компании как раз
 в отпуске.  ;)
 
 
 
 Я очень извиняюсь за неполное описание проблемы
 
 Подключение нормально работает в клиентах типа cadaver, список файлов
 нормально открывается в браузере (в т.ч. IE). Попытка подключить ресурс как
 сетевой диск (net use * https://server.example.ru/dav /USER:user password)
 выкидывает ошибку Системная ошибка 1244. Запрошенная операция не была
 выполнена, так как пользователь не зарегистрирован.
 Еще раз подчеркиваю, то же самое подключение на том же компьютере с той же
 учеткой в браузере открывается нормально
 
 В логах nginx ничего нет. То есть, при попытке подключить сетевой диск в
 логах просто ничего не появляется
 
 Мне кажется, проблема где-то в настройках SSL
 
 
 ___
 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
 
 -- 
 Ведущий программист отдела СА УИТ САФУ
 Усов С.А.
 
 s.u...@agtu.ru
 
 (8182)21-61-00p1797
 
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Nginx номинирован на премию Сделано в России на Snob.ru

2013-08-23 Пенетрантность Alexey V. Karagodov 
думаю я не единственный, кто проголосовал за 
по сравнению с NGINX, потуги автоТАЗа просто комичны и даже приступны 


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

в том же Рамблере накапало уже наверно не на одну статую Игоря из золота 
а так, спасибы, голоса ну иногда баг-репорты - вся благодарность 


On 23.08.2013, at 13:51, Anatoly Mikhailov anat...@sonru.com wrote:

 
 On Aug 23, 2013, at 9:38 AM, Den Bozhok undyin...@yandex.ru wrote:
 
 Не вижу ничего сложного что бы поддержать ребят, учитывая их труд.
 Хотя глядя на голоса, Nginx и так впереди :)
 
 23.08.2013, 08:41, Михаил Монашёв postmas...@softsearch.ru:
 Здравствуйте, Валентин.
 
 Раздел  Предпринимательство  выбирается вверху страницы, сразу под
 картинкой, а голосовалка находится внизу.
 
 Предпринимательство? Вебсервер - да, удачный продукт. А насколько вы
 успешны  в  бизнесе - хрен знает. С таким же успехом можно и в разделе
 Музыка участвовать. :-)
 
 Сомневаюсь, что успешный бизнесмен будет с таким негативом относиться
 к одному из самых успешных IT-продуктов и команде, которая его создала.
 Игорь, Максим, Валентин, вы большие молодцы, пошел за вас голосовать!
 
 
 --
 С уважением,
 Михаил  mailto:postmas...@softsearch.ru
 
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru
 
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru
 
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: WSUS без перенастройки клиентов

2013-07-17 Пенетрантность Alexey V. Karagodov 

On 17.07.2013, at 11:32, Dmitry Ivanov nginx...@sadok.spb.ru wrote:

 Здравствуйте, is_as.
 
 Вы писали 17 июля 2013 г., 9:30:02:
 
 Специалистов нет в школах, со своей стороны сервера мы поддержкой обеспечим,
 для этого весь трафик и централизовали. Отключать обновление совсем тоже
 неправильно, это-то мы всегда можем сделать.
 
 offtopic
 
 не проще ли разослать по очкам cmd-шник, который пропишет один раз
 настройки и самоудалится? результат, конечно, не 100%-ый, но over 50%
 точно.

1. есть групповая политика 
2. есть МОРЕ мануала, по запуску локального ВСУС-сервера, как официального, 
громоздкого, дорого и пр и пр, так и на всяких там апачах 

обычно, и чтоб точно работало, надо выполнить оба пункта 
если вы хотите реализовать что-то вроде ДНС-спуффинга (иногда оно работает, 
конечно же, к примеру с провиженингом IP-телефонов), то тут ни кто не мешает 
экспериментировать, удачи … 


 
 
 -- 
 С уважением,
 Dmitry  mailto:nginx...@sadok.spb.ru
 
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Достаточно ли качественнен nginx-auth-ldap?

2013-07-16 Пенетрантность Alexey V. Karagodov 

On 16.07.2013, at 12:46, Daniel Podolsky onoko...@gmail.com wrote:

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

 ___
 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

Re: про якобы уязвимость

2013-04-29 Пенетрантность Bondar Alexey 
Это про вот это? http://www.securityfocus.com/archive/1/526439/30/0/threaded

On 29 Apr 2013, at 14:32, Maxim Dounin mdou...@mdounin.ru wrote:

 Hello!
 
 Недавно в сети появилось сообщение о якобы имеющейся в nginx'е
 уязвимости, и утверждающее возможность удалённого выполнения
 произвольного кода.  Мы таки тщательно изучили вопрос, и не
 подтверждаем наличия указанной уязвимости.
 
 Пользуясь случаем, хочу напомнить, что если вы считаете, что нашли
 уязвимость в nginx, - хорошей идеей будет сообщить подробности по
 адресу security-al...@nginx.org, как указано на странице nginx
 security advisories тут:
 
 http://nginx.org/en/security_advisories.html
 
 -- 
 Maxim Dounin
 http://nginx.org/en/donation.html
 
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru



smime.p7s
Description: S/MIME cryptographic signature
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Регексповый server_name

2013-03-07 Пенетрантность Bondar Alexey 
server {
   listen 80;
   server_name ~^(?project.+)\.(?user.+)\.example\.net$;

   root /var/www/$user/$project/public;
}

Как следствие 

project1.user1.example.net = /var/www/user1/project1/public

Или я не понял вопроса?

On 7 Mar 2013, at 17:12, Юрий Гончаров n...@miritec.com wrote:

 Здравствуйте
 
 есть инфраструктура
 
 /lab/user1/project1
 /lab/user1/project2
 /lab/user1/project3
 /lab/user1/project4
 /lab/user2/someproject1
 /lab/user2/someproject2 
 
 и т д
 
 Есть ли возможность в nginx для каждого user1 создавать один умный 
 server_name и root для работы...что-то типа
 
server {
 listen 80;
 server_name  $project.user1.lab.domain.com;
 location /
  {
   root /lab/user1/$project;
   }
 }
 
 
 Или все же писать скрипты которые будут генерить конфиги?
 
 Спасибо!
 
 --
 NEO83-RIPE
 
 
 ___
 nginx-ru mailing list
 nginx-ru@nginx.org
 http://mailman.nginx.org/mailman/listinfo/nginx-ru



smime.p7s
Description: S/MIME cryptographic signature
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru