ПРОЕКТЫ 


  АРХИВ 


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: Fwd: Nginx при обновлении бо льшого числа пакетов APT



29 июля 2011 г. 13:31 пользователь Maxim Dounin <mdounin@xxxxxxxxxx> написал:
> Hello!
>
> On Fri, Jul 29, 2011 at 01:01:54PM +0400, Evgeny Sinelnikov wrote:
>
...
>> 29 июля 2011 г. 11:34 пользователь Igor Sysoev <igor@xxxxxxxxx> написал:
>> > On Fri, Jul 29, 2011 at 06:53:32AM +0400, Evgeny Sinelnikov wrote:
...
>> > Lingering close не связан с SO_LINGER, про него можно почитать
>> > здесь (во второй ссылке много всего, нужно искать lingering close):
>> > http://sysoev.ru/web/upload.html
>> > http://httpd.apache.org/docs/1.3/misc/perf-tuning.html
>> >
>> > Тут похоже на проблему с pipelined.
>> > Скорее всего, в следующей версии будет исправлено.
>>
>> Это было бы замечательно. Хотя, на счёт того, что "Lingering close не
>> связан с SO_LINGER" мне не совсем понятно. Ведь как раз во второй
>> ссылке есть такое: "There are two ways of accomplishing this. One is
>> the socket option SO_LINGER. But as fate would have it, this has never
>> been implemented properly in most TCP/IP stacks."
>
> Оно не связано в том смысле, что TCP/IP стеков, где SO_LINGER
> делал бы необходимое для корректного закрытия соединения со
> стороны сервера - нет.
>
>> Кроме того, я на тесте проверил, что это именно проблема слишком
>> раннего закрытия. Мне пришлось убрать lingering_close, поскольку когда
>
> Судя по патчу, под словами "убрать lingering_close" следует
> понимать "убрать проверку r->lingering_close и соответственно
> всегда использовать закрытие с lingering'ом".
>
>> заканчивается keep alive time соединение сразу закрывается, а значение
>> lingering_timeout игнорируется. В большинстве случаев (не всегда) у
>> меня это приводит к тому, что клиентская сторона фиксирует обрыв
>> соединения со стороны сервера.
>
> Вот тут есть патч, добавляющий "lingering_close always" и пару
> дополнительных проверок в обычном случае:
>
> http://mailman.nginx.org/pipermail/nginx-devel/2011-July/001016.html
>
> В варианте "always" оно аналогично убранной проверке
> r->lingering_close (т.е. lingering close используется всегда).  Но
> насколько я понимаю конкретная проблема должна полечиться просто за
> счёт дополнительных проверок в обычном случае.
>
> Если не сложно - потестируйте pls.

Я проверил, изменения доступны здесь:
http://git.altlinux.org/people/sin/packages/nginx.git
http://git.etersoft.ru/people/sin/packages/nginx.git

Да, всё, отлично. Режим, по умолчанию работает. При "lingering_close
off" проблема стабильно воспроизводится. Новая проверка вида
(r->lingering_close || r->header_in->pos < r->header_in->last ||
r->connection->read->ready), вместо только r->lingering_close, решает
проблему и без "lingering_close always".

Кстати, связка "lingering_close always" и "lingering_timeout 0"
приводит к ещё более страшным последствиям... ;)


-- 
Sin (Sinelnikov Evgeny)
Etersoft
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.