Linux负载CPU状态分析（一）

发布时间：2023-02-27 10:14:37 所属栏目：Linux 来源：

导读：一、Linux系统状态概述
1、Linux系统状态分析工具

Basic Tool有如下：

uptime、top(htop)、mpstat、isstat、vmstat、free、ping、nicstat、dstat。

高级的命令如下：
sar、netstat、pidstat、strace、tc

一、Linux系统状态概述
1、Linux系统状态分析工具

Basic Tool有如下：

uptime、top(htop)、mpstat、isstat、vmstat、free、ping、nicstat、dstat。

高级的命令如下：
sar、netstat、pidstat、strace、tcpdump、blktrace、iotop、slabtop、sysctl、/proc。

静态代码检测工具或平台：cppcheck、PC-lint、Coverity、QAC C/C++、Clang-Tidy、Clang Static Analyzer、SonarQube+sonar-cxx（推荐）、Facebook的infer
profiling工具：gnu prof、Oprofile、google gperftools（推荐）、perf、intel VTune、AMD CodeAnalyst
内存泄漏：valgrind、AddressSanitizer（推荐）、mtrace、dmalloc、ccmalloc、memwatch、debug_new
cpu使用率：pidstat（推荐）、vmstat、mpstat、top、sar
上下文切换：pidstat（推荐）、vmstat
网络I/O：dstat、tcpdump（推荐）、sar
磁盘I/O：iostat（推荐）、dstat、sar
系统调用追踪：strace（推荐）
网络吞吐量：iftop、nethogs、sar
网络延迟：ping
文件系统空间：df
内存容量：free、vmstat（推荐）、sar
进程内存分布：pmap
cpu负载：uptime、top
软中断硬中断：/proc/softirqs、/proc/interrupts
确定哪些进程正在使用一组给定的文件：lsof
很多的监控工具 Ubuntu/CentOS 都不自带，需要手动安装，在开始前我们最好先把所有可能用得上的监控工具都装上。（它们都很小，基本不占空间）

# ubuntu/debian
sudo apt-get install \
sysstat iotop fio \
nethogs iftop
# centos
# 需要安装 epel 源，很多监控工具都在该源中！
# 也可使用[阿里云 epel 源](https://developer.aliyun.com/mirror/epel)
sudo yum install epel-release
sudo yum install \
sysstat iotop fio \
nethogs iftop
2、大一统的监控工具
下面介绍两个非常方便的大一统监控工具，它们将一台服务器的所有监控数据汇总到一个地方，方便监控。

多机监控推荐用 prometheus+grafana，不过这一套比较吃性能，个人服务器没必要上。

NetData: 极简安装、超详细超漂亮的 Web UI。

这里只介绍单机监控。NetData 也支持中心化的多机监控，待进一步研究。netdata 也可以被用作 prometheus 的 exporter.

NetData 我要吹爆！它是 Github 上最受欢迎的系统监控工具，目前已经 44.5k star 了。
cpu 占用率低（0.1 核），界面超级漂亮超级详细，还对各种指标做了很详细的说明，安装也是一行命令搞定。相当适合萌新运维。

默认通过 19999 端口提供 Web UI 界面。
sudo apt-get install netdata
# 然后修改 /etc/netdata/netdata.conf，绑定 ip 设为 0.0.0.0
sudo systemctl restart netdata
现在就可以访问http://<server-ip>:19999查看超级漂亮超级详细的监控界面了！

Glances: 同样极简安装、方便的命令行 UI

netdata 只以 Web 服务器的方式提供 Web UI，因此必须常驻后台。
如果只是想要临时在 ssh 控制台进行监控，可以使用 Glances，安装命令如下：

sudo apt-get install glances
sudo yum install glances
启动命令：glances，可提供 cpu、RAM、NetWork、disk 和系统状态等非常全面的信息。（只是不够详细）
glances 同样提供中心化的多机监控，还有 Web 界面，但是和 netdata 相比就有些简陋了。

3、Linux主要性能指标说明
一台 Linux 服务器的四类指标如下：

