This is a Canonical Question about selecting the right Apache httpd MPM.
I'm a little confused between the different MPMs offered by Apache - 'worker', 'event', 'prefork', etc.
What are the major differences between them, and how can I decide which one will be best for a given deployment?
I'm running Apache 2.2.21 with the MPM prefork on a dedicated server. More details:
Server Version: Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/1.0.0-fips DAV/2 SVN/1.7.0 mod_python/3.3.1 Python/2.6.5 mod_bwlimited/1.4 PHP/5.3.6
Traffic is usually somewhere between 10-30 requests/sec, there's 12GB of RAM, and we've tuned MaxClients fairly conservatively (250). We do see spikes of usage for various reasons (on an older server, we hit our MaxClients of 100 several times during these spikes).
Anyways, this is a new server. After running for a while, our Apache status starts to look something like this:
GGG_._._RC_.G..C.G_G.C_G..C_.CG_._._G__W____..R.WCR_.W..G_......
The G's ("Gracefully finishing") are getting stuck. They only disappear if I restart Apache. This will definitely cause us to hit our MaxClients limit without regular monitoring/fixing. I read around on the internet and there seems to be a bug in Apache that is similar to this, but happens under different conditions. It was also apparently fixed in version 2.2.14.
I'm included the stacktrace of a hung process for your inspection.
#0 0x000000350c6f119e in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x000000350c67c138 in _L_lock_9164 () from /lib64/libc.so.6
#2 0x000000350c679a32 in malloc () from /lib64/libc.so.6
#3 0x000000350c66fcfb in __libc_message () from /lib64/libc.so.6
#4 0x000000350c675676 in malloc_printerr () from /lib64/libc.so.6
#5 0x000000350c675aa1 in malloc_consolidate () from /lib64/libc.so.6
#6 0x000000350c677f38 in _int_free () from /lib64/libc.so.6
#7 0x0000003906c64cbb in my_once_free () at my_once.c:117
#8 0x0000003906c5d6ff in my_end (infoflag=0) at my_init.c:170
#9 0x0000003906c5c547 in mysql_server_end () at libmysql.c:209
#10 0x00007f34ac195be8 in zm_shutdown_mysqli (type=<value optimized out>, module_number=22)
at /home/cpeasyapache/src/php-5.3.6/ext/mysqli/mysqli.c:834
#11 0x00007f34ac2b825f in module_destructor (module=0x1eafce0) at /home/cpeasyapache/src/php-5.3.6/Zend/zend_API.c:2098
#12 0x00007f34ac2be945 in zend_hash_apply_deleter (ht=0x7f34ac988aa0, p=0x1eafc80) at /home/cpeasyapache/src/php-5.3.6/Zend/zend_hash.c:614
#13 0x00007f34ac2bebd8 in zend_hash_graceful_reverse_destroy (ht=0x7f34ac988aa0) at /home/cpeasyapache/src/php-5.3.6/Zend/zend_hash.c:649
#14 0x00007f34ac2b3085 in zend_shutdown () at /home/cpeasyapache/src/php-5.3.6/Zend/zend.c:759
#15 0x00007f34ac26017a in php_module_shutdown () at /home/cpeasyapache/src/php-5.3.6/main/main.c:2146
#16 0x00007f34ac260229 in php_module_shutdown_wrapper (sapi_globals=<value optimized out>)
at /home/cpeasyapache/src/php-5.3.6/main/main.c:2118
#17 0x00007f34ac33a461 in php_apache_child_shutdown (tmp=<value optimized out>)
at /home/cpeasyapache/src/php-5.3.6/sapi/apache2handler/sapi_apache2.c:399
#18 0x00007f34ae59dea4 in run_cleanups () from /usr/local/apache/lib/libapr-1.so.0
#19 0x00007f34ae59cd72 in apr_pool_destroy () from /usr/local/apache/lib/libapr-1.so.0
#20 0x00000000004cc004 in clean_child_exit ()
#21 0x00000000004ccd00 in child_main ()
#22 0x00000000004cce62 in make_child ()
#23 0x00000000004cd107 in perform_idle_server_maintenance ()
#24 0x00000000004cd664 in ap_mpm_run ()
#25 0x000000000042e24f in main ()
It looks like the problem happens when our PHP script closes the mysqli connection. There's a hang when attempting to free memory. Anyone with a similar configuration - Apache 2.2.21, PHP 5.3.6, MySQL/mysqli (5.1.56) - having similar issues?
Anyone know what I can attempt to do to fix this? Upgrade MySQL/Apache/PHP? I'm happy to provide more information if it helps.
Thanks!
UPDATE: Seems like MySQL isn't really involved in the problem. Here's another stacktrace of a hanging process that only includes PHP:
#0 0x000000350c6f119e in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x000000350c67c138 in _L_lock_9164 () from /lib64/libc.so.6
#2 0x000000350c679a32 in malloc () from /lib64/libc.so.6
#3 0x000000350c66fcfb in __libc_message () from /lib64/libc.so.6
#4 0x000000350c675676 in malloc_printerr () from /lib64/libc.so.6
#5 0x000000350c675aa1 in malloc_consolidate () from /lib64/libc.so.6
#6 0x000000350c677f38 in _int_free () from /lib64/libc.so.6
#7 0x00007f532accb951 in zend_mm_shutdown (heap=0x2327aa0, full_shutdown=1, silent=<value optimized out>) at /home/cpeasyapache/src/php-5.3.6/Zend/zend_alloc.c:1648
#8 0x00007f532ac951af in php_module_shutdown () at /home/cpeasyapache/src/php-5.3.6/main/main.c:2159
#9 0x00007f532ac95229 in php_module_shutdown_wrapper (sapi_globals=<value optimized out>) at /home/cpeasyapache/src/php-5.3.6/main/main.c:2118
#10 0x00007f532ad6f461 in php_apache_child_shutdown (tmp=<value optimized out>) at /home/cpeasyapache/src/php-5.3.6/sapi/apache2handler/sapi_apache2.c:399
#11 0x00007f532cfd2ea4 in run_cleanups () from /usr/local/apache/lib/libapr-1.so.0
#12 0x00007f532cfd1d72 in apr_pool_destroy () from /usr/local/apache/lib/libapr-1.so.0
#13 0x00000000004cc004 in clean_child_exit ()
#14 0x00000000004ccd00 in child_main ()
#15 0x00000000004cce62 in make_child ()
#16 0x00000000004cd107 in perform_idle_server_maintenance ()
#17 0x00000000004cd664 in ap_mpm_run ()
#18 0x000000000042e24f in main ()
UPDATE 2: Turns out this is a known problem for some systems.
I've noticed I'm also getting "C" status Apache processes hanging around for quite some time (>3000 seconds). I've written a cron to kill processes hanging in either "G" or "C" status for a long time... but that's a band-aid. I'd like to fix the problem.
One thing I noticed, and also changed, about my configuration was that I wasn't setting thie "GracefulShutdownTimeout" directive:
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#gracefulshutdowntimeout
I added this and changed it to 30 seconds. We'll see if that also helps.
More Info: Here's the output of cat /proc/PROCESS_ID/status for one of the "G" processes:
Name: httpd
State: S (sleeping)
Tgid: 14867
Pid: 14867
PPid: 30017
TracerPid: 0
Uid: 99 99 99 99
Gid: 99 99 99 99
Utrace: 0
FDSize: 64
Groups: 99
VmPeak: 355752 kB
VmSize: 222996 kB
VmLck: 0 kB
VmHWM: 191120 kB
VmRSS: 77928 kB
VmData: 62300 kB
VmStk: 96 kB
VmExe: 1032 kB
VmLib: 24736 kB
VmPTE: 488 kB
VmSwap: 0 kB
Threads: 1
SigQ: 0/95107
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 000000018c0046eb
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: ffffff
Cpus_allowed_list: 0-23
Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003
Mems_allowed_list: 0-1
voluntary_ctxt_switches: 24708
nonvoluntary_ctxt_switches: 2651
Loaded Modules in Apache:
core_module (static)
authn_file_module (static)
authn_default_module (static)
authz_host_module (static)
authz_groupfile_module (static)
authz_user_module (static)
authz_default_module (static)
auth_basic_module (static)
include_module (static)
filter_module (static)
log_config_module (static)
logio_module (static)
mime_magic_module (static)
expires_module (static)
setenvif_module (static)
ssl_module (static)
mpm_prefork_module (static)
http_module (static)
mime_module (static)
dav_module (static)
status_module (static)
autoindex_module (static)
info_module (static)
suexec_module (static)
cgi_module (static)
dav_fs_module (static)
dav_lock_module (static)
negotiation_module (static)
dir_module (static)
actions_module (static)
userdir_module (static)
alias_module (static)
rewrite_module (static)
so_module (static)
python_module (shared)
dav_svn_module (shared)
authz_svn_module (shared)
bwlimited_module (shared)
php5_module (shared)
Loaded Modules in PHP:
[PHP Modules]
bcmath
Core
ctype
curl
date
dom
eAccelerator
ereg
exif
filter
gd
gettext
hash
iconv
imap
json
libxml
mbstring
mcrypt
memcache
mysql
mysqli
openssl
pcre
PDO
pdo_mysql
pdo_sqlite
posix
Reflection
session
SimpleXML
sockets
SPL
SQLite
sqlite3
standard
tokenizer
xml
xmlreader
xmlwriter
zlib
[Zend Modules]
eAccelerator
I'm running CentOS 64 bit, and just found out I am running prefork MPM on my dual quad Xeon. I was told worker will give me lower memory usage and higher performance, since I run a very high traffic website.
If this is true, how do I do it?
I currently have an Apache2 server running with mpm-prefork and mod_php on a OpenVZ VPS with 512M real / 1024M burstable RAM (no swap). After running some tests, I found that the maximum process size Apache gets is 23M, so I've set MaxClients to 25 (23M x 25 = 575 MB, ok for me). I decided to run some load tests on my server, and the results left me puzzled.
I'm using ab on my desktop machine requesting the main page from a wordpress blog.
When I run ab with 24 concurrent connections, everything seems fine. Sure, CPU goes up, free RAM goes down, and the result is about 2-3s response time per request.
But if I run ab with 25 concurrent connections (my server limit), Apache just hangs after a couple of seconds. It starts processing the requests, then it stops responding, CPU goes back to 100% idle and ab times out. Apache log says it reached MaxClients.
When this happens, Apache keeps itself locked up with 25 running processes (they're all in "W" if I check server status) and only after the TimeOut setting the processes start to die and the server starts responding again (in my case it's set to 45).
My question: is that expected behaviour? Why Apache just dies when it reaches MaxClients? If it works with 24 connections, shouldn't it work with 25, just taking maybe more time to respond each request and queueing up the rest?
It sounds kinda strange to me that any kid running ab can alone kill a webserver just by setting the concurrent connections to the servers MaxClients.
Based on the descriptions for both the Prefork and Worker MPM, it seems the prefork type is somewhat outdated, but I can't really find a proper comparison of the two types.
What i'd like to know: