☰

php-fpm、nginx magento store。即将停止

tag-icon • tag-icon nginx php-fpm magento alternative-php-cache
php-fpm、nginx magento store。即将停止

我们刚刚搬到了一台新服务器。2 x 专用服务器，48 GB 内存，php-fpm，nginx，memcached，APC。我们遇到一个问题，即生成的每个 php-fpm 进程都变得越来越大。重新启动 php-fpm 显示每个进程占用 30-100 MB。几个小时后，它们超过 250MB。8 小时后，每个生成的 php-fpm 进程占用 1.1GB 或更多。服务器不堪重负。我不得不每小时重新启动 php-fpm。为了暂时缓解这种情况，我们将 pm.max_requests 从 10,000 减少到 1,000。这似乎阻止了每个进程的增长，但我们还有其他问题。

  1. 每次在管理员中保存产品时，我们都会收到 500 服务器错误。产品可以保存，但这很烦人。

  2. 我们从 stoneedge 导入 magento 的脚本无法导入订单，并给出 503 Bad Gateway Error。所以我们无法导入订单。此错误出现在导入脚本的 nginx 中

2013/01/31 07:45:30 [错误] 15417#0：*435945 recv() 失败（104：对等方重置连接）从上游读取响应标头时，客户端：173.14.230.102，服务器：www.campsaver.com，请求：“POST /magento-import.php HTTP/1.1”，上游：“fastcgi://127.0.0.1:9000”，主机：“www.campsaver.com”

  1. 这个错误在 nginx 错误日志中也随处可见。每隔几分钟就会出现一次。

2013/01/31 23:53:06 [错误] 15430#0：*1176895 recv() 失败（104：对等方重置连接），同时从上游读取响应标头，客户端：209.85.238.209，服务器：www.campsaver.com，请求：“GET /mens-clothing/men-s-shirts?brand=254 HTTP/1.1”，上游：“fastcgi://127.0.0.1:9000”，主机：“www.campsaver.com”

  1. 这些错误遍布我的 php-fpm 错误日志

1 月 31 日 23：56：40.551917 [警告] [pool www] 子进程 32011 在启动后经过 8332.830655 秒后，因信号 7 SIGBUS 而退出 1 月 31 日 23：56：40.552514 [通知] [pool www] 子进程 935 于 1 月 31 日 23：56：51.018778 开始 [警告] [pool www] 子进程 675 在启动后经过 1080.377420 秒后，因信号 7 SIGBUS 而退出 1 月 31 日 23：56：51.019400 [通知] [pool www] 子进程 936 于 1 月 31 日 23：57：07.588714 开始 [警告] [pool www] 子进程 601 在启动后经过 1456.255594 秒后，因信号 7 SIGBUS 而退出 1 月23：57：07.589324 [注意] [pool www] 子进程 940 于 1 月 31 日启动 23：57：51.147662 [警告] [pool www] 子进程 32037 在启动后经过 8302.292151 秒后，因信号 7 SIGBUS 而退出 1 月 31 日 23：57：51.148279 [注意] [pool www] 子进程 942 于 1 月 31 日启动 23：58：33.067957 [警告] [pool www] 子进程 843 在启动后经过 430.257647 秒后，因信号 7 SIGBUS 而退出 1 月 31 日 23：58：33.068582 [注意] [pool www] 子进程 944 于

您知道我的服务器设置有什么问题吗？

答案1

信号总线
当进程发生总线错误时，会向其发送 SIGBUS 信号。导致信号发出的条件包括内存访问对齐不正确或物理地址不存在。

因此，这听起来就像是您在内存上投入了过多，并且 PHP 也因此而崩溃了。

您可以通过查看最后的内核消息来确认

dmesg

或者简单地检查你的已提交内存 - 并将其与你已使用的内存量进行比较实际上有可用。

cat /proc/meminfo | grep Committed_AS

您的问题听起来像是源于 PHP 扩展中的内存泄漏 - 或者仅仅是糟糕的 Magento 编程 -后者的可能性更大。

值得庆幸的是，前者很容易测试。只需禁用全部除了 Magento 所需的最低限度之外的 PHP 扩展（例如 APC/Source Guardian/Ioncube 等）。

后者只需遵循标准即可进行测试Magento 调试过程。

目前，您只是通过降低最大请求值来掩盖问题。如果您对 Nginx 和 PHP-FPM 没有丰富的经验 - 请不要费心饮用Magento kool-aidNginx/PHP-FPM 是性能的圣杯。不是。这显然给你带来了问题。我的建议是回到更易于管理的 Apache/mod_php 配置，这将产生相同的性能并更加稳定。

相关内容