cpu：使用率、平均负载（load average）
RAM：used | free | buffer/cache | avaliable
disk：空闲容量大小、IO 状态
Network：网速、延迟、丢包率等
1）cpu指标

1. cpu 使用率

cpu 使用率即 cpu 运行在非空闲状态的时间占比，它反应了 cpu 的繁忙程度。使用 top 命令我们可以得到如下信息：

%cpu(s): 0.0 us,2.3 sy,0.0 ni,97.7 id,0.0 wa,0.0 hi,0.0 si,0.0 st
us(user)：表示 cpu 在用户态运行的时间百分比，通常用户态 cpu 高表示有应用程序比较繁忙。典型的用户态程序包括：数据库、Web 服务器等。
sy(sys)：表示 cpu 在内核态运行的时间百分比（不包括中断），通常内核态 cpu 越低越好，否则表示系统存在某些瓶颈。
ni(nice)：表示用 nice 修正进程优先级的用户态进程执行的 cpu 时间。nice 是一个进程优先级的修正值，如果进程通过它修改了优先级，则会单独统计 cpu 开销。
id(idle)：表示 cpu 处于空闲态的时间占比，此时，cpu 会执行一个特定的虚拟进程，名为 System Idle Process。
wa(iowait)：表示 cpu 在等待 I/O 操作完成的时间占比，通常该指标越低越好，否则表示 I/O 可能存在瓶颈，需要用 iostat 等命令做进一步分析。
iowait 只考虑 Synchronous File IO，It does NOT count time spent waiting for IPC objects such as sockets,pipes,ttys,select(),poll(),sleep(),pause() etc.
hi(hardirq)：表示 cpu 处理硬中断所花费的时间。硬中断是由外设硬件（如键盘控制器、硬件传感器等）发出的，需要有中断控制器参与，特点是快速执行。
si(softirq)：表示 cpu 处理软中断所花费的时间。软中断是由软件程序（如网络收发、定时调度等）发出的中断信号，特点是延迟执行。
st(steal)：表示 cpu 被其他虚拟机占用的时间，仅出现在多虚拟机场景。如果该指标过高，可以检查下宿主机或其他虚拟机是否异常。
2. 平均负载（Load Average）

top命令的第一行输出如下：

top - 21:11:00 up 8 min,0 users,load average: 0.52,0.58,0.59
其中带有三个平均负载的值，它们的意思分别是** 1 分钟（load1）、5 分钟（load5）、15 分钟（load15）内系统的平均负载**。

平均负载（Load Average）是指单位时间内，系统处于可运行状态（Running / Runnable）和不可中断态的平均进程数，也就是平均活跃进程数。

我们知道实际上一个 cpu 核只能跑一个进程，操作系统通过分时调度提供了多进程并行的假象。所以当平均负载（平均活跃进程数）不大于 cpu 逻辑核数时，系统可以正常运转。
如果平均负载超过了核数，那就说明有一部分进程正在活跃中，但是它却没有使用到 cpu（同一时间只能有 1 个进程在使用 cpu），这只可能有两个原因：

这部分进程在排队等待 cpu 空闲。
这部分 cpu 在进行 IO 操作。
不论是何种状况，都说明系统的负载过高了，需要考虑降负或者升级硬件。

理想状态下，系统满负荷工作，此时平均负载 = cpu 逻辑核数（4核8线程 cpu 有8个逻辑核）。但是，在实际生产系统中，不建议系统满负荷运行。通用的经验法则是：平均负载 <= 0.7 * cpu 逻辑核数。

当平均负载持续大于 0.7 * cpu 逻辑核数，就需要开始调查原因，防止系统恶化；
当平均负载持续大于 1.0 * cpu 逻辑核数，必须寻找解决办法，降低平均负载；
当平均负载持续大于 5.0 * cpu 逻辑核数，表明系统已出现严重问题，长时间未响应，或者接近死机。
除了关注平均负载值本身，我们也应关注平均负载的变化趋势，这包含两层含义。一是 load1、load5、load15 之间的变化趋势；二是历史的变化趋势。

