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

[Anton Kuznetsov]

Спасибо за версии, но давайте мыслить дедуктивно.

Объем гадкого ответа рядом с размером в этой строчке конфига
listen       80 default sndbuf=64k;

Еще факт отфильтровал:
Добавил время ответа в лог (перед GET). Удивительная стабильность размера
ответа и времени.

195.34.252.13 - - [15/Jul/2009:22:40:00 +0400] 30.001 GET
/filmiki/4.tankista.i.sobaka.14.nad.shluzom.avi HTTP/1.0 ZZ 206 63461
195.34.252.13 - - [15/Jul/2009:22:40:07 +0400] 30.885 GET
/filmiki/4.tankista.i.sobaka.14.nad.shluzom.avi HTTP/1.0 ZZ 206 62604
217.118.79.26 - - [15/Jul/2009:22:40:33 +0400] 34.833 GET
/multiki/armenfilm.uh.ty.govorjaschaja.ryba.avi HTTP/1.0 ZZ 206 64434
195.34.253.17 - - [15/Jul/2009:22:40:44 +0400] 30.114 GET
/multiki/burenka.iz.maslenkino.avi HTTP/1.0 ZZ 206 64032

 Если пытаться привязать к конфигу, у меня есть такая строчка:
    send_timeout           30s;

Решил сразу проверить, все верно:
listen       80 default sndbuf=32k;
   send_timeout           40s;

Пожалуйста:
80.73.6.156 - -      [15/Jul/2009:22:52:58 +0400] 40.000 GET
/film/traktoristy.avi HTTP/1.0 ZZ 206 31040
195.34.252.13 - -   [15/Jul/2009:22:52:58 +0400] 40.003 GET
/filmiki/4.tankista.i.sobaka.14.nad.shluzom.avi HTTP/1.0 ZZ 206 30252
95.104.171.181 - - [15/Jul/2009:22:53:02 +0400] 40.914 GET
/multiki/koshkin.dom.1958.avi HTTP/1.0 ZZ 206 31456
79.139.154.17 - -   [15/Jul/2009:22:53:06 +0400] 40.002 GET /film/gu.ga.avi
HTTP/1.0 ZZ 206 37272

Плюс у всех "Download Master" - проверил по другому логу. И все пытаются
работать в 5 потоков.
все выше про сервер под фрюхой, nginx 0.8.5, нагрузка - 400Mbit

Тааак, присмотрелся к логу на линуксе (nginx/0.7.57, 800Mbit)
send_timeout           30s;
sendfile       off;
limit_req_zone $binary_remote_addr  zone=avi:10m   rate=2r/m;
listen       80 default sndbuf=64k;

85.172.38.82 - -     [15/Jul/2009:23:07:56 +0400] 30.958 GET
/film/za.dvumja.zajcami.avi HTTP/1.0  206 129427
89.232.105.131 - - [15/Jul/2009:23:07:56 +0400] 30.073 GET
/multiki/zolotoi.malchik.avi HTTP/1.0  206 130389
62.33.41.30 - -      [15/Jul/2009:23:07:58 +0400] 31.761 GET
/film/aljoshkina.ljubov.avi HTTP/1.0  206 131107
93.185.24.117 - -  [15/Jul/2009:23:08:03 +0400] 30.903 GET
/film/a.zori.zdes.tihie.1.avi HTTP/1.0  206 130385
91.204.196.31 - -  [15/Jul/2009:23:08:03 +0400] 30.098 GET
/film/sluzhili.dva.tovarischa.avi HTTP/1.0  206 131108

Проблема в полный рост, просто размер мной не ожидаемый и долго
маскировался.

Третий нагруженный сервер: фрюха, nginx/0.7.61 + patch  400 Mbit
sendfile       on;
limit_req_zone $binary_remote_addr  zone=avi:10m   rate=5r/m;
Проблема полностью отсутствует!!!

Еще два мало нагруженных сервера под фрюхой и sendfile off; - проблемы нет.

"Клиент" везде одинаковый, контент тоже - в этом смысле серверы в равных
условиях.

Внимание, вопрос - какой правильный вывод?  :)



Антон.

2009/7/15 AleXXX V. NovikoFF <alexxx at alexxx.ru>

> Hi!
>
> Ну, например, Reget и DM при добавлении закачки, еще до начала скачивания,
> делают HEAD, чтобы нарисовать юзеру длину файла и проверить, существует
> ли он там вообще, его миме-тип и т.д.
>
> Wed, 15 Jul 2009 12:47:32 +0400
> "Dmitry Dedukhin" <dedukhin at mail.ru> писал(а):
>
> > >>Обычно качалки делают HEAD к файлу, чтобы узнать длину ответа.
> >
> > Позвольте узнать, какие популярные качалки делают HEAD-запрос?
> > Обычно, качалки делают запрос в первом потоке без Range, узнавая длину
> файла
> > из ответа, потом создают дополнительные потоки с Range-запросами. При
> этом
> > первый поток качает файл с начала и до того места, которое уже скачал
> другой
> > поток, затем обрывает соединение.
> >
>
> --
> Цитируйте предыдущую переписку, пожалуйста.
> AleXXX V. NovikoFF <alexxx at alexxx.ru>
> WWW: http://alexxx.ru/
>
>
>


-- 
Best regards,
Anton Kuznetsov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20090715/2f163164/attachment.html>