[Sysadmins] apache tuning in nginx presence

[Sysadmins] apache tuning in nginx presence

[Michael Shigorin]

	Здравствуйте.
Тут нарисовались довольно любопытные тенденции по настройке 
apache-1.3 в качестве бэкенда за nginx.

Если традиционно предлагается[1] поднимать в заметной мере
параметры, отвечающие за количество свободных серверов,
то в случае приёма соединений nginx этот подход, похоже,
менее полезен и может быть вредным (увеличивается scheduling
overhead).

Например, если до внедрения nginx были задействованы такие
параметры:

MinSpareServers 5
MaxSpareServers 20
StartServers 12
MaxClients 12

и это было близко к оптимуму, то в случае, когда неспешные
коннекшны отрабатывает мультиплексирующий nginx, нам гораздо
интересней снизить scheduling overhead путём понижения количества
процессов, между которыми будет распределяться процессорное время:

MinSpareServers 1
MaxSpareServers 2
StartServers 3
MaxClients 4

На двухъядерной однопроцессорной системе (HP ML150 G3,
один Xeon 5140, 2G FBDIMM) под Linux 2.6.18 (Server 4.0)
и скедулере имени OpenVZ (который "двухэтажный" -- сперва
контейнеры, потом задачи в них) исключительно такое изменение
конфигурации только apache привело к изменению результатов
/usr/sbin/ab -n 100 -c 20 (сто запросов в двадцать потоков)
по страничке с форумом:

Time per request:       5505.80 -> 4478.60 [ms] (mean)
Requests per second:    3.63 -> 4.47 [#/sec] (mean)
Time per request:       275.29 -> 223.93 [ms] (mean, across all concurrent requests)

Percentage of the requests served within a certain time (ms)
  50%   4785 -> 4285
  66%   5825 -> 4472
  75%   6879 -> 4610
  80%   7076 -> 4681
  90%   8408 -> 4826
  95%   9112 -> 5005
  98%   9587 -> 5071
  99%   9656 -> 5136
 100%  11491 -> 5276 (last request)

При этом MySQL настроен по соотносящейся части так[2]:

thread_cache = 8
thread_concurrency = 2

Настройка ставила своей целью наличие не менее двух потенциально
конкурентных процессов на одно процессорное ядро согласно общей
практике расчёта оптимальной загрузки системы, но при этом
в отличие от обычных рекомендаций -- была направлена на разумную
минимизацию количества конкурирующих экземпляров httpd, которые
в данной постановке задачи занимаются почти исключительно работой
с веб-приложением, а не дисковым или сетевым I/O и таким образом
конкурируют практически исключительно за CPU и RAM.

Т.е. ограничение количества наиболее активных процессов до двух
на ядро позволило выиграть примерно 10% латентности по нижней
границе и более 50% -- по верхней.

Нагрузка выглядит как две пары httpd:mysql с распределением
потребления процессора примерно как 10:1 на каждое ядро;
уменьшение MaxClients до двух с тем, чтобы ещё снизить
конкуренцию, принесло ~10% уменьшение верхней границы (100%),
но при этом примерно на ту же величину подняло нижнюю границу.

Проварьировав связку с "1-2-3-4", получилось, что при количестве
одновременных подключений 4/20/40/100 среднее время на запрос
особенно не изменяется (скорость остаётся около 4.50/сек).
Последнее замерялось как -n 500 -c 100.

Если эти результаты окажутся полезными -- буду рад включить ещё
несколько комментариев в штатный httpd.conf нашего apache-1.3.x.

PS: народ в Bcc:, надеюсь, не обидится, что поленился форвардить :)

PPS: ещё надеюсь, что не открыл америку через Форточку :)

[1] http://people.redhat.com/alikins/system_tuning.html
[2] http://fly.osdn.org.ua/~mike/docs/mysql-tuning.txt

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] apache tuning in nginx presence

[Slava Dubrovskiy]

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

