Re: [Sysadmins] apache tuning in nginx presence

[Michael Shigorin <mike@osdn.org.ua>]

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/