ПРОЕКТЫ 


  АРХИВ 


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: Re[8]: Постоянные обры вы коннектов



Hello!

On Thu, Jul 16, 2009 at 09:52:56AM +0200, Anton Kuznetsov wrote:

> #pfctl -d
> No ALTQ support in kernel
> ALTQ related functions disabled
> pfctl: pf not enabled
> 
> #ipfw l
> 65535 allow ip from any to any
> 
> Вроде все чисто.
> 
> Что-то борьба за дисциплину и чистоту логов выходит боком. :)
> Можешь подсказать с какими ключами tcpdump дампить заголовки?

Заголовки - всмысле tcp пакетов. Запустить как-нибудь так:

tcpdump -npi <интерфейс> -w <файл куда писать> port 80

Дождатся появления проблемы (не забыв включить debug log в 
nginx'е), выключить.  При этом не забывать, что в access_log'е 
появляется запись только по окончании запроса, а нам нужно чтобы в 
tcpdump'е было видно и его начало.  После чего через

tcpdump -n -r <файл куда писали> host <ip с проблемой>

(другие условия по вкусу, вероятно нужно будет выбирать тчательно 
- ибо они же ломяться) найти соответствующую сессию и дать 
посмотреть вместе с соотвтетствующим куском debug log'а.

Maxim Dounin


> 
> А я все больше склоняюсь к nodelay и 503. Хотя один образцовый сервер не
> дает покоя - как-то на нем завелось же все как мне хочется. И limit_req
> работает и в логи всякие обрезки не падают..
> 
> Антон.
> 
> 
> 
> 2009/7/16 Maxim Dounin <mdounin@xxxxxxxxxx>
> 
> >
> > Ушёл, дождался окончания задержки, начал отправлять данные
> > клиенту, забил tcp'шный буфер на отправку, ушёл дожидаться пока
> > клиенту из буфера что-нибудь уйдёт.  Клиенту так ничего и не
> > отправилось, соединение было закрыто по таймауту.
> >
> > Для полноты картины неплохо бы ещё поймать tcpdump подобной сессии
> > (достаточно просто заголовков, без содержимого пакетов), и
> > рассматривать вместе с debug log'ом.
> >
> > > Фича? Конфликт двух настроек? Но вылазит только на "Download Master"?
> > Истина
> > > где-то рядом.... :)
> >
> > У вас случайно никаких файрволов сопровождающихся блокировками не
> > настроено?  Очень похоже что где-то по дороге стали просто дропать
> > пакеты.  Я сомневаюсь что вышеописанное поведение свойственно
> > самому Download Master'у, но вот его неумеренная настойчивость
> > вполне может вызывать реакцию всяких скриптов следящих за
> > логами...
> >
> > --
> Best regards,
> Anton Kuznetsov.



 




Copyright © Lexa Software, 1996-2009.