Re: Меня опять терзают смут ные сомнения... (с)

[Vladimir Romanov <vromanov@xxxxxxxxx>]

1) А не может ли у вас быть размер окна TCP/IP в 128к?
2) На качалке (а судя по 206 это не бровзер) может работать лимит
скорости скачивания. Т.е. программа на выбирает из сокета больше чем
столько-то байтов
3) Есть еще один странный косяк в ядре линукса. У вас contrack не
задействован (iptables)? Как раз проявляется на медленных линках типа
GPRS, или плохого WiFI.

2010/1/17 Maxim Dounin <mdounin@xxxxxxxxxx>:
> Hello!
>
> On Sun, Jan 17, 2010 at 12:01:39AM +0100, Anton Kuznetsov wrote:
>
>> Я уже не раз писал о проблемах с частым обрывом коннектов при раздаче
>> большой статики. И вот у меня на форуме появился человек который пожаловался
>> со своей стороны на то, что мне так не нравилось в логах. И кажется мы
>> нащупали в чем дело.
>> Проблема в логах выглядит так:
>>
>> 217.118.79.28 - - [01/Dec/2009:00:07:57 +0300] 31.386 GET
>> /multiki/rovno.v.3-15.avi HTTP/1.1  206 132988
>> 85.202.188.196 - - [01/Dec/2009:00:08:01 +0300] 31.762 GET
>> /filmiki/gostja.iz.buduschego.1.avi HTTP/1.0  206 132255
>> 195.158.228.210 - - [01/Dec/2009:00:08:02 +0300] 30.284 GET
>> /filmiki/voskresene.polovina.shestogo.2.avi HTTP/1.1  206 123537
>>
>> За 30 секунд ( send_timeout  30s;) скачивается некий тоже весьма одинаковый
>> кусок (sndbuf=64k; 2 раза?) и разрыв.
>>
>> Пользователь отписал что у него 128кбит adsl и с других моих серверов, где
>> фрюха и sendfile on; все качается без разрывов.
>> Проблемный сервер под линуксом, sendfile off и output_buffers   2 1024k;
>>
>> Я поставил
>> send_timeout  120s;
>> output_buffers   2 512k;
>>
>> И всем сразу полегчало. Я правильно догадываюсь, что если юзер очень
>> медленный и если он не успел за время send_timeout скачать весь
>> output_buffers и попросить новый, то nginx думает что передача встала и
>> принудительно рвет коннект??? Качание из буфера за активность не
>> считается???
>
> Нет, не правильно.  При отправке данных в сокет отсчёт таймаута
> начинается заново, вне зависимости от того отправился ли полный
> буфер или нет.
>
> Потенциально возможны грабли в тех местах где отправка данных
> специально откладывается - i.e. при использовании
> sendfile_max_chunk, limit_rate/limit_rate_after, postpone_output,
> send_lowat.  Но эти места довольно прозрачны, перечитывались уже
> не один раз, и шансов найти что-то без debug log'а - никаких.
>
> Впрочем, мне усиленно кажется что проблемы лежат где-то в области
> поведения клиентов и/или tcp/ip.  И таймауты в 30 секунд вполне
> реально есть.  Но тут уже надо смотреть tcpdump, причём хорошо бы с
> двух сторон.  Да и не факт что это проблема, а не суровая
> реальность:
>
> 217.118.79.28 = билайн gprs
> 85.202.188.196 - не знаю что, но где-то на сахалине
> 195.158.228.210 - спутниковая связь
>
> Мне вот совсем не удивительно что оно провисает на неведомо
> сколько.
>
> [...]
>
> Maxim Dounin
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://nginx.org/mailman/listinfo/nginx-ru
>



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