Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-26 Пенетрантность Илья Шипицин 
зачем огромные ?

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

26 мая 2016 г., 21:12 пользователь S.A.N 
написал:

> Илья Шипицин Wrote:
> ---
> > а вы настройте keepalive между nginx и бекендами.
>
> Да, этим и спасаемся, у нас огромные значения keepalive в upstream :)
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,266693,267180#msg-267180
>
> ___
> 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

когда лучше использовать multi_accept on

2016-05-26 Пенетрантность VovansystemS 
Добрый вечер,

подскажите пожалуйста, в каких случаях нужно включать multi_accept on
и как именно он работает?

документацию читал http://nginx.org/r/multi_accept/ru
из того, что мне удалось нагуглить, ничто не проясняет ситуацию для меня:

http://mailman.nginx.org/pipermail/nginx-ru/2009-October/028973.html :
При "multi_accept on" nginx пытается accept()нуть все соединения при
получении сообщения о новых соединениях

http://mailman.nginx.org/pipermail/nginx-ru/2015-May/056041.html :
С multi_accept не пересекается никак - в зависимости от workload'а
и желаемых результатов может иметь или не иметь смысл включать
multi_accept.  Проблема всё та же: multi_accept позволяет принять
сразу несколько соединений за одну итерацию event loop'а, но ценой
одного лишнего вызова accept().  Есть небольшой положительный
эффект - при использовании reuseport из-за multi_accept'а не будут
возникать перекосы в распределении соединений между рабочими
процессами при microbenchmark'ах.

http://mailman.nginx.org/pipermail/nginx-ru/2014-June/054012.html :
По умолчанию nginx старается работать так, чтобы "пробуждалось"
минимальное количество рабочих процессов - это позволяет экономить
затраты на переключение контекстов и "лишние" пробуждения
процессов.  При реальной работе - в результате используется
столько процессов, сколько на самом деле нужно для обработки той
нагрузки, которая есть.
Если хочется получить более ровное распределение в тестах - то
имеет смысл:
- accept_mutex выключить;
- multi_accept, если вдруг включён, выключить;
- убедиться, что тесты не используют постоянные соединения и/или
  количество устанавливаемых соединений так или иначе велико.

Я не понимаю что мы выигрываем от принятия сразу нескольких
соединений за одну итерацию event loop'а.

Валентин, может быть Вы сможете проиллюстрировать ситуацию со
включенным и отключенным multi_accept на примере с бомжами и мусорными
баками?
https://habrahabr.ru/post/188114/#comment_6549442
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Короткое имя hostname

2016-05-26 Пенетрантность wavedocs 
Есть нужда передавать в хидере типа X-Aloha передавать хостней сервера, но
без site.ru.
Какие есть варианты кроме regex, map и lua?

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

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

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-26 Пенетрантность S.A.N 
Илья Шипицин Wrote:
---
> а вы настройте keepalive между nginx и бекендами.

Да, этим и спасаемся, у нас огромные значения keepalive в upstream :)

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

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

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-26 Пенетрантность Илья Шипицин 
а вы настройте keepalive между nginx и бекендами.

26 мая 2016 г., 16:28 пользователь S.A.N 
написал:

> >  Конечно, мультиплексирование в FastCGI будет легче чем в HTTP/2.
> >
> >  Но само по себе мультиплексирование не является самоцелью, оно может
> >  быть уместно в каких-то вычурных ситуациях (вроде исчерпания
> > сокетов),
> >  которые на самом деле разруливаются другими методами.
>
> Подскажите где почитать про другие эффективные методы решения дефицита
> свободных fd в линуксе?
>
> Сейчас fd улетают как горячие пирожки, реал юзкейс
>
> Nginx, получает соединения от клиента, открывает соединения к бекенду, а
> бекенд открывает 30 соединений к Nginx для получения 30 JSON ответов от
> других бекендов, нам же приходится каждый запрос делать в отдельном
> соединение чтобы Nginx и бекенды могли параллельно их обрабатывать, вот для
> этой пустяковой задачи мы уже потратили 93 fd.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?21,266693,267166#msg-267166
>
> ___
> 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 из-за memcached

