Re: [Sysadmins] apache tuning in nginx presence

["Денис Смирнов" <mithraen@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 5581 bytes --]

On Wed, Aug 22, 2007 at 02:44:25PM +0300, Michael Shigorin wrote:

>> То есть если по каким-то причинам время выдачи одним апачем
>> ответа существенно большое на отдельных страницах, то
>> количество бэкендов приходится увеличивать.
MS> Угу, но это скорее anti-DoS уже получается.

Если у тебя есть страницы которые по каким-то причинам могут сильно
тормозить -- то они сами по себе DoS. Соответственно для хостинга, где
запросто какой-нибудь умник таки может склепать подобную страницу,
подобная настройка сама по себе DoS. Увы :(


> >> MinSpareServers 5
> >> MaxSpareServers 20
> >> StartServers 12
> >> MaxClients 12
>> Везет... мне StartServer 50 надо было делать, а MaxClients 100
>> на одном их хостов не хватало... А когда я их увеличил
>> оказалось что надо поднимать и в MySQL лимиты.
MS> Это у тебя так долго барахлишко тарахтело?

Там автор поделия на PHP шибко умный. Это ещё оно быстро работало, после
того как я грязно матерясь смотрел на особо долгие запросы и ручками
создавал индексы.

MS> Я бы попробовал разбросать по разным апачам с разными лимитами
MS> на время исполнения скрипта, наверное.  И всё-таки держать их 
MS> не более двух-трёх на процессор, иначе ты всё равно только дольше
MS> разрываешь скедулер.

Разрывать-то разрываю. Но когда у тебя пускается одновременно 10 запросов
каждый из которых выполняется 5 секунд, а параллельно тарахтит ворох
запросов, каждый из которых обрабатывается десятки миллисекунд угадай что
будет от заниженого MaxClients.

> >> и это было близко к оптимуму, то в случае, когда неспешные
> >> коннекшны отрабатывает мультиплексирующий nginx, нам гораздо
> >> интересней снизить scheduling overhead путём понижения
> >> количества процессов, между которыми будет распределяться
> >> процессорное время:
> >> MinSpareServers 1
> >> MaxSpareServers 2
> >> StartServers 3
> >> MaxClients 4
>> Что-то вроде. Правда логику по которой надо рассчитывать
>> оптимум для этих значений я так и не смог продумать.
MS> Я ж писал -- по два активных процесса на CPU core, это довольно
MS> известное правило оптимальной загрузки при наличии I/O (бишь
MS> когда задача не исключительно в CPU и только в него упёрлась).
MS> У меня в парах httpd/mysqld активным можно было считать httpd,
MS> поскольку он отъедал примерно на порядок больше времени.

Ты сначала расскажи что такое "активный процесс" для обычного
web-приложения. Особенно с учетом того что часть запросов тормозиться о
диск, а часть о процессор. И ты заранее не знаешь какой из них к чему
более жручий. А распараллеливать надо исходя ещё и из этого (пока молотят
процессор несколько тредов, можно другими несколькими тредами создавать
проблемы HDD). При том что для _правильной_ дисковой системы (то бишь SCSI
какие) наборот нужно нагружать диск _параллельно_.

MS> Это не дисковое I/O, а shm в php-mmcache ;) (кстати, это только 
MS> мне показалось или и php5-eaccelerator, и php5-xcache в 4.0
MS> скорее прикидываются рабочими?)

Ты не забудь что нормальный кэш все-таки обязан сделать stat() на каждый
php-шник и все его include'ы, чтобы убедиться что он не обновился. Так что
не все так радужно. Вот в случае если у тебя это FastCGI какой
действительно не будет лишнего i/o.

Вполне возможно. xcache какие-то намеки на работоспособность даже делает
:) Но, возможно, это больше намеки чем работоспособность.

> >> Т.е. ограничение количества наиболее активных процессов до
> >> двух на ядро позволило выиграть примерно 10% латентности по
> >> нижней границе и более 50% -- по верхней.
>> А вот это бесспорно. nginx отлично справляется с сериализацией
>> потоков запросов. Собственно на том самом сайте где то
>> установки nginx не справлялось 100 дочек апача, сейчас их
>> трудится несколько штук.
MS> Так я и говорю -- попробуй _ограничить_ этими несколькими штуками.

Дык я-ж говорю -- пробовал. Получается DoS. Помнишь на f.i когда спамили
отдельные странички не грузились (по таймауту резались)? Так вот, в те
времена я на себе это ограничение и прочувствовал. Из-за нескольких
заспамленых страничек f.i ложился целиком и полностью. Потому что
несколько человек обращались к ним, и в результате весь остальной сайт был
попросту недоступен.

У меня есть идея как решить эту проблему, но решать надо не на уровне
апача, а на уровне nginx. Чтобы он держал connections pool с сервером
фиксированого размера, и имел два таких пула -- один общий, а один для
"тормозов". И если попался "тормоз" то переводил соединение в другой пул,
а первый -- освобождал.

Так по крайней мере DoS'а настройками не будет, хотя и исчезнет
возможность защитится от внешнего DoS'а.

>> В теории необходимо их выносить и обслуживать отдельным апачем,
>> и nginx разруливать по разным апачам обращения к разным
>> страницам.
MS> Да-да-да-да-да ;-)  Интересно, что я ещё написал, не прочитав 
MS> уже написанное тобой там, чуть ниже? ;-)

:)

MS> Естественно.  Причём какой-нить редкого ума околовнедренец,
MS> выключивший кэш на одной-единственной посещаемой странице ради
MS> какой-нить своей финтифлюшки, может угробить весь сайт -- 
MS> наблюдался тут не шибко давно один такой случай со стороны.

Кстати в nginx есть ещё одна фича, которую я пока ещё не начал применять
но возможно таки начну -- его встроеный SSI. Совместно с
предгенерированием части контента может быть тоже весьма интересной
штукой.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Папа! А что означает Format C: Complete?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]