我们刚搬到新的服务器。 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减less到1,000。 似乎已经停止了每个过程的增长，但是我们还有其他的问题。
无论何时，您在pipe理员中保存产品，都会收到500个服务器错误。 该产品可以节省，但是很烦人。
我们从stoneedge magentoimport脚本将不会导入订单，并给我503错误的网关错误。 所以我们不能导入订单。 这个错误是在nginx中的导入脚本
2013/01/31 07:45:30 [error] 15417＃0：* 435945从上游读取响应头时，recv（）失败（104：由对等方重置连接），客户端：173.14.230.102，服务器：www.campsaver。请求：“POST /magento-import.php HTTP / 1.1”，上游：“fastcgi：//127.0.0.1：9000”，主机：“www.campsaver.com”
2013/01/31 23:53:06 [error] 15430＃0：* 1176895从上游读取响应头时，recv（）失败（104：由对等方重置连接），客户端：209.85.238.209，服务器：www.campsaver。请求：“GET /男士服装/男士衬衫？品牌= 254 HTTP / 1.1”，上游：“fastcgi：//127.0.0.1：9000”，主机：“www.campsaver.com”
1月31日23：56：40.551917 [警告] [池www]孩子32011信号退出7 SIGBUS后8332.830655秒从开始1月31日23：56：40.552514 [公告] [池www]孩子935开始1月31日23：56：51.018778 [警告] [池www]子675信号退出7 SIGBUS后从1080.377420秒开始1月31 23：56：51.019400 [注意] [池www]子936开始1月31日23：57：07.588714 [警告] [池www]儿童601从信号7退出SIGBUS从14月1日起开始1456.255594秒1月31日23：57：07.589324 [注意] [pool www]儿童940开始1月31日23：57：51.147662 [警告] [pool www]孩子32037退出信号7 SIGBUS从1月31日开始8302.292151秒23：57：51.148279 [注意] [pool www]子女942开始1月31日23：58：33.067957 [警告] [pool www]子843信号退出7 SIGBUS从430.257647开始后1月31日23：58：33.068582 [注意] [池www]孩子944开始
任何想法我的服务器设置在这里有什么问题？
SIGBUS
SIGBUS信号在发生总线错误时被发送到进程。 导致信号boost的条件例如是不正确的存储器访问对准或不存在的物理地址。
所以这听起来像是你在内存上承诺，PHP正在下降，因为它。
你可以通过查看最后的内核消息来确认
dmesg 或者通过简单地检查你提交的内存，并比较你实际拥有多less内存。
cat /proc/meminfo | grep Committed_AS
你的问题听起来像是源于PHP扩展中的内存泄漏 – 或者仅仅是糟糕的Magento编程 – 后者更可能。
谢天谢地，前者很容易testing。 只要禁用所有 PHP扩展除了Magento所需的最低限度（例如，APC / Source Guardian / Ioncube等）。
后者可以通过仅仅遵循一个标准的Magentodebugging过程来testing。
目前，您只是通过降低最大请求值来掩盖问题。 如果你对Nginx和PHP-FPM没有很好的使用经验，那么不要去喝 Nginx / PHP-FPM是性能的圣杯的Magento kool-aid 。 事实并非如此 。 它清楚地导致你的问题。 我的build议是回到一个更易pipe理的Apache / mod_phpconfiguration， 这将产生相同的性能和更稳定。