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

[Igor Sysoev <is@xxxxxxxxxxxxx>]

On Wed, Jul 15, 2009 at 06:47:32AM +0400, Maxim Dounin wrote:

> Hello!
> 
> On Tue, Jul 14, 2009 at 10:42:23PM +0200, Anton Kuznetsov wrote:
> 
> > Тоже спасибо :)
> > Поставил 8.0.5 - проблему опять видно.
> > 
> > В принципе конфиг работает - 2 запроса в минуту и остальные ждут. Но.. масса
> > строчек в логе с размером ответа 60к-65к.
> 
> Те "строчки в логе с размером ответа 60к-65к", которые вы до сих 
> пор приводили для nginx'а с наложенным патчем, не являются 
> проблемой в nginx'е, а лишь отражают поведение ваших 
> пользователей.

У меня ощущение, что 60-65К (или 32К, если kernel send буфер такого размера),
возникают так - многопотоковая качалка запрашивает файл, берёт из
ответа длину, закрывает соединение. А потом начинает тянуть в несколько
потоков, исходя из длины. Можно поставить эксперементы или посмотреть
в исходники, если они есть.

> Судя по описываемым симптомам - очень может быть что они просто не 
> дожидаются ответа и закрывают соединение.
> 
> В качестве проверки можно попробовать убрать реальный сервер за 
> proxy_pass (можно в том же nginx'е и видимо с 
> proxy_max_temp_file_size 0 чтобы диск лишнего не грузить) - будет 
> работать детектирование закрытия соединения клиентом, и подобные 
> запросы до диска не дойдут.  В логах должно появиться что-то вроде 
> "kevent() reported that client closed prematurely connection" на 
> уровне info.
> 
> Maxim Dounin
> 
> > Отключаю все limit_req - пропадают эти ненавистные строчки 60к-65к, но
> > начинается основная проблема - просто долбежка запросами от качалок, ответы
> > там разных размеров, но в основном до 1м. Что меня не очень устраивает, ни
> > по распухающим логам, ни по эффективности работы сервера. Не хочу чтобы
> > нжинкс только и делал что открывал коннекты и закрывал. Десятками в секунду.
> > И еще чтобы он не читал по 500к-1000к с диска в буфер из которого потом
> > отдает только 150к. Хочу чтобы качали нормальные люди, которые могут
> > настроить качалку в один поток. Остальные пусть смотрят на свои 2000
> > ESTABLISHED коннектов в которые ничего не отдается.
> > 
> > Может я неправильным путем иду?
> > Исходная задача - отдавать в один поток, остальные подвешивать, стреляя 503
> > крайне медленно и долго.
> > Кол-во запросов в минуту тоже ограничить, превышение аналогично подвешивать.
> > 
> > Антон.
> > 
> > 
> > 2009/7/14 Maxim Dounin <mdounin@xxxxxxxxxx>
> > 
> > > Hello!
> > >
> > > On Tue, Jul 14, 2009 at 09:24:48PM +0200, Anton Kuznetsov wrote:
> > >
> > > > Ну раз уж взялся ковырять проблему хотел и обновиться.. Ну делать 
> > > > нечего,
> > > > пропатчил 0.7.61
> > > >
> > > > Собственно  возвращаясь к сути проблемы - на разных серверах все сильно
> > > по
> > > > разному.
> > > > Вот логи с сервера где проблему побороть не удалось.
> > > > FREEBSD 7.0-RELEASE
> > > > nginx version: nginx/0.7.61
> > > > Патч наложен.
> > >
> > > [...]
> > >
> > > > 2009/07/14 23:02:57 [debug] 89383#0: *969 limit_req: -2 1.000
> > > > 2009/07/14 23:02:57 [warn] 89383#0: *969 delaying request, excess: 
> > > > 1.000,
> > > by
> > > > zone "avi", client: 95.24.28.67, server: inka.arjlover.net, request:
> > > "GET
> > > > /multiki/ostrov.osh
> > > > ibok.avi HTTP/1.0", host: "inka.arjlover.net", referrer: "
> > > > http://multiki.arjlover.net/info/ostrov.oshibok.avi.html";
> > > > 2009/07/14 23:02:57 [debug] 89383#0: *969 event timer add: 80:
> > > > 1000:2057662719
> > > > 2009/07/14 23:02:58 [debug] 89383#0: *969 event timer del: 80: 
> > > > 2057662719
> > > > 2009/07/14 23:02:58 [debug] 89383#0: *969 http run request:
> > > > "/multiki/ostrov.oshibok.avi?"
> > > > 2009/07/14 23:02:58 [debug] 89383#0: *969 limit_req delay
> > >
> > > [...]
> > >
> > > Патч не наложен.  Тут должно быть написано "limit_req delay patched 2".
> > >
> > > Maxim Dounin
> > >
> > >
> > 
> > 
> > -- 
> > Best regards,
> > Anton Kuznetsov.

-- 
Игорь Сысоев
http://sysoev.ru