Michael Shigorin пишет:
> Тут нарисовались довольно любопытные тенденции по настройке 
> apache-1.3 в качестве бэкенда за nginx.
>   
Вот еще бы такое потестировать и для apache-2 ...
> Если эти результаты окажутся полезными -- буду рад включить ещё
> несколько комментариев в штатный httpd.conf нашего apache-1.3.x.
>   
Да, полезно очень. Спасибо.

-- 
WBR,
Dubrovskiy Vyacheslav


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3249 bytes --]

Re: [Sysadmins] apache tuning in nginx presence

[Michael Shigorin]

On Tue, Aug 21, 2007 at 08:55:09AM +0300, Slava Dubrovskiy wrote:
> > Тут нарисовались довольно любопытные тенденции по настройке
> > apache-1.3 в качестве бэкенда за nginx.
> Вот еще бы такое потестировать и для apache-2 ...

Потестируй ;-)  Я его сейчас не применяю.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] apache tuning in nginx presence

[Denis Smirnov]

20.08.07, Michael Shigorin<mike@osdn.org.ua> написал(а):

> Если традиционно предлагается[1] поднимать в заметной мере
> параметры, отвечающие за количество свободных серверов,
> то в случае приёма соединений nginx этот подход, похоже,
> менее полезен и может быть вредным (увеличивается scheduling
> overhead).

Именно так. Есть одно принципиальное исключение -- надо учитывать
latency. То есть если по каким-то причинам время выдачи одним апачем
ответа существенно большое на отдельных страницах, то количество
бэкендов приходится увеличивать.


> MinSpareServers 5
> MaxSpareServers 20
> StartServers 12
> MaxClients 12

Везет... мне StartServer 50 надо было делать, а MaxClients 100 на
одном их хостов не хватало... А когда я их увеличил оказалось что надо
поднимать и в MySQL лимиты.

> и это было близко к оптимуму, то в случае, когда неспешные
> коннекшны отрабатывает мультиплексирующий nginx, нам гораздо
> интересней снизить scheduling overhead путём понижения количества
> процессов, между которыми будет распределяться процессорное время:
> MinSpareServers 1
> MaxSpareServers 2
> StartServers 3
> MaxClients 4

Что-то вроде. Правда логику по которой надо рассчитывать оптимум для
этих значений я так и не смог продумать.

> Time per request:       5505.80 -> 4478.60 [ms] (mean)

А что так дофига?

> Requests per second:    3.63 -> 4.47 [#/sec] (mean)
> Time per request:       275.29 -> 223.93 [ms] (mean, across all concurrent requests)
>
> Percentage of the requests served within a certain time (ms)
>   50%   4785 -> 4285
>   66%   5825 -> 4472
>   75%   6879 -> 4610
>   80%   7076 -> 4681
>   90%   8408 -> 4826
>   95%   9112 -> 5005
>   98%   9587 -> 5071

Я правильно понимаю, что это 5 секунд на ответ? И что только 50%
успевают получить ответ за 4 секунды?

>   99%   9656 -> 5136
>  100%  11491 -> 5276 (last request)
>
> При этом MySQL настроен по соотносящейся части так[2]:
>
> thread_cache = 8
> thread_concurrency = 2
>
> Настройка ставила своей целью наличие не менее двух потенциально
> конкурентных процессов на одно процессорное ядро согласно общей
> практике расчёта оптимальной загрузки системы,

Тут есть тонкость -- не все процессы хотят проц, многие хотят всего
лишь диск. Особенно касаемо MySQL. Именно поэтому я пока остановился
на логике "4 треда на ядро".

> но при этом
> в отличие от обычных рекомендаций -- была направлена на разумную
> минимизацию количества конкурирующих экземпляров httpd, которые
> в данной постановке задачи занимаются почти исключительно работой
> с веб-приложением, а не дисковым или сетевым I/O и таким образом
> конкурируют практически исключительно за CPU и RAM.

Дисковым I/O они не будут заниматься исключительно когда ты сделаешь
все на FastCGI каком. А пока у тебя на один запрос минимум:
а) прочитать код скрипта;
б) попытаться прочитать .htaccess (если он не отключен);
в) попытаться прочитать .htacces во всей иерархии каталогов до текущего;
г) намусорить в лог;

