From: "Denis Smirnov" <mithraen@freesource.info> To: shigorin@gmail.com, sysadmins@lists.altlinux.org Subject: Re: [Sysadmins] apache tuning in nginx presence Date: Wed, 22 Aug 2007 15:16:24 +0400 Message-ID: <b6fe84cf0708220416ha5d0628m327eefe227649b5e@mail.gmail.com> (raw) In-Reply-To: <20070820173837.GD26360@osdn.org.ua> 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
next prev parent reply other threads:[~2007-08-22 11:16 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-08-20 17:38 Michael Shigorin 2007-08-21 5:55 ` Slava Dubrovskiy 2007-08-21 7:55 ` Michael Shigorin 2007-08-22 11:16 ` Denis Smirnov [this message] 2007-08-22 11:44 ` Michael Shigorin 2007-09-01 20:34 ` Денис Смирнов 2007-09-01 20:51 ` Michael Shigorin 2007-09-11 14:12 ` Денис Смирнов
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=b6fe84cf0708220416ha5d0628m327eefe227649b5e@mail.gmail.com \ --to=mithraen@freesource.info \ --cc=shigorin@gmail.com \ --cc=sysadmins@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux sysadmins discussion This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/sysadmins/0 sysadmins/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 sysadmins sysadmins/ http://lore.altlinux.org/sysadmins \ sysadmins@lists.altlinux.org sysadmins@lists.altlinux.ru sysadmins@lists.altlinux.com public-inbox-index sysadmins Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.sysadmins AGPL code for this site: git clone https://public-inbox.org/public-inbox.git