我有一台运行 Redis 的 Ubuntu 服务器，它遇到了高负载问题。
法证学
正常运行时间
# uptime
05:43:53 up 19 min, 1 user, load average: 2.96, 2.07, 1.52
萨尔
# sar -q
05:24:00 AM LINUX RESTART
05:25:01 AM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked
05:35:04 AM 0 116 3.41 2.27 1.20 4
Average: 0 116 3.41 2.27 1.20 4
顶部
CPU 利用率低htop得令人尴尬：
顶部
网络统计
34 个开放redis-server连接：
$ sudo netstat -natp | grep redis-server | wc -l
34
自由的
$ free -g
total used free shared buffers cached
Mem: 14 6 8 0 0 2
-/+ buffers/cache: 4 10
Swap: 0 0 0
我如何知道哪些进程导致高负载，等待进入状态Running？连接数是否过多？
答案1
由于 iowait 较高，您会看到意外的平均负载。顶部部分中的 98.7wa表明了这一点。从你的屏幕截图中我看到 kworker 进程也处于不间断睡眠状态（top 内的 D 状态），当进程等待磁盘 I/O 完成时会发生这种情况。
vmstat让您可以了解运行队列。vmstat 1以典型方式执行sar每秒更新一次。
r 列显示内核用来计算 loadavg 的可运行/正在运行的进程，b 列显示阻塞等待磁盘 I/O 的进程，也称为不间断睡眠。 b 中的进程被添加到 loadavg 计算中，这就是 iowait 导致神秘 loadavg 的原因。
因此，要回答如何查看哪些进程导致高负载平均的问题，在 iowait 的情况下，请使用top/ps查找处于 D 状态的进程，然后从那里进行故障排除。
答案2
Linux 与大多数（如果不是全部）类似 Unix 的操作系统不同，它不仅对使用 CPU 的进程进行计数或在运行队列中等待 CPU 作为其负载计算的参考，而且还添加正在运行的进程（实际上是线程）的数量。不间断状态，即等待磁盘或网络 I/O 完成。后者实际上是空闲的，即不使用CPU。
那么可能就不用担心您的（不那么）高负载了。您正在寻找的进程可能是单线程redis加瞬态内核线程。