Далее, если используется PHP, то мы ещё обычно грузим все include'ы (а
если не грузим потому как умные и юзаем кэши, то тогда как минимум
stat на все include'ы по всей цепочке).

> Т.е. ограничение количества наиболее активных процессов до двух
> на ядро позволило выиграть примерно 10% латентности по нижней
> границе и более 50% -- по верхней.

А вот это бесспорно. nginx отлично справляется с сериализацией потоков
запросов. Собственно на том самом сайте где то установки nginx не
справлялось 100 дочек апача, сейчас их трудится несколько штук.

> Нагрузка выглядит как две пары httpd:mysql с распределением
> потребления процессора примерно как 10:1 на каждое ядро;
> уменьшение MaxClients до двух с тем, чтобы ещё снизить
> конкуренцию, принесло ~10% уменьшение верхней границы (100%),
> но при этом примерно на ту же величину подняло нижнюю границу.

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

В теории необходимо их выносить и обслуживать отдельным апачем, и
nginx разруливать по разным апачам обращения к разным страницам.

> PPS: ещё надеюсь, что не открыл америку через Форточку :)

Вообще знание этих фактов позволяет заточить конфиги под один
конкретный сайт чтобы он летал со скоростью света. А вот придумать
более-менее универсальную схему крайне сложно. Мало того, я осмелюсь
утверждать что это практически невозможно.

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

> [1] http://people.redhat.com/alikins/system_tuning.html
> [2] http://fly.osdn.org.ua/~mike/docs/mysql-tuning.txt

Re: [Sysadmins] apache tuning in nginx presence

[Michael Shigorin]

On Wed, Aug 22, 2007 at 03:16:24PM +0400, Denis Smirnov wrote:
> То есть если по каким-то причинам время выдачи одним апачем
> ответа существенно большое на отдельных страницах, то
> количество бэкендов приходится увеличивать.

Угу, но это скорее anti-DoS уже получается.

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

Это у тебя так долго барахлишко тарахтело?

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

> > и это было близко к оптимуму, то в случае, когда неспешные
> > коннекшны отрабатывает мультиплексирующий nginx, нам гораздо
> > интересней снизить scheduling overhead путём понижения
> > количества процессов, между которыми будет распределяться
> > процессорное время:
> > MinSpareServers 1
> > MaxSpareServers 2
> > StartServers 3
> > MaxClients 4
> Что-то вроде. Правда логику по которой надо рассчитывать
> оптимум для этих значений я так и не смог продумать.

Я ж писал -- по два активных процесса на CPU core, это довольно
известное правило оптимальной загрузки при наличии I/O (бишь
когда задача не исключительно в CPU и только в него упёрлась).

У меня в парах httpd/mysqld активным можно было считать httpd,
поскольку он отъедал примерно на порядок больше времени.

> > Time per request:       5505.80 -> 4478.60 [ms] (mean)
> А что так дофига?

Дели на 20 и учитывай, что это один двуствольный Xeon -- они 
для веба по всем тестам оптеронам проигрывают, как sr@ припомнил
аж на прошлой неделе. (если докинуть второй процессор, то
коэффициент масштабирования для dualcore ~0.78 на linpack,
для quad core xeon -- ~0.74 или около того)

> > Time per request:       275.29 -> 223.93 [ms] (mean, across all concurrent requests)

Это поделенное.

> > Percentage of the requests served within a certain time (ms)
> >   50%   4785 -> 4285
> Я правильно понимаю, что это 5 секунд на ответ? И что только
> 50% успевают получить ответ за 4 секунды?

На двадцать ;-)  За четыре с лишним, но поскольку обслуживаются
они в моём варианте ограничений более последовательно -- то кто
первый пришёл, тот более-менее первым и уйдёт.  Т.е. вися в
очереди, они не пытаются отгрызть свой кусочек процессора,
пока он не доступен в разумной мере (это когда накладные на
распределение не сопоставимы с распределяемым ресурсом).

Вместо двадцати запросов, которые попытаются считаться ~5 сек
ближе к одновременно, получается четыре, которые меньше чем за
полсекунды выплёвываются, потом следующие четыре, etc.

