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

Животнев Влад inkvizitor68sl на gmail.com
Вт Июн 26 17:38:02 UTC 2012


Есть подозрения, что под нагрузкой модуль 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;
                }
}
----------- следущая часть -----------
A non-text attachment was scrubbed...
Name: some_nfront_log
Type: application/octet-stream
Size: 1827 bytes
Desc: отсутствует
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20120626/43dba15c/attachment.obj>


Подробная информация о списке рассылки nginx-ru