Re: Re[8]: Постоянные обрывы коннектов

[Anton Kuznetsov]

#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 дампить заголовки?

А я все больше склоняюсь к nodelay и 503. Хотя один образцовый сервер не
дает покоя - как-то на нем завелось же все как мне хочется. И limit_req
работает и в логи всякие обрезки не падают..

Антон.



2009/7/16 Maxim Dounin <mdounin at mdounin.ru>

>
> Ушёл, дождался окончания задержки, начал отправлять данные
> клиенту, забил tcp'шный буфер на отправку, ушёл дожидаться пока
> клиенту из буфера что-нибудь уйдёт.  Клиенту так ничего и не
> отправилось, соединение было закрыто по таймауту.
>
> Для полноты картины неплохо бы ещё поймать tcpdump подобной сессии
> (достаточно просто заголовков, без содержимого пакетов), и
> рассматривать вместе с debug log'ом.
>
> > Фича? Конфликт двух настроек? Но вылазит только на "Download Master"?
> Истина
> > где-то рядом.... :)
>
> У вас случайно никаких файрволов сопровождающихся блокировками не
> настроено?  Очень похоже что где-то по дороге стали просто дропать
> пакеты.  Я сомневаюсь что вышеописанное поведение свойственно
> самому Download Master'у, но вот его неумеренная настойчивость
> вполне может вызывать реакцию всяких скриптов следящих за
> логами...
>
> --
Best regards,
Anton Kuznetsov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20090716/e7ba8727/attachment.html>