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

[Anton Kuznetsov]

Я уже не раз писал о проблемах с частым обрывом коннектов при раздаче
большой статики. И вот у меня на форуме появился человек который пожаловался
со своей стороны на то, что мне так не нравилось в логах. И кажется мы
нащупали в чем дело.
Проблема в логах выглядит так:

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 думает что передача встала и
принудительно рвет коннект??? Качание из буфера за активность не
считается???

Тут возникает дилема. У меня дома интернет 10мбит - ровно в 100 раз быстрее
и мне кажется таких сейчас больше чем  128кбит, по логам сервера, средняя
скорость - 1мбит. При output_buffers   2 512k; диски заметно поднапреглись -
этот сервер раздает гигабит в полку и диски у меня всегда были проблемным
местом. :(
Как сделать поумнее, если я вообще правильно распутываю проблему? задирать
send_timeout в бесконечность не хотелось бы, при ограничении на количество
потоков = 1 - это выйдет боком при тех же разрывах. :(

Так же интересен алгоритм обработки send_timeout при sendfile on; там где
kern.ipc.sfreadahead=8

-- 
Best regards,
Anton Kuznetsov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20100117/9a821a82/attachment-0001.html>