2016-05-26 Пенетрантность Валентин Бартенев 
On Thursday 26 May 2016 15:11:06 Дмитрий Андреев wrote:
> чт, 26 мая 2016 г. в 15:20, Валентин Бартенев :
> 
> > On Thursday 26 May 2016 08:04:59 Vadim Osipov wrote:
> > > location /screenshot/ {
> > > if ($request_method != GET) {
> > >   proxy_pass http://127.0.0.1:8080;
> > >   break;
> > > }
> > >
> > > more_clear_headers 'Content-Type';
> > > more_clear_headers 'Cache-Control';
> >
> > Это делается с помощью proxy_hide_header.
> >
> И для случаев, когда нужно удалить header из ответа клиенту, но
> залогировать в access_log-е тоже? Ну вдруг счастье уже наступило, а я не в
> курсе.

Всегда было можно:

$ cat test.conf
events {}

http {
log_format header '"$request_uri" "$upstream_http_x_header"';

server {
listen 8080;

location / {
proxy_pass http://127.0.0.1:8080/header;
proxy_hide_header X-Header;

access_log logs/headers.log header;
}

location /header {
add_header X-Header $arg_v;
return 204;
}
}
}
$ build/sbin/nginx -c ../test.conf
$ curl -i 127.0.0.1:8080/?v=hello
HTTP/1.1 204 No Content
Server: nginx/1.11.1
Date: Thu, 26 May 2016 15:26:11 GMT
Connection: keep-alive

$ curl -i 127.0.0.1:8080/?v=world
HTTP/1.1 204 No Content
Server: nginx/1.11.1
Date: Thu, 26 May 2016 15:26:15 GMT
Connection: keep-alive

$ cat build/logs/headers.log 
"/?v=hello" "hello"
"/?v=world" "world"

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Зависание nginx из-за memcached

2016-05-26 Пенетрантность Дмитрий Андреев 
чт, 26 мая 2016 г. в 15:20, Валентин Бартенев :

> On Thursday 26 May 2016 08:04:59 Vadim Osipov wrote:
> > location /screenshot/ {
> > if ($request_method != GET) {
> >   proxy_pass http://127.0.0.1:8080;
> >   break;
> > }
> >
> > more_clear_headers 'Content-Type';
> > more_clear_headers 'Cache-Control';
>
> Это делается с помощью proxy_hide_header.
>
И для случаев, когда нужно удалить header из ответа клиенту, но
залогировать в access_log-е тоже? Ну вдруг счастье уже наступило, а я не в
курсе.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-26 Пенетрантность Evgeniy Berdnikov 
On Thu, May 26, 2016 at 07:28:59AM -0400, S.A.N wrote:
> >  Конечно, мультиплексирование в FastCGI будет легче чем в HTTP/2.
> > 
> >  Но само по себе мультиплексирование не является самоцелью, оно может
> >  быть уместно в каких-то вычурных ситуациях (вроде исчерпания
> > сокетов),
> >  которые на самом деле разруливаются другими методами.
> 
> Подскажите где почитать про другие эффективные методы решения дефицита
> свободных fd в линуксе?
> 
> Сейчас fd улетают как горячие пирожки, реал юзкейс

 Интересно, сколько нужно открыть fd чтобы ощутить их дефицит в системе?

> Nginx, получает соединения от клиента, открывает соединения к бекенду, а
> бекенд открывает 30 соединений к Nginx для получения 30 JSON ответов от
> других бекендов, нам же приходится каждый запрос делать в отдельном
> соединение чтобы Nginx и бекенды могли параллельно их обрабатывать, вот для
> этой пустяковой задачи мы уже потратили 93 fd.

 Если у клиента такая логика, что он делает 30 запросов json одновременно,
 может быть, стоит подумать о пересмотре модели работы клиента? Так ли уж
 там нужна параллельная обработка этих 30 запросов?
-- 
 Eugene Berdnikov

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

Re: Зависание nginx из-за memcached

2016-05-26 Пенетрантность Валентин Бартенев 
On Thursday 26 May 2016 08:04:59 Vadim Osipov wrote:
> location /screenshot/ {
> if ($request_method != GET) {
>   proxy_pass http://127.0.0.1:8080;
>   break;
> }
> 
> more_clear_headers 'Content-Type';
> more_clear_headers 'Cache-Control';

Это делается с помощью proxy_hide_header.


> more_set_headers 'Content-Type: image/jpeg';
> more_set_headers 'Cache-Control: no-cache';
> 
> add_header  Cache-Control  no-cache;
> add_header  Content-Type   image/jpeg;

Это какой-то перебор.

Модуль headers-more-nginx-module вам тоже не нужен,
всё это реализуется штатными средствами.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: proxy http version 2; без SSL, для мультиплексирование запросов к бекенду

2016-05-26 Пенетрантность S.A.N 
>  Конечно, мультиплексирование в FastCGI будет легче чем в HTTP/2.
> 
>  Но само по себе мультиплексирование не является самоцелью, оно может
>  быть уместно в каких-то вычурных ситуациях (вроде исчерпания
> сокетов),
>  которые на самом деле разруливаются другими методами.

Подскажите где почитать про другие эффективные методы решения дефицита
свободных fd в линуксе?

Сейчас fd улетают как горячие пирожки, реал юзкейс

Nginx, получает соединения от клиента, открывает соединения к бекенду, а
бекенд открывает 30 соединений к Nginx для получения 30 JSON ответов от
других бекендов, нам же приходится каждый запрос делать в отдельном
соединение чтобы Nginx и бекенды могли параллельно их обрабатывать, вот для
этой пустяковой задачи мы уже потратили 93 fd.

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

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

Re: Зависание nginx из-за memcached

2016-05-26 Пенетрантность Валентин Бартенев 
On Thursday 26 May 2016 06:17:00 Vadim Osipov wrote:
> Новые подробности. Благодаря советам, решил попытаться дать такую нагрузку
> на nginx, чтобы потом заsegfault-ив memcached, попытаться смоделировать у
> проблему у клиента. Однако, заинтересовала ситуация, возможно, подобная
> тому, что есть у клиента, по меньшей мере, по загрузке CPU и косвенным
> признакам, что memcached является причиной.
> 
> В общем.
> 
> upstream  memcached_cluster  {
> server 10.197.162.35:11211;# <-- такого memcached нету либо он
> не запущен (или упал, завис как в случае как у клиента)
> hash   $uri/3.6;
> hash_again  1000;

Такой директивы как hash_again в стандартном nginx нет.

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

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Зависание nginx из-за memcached

2016-05-26 Пенетрантность Vadim Osipov 
Vadim Osipov Wrote:
---
> Новые подробности. Благодаря советам, решил попытаться дать такую

> upstream  memcached_cluster  {
> server 10.197.162.35:11211;# <-- такого memcached нету
> либо он не запущен (или упал, завис как в случае как у клиента)
> hash   $uri/3.6;
> hash_again  1000;
> keepalive 512;
> }
> 

> # service nginx restart
> nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
> nginx: configuration file /etc/nginx/nginx.conf test is successful
> Stopping
> nginx:
> ..
> ..
> ..
> ..
> ..
> ^C

Забыл добавить, что пытался как лечить 

Установка memcached_connect_time с 60s на 5s;
Убирание директивы worker_priority -5; 
Добавление fail_timeout=15s max_fails=3; к server 10.197.162.35:11211;
- не помогло

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

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

Re: Зависание nginx из-за memcached

2016-05-26 Пенетрантность Vadim Osipov 
Спасибо. Появились некоторые новые детали, которые, возможно, будут
интересны вам.

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

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

Re: Зависание nginx из-за memcached

2016-05-26 Пенетрантность Vadim Osipov 
Новые подробности. Благодаря советам, решил попытаться дать такую нагрузку
на nginx, чтобы потом заsegfault-ив memcached, попытаться смоделировать у
проблему у клиента. Однако, заинтересовала ситуация, возможно, подобная
тому, что есть у клиента, по меньшей мере, по загрузке CPU и косвенным
признакам, что memcached является причиной.

В общем.

upstream  memcached_cluster  {
server 10.197.162.35:11211;# <-- такого memcached нету либо он
не запущен (или упал, завис как в случае как у клиента)
hash   $uri/3.6;
hash_again  1000;
keepalive 512;
}

Запускаю nginx с описанным выше upstream.
Если запросов нету, которые приводят к обращению к memcached_cluster, то все
нормально, 
но когда приходит несколько запросов (может быть даже 1, точно не скажу, но
5-10 точно хватит), начинается загрузка CPU примерно 96-99.5% при server,
который не работает (или был, но упал/завис). 
Естественно, если server работает, то все нормально и такой загрузки нету.

После такой загрузки, service nginx stop/restart пытается остановить,
перезапустить сервис, но ... я не дождался. Более подробно - ниже.


ps uax | grep nginx

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
nginx 5072  0.0  0.2 428488 16500 ?S11:03   0:00 nginx:
worker process   
nginx 5073  0.0  0.2 428488 16500 ?S11:03   0:00 nginx:
worker process   
nginx 5074  0.0  0.2 428488 16500 ?S11:03   0:00 nginx:
worker process   
nginx 5075  0.0  0.0 416764  4724 ?S11:03   0:00 nginx:
cache manager process
root 15711  0.0  0.1 416764  6532 ?Ss   May25   0:00 nginx:
master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx15715  3.8  0.2 426956 15468 ?R<   May25  40:17 nginx:
worker process 

root  5130  0.0  0.0 103268   896 pts/2S+   11:03   0:00 grep nginx

top

top - 11:08:11 up 2 days, 2 min,  3 users,  load average: 1.03, 1.03, 0.92
Tasks:  96 total,   2 running,  94 sleeping,   0 stopped,   0 zombie
Cpu(s): 98.0%us,  0.0%sy,  2.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si, 
0.0%st
Mem:   5993264k total,  2813292k used,  3179972k free,   221772k buffers
Swap:  3145724k total,0k used,  3145724k free,  1060512k cached

PID   USER  PR  NI  VIRT  RES  SHR  S %CPU %MEM  TIME+COMMAND   
  
15715 nginx 15  -5  416m  15m  1256 R 97.2  0.3  44:23.91 nginx 



# service nginx restart
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Stopping
nginx:..^C
Пришлось, как видно, сделать Ctrl + C, а затем kill -9


error_log в режим error:

2016/05/26 11:21:29 [alert] 15711#0: worker process 15715 exited on signal
9
2016/05/26 11:24:42 [error] 7159#0: *1 upstream timed out (110: Connection
timed out) while connecting to upstream, client: 172.16.11.46, server:
10.197.162.35, request: "GET /url1?rnd=0.7008626744856947 HTTP/1.1",
upstream: "memcached://10.197.164.22:11211", host: "172.20.1.240", referrer:
"http://172.20.1.240/url2;
2016/05/26 11:24:47 [error] 7159#0: *1 upstream timed out (110: Connection
timed out) while connecting to upstream, client: 172.16.11.46, server:
10.197.162.35, request: "GET /url1?rnd=0.7008626744856947 HTTP/1.1",
upstream: "memcached://10.197.162.35:11211", host: "172.20.1.240", referrer:
"http://172.20.1.240/url2;


Установил error_log в режим info:
2016/05/26 12:15:51 [notice] 11221#0: using the "epoll" event method
2016/05/26 12:15:51 [notice] 11221#0: nginx/1.4.2
2016/05/26 12:15:51 [notice] 11221#0: built by gcc 4.4.7 20120313 (Red Hat
4.4.7-3) (GCC)
2016/05/26 12:15:51 [notice] 11221#0: OS: Linux 2.6.32-504.12.2.el6.x86_64
2016/05/26 12:15:51 [notice] 11221#0: getrlimit(RLIMIT_NOFILE): 2048:4096
2016/05/26 12:15:51 [notice] 11222#0: start worker processes
2016/05/26 12:15:51 [notice] 11222#0: start