当 load1、load5、load15 三个值非常接近，表明短期内系统负载比较平稳。此时，应该将其与昨天或上周同时段的历史负载进行比对，观察是否有显著上升。
当 load1 远小于 load5 或 load15 时，表明系统最近 1 分钟的负载在降低，而过去 5 分钟或 15 分钟的平均负载却很高。
当 load1 远大于 load5 或 load15 时，表明系统负载在急剧升高，如果不是临时性抖动，而是持续升高，特别是当 load5 都已超过 0.7 * cpu 逻辑核数时，应调查原因，降低系统负载。
日常运维时，应该重点关注上述三个负载值之间的关系。

3. cpu 使用率与平均负载的关系

cpu 使用率是单位时间内 cpu 繁忙程度的统计。而平均负载不仅包括正在使用 cpu 的进程，还包括等待 cpu 或 I/O 的进程（前面讲过平均负载过高的两种情况）。

因此 cpu 使用率是包含在平均负载内的。这两个参数有两种组合需要注意：

两个参数值都很高：需要降低 cpu 使用率！
cpu 使用率很低，可平均负载却超过了cpu逻辑核数：IO 有瓶颈了！需要排查内存/磁盘/网络的问题。
最常遇到的场景：内存用尽导致负载飙升。
2）RAM内存指标

free # 单位 kb
free -m # 单位 mb
free -g # 单位 gb
不考虑 Swap 时，建议以 Avaliable 值为可用内存的参考，因为 buffer/cache 中的内存不一定能完全释放出来！因为：

OS 本身需要占用一定 buffer/cache
通过 tmpfs 等方式被使用的 cache 不能被回收使用
通过 cgroups 设置的资源预留无法被别的进程回收利用。（容器资源预留）
内存泄漏

内存泄漏有多种可能，通过监控能确定的只有内存是否在无上限地上升。很难直接通过监控排查。

3）disk 磁盘指标

disk 的性能指标主要有：

bandwidth 带宽，即每秒的 IO 吞吐量
连续读写频繁的应用（传输大量连续的数据）重点关注吞吐量，如读写视频的应用。
IOPS，每秒的 IO 次数
随机读写频繁的应用需要关注 IOPS，如大量小文件（图片等）的读写。
我们是 Web 服务器/数据库服务器，主要是随机读写，更关注 IOPS。

1. IO 基准测试

要监控磁盘的指标，首先得有个基准值做参考。

方法一：对整块磁盘进行测试

首先安装磁盘测试工具 fio（安装命令见文章开始），然后将如下内容保存为fio-rand-rw.fio（Web 服务器/数据库更关注随机读写）：

; https://github.com/axboe/fio/blob/master/examples/fio-rand-RW.fio
; fio-rand-RW.job for fiotest
[global]
name=fio-rand-RW
filename=fio-rand-RW
rw=randrw
rwmixread=60
rwmixwrite=40
bs=4K
direct=0
numjobs=4
time_based=1
runtime=900
[file1]
size=4G
ioengine=libaio
iodepth=16
现在运行命令fio fio-rand-rw.fio以启动测试，可根据情况调整 .fio 文件中的参数，最后记录测试结果。

方法二：使用 dd 进行磁盘速度测试

使用 dd 测试的好处是系统自带，而且也不会破坏磁盘内容。

# 写入测试，读取 /dev/zero 这个空字符流，写入到 test.dbf 中（就是只测写入）
# 块大小为 8k，也就是说偏向随机写
dd if=/dev/zero of=test.dbf bs=8k count=50000 oflag=dsync # 每次写完一个 block 都同步，伤硬盘，不要没事就测
# 读取 /dev/sda1 中的数据，写入到 /dev/null 这个黑洞中（只测读取）
# 块大小还是 8k，即偏向随机读
dd if=/dev/sda1 of=/dev/null bs=8k
日常监控的数值远低于上面测得的基准值的情况下，基本就可以确定磁盘没有问题。

2. 使用率

通过df -h查看磁盘的使用情况。

磁盘不足会导致各种问题，比如：

ElasticSearch 自动将索引设为只读，禁止写入。
k8s 报告 "disk Pressure"，导致节点无法调度。
shell 的 tab 补全无法使用，会报错。
3. IO 带宽（吞吐量）以及 IOPS

使用 iostat 查看磁盘 io 的状态（需要安装 sysstat）：

# 每个磁盘一列，给出所有磁盘的当前状态
iostat -d -k 3 # 以 kb 为单位，3 秒刷新一次
iostat -d -m 3 # 以 mb 为单位，其他不变
# 每个进程一列，可用于排查各进程的磁盘使用状态
iotop
将监控值与前述测试得到的基准值进行对比，低很多的话，基本就可以确认磁盘没问题。

1. 网络带宽监控

nethogs: 每个进程的带宽监控，并且进程是按带宽排序的
使用：sudo nethogs
快速分析出占用大量带宽的进程
tcpdump/tshark/mitmproxy: 命令行的网络抓包工具，mitmproxy 提供 Web UI 界面，而 tshark 是 wireshark 的命令行版本。
tcpdump -i eth0 -w dump.pcap: 使用 tcpdump 抓 eth0 的数据包，保存到 dump.pcap 中。之后可以通过 scp/ssh 等命令将该 pcap 文件拷贝下来，使用 wireshark 进行分析。
2. Socket

Socket 的状态查看方法：

# 查看 socket 连接的统计信息
# 主要统计处于各种状态的 tcp sockets 数量，以及其他 sockets 的统计信息
ss --summary
ss -s # 缩写
# 查看哪个进程在监听 80 端口
# --listening 列出所有正在被监听的 socket
# --processes 显示出每个 socket 对应的 process 名称和 pid
# --numeric 直接打印数字端口号（不解析协议名称）
ss --listening --processes --numeric | grep 80
ss -nlp | grep 80 # 缩写
ss -lp | grep http # 解析协议名称，然后通过协议名搜索监听
## 使用过时的 netstat
### -t tcp
### -u udp
netstat -tunlp | grep ":80"
# 查看 sshd 当前使用的端口号
ss --listening --processes | grep sshd
## 使用过时的 netstat
netstat -tunlp | grep <pid> # pid 通过 ps 命令获得
# 列出所有的 tcp sockets，包括所有的 socket 状态
ss --tcp --all
# 只列出正在 listen 的 socket
ss --listening
# 列出所有 ESTABLISHED 的 socket（默认行为）
ss
# 统计 TCP 连接数
ss | grep ESTAB | wc -l
# 列出所有 ESTABLISHED 的 socket，并且给出连接的计时器
ss --options
# 查看所有来自 192.168.5 的 sockets
ss dst 192.168.1.5
# 查看本机与服务器 192.168.1.100 建立的 sockets
ss src 192.168.1.5
# 查看路由表
routel
3. 网络延迟、丢包率

通过 ping 命令进行测试，使用 pathping （仅 Windows）进行分段网络延迟与丢包率测试。

4. DNS故障排查

dig +trace baidu.com # 诊断 dns 的主要工具，非常强大
host -a baidu.com # host 基本就是 dig 的弱化版，不过 host 有个有点就是能打印出它测试过的所有 FQDN
nslookup baidu.com # 和 host 没啥大差别，多个交互式查询不过一般用不到
whois baidu.com # 查询域名注册信息，内网诊断用不到
TCP 连接数受 Linux 文件描述符上限控制，可以通过如下方法查看已用文件句柄的数量。

# 已用文件描述符数量
lsof | wc -l
# 文件描述符上限
ulimit -n
Docker 容器有自己的 namespace，直接通过宿主机的 ss 命令是查看不到容器的 socket 信息的。

比较直观的方法是直接通过 docker exec 在容器中通过 ss 命令。但是这要求容器中必须自带 ss 等程序，有的精简镜像可能不会自带它。

（编辑：汽车网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!