Linux CPU、Memory、IO、Network 分析

Linux性能监控 - CPU、Memory、IO、Network

CPU

CPU 查看这些重要参数: 中断、上下文切换、可运行队列、CPU 利用率来监测性能。

每个参数的健康区间:

CPU利用率: User Time <= 70%，System Time <= 35%，User Time + System Time <= 70%。
上下文切换: 与CPU利用率相关联，如果CPU利用率状态良好，大量的上下文切换也是可以接受的。
可运行队列: 每个处理器的可运行队列 <=3 个线程。如双处理器系统的可运行队列里不应该超过6个线程。

运用到的工具有Linux vmstat命令详解、Linux top命令详解、Linux mpstat-显示各个可用CPU的状态

top 查看 CPU 利用率，如果 User Time 比较高，使用 show-busy-java-threads 工具排查，其会从所有运行的Java进程中找出最消耗CPU的线程（缺省5个），打印出其线程栈。Linux 系统 CPU 过高异常排查

如果 System Time 比 User Time 高，以及高频度的上下文切换（cs），说明应用程序进行了大量的系统调用。

vmstat 输出例子

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0 361396 196772  55820 359372    0    0    13    21    1    1  2  0 98  0  0
 1  0 361392 196524  55820 359616    8    0   236     0  411  527  1  0 90  9  0
 2  1 361392 196524  55828 359608    0    0     0    48  370  503  1  1 98  0  0
 4  0 361392 196524  55828 359616    0    0     0     0  442  559  1  0 99  0  0

需要关注的参数

r: 当前运行队列中线程的数目，代表线程处于可运行状态，但CPU还未能执行
b: 等待IO的进程数量；如果该值一直都很大，说明IO比较繁忙，处理较慢
in: 每秒中断数
cs: 每秒上下文切换数
us: 用户占用CPU的百分比
sys: 内核占用CPU的百分比
id: CPU 完全空闲的百分比

Memory

分析 vmstat 输出

si: 每秒从交换区写到内存的大小
so: 每秒写入交换区的内存大小

内存够用的时候，这2个值都是0，如果这2个值长期大于0时，系统性能会受到影响，磁盘IO和CPU资源都会被消耗。有时我们看到空闲内存（free）很少的或接近于0时，就认为内存不够用了，不能光看这一点，还要结合si和so，如果free很少，但是si和so也很少（大多时候是0），那么不用担心，系统性能这时不会受到影响的

查询进程占用内存情况方法

IO

通过 vmstat 的输出，重点关注b、bi、bo和wa字段。这几个值变大，都意味着IO的消耗增加。

对于读请求大的服务器，一般b、bi、wa都会比较大，而对于写入量大的服务器，一般b、bo、wa都会比较大。

借助Linux iostat命令详解可以查看相关参数

%iowait: 如果该值较高，表示磁盘存在I/O瓶颈
await: 平均每次设备I/O操作的等待时间 (毫秒)，一般地，系统I/O响应时间应该低于5ms，如果大于 10ms就比较大了
%util：一秒中有百分之多少的时间用于I/O操作，即被IO消耗的CPU百分比，一般地，如果该参数是100%表示设备已经接近满负荷运行了

借助pidstat -d 1定位出导致瓶颈的进程，参阅Linux pidstat命令详解

现在定位到进程级别了，可能需要知道这个进程到底打开了哪些文件，借助lsof -p 20711命令列出指定20711进程打开的文件列表，参阅Linux lsof命令详解

Network

网络的监测是所有 Linux 子系统里面最复杂的，这里贴了解到的运维命令

iftop 命令查看端到端流量

NetHogs实时监控进程的网络带宽占用情况，参阅Linux NetHogs 监控工具

还有些ip，netstat，tcpdump，sar 来分析网络性能问题，参阅Linux性能监测：网络篇

UDP监控

对于UDP服务，查看所有监听的UDP端口的网络情况

$  watch netstat -unlp
Every 2.0s: netstat -unlp                                                                                                                      Fri Feb  7 21:36:55 2020

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State	PID/Program name
udp        0	  0 0.0.0.0:627             0.0.0.0:*                           6813/rpcbind
udp        0	  0 0.0.0.0:7191            0.0.0.0:*                           8137/python2
udp        0	  0 0.0.0.0:68              0.0.0.0:*                           780/dhclient
udp        0	  0 0.0.0.0:111             0.0.0.0:*                           1/systemd
udp        0	  0 10.0.0.122:123          0.0.0.0:*                           3924/ntpd
udp        0	  0 127.0.0.1:123           0.0.0.0:*                           3924/ntpd
udp        0	  0 0.0.0.0:123             0.0.0.0:*                           3924/ntpd
udp6	   0	  0 :::627                  :::*                                6813/rpcbind
udp6	   0	  0 :::7191                 :::*                                8137/python2
udp6	   0	  0 :::111                  :::*                                6813/rpcbind
udp6	   0	  0 :::123                  :::*                                3924/ntpd

对于Recv-Q和Send-Q两个指标值为0，或者没有长时间大于0的数值是比较正常的。

对于UDP服务，查看丢包情况（网卡收到了，但是应用层没有处理过来造成的丢包）

$ netstat -su
...
Udp:
    14706185 packets received
    272545 packets to unknown port received.
    11026 packet receive errors
    46474392 packets sent
    10964 receive buffer errors
    0 send buffer errors
    InCsumErrors: 62
....

packet receive errors 这一项数值增长了，则表明在丢包。

TCP监控

对于TCP服务而言，这个就比较复杂；因为TCP涉及到重传，所以我们就需要重点关注这个重传率。

$ netstat -st | grep segments
    689039681 segments received
    864949096 segments send out
    2233493 segments retransmited
    5186 bad segments received.

查看segments send out和segments retransmited指标，对比一段时间内，这两个指标的增长率就是对应的重传率(Linux性能监测：网络篇文末尾有计算重传率的Shell脚本)，发生重传说明网络传输有丢包，基本上从3个点去定位：客户端网络情况、服务端网络情况、中间链路网络情况。

网卡吞吐率

可以通过sar -n DEV 2 3命令来查看

$ sar -n DEV 2 3
Linux 3.10.0-862.14.4.el7.x86_64 (region-0-0-122) 	2020年02月07日 	_x86_64_	(4 CPU)

21时43分32秒     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
21时43分34秒      eth0    116.50    119.50     11.77     19.72      0.00      0.00      0.00
21时43分34秒        lo     66.00     66.00    144.26    144.26      0.00      0.00      0.00

21时43分34秒     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
21时43分36秒      eth0    155.00    152.00     19.60     44.66      0.00      0.00      0.00
21时43分36秒        lo     29.00     29.00     94.53     94.53      0.00      0.00      0.00

21时43分36秒     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
21时43分38秒      eth0    116.00    118.00     11.86     19.80      0.00      0.00      0.00
21时43分38秒        lo     33.00     33.00     68.67     68.67      0.00      0.00      0.00

平均时间:     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
平均时间:      eth0    129.17    129.83     14.41     28.06      0.00      0.00      0.00
平均时间:        lo     42.67     42.67    102.49    102.49      0.00      0.00      0.00

将rxkB/s和txkB/s进行相加，得到网卡设备的实际吞吐率，然后再和网卡的硬件指标进行比对即可。

比如一个网卡的rxkB/s指标为21999.10，txkB/s指标为482.56，那这个网卡的吞吐率大概在22Mbytes/s，即176 Mbits/sec，没有达到1Gbit/sec的硬件上限。

参考链接

Linux性能监控 - CPU、Memory、IO、Network