web-dev-qa-db-ja.com

Segfault PHP-FPM、Nginx、Freebsd

高負荷でCPU不足が発生しています。それはオンラインユーザーがおよそ1300年から1400年のある時点でのみ起こります（グーグルアナリティクスによると）。ブラウザで空の応答を受信して​​います。

思いがけず不足が発生するのは不思議に思えます。つまり、アイドル状態のCPUが50％を超えていて、突然数秒間0％に低下し、その後ジャンプして戻ります。

これがその瞬間の「iostat1」出力です。最後の列を見てください。 70％が最新の正常な動作です。 http://Pastebin.com/sMjQ0AaJ

キュー内のすべてのPHP-FPMプロセスが停止し、これらのログが/ var/log/messagesに残ります

Feb 25 20:20:01 <kern.info> dasaran kernel: pid 36267 (php-fpm), uid 80: exited on signal 11
Feb 25 20:20:01 <kern.info> dasaran kernel: pid 36265 (php-fpm), uid 80: exited on signal 11
Feb 25 20:20:01 <kern.info> dasaran kernel: pid 36263 (php-fpm), uid 80: exited on signal 11
Feb 25 20:20:01 <kern.info> dasaran kernel: pid 36262 (php-fpm), uid 80: exited on signal 11

Nginxエラーログ

2013/02/25 20:22:14 [error] 34877#0: accept() failed (53: Software caused connection abort)
2013/02/25 20:22:14 [error] 34877#0: accept() failed (53: Software caused connection abort)
2013/02/25 20:22:14 [error] 34877#0: accept() failed (53: Software caused connection abort)
2013/02/25 20:22:14 [error] 34877#0: accept() failed (53: Software caused connection abort)
2013/02/25 20:22:14 [error] 34874#0: accept() failed (53: Software caused connection abort)

私は2つの理由でこの振る舞いを理解していません。

  1. 負荷がCPU不足の原因である場合、CPUアイドルは突然ではなく、直線的に低下するべきではありませんか？しかし、もう1つの事実は、これが負荷時に発生することです。
  2. 0％アイドルが数秒間続くのはなぜですか？

スクリプト、サーバー、データベース（別のサーバー）を最適化してみました。ピークユーザーのわずかな増加のみをもたらしました。

サーバー構成：

FreeBSD 8.3
Intel® Xeon® E3-1245 Quadcore
32 GB ECC RAM

このような問題を引き起こす可能性があるのは何ですか？ボトルネックを見つけるためにどのような戦略を実践する必要がありますか？

[〜＃〜] update [〜＃〜]btとdump_btのgdb出力は次のとおりです。

(gdb) dump_bt executor_globals.current_execute_data
[0x801827a58] getSaveHandler() /www/svn/zend-libs/Toktik/Session/Set.php:42
[0x8018278d0] Toktik_Session_Set::getSaveHandler() /www/svn/zend-libs/Toktik/Session/Set.php:59
[0x801827630] Toktik_Session_Set->add("6j6omknh8tbr28358gadtp40s7") /www/svn/zend-libs/Toktik/Session/SaveHandler/Phpredis.php:146
[0x7fffffffc350] Toktik_Session_SaveHandler_Phpredis->write("6j6omknh8tbr28358gadtp40s7", "Zend_Auth|a:1:{s:7:"storage";s:7:"3963623";}")
(gdb) bt
#0 0x0000000000695cfe in zend_fetch_var_address_helper_SPEC_CONST_VAR (type=0, execute_data=0x801827a58)
at zend_vm_execute.h:4836
#1 0x00000000006961da in ZEND_FETCH_R_SPEC_CONST_VAR_HANDLER (execute_data=0x801827a58)
at zend_vm_execute.h:4863
#2 0x0000000000680a01 in execute (op_array=0x80dc8e2c8) at zend_vm_execute.h:410
#3 0x000000000063101d in zend_call_function (fci=0x7fffffffc640, fci_cache=0x7fffffffc320)
at /usr/ports/lang/php5/work/php-5.4.10/Zend/zend_execute_API.c:958
#4 0x000000000062fe8a in call_user_function_ex (function_table=0x80185e060, object_pp=0x0,
function_name=0x80dc99b78, retval_ptr_ptr=0x7fffffffc6e8, param_count=2, params=0x80dadcab0,
no_separation=1, symbol_table=0x0) at /usr/ports/lang/php5/work/php-5.4.10/Zend/zend_execute_API.c:750
#5 0x000000000062fcbd in call_user_function (function_table=0x80185e060, object_pp=0x0,
function_name=0x80dc99b78, retval_ptr=0x80dae2670, param_count=2, params=0x7fffffffc7a0)
at /usr/ports/lang/php5/work/php-5.4.10/Zend/zend_execute_API.c:723
#6 0x0000000803cc924f in ps_call_handler () from /usr/local/lib/php/20100525-debug/session.so
#7 0x0000000803cc9924 in ps_write_user () from /usr/local/lib/php/20100525-debug/session.so
#8 0x0000000803cbf4a8 in php_session_save_current_state () from /usr/local/lib/php/20100525-debug/session.so
#9 0x0000000803cc3d06 in php_session_flush () from /usr/local/lib/php/20100525-debug/session.so
#10 0x0000000803cc5cd9 in zm_deactivate_session () from /usr/local/lib/php/20100525-debug/session.so
#11 0x000000000064f121 in zend_deactivate_modules () at /usr/ports/lang/php5/work/php-5.4.10/Zend/zend_API.c:2335
#12 0x00000000005b8aea in php_request_shutdown (dummy=0x0)
at /usr/ports/lang/php5/work/php-5.4.10/main/main.c:1759
#13 0x000000000079ec06 in main (argc=1, argv=0x7fffffffed58)
at /usr/ports/lang/php5/work/php-5.4.10/sapi/fpm/fpm/fpm_main.c:1948

Phpredisを使用したセッション管理を担当するクラスは次のとおりです（dump_btはこれらを指します） http://Pastebin.com/kaRNXGCa

http://Pastebin.com/njmmm2CD

phpnginxfreebsdphp-fpm
4
Toktik

申し訳ありませんが、適切な回答ではありませんが、コメントするには少し長すぎます。

スタックが言っていることは、実行エンジンがセッションのシャットダウン中にユーザーのコールバックを妨害したということです。これは、セッションハンドラーToktik_Session_SaveHandler_Phpredis :: writeが146行目で例外をスローしたときです。追加が失敗した理由はわかりませんが、イメージのランダウン中に例外をスローすることはお勧めできません。そう

  • 追加が失敗するのはなぜですか？キューのオーバーフロー/タイムアウトを引き起こす何らかの形式の更新の過負荷がありますか。
  • これを飲み込んで、この1つのセッションを失うことを検討してください。
3
TerryE