如何防止Apache跌落？

我有两台服务器托管着一个流量适中的Magento电子商务网站（每天从Google Analytics（分析）报告的浏览量为60k，我认为服务器本身报告的浏览量为80k）。除了罕见的偶发嘶哑之外，数据库服务器还可以平稳，快速地运行，但是apache服务器经常崩溃。

我已经设置了magento以使用推荐的PHP缓存（APC），以及将其自己的缓存文件保存在1.5 gig tmpfs中（此tmpfs通常会变得很满，当tmpfs为超过80％的容量）。我为Amazon Cloudfront提供大多数图像。我最近将nginx设置为apache的反向代理（nginx也提供静态文件）。我已尽力配置apache-keepalive和hostnamelookups已关闭，并且prefork的配置如下：

<IfModule prefork.c>
    StartServers      50
    MinSpareServers   50
    MaxSpareServers  100
    ServerLimit  512
    MaxClients   256
    MaxRequestsPerChild 400
</IfModule>

我尚未关闭.htaccess文件，并且访问日志记录已打开。我知道有些模块可以关闭。我不确定这三个更改中的任何一个将产生什么影响（如果有）。

apache服务器是具有6 gig RAM的VPS。截至撰写本文时，服务器正在报告load average: 17.77, 18.27, 49.76，但大约有2 GB的可用RAM。如果情况真的很糟，负载将达到120+并保持在该水平-重新启动apache会使站点恢复正常，负载也会下降。

vmstat是（当服务器报告上述负载时），我认为这表明CPU空闲值在0到70左右之间波动。iostat显示的iowait值介于0到0.2％之间。

我有点卡住了。我所知道的很少是告诉我的问题是，由于正在运行的代码和用户数量的结合，导致CPU过载。但是我经验不足，无法确定这就是问题所在。如果这是问题所在，我认为解决方案将是改进代码或使用负载均衡器将站点托管在两个VPS上。

所以，我想我的问题是：

1. 我还能做些什么来发现服务器上的问题或瓶颈？
2. 我可以对服务器配置进行任何明显的更改以改善这一点吗？
3. 设置自动化系统以在负载超过一定水平时重新启动apache是​​一个好主意吗？
4. 从上面可以看出，该站点超出服务器的可能性有多大？

编辑：

我发现有些奇怪的东西-/ var / spool / mail / root很大... 38演出。听起来不健康。这可能是问题吗？

正如您所注意到的，Magento和Zend Framework占用大量CPU。避免CPU负载的最好方法就是简单地将任何内容渲染一次，直到内容改变为止。目录的大多数部分不会经常更改，通常只有页面上的购物车块或“最受欢迎商品”块是唯一动态的部分。

我建议将Varnish缓存放在Apache的前面。这为您提供了高性能的页面缓存，可以大大减轻LAMP堆栈的负担。感谢Varnish，我们最近在一个非常公开的网站发布中幸存下来，而速度和低CPU负荷给我留下了深刻的印象。Varnish是免费的，并且足够灵活以缓存整个页面，或仅缓存相对静态的部分并动态包含购物车。

但是，由于有很多基于用户的动态内容，cookie等，因此Varnish在默认的Magento安装中不会缓存太多内容。Magento模块（例如由Varnish提供支持的PageCache修改了Magento使其可以与Varnish很好地配合使用）。它还提供了与Magento设置匹配的Varnish配置文件。这两个一起使设置非常有效。这是一个商业模块，但是比功能更强大的服务器便宜得多。

卸载到CDN或Nginx的零件不是真正的问题，尽管确实有帮助。甚至Apache也可以处理很多静态请求。您需要缓存需要一次又一次地生成的内容，即动态部分。

我通常将MaxRequestsPerChild设置为成千上万-通常接近10,000。

您说您拥有“推荐的PHP缓存”-但是您是否已安装APC？最后，您看到有多少用户同时访问该网站。如果您具有Apache扩展的统计信息，则可以一次查看实际上有多少个Apache进程处于“运行中”状态。

每秒命中800个APC文件，另外还有200个用户缓存。如果这是双核或四核，我希望它可以保持正常运行。如果数据库确实保持正常运行，那么最好至少现在拥有一台更大的计算机和更多的CPU，这可能是最好的选择。

对于双核VPS，您的平均负载完全太高了。最大值为8。

我对Magento使用mod_pagespeed和事件MPM取得了成功。我建议切换到使用事件MPM，并安装mod_pagespeed。

有关事件MPM的更多信息：Apache事件MPM文档

和mod_pagespeed：Google代码：mod_pagespeed

即使进行了上述更改后，如果仍然遇到负载问题，则可能需要考虑切换到其他更好的VPS计划。

正如Alister所暗示的，MaxRequestsPerChild值为400实在是太低了。

平均负载非常高-但是每天60k的页面访问量并不多。

您通常有几个处理服务请求？

我不熟悉Magento，但此设置似乎有问题。我希望您在较低的负载水平下可以获得明显更高的吞吐量。

去拿一本史蒂夫·苏德斯（Steve Souders）的书，然后阅读。对所有传出的HTML内容（静态和动态）启用压缩。并确保您具有良好的缓存配置。开始在您的access_log文件中记录％D，并构建一些工具来分析数据/隔离慢度。与MySQL类似。

试试mysqltuner.pl，看看它是否标记了任何问题。

我运行了类似的设置，但是使用了nginx / php-fpm / apc（操作码和fast_backend / memcached（slow_backend））。我发现php是最大的资源问题，可能是因为magento要么很大，要么编码很差。看看究竟是什么在消耗资源，是否像我这样是php？

除了Martijn Heemels撰写的内容之外，您还可以尝试使用开源清漆模块。查看http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/和https://github.com/madalinoprea/magneto-varnish。
我只在测试环境中对其进行了测试，到目前为止，效果很好。

您是否将会话保存在数据库中或磁盘上（如果这样，则保存在tmpfs上）？

使用VPS时，您正在共享CPU。我建议您与主机交谈，以将VPS转移到不太繁忙的硬件或专用。

由于使用了共享的CPU，因此您的应用程序无法按时运行，并且无法排队，从而导致要处理的更高请求以及随之而来的开销。最终，有一种情况会导致Apache或php或mysql超出其自身的限制，从而导致问题。

底线是。VPS基本上是共享的CPU。您的主机可能在同一CPU上放置了太多VPS帐户。

如果您想充分利用分配的CPU，则可能的话，要求使用VPS更少的更好的服务器（尽管麻烦，但要移走主机）或专用。

您也可以完全选择Amazon，而不必担心使用其负载平衡器的nginx，只需单击几下即可为您的云中的所有服务器进行设置。

/var/mail.../root文件夹是hue，表示它收集了大量通常来自您的应用程序的电子邮件。例如，一个越野车php脚本正在尝试发送电子邮件，或者所有cron作业都配置为向您发送cron运行状态和输出的电子邮件。您可以查看邮件内部，查看文件的内容。我猜它的错误消息，以便您可以找到它的来源。

如果您需要更多信息，我会添加更多信息，也许我也需要一些信息