我有一对服务器托pipe一个单一的Magento电子商务网站与中等stream量（每天从谷歌分析报告60k的页面浏览量，我认为约80k报告在服务器本身）。 数据库服务器运行平稳而迅速，除了偶尔出现的一个小问题，但是Apache服务器每隔一段时间就会崩溃。
我已经设置了magento来使用推荐的PHPcaching（APC），以及在1.5 gig的tmpfs中保存自己的caching文件（这个tmpfs经常变得非常满，而且当tmpfs是超过80％满）。 我从amazon cloudfront服务大多数图像。 我最近设置了nginx作为apache的反向代理（nginx也提供了静态文件）。 我已经尽我所能configuration了apache – keepalives和hostnamelookups已closures，preforkconfiguration如下：
<IfModule prefork.c> StartServers 50 MinSpareServers 50 MaxSpareServers 100 ServerLimit 512 MaxClients 256 MaxRequestsPerChild 400 </IfModule> 我没有closures.htaccess文件，并打开访问日志logging。 我知道有一些模块可以closures。 如果有的话，我不确定这三个变化会有什么影响。
apache服务器是一个带有6个RAM的VPS。 到编写的时候，服务器报告的load average: 17.77, 18.27, 49.76是load average: 17.77, 18.27, 49.76 ，但是大约有load average: 17.77, 18.27, 49.76 RAM是免费的。 当它真的很糟糕，负载达到120+，并停留在那里 – 重新启动Apache将站点备份和负载回落。
vmstat是（而服务器正在报告上面的负载），我认为，显示一个CPU空闲值在0和70之间波动。 iostat显示0到0.2％之间的iowait值。
我有点卡住了 我所知道的是告诉我，问题在于由于正在运行的代码和用户数量的组合导致CPU过载。 但是我没有足够的经验来确定这是问题所在。 如果这是问题，我认为解决scheme是要么改善代码，要么分割托pipe在两个VPS上的负载平衡器的站点。
所以，我想我的问题是：
编辑：
我发现一些奇怪的 – / var / spool / mail / root很大… 38演出。 这听起来…不健康。 这可能是问题吗？
正如你注意到的那样，Magento和Zend Framework是相当CPU的。 避免CPU负载的最好方法就是简单地渲染任何内容一次，直到它改变。 目录的大部分内容不会经常更改，而且通常只有页面上的购物车块或“最受欢迎的项目”块是唯一dynamic部分。
我build议在Apache之前放置一个Varnishcaching。 这给你高性能的页面caching，可以严重卸载你的LAMP堆栈。 我们最近幸运地在一个网站的公开发布上感谢Varnish，我对速度和低CPU负载印象深刻。 清漆是免费的，并且足够灵活以caching整个页面，或者仅caching相对静态的部分并dynamic地包含购物车。
然而，Varnish在默认的Magento安装上不会caching太多，因为每个用户都有很多的dynamic内容，cookies等等。一个Magento模块，例如“ 由Varnish提供动力的PageCache ”，修改了Magento与Varnish的良好配合。 它还提供了一个与Magento安装相匹配的清漆configuration文件。 这两个在一起做一个非常有效的设置。 这是一个商业模块，但比更强大的服务器更便宜。
卸载到CDN或Nginx的部分不是你真正的问题，虽然它确实有帮助。 即使Apache可以处理相当多的静态请求。 您需要caching需要一次又一次生成的内容，即您的dynamic部分。
我通常将MaxRequestsPerChild设置为成千上万，通常接近10,000。
你说你有“推荐的PHPcaching” – 但是你有没有安装APC？ 最后，您看到有多less用户同时访问该网站。 如果您有Apache扩展统计信息，您将能够看到有多lessApache进程实际上处于“正在运行”状态。
每秒800个APC文件命中，而另外200个用户caching是很多的。 如果这是一个双核或四核，我希望它保持不错，但是。 如果数据库真的在跟上，那么获得更大的机器和更多的CPU可能是最好的select，至less现在是这样。
双核VPS的平均负载过高。 8应该是最大的。
我在使用mod_pagespeed和事件MPM for Magento方面取得了很好的成功。 我build议切换到使用事件MPM，并安装mod_pagespeed。
有关Event MPM的更多信息： Apache事件MPM文档
和mod_pagespeed： Google Code：mod_pagespeed
如果您在进行上述更改后仍然存在负载问题，则可能需要考虑切换到另一个更好的VPS计划。
正如Alister所暗示的，MaxRequestsPerChild的值为400是荒谬的。
平均负载非常高 – 但每天6万页的浏览量并不是很多的stream量。
你通常有多less个进程有服务请求？
我不熟悉Magento，但看起来这个设置有问题。 我希望你可以在更低的负载水平上获得更多的吞吐量。
去拿一本Steve Souders的书并阅读。 为所有传出的HTML内容启用压缩（静态和dynamic）。 并确保你有一个很好的cachingconfiguration。 开始在access_log文件中logging％D，并构build一些分析数据/隔离缓慢的工具。 类似于MySQL。
尝试mysqltuner.pl，看看是否有任何问题。
我运行一个类似的设置，但是用nginx / php-fpm / apc（opcode和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 。
我只在一个testing环境中testing过，到目前为止这么好。
你是否将会话保存在数据库或磁盘上（如果是的话，在tmpfs上）？
当您使用VPS时，您正在共享CPU。 我build议你跟你的主机谈谈，把你的VPS移到一个不太繁忙的硬件上去，或者去专门的。
由于共享的CPU，应用程序无法按时运行，因此无法继续排队等待处理更高的请求以及随之而来的开销。 最终有一个条件，Apache或PHP或MySQL会超出自己的限制，这些问题。
底线是。 VPS基本上是共享CPU。 您的主机可能将太多的VPS帐户放在同一个CPU上。
如果你想充分利用分配的CPU，或者尽可能减lessVPS请求一个更好的服务器（移动主机，尽pipe这很麻烦），或者专用。
你也可以select完全的亚马逊，而不用担心nginx使用他们的负载平衡器，这是几个点击设置为您的云中的所有服务器。
/var/mail…/root文件夹是色调意味着它通常收集来自您的应用程序的很多电子邮件。 例如，一个错误的php脚本正试图发送电子邮件或所有的cron作业被configuration为通过电子邮件发送cron运行状态和输出。 你可以看看里面的邮件，看看有什么文件。 我猜测它的错误信息，所以你可以find它来自哪里。
如果您需要更多的信息，我会添加更多信息，也许我也需要一些信息