Segfault PHP-FPM,Nginx,Freebsd

我们正在经历高负荷的CPU短缺。 它只发生在网上用户在1300-1400左右(根据谷歌分析)。 我们在浏览器中收到空响应。

短缺意外地发生在我看来很奇怪。 我的意思是 – 有50%以上的空闲CPU,突然下降到0%几秒钟,然后跳回来。

这是当时的“iostat 1”输出。 看最后一栏。 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) 

我不明白这个行为有两个原因。

  1. 如果负载导致CPU短缺,CPU空闲不应该线性下降,不是突然的? 但另一个事实是,这是在负载情况下发生的。
  2. 为什么0%的空闲时间会持续几秒?

我们尝试优化脚本,服务器和数据库(单独的服务器)。 高峰用户仅略有增加。

服务器configuration:

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

什么会导致这样的问题? 我应该采取什么策略来find瓶颈?

更新这里是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负责会话pipe理的类(dump_bt指向这些) http://pastebin.com/kaRNXGCa

http://pastebin.com/njmmm2CD

对不起,没有一个正确的答案,但有点太长的评论。

堆栈说的是执行引擎在会话closures期间在用户callback上禁止。 这是当你的会话处理程序Toktik_Session_SaveHandler_Phpredis ::写在第146行抛出一个exception。我不知道为什么添加失败,但在图像损坏期间抛出exception是一个坏主意。 所以

  • 为什么添加失败? 你有某种forms的更新超载导致队列溢出/超时。
  • 考虑只是吞咽这个,放松这一个会议;