为什么PHP偶尔挂在session_start()上

Wil*_*lem 7 php session magento

注意:这不是欺骗PHP session_start()导致HTTP请求挂起(以及SO上的其他类似命名的问题),因为我的挂起是偶然的,而不是永久性的.

使用Ubuntu 12.04, Magento,PHP-FPM (5.4)而默认的PHP会话处理程序(与EXT4文件).

顺便说一句,(once per month)所有PHP进程都挂起session_start()(根据fpm-slow.log):

[24-Sep-2014 11:03:04]  [pool www] pid 24259
script_filename = /data/web/public/index.php
[0x00007f00b4ec6480] session_start() /data/web/public/includes/src/__default.php:7687
[0x00007f00b4ec6130] start() /data/web/public/includes/src/__default.php:7730
[0x00007f00b4ec5fb8] init() /data/web/public/includes/src/__default.php:8086
[0x00007f00b4ec5e30] init() /data/web/public/includes/src/__default.php:33902
[0x00007f00b4ec5bd0] __construct() /data/web/public/includes/src/__default.php:23841
[0x00007f00b4ec5ae8] getModelInstance() /data/web/public/app/Mage.php:463
[0x00007f00b4ec59c8] getModel() /data/web/public/app/Mage.php:477
[0x00007f00b4ec49a0] getSingleton() /data/web/public/includes/src/__default.php:14044
[0x00007f00b4ec4848] preDispatch() /data/web/public/includes/src/Mage_Adminhtml_Controller_Action.php:160
[0x00007f00b4ec3b00] preDispatch() /data/web/public/includes/src/__default.php:13958
[0x00007f00b4ec26e0] dispatch() /data/web/public/includes/src/__default.php:18331
[0x00007f00b4ec20c0] match() /data/web/public/includes/src/__default.php:17865
[0x00007f00b4ec1a98] dispatch() /data/web/public/includes/src/__default.php:20465
[0x00007f00b4ec1908] run() /data/web/public/app/Mage.php:684
[0x00007f00b4ec17f8] run() /data/web/public/index.php:87
Run Code Online (Sandbox Code Playgroud)

Lsof说:

COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
php5-fpm 24259  app   10uW  REG  202,1    82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6
php5-fpm 24262  app   10u   REG  202,1    82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6
php5-fpm 24351  app   10u   REG  202,1    82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6
php5-fpm 24357  app   10u   REG  202,1    82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6
php5-fpm 24358  app   10u   REG  202,1    82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6
php5-fpm 25563  app   10u   REG  202,1    82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6
php5-fpm 25564  app   10u   REG  202,1    82492 1220594 /data/web/public/var/session/sess_gr2clur9icgd7s2j9linag7ue6
Run Code Online (Sandbox Code Playgroud)

根据strace,所有这些进程都在等待flock (LOCK_EX),即使是在上面的lsof输出中具有W标志的那个.

此事件期间的CPU使用率接近0.

那么为什么第一个session_start挂起,即使它似乎已经获得了会话文件的写锁定?我怎么能进一步调试呢?

这是一个名为" 带有ajax和php会话的竞争条件 "的讨论.事实上,触发上述问题的请求是一致的AJAX调用.但是,本文指出:

如果您使用了PHP的内置默认会话处理(使用文件),您将永远不会遇到问题.

所以目前我不知道接下来要去哪看.

uni*_*iah -1

在你的 Ajax 调用中,我猜测在该文件中你有 session_start 并且你的 ubuntu php 中的 /tmp 目录中的某个位置正在保存其会话。为了解决您的问题,您需要对这些脚本运行负载测试,数据库也可能是您肉眼无法看到的因素。

尝试这样的事情:http://smartbear.com/products/qa-tools/load-testing-tool/ajax-load-testing/作为试用,也许您可​​以找到问题的根源。您还需要更深入地研究与此相关的会话,包括那些使用 ajax 调用的单个文件。

您应该针对问题发生时可以运行的后端调用设置某种类型的性能测试。这些层是 PHP、PHP-FPM、Magento、我猜是 MySQL、Ubuntu、网络连接和 Apache?