我有一台运行 Ubuntu 的 Rackspace 云服务器，具有 2GB 内存，用作应用程序服务器（html 和 php 文件从该服务器加载，mysql 数据库位于同一数据中心的另一台服务器上）。
当我的 webapp 的用户数量增加（每天 10,000+）时，负载会上升到 1.00，有时甚至达到 2.00。这在逻辑上是合理的，但我找不到瓶颈所在。使用“top”命令，我发现 CPU 使用率几乎一直接近 1%，并且它只使用了 2 GB 内存总量中的大约 500 MB（几乎全部用于 apache 进程）。我还安装了 munin，看来这些数字对于一整天来说大致准确（两个统计数据都没有出现大幅飙升）。
如果问题不是 CPU 或内存，那么我应该监控和/或优化什么来应对更大的流量？（我不知道该改进什么，因为我不知道负载的原因！）
谢谢！如果您需要有关我的服务器设置的任何其他信息，请告诉我。
答案1
“负载”不仅仅来自于 CPU 利用率。它还指等待资源的进程数。
您需要做的第一件事是确定这是否会对您服务的应用程序产生影响。负载低于您拥有的 CPU 数量通常被认为是好的。
当你看到这个时，top 对你的 iowait 有什么看法？显示
了什么free -m？
您可能还想看看 iostat。
答案2
在 Linux 调度程序中，进程可以处于几种状态之一。较新的内核有一些奇特的状态，但基本状态如下（来自include/linux/sched.h）：
#define TASK_RUNNING 0
#define TASK_INTERRUPTIBLE 1
#define TASK_UNINTERRUPTIBLE 2
#define TASK_STOPPED 4
第一个应该是显而易见的；最后一个是实际已停止的任务。可中断状态适用于正在休眠的任务。不可中断任务通常正在等待系统资源——如磁盘或其他 IO。
大概是因为不可中断的任务通常预计很快就会被安排，所以它们被算作在运行队列中。
/proc/loadavg您在（以及在和其他工具中）看到的 loadavg 数字top只是该运行队列（等待调度的进程）在 1、5 和 15 分钟间隔内的平均大小。如果您实际上有很多进程处于 TASK_RUNNING 状态，那么 loadavg 就会增加，但卡在 TASK_UNINTERRUPTIBLE 状态的进程也会增加 loadavg。（事实上，根据我的经验，这是通常导致负载数字过高的罪魁祸首。
因此，如果您看到高负载但 CPU 使用率不高，则需要查找 io。iotop这是一个方便的工具。但这需要内核 2.6.20。在较旧的系统上，或者只是为了换一种视角，iostat（来自sysstat包）和vmstat（来自procps）可以显示一些一般统计数据。或者，如果您使用的是 NFS，卡住的进程实际上可能只做了很少的实际 io，但仍然被卡住了。（Yay NFS。）
如果您没有看到任何这些，则虚拟机基础设施中可能出现了问题。
答案3
监控磁盘 I/O 操作以及磁盘 I/O 操作的大小。
这会告诉你
- 瓶颈在哪里（例如每秒有多少个读取 I/O 操作，或者有几个非常大的写入），它会告诉你
- 您应该进行哪些更改来提高性能（例如，更改为 RAID10 阵列，或切换到 SSD）。
我不确定您对环境中的磁盘配置有何控制，但这似乎是您的瓶颈。