web-dev-qa-db-ja.com

Apacheでハングしたプロセス？

専用サーバーでMPMプリフォークを使用してApache2.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

トラフィックは通常、1秒あたり10〜30リクエストの間で、12 GBのRAMがあり、MaxClientsをかなり控えめに調整しました（250）。さまざまな理由で使用量の急増が見られます（古いサーバーでは、これらの急増中にMaxClientsが100に数回ヒットしました）。

とにかく、これは新しいサーバーです。しばらく実行すると、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スクリプトがmysqli接続を閉じると、問題が発生するようです。メモリを解放しようとするとハングします。同様の構成を持つ人-Apache 2.2.21、PHP 5.3.6、MySQL/mysqli（5.1.56）-同様の問題がありますか？

誰かがこれを修正するために私が何をしようと試みることができるか知っていますか？ MySQL/Apache/PHPをアップグレードしますか？お役に立てれば、さらに詳しい情報を提供させていただきます。

ありがとう！

UPDATE：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 ()

UPDATE 2：これは一部のシステムの既知の問題であることが判明しました。

http://docs.cpanel.net/twiki/bin/view/EasyApache3/EA3KnownIssues#Bug:%20Apache%202.2%20Child%20Processes

また、「C」ステータスのApacheプロセスがかなりの時間（> 3000秒）ぶらぶらしていることに気づきました。私は長い間「G」または「C」ステータスのいずれかにぶら下がっているプロセスを強制終了するためのcronを作成しました...しかしそれはバンドエイドです。問題を解決したいのですが。

私が自分の構成について気づき、また変更したことの1つは、「GracefulShutdownTimeout」ディレクティブを設定していなかったことです。

http://httpd.Apache.org/docs/2.2/mod/mpm_common.html#gracefulshutdowntimeout

これを追加して30秒に変更しました。それも役立つかどうかを確認します。

詳細情報：「G」プロセスの1つに対する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
apache-2.2mysqlphpmpm-prefork
6
thexfactor

Keepalive Offを設定してみてください。特に仮想マシンのようなIO競合システムでは、これを自動的に行う傾向があります。

1
Tom O'Connor

私が取り組んでいるいくつかの一般的なガイドライン、これがあなたにとってすぐに実行可能でない場合は申し訳ありません：

  • worker MPMを使用します
  • mod_<language>を避けてください
  • 代わりに、fcgiインターフェイスPHPを使用し、Pythonなどが提供します
  • mod_fcgidを使用します

アプリケーションでHTTPヘッダーなどを変更していない場合は、コードを変更せずにfcgiに切り替えることができる場合があります。

これによって得られるのは、このセットアップで機能するさまざまな要素をはるかに明確に分離することです。 httpdは、サードパーティのモジュールが引き起こすバグ（パフォーマンスだけでなくセキュリティ面でも）に対してはるかに堅牢になります。

1
al.