top

top.jpg

• 第一行显示的信息分别为：

  • 目前的时间
  • 开机到目前的时间
  • 已经登录的系统用户数
  • 系统在1,5,15分钟的平均工作负载

• 第二行显示的信息：

  • 目前进程总数，以及各状态的进程数量

• 第三行CPU的整体负载

  • %us
  • %sy
  • %ni
  • %id
  • %wa
  • %hi
  • %si
  • %st

• 第四行物理内存使用量

• 第五行虚拟内存使用量，交换分区

• 在top执行过程中：可以输入以下命令：

  • P 按照CPU使用排序
  • M 按照内存资源使用排序
  • N 按照PID使用排序

• top -d 5 界面更新的秒数

• top -Hp [进程ID] 可以看某个进程的所有线程运行情况

• top -b -n 2 > text 可以将结果写入文件

• top -p [PID] 检测指定进程的资源占用

怎么理解平均负载

平常我们最关心的应该是平均工作负载，那怎么理解这个平均工作负载？

man uptime

System load averages is the average number of processes that are either in a runnable or uninter‐
ruptable state.
A process in a runnable state is either using the CPU or waiting to use the CPU.
A process in uninterruptable state is waiting for some I/O access, eg waiting for disk.
The averages are taken over the three time intervals.
Load averages are not normalized for the number of CPUs in a system, so a load average of 1 means a single CPU system is loaded all the time while on a 4 CPU system it means it was idle 75% of the time.

平均负载是指单位时间内，系统处于 可运行状态 和 不可中断状态 的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。

• 可运行状态的进程，是指正在使用 CPU 或者正在等待 CPU 的进程，也就是我们常用 ps 命令看到的，处于 R 状态（Running 或 Runnable）的进程。

• 不可中断状态的进程 则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，也就是我们在 ps 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。

  比如最常见的是等待硬件设备的 I/O 响应，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。

平均负载多少合适

平均负载最理想的情况是等于 CPU 个数。

# grep 'model name' /proc/cpuinfo | wc -l  # 查看cpu个数
  2

最理想的，就是每个 CPU 上都刚好运行着一个进程，这样每个 CPU 都得到了充分利用。
比如当平均负载为 2 时，意味着什么呢？

• 在只有 2 个 CPU 的系统上，意味着所有的 CPU 都刚好被完全占用。
• 在 4 个 CPU 的系统上，意味着 CPU 有 50% 的空闲。
• 而在只有 1 个 CPU 的系统中，则意味着有一半的进程竞争不到 CPU。

当平均负载高于 CPU 数量 70% 的时候，就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。

1 5 15 3个平均负载反应了什么

三个不同时间间隔的平均值，其实给我们提供了，分析系统负载趋势的数据来源，让我们能更全面、更立体地理解目前的负载状况。

平均负载 和 cpu使用率

平均负载指单位时间内，处于正在使用 CPU 或者正在等待 CPU 的和等待I/O的进程

而 CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。比如：

• CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
• I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
• 大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。

测试

在理解了上面的平均负载后，分别测试不同场景下的表现。
先简单介绍一下 stress 和 sysstat。

• stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。
• sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。下面会用到这个包的两个命令 mpstat 和 pidstat。
  • mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
  • pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

CPU密集型

第一个终端执行：stress --cpu 1 --timeout 600
第二个终端执行：watch -d uptime
第三个终端执行：mpstat -P ALL 5

image.png

从上面可以看出 1 分钟的平均负载会慢慢增加到 1.00，而从终端三中还可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。

那么到底时哪个进程导致了CPU的使用率为100%呢，可以使用pidstat -u 5 1来查询：

image.png

IO密集型

第一个终端执行：stress -i 1 --timeout 600
第二个终端执行：watch -d uptime
第三个终端执行：mpstat -P ALL 5

image.png

那么到底时哪个进程导致了CPU的使用率为100%呢，可以使用pidstat -u 5 1来查询：

大量进程

第一个终端执行：stress -c 4 --timeout 600
第二个终端执行：watch -d uptime

参考资料