> > При этом MySQL настроен по соотносящейся части так[2]:
> > thread_cache = 8
> > thread_concurrency = 2
> > Настройка ставила своей целью наличие не менее двух
> > потенциально конкурентных процессов на одно процессорное ядро
> > согласно общей практике расчёта оптимальной загрузки системы,
> Тут есть тонкость -- не все процессы хотят проц, многие хотят
> всего лишь диск. Особенно касаемо MySQL. Именно поэтому я пока
> остановился на логике "4 треда на ядро".

Так у меня и получается 2*httpd+2*mysqld на ядро.
Опускание до 1* тоже описано, как и предполагалось -- хуже.

> > но при этом в отличие от обычных рекомендаций -- была
> > направлена на разумную минимизацию количества конкурирующих
> > экземпляров httpd, которые в данной постановке задачи
> > занимаются почти исключительно работой с веб-приложением,
> > а не дисковым или сетевым I/O и таким образом конкурируют
> > практически исключительно за CPU и RAM.
> Дисковым I/O они не будут заниматься исключительно когда ты
> сделаешь все на FastCGI каком. А пока у тебя на один запрос
> минимум:
> а) прочитать код скрипта;

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

> б) попытаться прочитать .htaccess (если он не отключен);
> в) попытаться прочитать .htacces во всей иерархии каталогов до текущего;

Это всё из дискового кэша.  Поскольку я люблю noatime для таких
разделов, да и вообще почти по умолчанию.

> г) намусорить в лог;

Вот это запись.

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

Так я и говорю -- попробуй _ограничить_ этими несколькими штуками.

> > Нагрузка выглядит как две пары httpd:mysql с распределением
> > потребления процессора примерно как 10:1 на каждое ядро;
> > уменьшение MaxClients до двух с тем, чтобы ещё снизить
> > конкуренцию, принесло ~10% уменьшение верхней границы (100%),
> > но при этом примерно на ту же величину подняло нижнюю границу.
> Ты ещё обрати внимание на то, что на сайте обычно находятся
> страницы которые исполняются сильно разное количество времени.
> И вот они могут здорово тормозить всех остальных.

Ессно.  Это было на стенде, хотя после переехало и в реальную
жисть на старый одномоторный P4 с IDE и DDR266.  На глаз ему
тоже несколько полегчало -- при том, что в отличие от стенда
там роботы топчутся и порой люди ходят.

> В теории необходимо их выносить и обслуживать отдельным апачем,
> и nginx разруливать по разным апачам обращения к разным
> страницам.

Да-да-да-да-да ;-)  Интересно, что я ещё написал, не прочитав 
уже написанное тобой там, чуть ниже? ;-)

> > PPS: ещё надеюсь, что не открыл америку через Форточку :)
> Вообще знание этих фактов позволяет заточить конфиги под один
> конкретный сайт чтобы он летал со скоростью света. А вот
> придумать более-менее универсальную схему крайне сложно. Мало
> того, я осмелюсь утверждать что это практически невозможно.

Ну я и не брался это утверждать.

> Я как-то развлекался с идеей спроектировать особо шустрый хостинг для
> особо сложных проектов. Так вот все закончилось на том, что либо с
> самого начала проектирования сайта в процессе участвует головастый
> товарищ, который каждые две секунды пинает всех по поводу того как
> правильно писать код с точки зрения производительности, либо можно
> слегка (в разы) поднять производительность силами грамотного админа
> (который попытается порезать сайт на подсайты, натравить несколько
> апачей на один и тот же сайт, разрулить между ними обращения со
> стороны nginx, а дальше непрерывно мониторить и крутить настройки).

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

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] apache tuning in nginx presence

[Денис Смирнов]

[-- 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 --]

Re: [Sysadmins] apache tuning in nginx presence

[Michael Shigorin]

