Re: Проблема в upstream с max_fails/fail_timeout

[Животнев Влад <inkvizitor68sl@xxxxxxxxx>]

А под нагрузкой в 1к rps всё ещё веселее:

root@nfront01g:~# tail -100000 /var/log/nginx/error.log | grep
http://178.154.239.80:80/firefox/  | grep "22:08:02"| wc -l
124
root@nfront01g:~# tail -100000 /var/log/nginx/error.log | grep
http://178.154.239.80:80/firefox/  | grep "22:08:02"| wc -l
124
root@nfront01g:~# tail -100000 /var/log/nginx/error.log | grep
http://178.154.239.80:80/firefox/  | grep "22:08:03"| wc -l
127
root@nfront01g:~# tail -100000 /var/log/nginx/error.log | grep
http://178.154.239.80:80/firefox/  | grep "22:08:04"| wc -l
162
root@nfront01g:~# tail -100000 /var/log/nginx/error.log | grep
http://178.154.239.80:80/firefox/  | grep "22:08:05"| wc -l
125
<и так ещё доооолго можно продолжать>

То есть оно даже и не пытается отстрелить риалы, похоже.

26 июня 2012 г., 21:38 пользователь Животнев Влад
<inkvizitor68sl@xxxxxxxxx> написал:
> Есть подозрения, что под нагрузкой модуль upstream ведет себя
> неведомым образом.
>
> Конфиг в конце письма.
>
> 5 машин из 9 закрыты с -j DROP
> Что ожидается ( в худшем случае):
> В проксю прилетает 10-100-800 запросов. Она немного тупит, перебирает
> риалы, в самом худшем случае отвечает за 3-4 секунды (5*500ms+время
> ответа приложения, хоть оно и <0,1с). За это время оно делает 2
> запроса в каждый из упавших фронтов, забывает про каждый закрытый на
> 300 секунд.
>
> Что имеет в реальности.
> Transactions:                 358671 hits
> Availability:                  99.92 %
>
> (0,8% запросов улетело в трубу, не вписавшись в таймаут siege).
> Longest transaction:           95.05
>
> Около 2-3% запросов - по 18+ секунд. Во время обстрела конструкции
> можно браузером на глаз увидеть, как периодически достаточно часто
> тупит балансер.
>
> Ну и странности с собственно обработкой max_fails/fail_timeout - в
> упавший риал прилетает 6-7 запросов за 20 секунд, потом через 20
> секунд ещё 1-2, потом в риал nginx не ходит ~4 минуты 20 секунд, потом
> цикл повторяется. Собственно, тут скорее интересно понять, откуда оно
> взялось, что бы правильно покрутить параметры.
> А вот про долгие ответы - очень интересно и плохо.
>
> В аттаче есть лог обращений к одному из риалов во время обстрела
> (отгрепанный из error.log балансера).
>
> Выкручивание таймаутов в 50ms на connect, 200ms на read/send никаких
> результатов не даёт.
>
> Всё это выявлено под нагрузкой в ~700 rps, риалы сами по себе каждый
> держат по 700-800 без особых проблем.
>
> 2xXeon E5645, 48Г памяти, dom0 - lucid, nginx запущен в lxc-виртуалке
> с precise.
>
> Конфиг балансера:
>
> upstream elements-www {
> # server nfront01g max_fails=2 fail_timeout=60s;
> server nfront02g max_fails=2 fail_timeout=300s;
> server nfront03g max_fails=2 fail_timeout=300s;
> server nfront04g max_fails=2 fail_timeout=300s;
> server nfront05g max_fails=2 fail_timeout=300s;
>
> server nfront01f6 max_fails=2 fail_timeout=300s;
> server nfront02f6 max_fails=2 fail_timeout=300s;
> server nfront03f6 max_fails=2 fail_timeout=300s;
> server nfront04f6 max_fails=2 fail_timeout=300s;
> server nfront05f6 max_fails=2 fail_timeout=300s;
> }
>
>
> server {
>        listen 80;
>       server_name ...;
>
>       location / {
>                proxy_connect_timeout   500ms;
>                proxy_read_timeout      1000ms;
>                proxy_send_timeout      1000ms;
>                proxy_next_upstream error timeout invalid_header
> http_500 http_502 http_503 http_504;
>                                    # http_404;
>                proxy_set_header X-Real-IP $remote_addr;
>                proxy_set_header Host $host;
>                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>                proxy_pass http://elements-www;
>                }
> }
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru