ПРОЕКТЫ 


  АРХИВ 


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 max_fails и упавшие сервера



Hello!

On Tue, Jul 09, 2013 at 12:10:14PM +0400, Андрей Урядов wrote:

> Сделал так, как советовали: после старта бэкенд говорит фронтенду, что надо
> перечитать конфигурацию. Но в логах почему-то даже после перечитывания
> появляются ошибки: (110: Connection timed out) while connecting to
> upstream, причем указан ip бэкенда не из списка текущих - видимо, старый
> остался. Причем, такое повторяется через несколько минут после
> перечитывания конфигурации. Хотя, эти ошибки явно одиночные - проявляются
> только для нескольких клиентов, у остальных все нормально работает. Это
> результаты какого-то кэширования? Потому что запрос от клиента на nginx
> пришел явно после того, как конфигурация уже была перечитана.

Такое может быть, e.g., если запрос _начал_ приходить давно, и 
соответственно - в старый рабочий процесс, и делал это долго - 
e.g. от клиента принималось большое тело запроса.  Либо запрос до 
этого где-то долго обрабатывался (e.g. ходил на другой бекенд, и 
потом из-за ошибки или по X-Accel-Redirect был куда-то ещё 
отправлен).

В сообщениях об ошибках написан pid процесса, имеет смысл на него 
посмотреть - там должен быть pid одного из старых рабочих 
процессов.

Ну и $request_time, $upstream_response_time имеет смысл в логи 
добавить - чтобы не писать "явно после", а оперировать фактами.

-- 
Maxim Dounin
http://nginx.org/en/donation.html

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


 




Copyright © Lexa Software, 1996-2009.