Re: Отличия nginx о т varnish

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Wed, Dec 03, 2008 at 03:27:49PM +0200, MZ wrote:

> В ср, 03/12/2008 в 15:41 +0300, Igor Sysoev пишет:
> > On Wed, Dec 03, 2008 at 02:19:58PM +0200, MZ wrote:
> > 
> > > В ср, 03/12/2008 в 14:35 +0300, Igor Sysoev пишет:
> > > > On Wed, Dec 03, 2008 at 12:34:08PM +0200, MZ wrote:
> > > > 
> > > > > В вт, 02/12/2008 в 20:29 +0300, Igor Sysoev пишет:
> > > > > > On Tue, Dec 02, 2008 at 08:25:02PM +0300, Maxim Dounin wrote:
> > > > > > 
> > > > > > > Hello!
> > > > > > > 
> > > > > > > On Tue, Dec 02, 2008 at 06:54:24PM +0200, MZ wrote:
> > > > > > > 
> > > > > > > > В вт, 02/12/2008 в 18:32 +0300, Maxim Dounin пишет:
> > > > > > > > 
> > > > > > > > > Я бы ещё добавил что наличие многих процессов у nginx'а 
> > > > > > > > > ситуацию 
> > > > > > > > > не сильно лечит при использовании accept_mutex'а - ибо worker
> > > > > > > > > пытается получить accept_mutex раз в 500ms по умолчанию 
> > > > > > > > > (тюнится 
> > > > > > > > > через accept_mutex_delay), и соответственно если не повезёт 
> > > > > > > > > могут 
> > > > > > > > > быть задержки с accept()'ом вплоть до 500ms даже если есть 
> > > > > > > > > свободные worker'ы.
> > > > > > > > > 
> > > > > > > > > Maxim Dounin
> > > > > > > > 
> > > > > > > > А чем же воркеры заняты 500ms если получить accept_mutex не 
> > > > > > > > удалось ?
> > > > > > > 
> > > > > > > Висят и ждут очередного события по уже открытым соединениям.  В 
> > > > > > > предельном случае - ничего не делают и ждут того самого таймера в 
> > > > > > > 500ms.
> > > > > > 
> > > > > > Возможно, имеет смысл уменьшить 500ms до 100ms по умолчанию.
> > > > > 500ms задержки (250ms в среднем) это все ж достаточно серьезно :(
> > > > > Получается при текущей архитектуре nginx их не избежать, ведь рабочие
> > > > > соединения практически всегда в наличии.
> > > > > 
> > > > > 10ms при 40 workers дали ~2% нагрузки CPU на Xeon(R) X3320 (4 ядра
> > > > > 2.50GHz) без трафика.
> > > > > Терпимо.
> > > > > 
> > > > > Лучше по умолчанию ставить хотя бы 50ms, зачем больше? Оверхед при 
> > > > > 50ms
> > > > > практически неощутим никак.
> > > > 
> > > > Там, на самом деле, ситуация другая.
> > > > 
> > > > Процесс, захвативший accept_mutex вызывается kevent() и среди прочего
> > > > получает события о новых соединениях. Сначала он accept()ит эти 
> > > > соединения,
> > > > потом освобождает accept_mutex и начинает обрабатывать другие события.
> > > > После освобождения мьютекса его можно захватить любой воркер.
> > > > 
> > > > accept_mutex_delay - это максимальное время, на которое может заснуть
> > > > в kevent() воркер, не держащий accept_mutex. Такое может быть, только
> > > > если нагрузка совсем маленькая.
> > > > 
> > > > Так что, думаю, не нужно accept_mutex_delay уменьшать.
> > > 
> > > Что означает "accept_mutex_delay - это максимальное время" ? В каких
> > > случаях время между попыткой захватить этот мютекс меньше чем
> > > accept_mutex_delay ?
> > 
> > Воркер пытается захватить мьютекс перед каждым заходом в kevent().
> > Время между двумя kevent()ами на хорошей нагрузке - миллисекунды.
> 
> Просто Максим написал что воркер пытается получить этот мютекс раз в
> 500ms, а не перед каждым заходом в kevent() - все таки существенная
> разница )

Я некорректно выразился.  Раз в 500ms - если воркер ничего другого 
не делает (или по существующим соединениям ничего не происходит).  

Есть мнение что у Миши Монашёва с его 1000 воркеров подобная 
ситуация вероятна.  Процитированный абзац был написан именно в 
рамках объяснения наблюдаемых им ненулевых значений qlen у 
nginx'а, и не наблюдаемых у varnish'а.  

> То есть максимальная задержка для accept()-а нового соединения
> определяется поступлением нового события в kevent() какого-либо воркера
> (что происходит постоянно под нагрузкой) и временем потраченным на
> обработку этого события перед следующим вызовом kevent() - а тут
> возможны проблемы из-за блокировки на диске, хотя навряд ли она будет
> больше 10-30ms.

Задержки на дисках бывают очень разные, в остальном - да.

Maxim Dounin