From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 20 Aug 2007 20:38:37 +0300 From: Michael Shigorin To: sysadmins@lists.altlinux.org Message-ID: <20070820173837.GD26360@osdn.org.ua> Mail-Followup-To: sysadmins@lists.altlinux.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.1i Subject: [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: Mon, 20 Aug 2007 17:38:38 -0000 Archived-At: List-Archive: Здравствуйте. Тут нарисовались довольно любопытные тенденции по настройке 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 ------ Linux.Kiev http://www.linux.kiev.ua/