服务器不应付，CPU负载平均秒杀至33.0

“负载平均数”实际上并不是负载 – 它是处于“运行”或“可运行”状态的线程数。 前面提到的线程可以等待发生的事情 – 例如分页操作或I / O（这将是一个糟糕的performanceI / O通常是一个共享的资源，如果一些线程正在等待它，那么更好的机会，甚至更多join等待队列）。

在运行MySQL服务器的设置中，我看到了类似的数字，因为在较长时间的更新操作期间在常用表上争用锁 。 你可以通过发出SHOW PROCESSLIST命令来检查你的MySQL服务器（PHPMyAdmin甚至把这个function暴露出来）。 这个快捷的解决scheme是在MySQLconfiguration中启用低优先级更新。

你需要得到更详细的指标来查明问题。

我通常审查

• 磁盘io
• 内存使用率
• 交换使用
• networking使用
• 连接/秒在Apache
• 查询/秒在数据库中
• 防火墙问题
• networking堆栈（例如，等待时间，打开连接）

从这里开始，我开始了Apache，MySQL和系统的日志。

最后，转向任何应用程序的具体问题。

一些工具：

• Munin或仙人掌（或其他工具提供详细的统计）
• Sysstat和捆绑工具（iostat，vmstat等）
• Apache中的扩展状态
• 在MySQL中logging缓慢的查询
• caching任何操作码caching，memcache等报告
• http://www.webpagetest.org/用于前端检查
• 对于应用程序问题，我的一些客户已经与New Relic取得了成功

通过一个好的工具包和一个系统的方法，你通常可以开始解决这个问题。

一些有用的testing：

• 访问静态内容（img或css）
• 访问phpinfo或hello世界页面
• 访问一个简单的数据库连接的PHP页面，并closures
• 访问一个数据库连接的PHP页面，select，closures
• 访问一个DB页面连接写和closures
• 访问您的Web应用程序

通过对这些testing中的每一个进行计时，您可以开始解开可能发生延迟的地方。 我看到高负载的服务器很快就会返回静态内容。 第一个字节的时间非常短。 这表明应用层存在问题。 继续在应用程序堆栈中工作，直到find减速为止。

虽然乏味，但这个过程已经让我很好，一旦你习惯了，你可以很快地通过它。

这是否经常发生？ 也就是说，你每天都知道什么时候会发生？

克朗工作在那个时候运行？

哪些进程（top或htop应该显示它）正在运行？

你正在运行什么磁盘子系统？ RAIDtypes？ 控制器的types？ （在不同的频道…？）

服务器负载不仅仅是CPU的使用。 可能是networking过载或驱动系统过载。

您是否正在检查磁盘以查看驱动器上是否存在问题？ 一个可能失败？

你需要缩小究竟发生了什么，如果是数据库窒息，你是否获得了实际的高点击数量到网站，你的stream量是什么样子，在日志中是否有消息，是运行磁盘I / O上的某种重要的批处理作业…？ 任何这些事情都可能导致服务器“负载”上升。 你需要缩小在那个地方的位置，以及在那个地方会发生什么。 如果每次都几乎在同一时间发生，请检查cron时间表以及可能正在服务器上进行清理的任何事情，包括备份或磁盘转储。

如果它与其他东西相关…也许更新一个特定types的新闻故事…检查您的带宽使用情况。 检查您的日志，看看您是否受到某种恶意用户的扫描或探测。

缩放，为急躁或懒惰：

• caching数据库结果（memcached）和静态东西（varnish，nginx）;
• 应用服务（图片，js，css，来自不同的主机）提供独立的资产服务;
• 从应用程序分离DB;
• 在多台服务器上负载平衡应用程序访问

当然，在你像Bart说的那样检查你的服务器之前，你必须这样做，并且确定服务器正在尽其所能。 我的意思是，如果你现在的devise还有改进的空间，那就先做，但即使在这种情况下，caching也会有很大的帮助。