我有一台运行Ubuntu的Rackspace云服务器，2GB内存被用作应用服务器（HTML和PHP文件从该服务器加载，而mysql数据库在同一数据中心的另一台服务器上）。
当我的webapp的用户数量增加（10,000 + /天），负载上升到1.00，有时2.00。 这在逻辑上是合理的，但我无法find瓶颈来自哪里。 使用“top”命令，我发现几乎所有的时间CPU使用率都接近1％，并且只占用2GB内存总量的大约500MB（几乎全部用于Apache进程）。 我还安装了munin，看起来这些数字大致精确到一整天（统计数据没有大的峰值）。
如果问题不是CPU或内存问题，那么我应该监视和/或优化哪些内容以应对更大的stream量？ （我不知道该怎么改进，因为我不知道负载的原因！）
谢谢！ 请让我知道如果您需要任何其他信息关于我的服务器设置。
“加载”不仅仅来自CPU利用率。 这是等待资源的进程的数量。
你需要做的第一件事就是弄清楚这是否对你所提供的应用程序有任何影响。 一个小于你的CPU数量的负载通常被认为是好的。
当你看到这个顶部对你的iowait说什么？
free -m显示什么？
你也可以看看iostat。
进程可以在Linux调度器中的几个状态之一。 较新的内核有一些花哨的，但基本（从include/linux/sched.h ）：
#define TASK_RUNNING 0 #define TASK_INTERRUPTIBLE 1 #define TASK_UNINTERRUPTIBLE 2 #define TASK_STOPPED 4
首先应该是显而易见的; 最后是已经停止的任务。 可中断状态用于正在睡觉的任务。 不间断任务通常在系统资源上等待 – 像磁盘或其他IO。
据推测，由于不可中断的任务通常预计会很快安排，因此他们被视为在运行队列中。
您在/proc/loadavg （以及top工具和其他工具）中看到的loadavg数字只是该运行队列的平均大小 – 即等待调度的进程 – 超过1分钟，5分钟和15分钟的时间间隔。 如果你在TASK_RUNNING中实际上有很多进程，那么会导致loadavg，但TASK_UNINTERRUPTIBLE中的进程也会这样做。 （事实上，以我的经验来看，这通常是背负高负荷数字背后的罪魁祸首。）
所以，如果你看到高负载没有太多的CPU使用率，你想寻找io。 iotop是一个方便的工具。 不过，这需要内核2.6.20。 在较旧的系统上，或者仅仅用于替代视图， iostat （来自sysstat包）和vmstat （来自procps ）可以显示一些常规统计信息。 或者，如果你使用的是NFS，一个卡住的进程可能实际上只是做了很less的真正的io，但仍然卡住了。 （Yay NFS。）
如果您没有看到这些，虚拟机基础架构中可能会出现问题。
监视磁盘I / O操作和磁盘I / O操作的大小。
这会告诉你
我不确定你的环境中的磁盘configuration有什么控制，但看起来这是你的瓶颈。