On Sun, Sep 02, 2007 at 12:34:58AM +0400, Денис Смирнов wrote:
> >> То есть если по каким-то причинам время выдачи одним апачем
> >> ответа существенно большое на отдельных страницах, то
> >> количество бэкендов приходится увеличивать.
> MS> Угу, но это скорее anti-DoS уже получается.
> Если у тебя есть страницы которые по каким-то причинам могут
> сильно тормозить -- то они сами по себе DoS. Соответственно для
> хостинга, где запросто какой-нибудь умник таки может склепать
> подобную страницу, подобная настройка сама по себе DoS. Увы :(

Ага, только в этом случае DoS ещё контролируемый, а если у тебя
двадцать бэкендов жуют один процессор, то поди ещё доберись их
отстрелить... (даже если ты monit)

Бишь между полным DoS'ом, когда приходится звонить-бутать,
и частичным я всё-таки выберу второе.  Ну и за прошешдую 
неделю ни разу не жалел.

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

IMHO это VPS и ССЗБ.

> >> Что-то вроде. Правда логику по которой надо рассчитывать
> >> оптимум для этих значений я так и не смог продумать.
> MS> Я ж писал -- по два активных процесса на CPU core, это довольно
> MS> известное правило оптимальной загрузки при наличии I/O (бишь
> MS> когда задача не исключительно в CPU и только в него упёрлась).
> MS> У меня в парах httpd/mysqld активным можно было считать httpd,
> MS> поскольку он отъедал примерно на порядок больше времени.
> Ты сначала расскажи что такое "активный процесс" для обычного
> web-приложения.

Здесь это выглядело как libhttpd.ep+mysqld.

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

Я ж не спорю, и для более другого тазика выставил бы более другие
циферки.  Специально же описал железо и соображения.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] apache tuning in nginx presence

[Денис Смирнов]

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

On Sat, Sep 01, 2007 at 11:51:04PM +0300, Michael Shigorin wrote:

MS> Ага, только в этом случае DoS ещё контролируемый, а если у тебя
MS> двадцать бэкендов жуют один процессор, то поди ещё доберись их
MS> отстрелить... (даже если ты monit)
MS> Бишь между полным DoS'ом, когда приходится звонить-бутать,
MS> и частичным я всё-таки выберу второе.  Ну и за прошешдую 
MS> неделю ни разу не жалел.

Вопрос в том, сколько именно backend'ов делать. Если у тебя DoS каждый
день будет, то увы и ах -- никого это не устроит.

Глянь в код SeirosWiki, если разберешься как оно работает будешь очень
громко материться. Так вот ответственно заявляю -- это поделие _нельзя_
таким образом защищать. Иначе убиваться будет.

Собственно один из периодов когда меня все материли за постоянные gateway
timeout были потому как я попробовал такое сделать.

> MS>> Это у тебя так долго барахлишко тарахтело?
>> Там автор поделия на PHP шибко умный. Это ещё оно быстро
>> работало, после того как я грязно матерясь смотрел на особо
>> долгие запросы и ручками создавал индексы.
MS> IMHO это VPS и ССЗБ.

Так и сделано. А проку-то там -- в этом VPS все равно пара десятков апачей
крутятся. А если они у меня не будут крутиться -- клиент уйдет к тому, у
кого они крутиться будут :(

> >>> Что-то вроде. Правда логику по которой надо рассчитывать
> >>> оптимум для этих значений я так и не смог продумать.
> MS>> Я ж писал -- по два активных процесса на CPU core, это довольно
> MS>> известное правило оптимальной загрузки при наличии I/O (бишь
> MS>> когда задача не исключительно в CPU и только в него упёрлась).
> MS>> У меня в парах httpd/mysqld активным можно было считать httpd,
> MS>> поскольку он отъедал примерно на порядок больше времени.
>> Ты сначала расскажи что такое "активный процесс" для обычного
>> web-приложения.
MS> Здесь это выглядело как libhttpd.ep+mysqld.

У меня mysqld обычно процессорного времени жрет мало, а вот работает
долго. Диски :(

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

Я для архива комментирую возможные грабли такого решения, которые могут
оказаться неочевидными для тех, кто на них не напарывался.

В любом случае есть очень важная вещь -- конфиги у разных сервисов могут и
должны быть сильно разными.

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

http://freesource.info
----------------------------------------------------------------------------
[...] python22-devel тоже provides python-devel, и он лексикографически
круче.
		-- ldv in devel@

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