From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 22 Aug 2007 14:44:25 +0300 From: Michael Shigorin To: sysadmins@lists.altlinux.org Message-ID: <20070822114425.GE28425@osdn.org.ua> Mail-Followup-To: sysadmins@lists.altlinux.org References: <20070820173837.GD26360@osdn.org.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: [Sysadmins] apache tuning in nginx presence X-BeenThere: sysadmins@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: shigorin@gmail.com, ALT Linux sysadmin discuss List-Id: ALT Linux sysadmin discuss List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2007 11:44:30 -0000 Archived-At: List-Archive: 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 ------ Linux.Kiev http://www.linux.kiev.ua/