ПРОЕКТЫ 


  АРХИВ 


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: nginx status: reading 100-200, writing 1-5. Как побороть?



On Wednesday 19 September 2012 18:02:40 mikhal123 wrote:
[...]
> нет там ничего похожего (error.log ведется с момента перезапуска nginx с
> новыми параметрами)
> вы предполагаете, несмотря на опцию defer в listen эти пустые соединения
> все равно доходят до nginx? это можно проверить как-то проверить? может
> протухла в nginx эта опция :)

Они в любом случае будут доходить, так он работает.

Я понял в чем причина. Вы выставили client_header_timeout в 3 секунды, а 
deferred accept берет свой таймаут из этой же директивы.

В итоге, у вас 3 секунды соединение проводит в ядре, а потом кончается таймаут
deferred accept-а и соединение передается nginx-у, и nginx ждет ещё три секунды 
до таймаута.

Выставлять client_header_timeout в столь малое значение вообще была очень 
плохая 
идея в любом случае. Так жестко играясь с таймаутами (которые и так по дефолту 
имеют более-менее оптимальные значения) вы более навредите своим посетителям, 
чем получите какую-то выгоду. 100 соединений nginx способен держать даже на 
кофеварке, это не та цифра по которой надо переживать.

Рекомендую спилить client_header_timeout из конфига, 60 секунд по дефолту 
скорее 
всего будет достаточно чтобы Хром сам отвалился проведя всё время в ядре, и всё,
что осталось бы nginx - это отработать закрытие соединения.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.