我在专用服务器上运行带有MPM prefork的Apache 2.2.21。 更多细节:
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
stream量通常在10-30个请求/秒之间,有12GB的RAM,我们已经相当保守地调整了MaxClients(250)。 我们确实看到各种原因使用的峰值(在一个旧的服务器上,我们在这些峰值期间几次打我们的MaxClients)。
无论如何,这是一个新的服务器。 运行一段时间后,我们的Apache状态开始如下所示:
GGG_._._RC_.G..C.G_G.C_G..C_.CG_._._G__W____..R.WCR_.W..G_......
G的(“优雅地完成”)正在卡住。 如果我重新启动Apache,它们只会消失。 这肯定会导致我们在没有定期监控/修复的情况下达到我们的MaxClients限制。 我在互联网上阅读,似乎有一个类似于这个Apache的错误,但发生在不同的条件下。 它在2.2.14版中也显然是固定的。
我包含了一个挂起的过程的堆栈跟踪您的检查。
#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 ()
它看起来像我们的PHP脚本closuresmysqli连接时发生的问题。 试图释放内存时有一个挂起。 任何有类似configuration的人 – Apache 2.2.21,PHP 5.3.6,MySQL / mysqli(5.1.56) – 有类似的问题?
任何人都知道我可以尝试解决这个问题? 升级MySQL / Apache / PHP? 如果有帮助,我很乐意提供更多信息。
谢谢!
更新:似乎MySQL并没有真正涉及到这个问题。 这是另一个只包含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 ()
更新2:原来这是一些系统已知的问题。
http://docs.cpanel.net/twiki/bin/view/EasyApache3/EA3KnownIssues#Bug:%20Apache%202.2%20Child%20Processes
我注意到,我也正在获得“C”状态Apache进程相当长的一段时间(> 3000秒)。 我已经写了一个cron来杀死长时间处于“G”或“C”状态的进程…但这是一个创可贴。 我想解决这个问题。
我注意到的一件事,也改变了我的configuration,我没有设置“GracefulShutdownTimeout”指令:
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#gracefulshutdowntimeout
我添加了这个,并将其更改为30秒。 我们会看看这是否也有帮助。
更多信息:以下是“G”进程之一的cat / proc / PROCESS_ID / status的输出:
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
在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)
在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
尝试设置Keepalive Off 。 我倾向于自动执行此操作,特别是在IO争用系统(如虚拟机)上。
我工作的一些一般准则,对不起,如果这不是你的立即可行的:
mod_<language> mod_fcgid 如果您不修改应用程序中的HTTP标头或类似内容,则可以在不更改任何代码的情况下切换到fcgi。
你从中获得的是在这个设置中发挥作用的各种元素的更加清洁的分离。 对于第三方模块造成的任何错误(性能,但也是安全方面), httpd将会更加强大。