ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: upstream timed out (110: Connection timed out)



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



Вечер добрый.

Что может означать спонтанное высыпание в логах такой ошибки:

[error] 12536#0: *131050 upstream timed out (110: Connection timed out)
while reading response header from upstream,
[error] 12535#0: *132147 upstream timed out (110: Connection timed out)
while reading response header from upstream,
[error] 12538#0: *127648 upstream timed out (110: Connection timed out)
while reading response header from upstream,
[error] 12536#0: *130806 upstream timed out (110: Connection timed out)
while reading response header from upstream,
[error] 12541#0: *130073 upstream timed out (110: Connection timed out)
while reading response header from upstream,
....
Всего 100-200 ошибок в течение нескольких секунд, клиенты из самых разных
подсетей. Нагрузка при этом средняя -- в районе тысячи подключений, но
зачастую, когда ошибки валятся, количество подключений резко возрастает.
Сейчас вот вижу

Reading: 1 Writing: 3572 Waiting: 0

При этом, новые подключения сервер обрабатывает без задержек. Это может быть
следствием того, что менеджеры закачек начинают активно ломиться после
разрыва соединения.
Ошибка может появляться несколько раз в час, а бывает неделя тишины,
начинается и проходит само собой... Фронтенд занят раздачей файлов (5-150
Мб), которые лежат на nfs (на соседних серверах).

Наблюдается такое пару месяцев, поэтому всё, что предлагалось в списке
рассылки -- уже перепробовал. Ещё грешил на perl, но вот разделили nginx на
два процесса (на разные порты, perl на backend, раздатчик без модуля -- на
frontend), а ситуация опять повторилась...

Я пытался делать debug на одно из подключений, и там проскакивало http read
blocked. Если это причина, то как можно узнать, из-за чего оно blocked?

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

Система: старый Linux с ядром 2.6.9 + nginx 0.4.7

-----------

worker_processes  8;

worker_rlimit_nofile 16384;

events {
   worker_connections  1048;
}

http {
[...]

   sendfile       on;
   tcp_nopush     on;
   keepalive_timeout  0;
   tcp_nodelay        on;

   client_header_timeout  3m;
   client_body_timeout    3m;
   send_timeout           3m;

   proxy_connect_timeout      1m;
   proxy_send_timeout         1m;
   proxy_read_timeout         1m;


   location /test {
           internal;
           proxy_set_header  X-Orig-URL        $orig_uri;
           proxy_set_header  X-Bytes-Sent      $body_bytes_sent;
           proxy_set_header  X-User-IP         $remote_addr;
           proxy_set_header  X-User-Login      $login;
           proxy_pass   http://127.0.0.1:9997/final;
       }


   location /files {
           proxy_set_header  X-User-IP         $remote_addr;
           proxy_pass http://127.0.0.1:9997;
       }

[...]








 




Copyright © Lexa Software, 1996-2009.