- A+
前言
在K8s的Node节点上经常有其他进程和Pod争抢内存资源，导致该Node出现OOM现象，最终导致运行在该Node节点上Pod被OS给Kill掉；
采用监控系统和日志系统对该现象进行监控报警，并通过日志系统收集的日志进行佐证；
一、Top命令
我们平时会部署一些应用到Linux服务器，所以经常需要了解服务器的运行状态；
Top命令是帮助我们了解服务器当前的CPU、内存、进程状态的实用工具；
1.快速入门
(base) [root@docker /]# top top - 09:57:23 up 137 days, 25 min, 2 users, load average: 0.05, 0.03, 0.05 Tasks: 148 total, 1 running, 147 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 32779568 total, 31119584 free, 636676 used, 1023308 buff/cache KiB Swap: 0 total, 0 free, 0 used. 31707740 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8753 root 20 0 822868 47888 8040 S 0.7 0.1 11:52.10 python3.8 1 root 20 0 191028 4040 2604 S 0.0 0.0 0:46.16 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:00.26 kthreadd 4 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H 5 root 20 0 0 0 0 S 0.0 0.0 0:01.76 kworker/u16:0 6 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/0 7 root rt 0 0 0 0 S 0.0 0.0 0:00.06 migration/0 8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh 9 root 20 0 0 0 0 S 0.0 0.0 3:13.03 rcu_sched 10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 lru-add-drain 11 root rt 0 0 0 0 S 0.0 0.0 0:46.57 watchdog/0 12 root rt 0 0 0 0 S 0.0 0.0 0:41.06 watchdog/1 13 root rt 0 0 0 0 S 0.0 0.0 0:00.05 migration/1 14 root 20 0 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd/1 16 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H 17 root rt 0 0 0 0 S 0.0 0.0 0:39.13 watchdog/2 18 root rt 0 0 0 0 S 0.0 0.0 0:00.07 migration/2 19 root 20 0 0 0 0 S 0.0 0.0 0:00.01 ksoftirqd/2 21 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/2:0H 22 root rt 0 0 0 0 S 0.0 0.0 0:40.14 watchdog/3
2.系统状态概览
第一行是对当前Linux系统情况的整体概况；
top - 09:57:23 up 137 days, 25 min, 2 users, load average: 0.05, 0.03, 0.05
top:当前处在Top命令模式，系统时间
up：Linux操作系统运行了多久
users：当前活跃用户
load average：5分钟、10分钟、15分钟之内的CPU负载
2.1.load average
Linux系统中的Load是对当前CPU工作量的度量，简单的说是进程队列的长度。
Load Average 就是一个时间段 (1 分钟、5分钟、15分钟) 内CPU的平均 Load 。
2.2.如何衡量cpu load
假设1台电脑只有1个CPU，所有进程中的运算任务，都必须由这1个CPU来完成。
那么，我们不妨把这个CPU想象成1座单向通行大桥，桥上只有1根车道，所有车辆都必须从这1根车道上通过。
2.2.1.系统负荷为0
意味着大桥上1辆车也没有。
2.2.2.系统负荷为0.5
意味着大桥的一半，被车流占用了。
2.2.3.系统负荷为1.0
意味着大桥的全部，被车流占满了，但是直到此时该大桥还是能顺畅通行的，没有堵车；
2.2.4.系统负荷为1.7
大桥在通车的时候, 不光桥上的车流会影响通车的效率, 后面排队等着还没有上桥的车也增加道路的拥堵,；
如果把等待进入大桥的车，也算到负载中去, 那么Load就会 > 1.0.
例：系统负荷为1.7，意味着车辆太多了，大桥已经被占满了（100%），后面等待上桥的车辆为大桥上车辆的70%。
2.2.5.系统负荷高会造成什么影响？
以此类推，系统负荷2.0，意味着等待上桥的车辆与桥面的车辆一样多；
系统负荷3.0，意味着等待上桥的车辆是桥面车辆的2倍。
总之，当cpu load大于1时，后面的车辆（进程）就必须等待了，系统负荷越大，过桥的时间就越久。
2.3.cpu load和cpu使用率
CPU Load 低 CPU利用率低 ：CPU资源良好，系统运行正常
CPU Load 低 CPU利用率高：确定程序是否有问题，少量进程消耗大量COP计算资源
CPU Load 高 CPU利用率低：程序中IO操作比较多，导致系统出现IO瓶颈；
CPU Load 高 CPU利用率高：CPU资源不足
3.进程状态概览
Tasks: 148 total, 1 running, 147 sleeping, 0 stopped, 0 zombie
Tasks：当前系统中运行的进程总数
Running：当前系统中处在running 状态的进程个数
Sleeping：当前系统中处在sleeping状态的进程个数
Stopped：当前系统中处在Stopped状态的进程个数
Zombie：当前系统中处在Zombie状态的进程个数，子进程比父进程先结束，父进程无法获取到子进程的Exit状态，该进程称为僵尸进程。
4.CPU状态概览
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
CPU分为用户态和内核态
us：CPU在用户态花费的时间 ，应该<60%
sy：CPU在内核态花费的时间，sy+us<80%
id：CPU在空闲状态花费的时间
wa: 进程执行IO操作占用CPU的时间，<30%，不同功能的服务器，阈值不一，邮件服务器的wa很高；
5.内存使用概览
KiB Mem : 32779568 total, 31119584 free, 636676 used, 1023308 buff/cache KiB Swap: 0 total, 0 free, 0 used. 31707740 avail Mem
total：内存空间总和
used：已使用内存空间
free：空闲的内存空间
6.进程详细状态
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8753 root 20 0 822868 47888 8040 S 0.7 0.1 11:52.10 python3.8
PID：进程编号
USER：执行进程的用户
PR（Priority）：进程优先级，由OS决定的；（PR越低越优先被CPU调度），越低越优先
NI（Nice）：进程的Nice值，用户可以设置进程的执行优先权，root（-20到19），普通user 0-19
VIRT(Virtual memory usage )：进程“需要的”虚拟内存大小
RES（Resident Memory Usage）：进程当前使用的内存大小，但不包括swap out
SHR(Shared Memory）：除了自身进程的共享内存，也包括其他进程的共享内存
S（Status）：进程状态D（Dead）R（运行） T（跟踪/停止）Z（僵尸）
%CPU：当前进程占用CPU时间的百分比
%MEM：当前进程占用内存空间的百分比
TIME+：当前进程使用CPU时间的总和
COMMAND：命令行
7.常用快捷键
- shift+e：切换内存单位显示格式 (可重复按键切换）
- z：换是否彩色显示(可复按键换
- m： 切换内存使用率显示格式(可重复按键切换)
- e：切换底部各个进程详细中单位的显示模式 (可重复按键切换)
- b：切换高亮选中 (可重复按键切换)
- W：把当前配置保存到文件中，下次启动top会使用当前的配置
- h：进入帮助菜单(进入菜单后，可按ESC或q退出帮助菜单)
- q：退出 top命令
8.字段排序
top底部的进程列表信息是可以选择指定列进行排序的
- 按f进入字段选择界面
- 按上下键选择要进行排序的字段/ space键选择该字段是否显示
- 按下s键激活这个选择
- 按q键退出排序字段选择界面
