ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hello!

On Tue, Jul 14, 2009 at 10:42:23PM +0200, Anton Kuznetsov wrote:

> Тоже спасибо :)
> Поставил 8.0.5 - проблему опять видно.
> 
> В принципе конфиг работает - 2 запроса в минуту и остальные ждут. Но.. масса
> строчек в логе с размером ответа 60к-65к.

Те "строчки в логе с размером ответа 60к-65к", которые вы до сих 
пор приводили для nginx'а с наложенным патчем, не являются 
проблемой в nginx'е, а лишь отражают поведение ваших 
пользователей.

Судя по описываемым симптомам - очень может быть что они просто не 
дожидаются ответа и закрывают соединение.

В качестве проверки можно попробовать убрать реальный сервер за 
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.



 




Copyright © Lexa Software, 1996-2009.