Apache процессов в топе больше, чем MaxClients
У нас Apache работает с рабочим MPM, и для MaxClients установлено значение 6, но когда я открываю верх, я вижу более 6 запущенных процессов Apache. 13 видно на скриншоте ниже. Может кто-нибудь объяснить это? Также есть дамп экрана из /server-status/, взятый примерно в то же время. При нашей обычной загрузке, кажется, обрабатывается 2-6 запросов одновременно, поэтому я ожидаю увидеть, что многие процессы apache2 работают в топе. Единственный способ примирить это - предположить, что при максимальной нагрузке работают 3 сервера (ServerLimit 3, 3 процесса apache2), каждый из которых имеет 2 потока (3x2 = 6 процессов apache2), но даже это приведет к максимум 9 процессам apache.,
Apache, по сути, убегает и никогда не освобождает память. Мы обслуживаем около 5-6 запросов в секунду, отслеживаемых с помощью /server-status/, поэтому я решил, что установка MaxRequestsPerChild равной 1000 (у нас было всего 500) заставит процессы перезапускать и освобождать память, но это не так Похоже, что случилось. Мы отслеживаем память процесса Apache через New Relic. Когда мы перезапускаем Apache, он потребляет около 550M памяти с нашей конфигурацией ниже. Каждый процесс в конечном итоге набухает до VIRT: 300 м RES: 80 м, и мы, по-видимому, не можем контролировать количество запущенных процессов, поэтому Apache переходит с 550M - 5G в течение 12-14 часов и истощает нас.
Я проверил каталог /conf.d/, чтобы убедиться, что мы не переопределяем никакие настройки в нашей конфигурации apache. У кого-нибудь есть совет по контролю над Apache? Я знаю, что у нас есть толстое приложение на python, работающее с mod_wsgi, которое, возможно, имеет утечки памяти и, безусловно, может быть оптимизировано, но я просто пытаюсь контролировать количество процессов apache, которые порождаются.
Apache Config:
### Section 1: Global Environment
#
# The directives in this section affect the overall operation of Apache,
# such as the number of concurrent requests it can handle or where it
# can find its configuration files.
#
ServerRoot "/etc/apache2"
ServerName localhost
LockFile ${APACHE_LOCK_DIR}/accept.lock
PidFile ${APACHE_PID_FILE}
Timeout 120
KeepAlive Off
ExtendedStatus On
# worker MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadLimit: ThreadsPerChild can be changed to this maximum value during a
# graceful restart. ThreadLimit can only be changed by stopping
# and starting Apache.
# ThreadsPerChild: constant number of worker threads in each server process
# MaxClients: maximum number of simultaneous client connections
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_worker_module>
StartServers 1
ThreadsPerChild 2
MinSpareThreads 1
MaxSpareThreads 2
MaxClients 6
ServerLimit 3
MaxRequestsPerChild 1000
</IfModule>
# These need to be set in /etc/apache2/envvars
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
AccessFileName .htaccess
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy all
</Files>
DefaultType None
HostnameLookups Off
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
LogFormat "%v:%p %a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%a %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%a %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
# Include module configuration:
Include mods-enabled/*.load
Include mods-enabled/*.conf
# Include ports listing
Include ports.conf
# Include generic snippets of statements
Include conf.d/
Верхний:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24775 www-data 20 0 282m 68m 5160 S 104 0.8 3:04.67 apache2
24782 www-data 20 0 283m 66m 5376 S 57 0.8 3:24.31 apache2
24780 www-data 20 0 280m 65m 4976 S 55 0.8 3:20.74 apache2
24778 www-data 20 0 289m 72m 5540 S 29 0.9 3:09.55 apache2
24773 www-data 20 0 278m 64m 5116 S 26 0.8 2:55.66 apache2
24777 www-data 20 0 282m 65m 4664 S 20 0.8 3:08.39 apache2
13433 memcache 20 0 642m 597m 876 S 16 7.4 11:46.62 memcached
24774 www-data 20 0 288m 71m 4672 S 15 0.9 3:12.58 apache2
24781 www-data 20 0 283m 66m 5160 S 11 0.8 3:16.01 apache2
24779 www-data 20 0 281m 64m 4676 S 8 0.8 3:11.44 apache2
24776 www-data 20 0 284m 74m 4660 S 8 0.9 2:56.38 apache2
27105 www-data 20 0 49520 6180 2636 S 2 0.1 0:00.05 apache2
27100 www-data 20 0 49432 6084 2628 S 1 0.1 0:00.06 apache2
9 root 20 0 0 0 0 S 1 0.0 62:05.25 rcu_sched
27007 www-data 20 0 49568 6292 2684 S 1 0.1 0:00.60 apache2
1 root 20 0 3496 872 428 S 0 0.0 0:04.61 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0 0.0 0
/Статус сервера/
Apache Server Status for www.mysite.com
Server Version: Apache/2.2.22 (Ubuntu) mod_ssl/2.2.22 OpenSSL/1.0.1 mod_wsgi/3.3 Python/2.7.3
Server Built: Feb 13 2012 01:37:45
Current Time: Tuesday, 18-Feb-2014 10:53:01 EST
Restart Time: Tuesday, 18-Feb-2014 10:25:32 EST
Parent Server Generation: 0
Server uptime: 27 minutes 28 seconds
Total accesses: 8248 - Total Traffic: 126.6 MB
CPU Usage: u.36 s.15 cu0 cs0 - .0309% CPU load
5 requests/sec - 78.7 kB/second - 15.7 kB/request
2 requests currently being processed, 0 idle workers
................................................................
................................................................
WW..............................................................
Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process
Srv PID Acc M CPU SS Req Conn Child Slot Client VHost Request
0-0 - 0/0/1569 . 0.02 0 37 0.0 0.00 25.22 67.217.125.252 www.mysite.com GET /imgname.jpg HTTP/1.0
0-0 - 0/0/1502 . 0.03 0 786 0.0 0.00 22.47 65.55.52.119 www.mysite.com GET / HTTP/1.0
1-0 - 0/0/1629 . 0.04 13 260 0.0 0.00 24.85 70.208.67.110 www.mysite.com GET /article/s
1-0 - 0/0/1416 . 0.04 13 469 0.0 0.00 21.42 98.109.237.89 www.mysite.com GET / HTTP/1.0
2-0 27863 0/54/1021 W 0.44 0 0 0.0 0.69 15.95 66.151.5.10 www.mysite.com GET /storm-h
2-0 27863 0/50/1111 W 0.44 0 0 0.0 0.61 16.73 108.88.80.66 www.mysite.com GET /server-status/ HTTP/1.0
ОБНОВИТЬ
Было многошаговое решение этой проблемы.
1) Определите, что процессы mod_wsgi сообщаются top как apache2. Чтобы исправить это, добавьте параметр display-name=my-mod-wsgi-app в конфигурацию WSGIDaemonProcess.
2) Мы обнаружили, что в нашем приложении на python/Django есть какая-то ужасная часть, которая заставляет процесс mod_wsgi раздуваться до 600M. Запуск 5 из них будет потреблять 3G памяти на нашем VPS и будет очень печально.
3) Мы добавили inactivity-timeout=300 и максимум-запросов =200 в нашу конфигурацию WSGIDaemonProcess, и mod_wsgi красиво перезапускает себя, когда процесс не используется или он получает более 500 запросов, что обеспечивает бесперебойную работу нашего избыточного, неаккуратного приложения Django.
Спасибо Грэм за то, что помог мне начать в этом направлении. Вы можете прочитать, как я обсуждаю эту проблему, в группе Google mod_wsgi. https://groups.google.com/forum/
1 ответ
Разбивка процессов:
- Один родительский процесс Apache. Если Apache запускается из системных скриптов init.d, то этот процесс будет выполняться с правами root. Это будет идентификатор родительского процесса всех других процессов.
- Переменное число дочерних рабочих процессов Apache. Точное число зависит от настроек Apache MPM и объема трафика, который получает ваш сайт. Это варьируется, потому что Apache будет динамически контролировать количество дочерних рабочих процессов в зависимости от того, что требуется.
- Фиксированное количество процессов в режиме демона mod_wsgi. Это определяется тем, сколько процессов вы указали в директиве WSGIDaemonProcess.
Если вы используете опцию display-name для WSGIDaemonProcess, то некоторые инструменты, такие как производная от BSD команда "ps" и "htop", будут показывать указанное вами имя, а не "apache2". Таким образом, вы можете определить, какие из них на самом деле являются процессами демона mod_wsgi, выполняющими ваше веб-приложение.
Чтобы сделать вывод о большем, вам нужно показать, какую конфигурацию mod_wsgi вы используете. Прямо сейчас, хотя похоже, что у вас плохая конфигурация даже с настройками MPM, так как работа с таким небольшим числом потоков и предпочтение процессов при использовании Apache worker MPM не имеет большого смысла.
В любом случае, StackOverflow не является форумом и, как следствие, действительно плохое место, чтобы попытаться провести долгое обсуждение, чтобы помочь разобраться в вашей конфигурации. Вам лучше использовать список рассылки mod_wsgi.
Я бы также предложил вам посмотреть / прочитать: