文章目录
当我们登陆一台Linux服务器之后、如何快速对Linux主机的性能进行检测分析?我们可以使用包括有针对云上的监控工具 Atlas,和按需要进行实例分析的 Vector。虽然这些工具能帮助我们解决大多数问题,但是我们有时候还需要登陆机器实例去运行一些标准的 Linux 性能分析工具。
例如下面这些常用性能分析工具:
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
注:上面有些命令需要安装 sysstat 工具包。这些命令展示的指标会帮助你完成一些 USE(Utilization,Saturation,Errors) 方法:定位性能瓶颈的方法论。包括了检查使用率(Utilization),饱和度(Saturation),所有资源(比如 CPU,内存,磁盘等)的错误指标(Errors)。同样也要关注你什么时候检查和排除一个资源问题,因为通过排除可以缩小分析范围,同时也指导了任何后续的检查。下面我们来详细的看看这些命令的使用方法。
uptime
uptime 这是一个快速展示系统平均负载的方法,这也指出了等待运行进程的数量。在 Linux 系统中,这些数字包括等待 CPU 运行的进程数,也包括了被不可中断 I/O(通常是磁盘 I/O)阻塞的进程。这给出了资源负载的很直接的展示,可以在没有其它工具的帮助下更好的理解这些数据。它是唯一快捷的查看系统负载的方式。
这三个数字是以递减的方式统计了过去 1 分钟,5 分钟和 15 分钟常数的平均数。这三个数字给我们直观展示了随着时间的变化系统负载如何变化。例如,如果你被叫去查看一个有问题的服务器,并且 1 分钟的所代表的值比 15 分钟的值低很多,那么你可能由于太迟登陆机器而错过了问题发生的时间点。
[root@kubernetes-01 ~]# uptime
23:43:50 up 1 day, 1:30, 1 user, load average: 0.16, 0.21, 0.17
[root@kubernetes-01 ~]#
在上面的例子中,我们可以看到当前系统时间:23:43:50,系统状态是up、已经运行1天多1个半小时。平均负载显示是在不断增加的,1 分钟的值是 0.16,5分钟的值是0.21、相比 15 分钟的值 0.17 来说是增加了。这个数字增大就意味着有事情发生了:可能是 CPU 需求;如果想知道具体发生了什么、我们可以通过vmstat 或者 mpstat 会帮助确认到底是什么,这些命令会在本系列的第 3 和第 4 个命令中介绍。
当然、我们还可以通过–help查看uptime命令的更多参数:
[root@kubernetes-01 ~]# uptime --help
Usage:
uptime [options]
Options:
-p, --pretty show uptime in pretty format
-h, --help display this help and exit
-s, --since system up since
-V, --version output version information and exit
For more details see uptime(1).
[root@kubernetes-01 ~]#
dmesg | tail
‘dmesg’命令设备故障的诊断是非常重要的。在‘dmesg’命令的帮助下进行硬件的连接或断开连接操作时,我们可以看到硬件的检测或者断开连接的信息。‘dmesg’命令在多数基于Linux和Unix的操作系统中都可以使用。我们可以使用如‘more’, ‘tail’, ‘less ’或者‘grep’文字处理工具来处理‘dmesg’命令的输出。由于dmesg日志的输出不适合在一页中完全显示,因此我们使用管道(pipe)将其输出送到more或者less命令单页显示。
例如我们通过 dmesg | tail 命令来查看系统最近的10条消息日志:
[root@kubernetes-01 ~]# dmesg | tail
[ 19.013829] IPVS: [wrr] scheduler registered.
[ 19.021916] IPVS: [sh] scheduler registered.
[ 59.692452] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:38:crtc-0] flip_done timed out
[ 60.548999] kmem.limit_in_bytes is deprecated and will be removed. Please report your usecase to linux-mm@kvack.org if you depend on this functionality.
[ 71.789856] ipip: IPv4 and MPLS over IPv4 tunneling driver
[39048.971701] xfs filesystem being remounted at /tmp supports timestamps until 2038 (0x7fffffff)
[39048.973525] xfs filesystem being remounted at /var/tmp supports timestamps until 2038 (0x7fffffff)
[39365.790010] Key type ceph registered
[39365.790884] libceph: loaded (mon/osd proto 15/24)
[39365.844224] rbd: loaded (major 252)
[root@kubernetes-01 ~]#
这里展示的是最近 10 条系统消息日志,如果系统消息没有就不会展示。主要是看由于性能问题导致的错误。
vmstat 1
而对虚拟内存统计的简短展示,vmstat 是一个常用工具(最早是几十年前为 BSD 创建的)。它每一行打印关键的服务信息统计摘要。vmstat 使用参数 1 来运行的时候,是每 1 秒打印一条统计信息。在这个版本的 vmstat 中,输出的第一行展示的是自从启动后的平均值,而不是前一秒的统计。所以现在,可以跳过第一行,除非你要看一下抬头的字段含义。
[root@kubernetes-01 ~]# vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 6746784 2104 2192240 0 0 1 8 53 52 2 1 97 0 0
0 0 0 6746020 2104 2192244 0 0 0 40 7207 11758 3 1 96 0 0
0 0 0 6745956 2104 2192248 0 0 0 44 4265 7227 1 1 98 0 0
1 0 0 6745508 2104 2192256 0 0 0 41 4593 7819 2 1 98 0 0
0 0 0 6745444 2104 2192260 0 0 0 48 4085 7191 1 1 98 0 0
0 0 0 6745380 2104 2192260 0 0 0 52 4138 7248 1 1 98 0 0
1 0 0 6730744 2104 2192264 0 0 0 33 5662 9596 2 1 97 0 0
^C
[root@kubernetes-01 ~]# ^C
注释如下:
r: CPU 上的等待运行的可运行进程数。这个指标提供了判断 CPU 饱和度的数据,因为它不包含 I/O 等待的进程。可解释为:“r” 的值比 CPU 数大的时候就是饱和的。 f
ree:空闲内存,单位是 k。如果这个数比较大,就说明你还有充足的空闲内存。“free -m” 和下面第 7 个命令,可以更详细的分析空闲内存的状态。 si,so:交换进来和交换出去的数据量,如果这两个值为非 0 值,那么就说明没有内存了。
us,sy,id,wa,st:这些是 CPU 时间的分解,是所有 CPU 的平均值。它们是用户时间,系统时间(内核),空闲,等待 I/O 时间,和被偷的时间(这里主要指其它的客户,或者使用 Xen,这些客户有自己独立的操作域)。
CPU 时间的分解可以帮助确定 CPU 是不是非常忙(通过用户时间和系统时间累加判断)。持续的 I/O 等待则表明磁盘是瓶颈。这种情况下 CPU 是比较空闲的,因为任务都由于等待磁盘 I/O 而被阻塞。你可以把等待 I/O 看作是另外一种形式的 CPU 空闲,而这个命令给了为什么它们空闲的线索。 系统时间对于 I/O 处理来说是必须的。比较高的平均系统时间消耗,比如超过了 20%,就有必要进一步探索分析了:也有可能是内核处理 I/O 效率不够高导致。
在上面的例子中,CPU 时间几乎都是用户级别的,说明这是一个应用级别的使用情况。如果CPU 的使用率平均都超过了 90% 可以使用 “r” 列来检查使用饱和度。
mpstat -P ALL 1
[root@kubernetes-01 ~]# mpstat -P ALL 1
Linux 5.6.13-1.el7.elrepo.x86_64 (kubernetes-01) 05/23/2020 _x86_64_ (8 CPU)
11:59:11 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
11:59:12 PM all 0.88 0.00 0.50 0.00 0.00 0.13 0.00 0.00 0.00 98.49
11:59:12 PM 0 1.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 98.00
11:59:12 PM 1 1.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 98.99
11:59:12 PM 2 1.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.00
11:59:12 PM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
11:59:12 PM 4 1.98 0.00 0.99 0.00 0.00 0.00 0.00 0.00 0.00 97.03
11:59:12 PM 5 1.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 98.99
11:59:12 PM 6 1.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 98.00
11:59:12 PM 7 1.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 98.00
这个命令打印各个 CPU 的时间统计,可以看出整体 CPU 的使用是不是均衡的。有一个使用率明显较高的 CPU 就可以明显看出来这是一个单线程应用。
pidstat 1
pidstat 命令有点像 top 命令中的为每个 CPU 统计信息功能,但是它是以不断滚动更新的方式打印信息,而不是每次清屏打印。这个对于观察随时间变化的模式很有用,同时把你看到的信息(复制粘贴)记到你的调查记录中。
[root@kubernetes-01 ~]# pidstat 1
Linux 5.6.13-1.el7.elrepo.x86_64 (kubernetes-01) 05/24/2020 _x86_64_ (8 CPU)
12:00:05 AM UID PID %usr %system %guest %CPU CPU Command
12:00:06 AM 0 738 0.00 0.98 0.00 0.98 1 xfsaild/dm-0
12:00:06 AM 0 1227 1.96 0.00 0.00 1.96 1 dockerd
12:00:06 AM 0 1526 0.00 0.98 0.00 0.98 7 tuned
12:00:06 AM 0 1530 1.96 1.96 0.00 3.92 2 kube-apiserver
12:00:06 AM 0 1531 2.94 0.98 0.00 3.92 4 etcd
12:00:06 AM 0 1533 0.98 0.98 0.00 1.96 1 rsyslogd
12:00:06 AM 0 1540 3.92 0.98 0.00 4.90 6 kubelet
12:00:06 AM 0 4427 0.98 0.98 0.00 1.96 6 calico-node
12:00:06 AM 0 28437 0.00 0.98 0.00 0.98 2 pidstat
12:00:06 AM 0 30333 0.00 0.98 0.00 0.98 5 kworker/5:0-events
上面的例子可以看出 kubelet 进程在消耗 CPU。%CPU 列是所有 CPU 的使用率;4.90% 是说明这个 kubelet 进程消耗了几乎 0.05 个 CPU 核。
iosstat -xz 1
[root@kubernetes-01 ~]# iostat -xz 1
Linux 5.6.13-1.el7.elrepo.x86_64 (kubernetes-01) 05/24/2020 _x86_64_ (8 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
1.68 0.00 1.03 0.08 0.00 97.20
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
scd0 0.00 0.00 0.00 0.00 0.00 0.00 0.33 0.00 0.22 0.22 0.00 0.56 0.00
sda 0.00 0.14 0.14 10.58 11.38 62.69 13.82 0.01 1.97 13.99 1.81 0.89 0.95
sdb 0.00 0.00 0.00 0.00 0.03 0.00 57.60 0.00 3.16 3.16 0.00 0.23 0.00
dm-0 0.00 0.00 0.13 10.72 11.23 62.65 13.62 0.02 2.12 14.88 1.97 0.88 0.95
dm-1 0.00 0.00 0.00 0.00 0.02 0.00 51.80 0.00 2.80 2.80 0.00 0.29 0.00
dm-2 0.00 0.00 0.00 0.00 0.01 0.02 73.17 0.00 5.55 5.53 7.00 0.56 0.00
avg-cpu: %user %nice %system %iowait %steal %idle
2.02 0.00 1.52 0.00 0.00 96.46
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 16.00 0.00 136.50 17.06 0.00 0.69 0.00 0.69 0.94 1.50
dm-0 0.00 0.00 0.00 16.00 0.00 136.50 17.06 0.01 0.75 0.00 0.75 0.94 1.50
avg-cpu: %user %nice %system %iowait %steal %idle
0.88 0.00 0.75 0.63 0.00 97.74
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 5.00 0.00 25.00 0.00 289.50 23.16 0.06 3.04 0.00 3.04 0.32 0.80
dm-0 0.00 0.00 0.00 30.00 0.00 289.50 19.30 0.08 2.67 0.00 2.67
这个工具对于理解块设备(比如磁盘)很有用,展示了请求负载和性能数据。具体的数据看下面字段的解释:
- r/s, w/s, rkB/s, wkB/s:这些表示设备上每秒钟的读写次数和读写的字节数(单位是k字节)。这些可以看出设备的负载情况。性能问题可能就是简单的因为大量的文件加载请求。
- await:I/O 等待的平均时间(单位是毫秒)。这是应用程序所等待的时间,包含了等待队列中的时间和被调度服务的时间。过大的平均等待时间就预示着设备超负荷了或者说设备有问题了。
- avgqu-sz:设备上请求的平均数。数值大于 1 可能表示设备饱和了(虽然设备通常都是可以支持并行请求的,特别是在背后挂了多个磁盘的虚拟设备)。
- %util:设备利用率。是使用率的百分数,展示每秒钟设备工作的时间。这个数值大于 60% 则会导致性能很低(可以在 await 中看),当然这也取决于设备特点。这个数值接近 100% 则表示设备饱和了。
如果存储设备是一个逻辑磁盘设备,后面挂载了多个磁盘,那么 100% 的利用率则只是表示有些 I/O 是在 100% 处理,然而后端的磁盘或许远远没有饱和,还可以处理更多的请求。
请记住,磁盘 I/O 性能低不一定是应用程序的问题。许多技术通常都被用来实现异步执行 I/O,所以应用程序不会直接阻塞和承受延时(比如:预读取和写缓冲技术)。
free -m
[root@kubernetes-01 ~]# free -m
total used free shared buff/cache available
Mem: 9966 1247 6574 507 2145 8175
Swap: 0 0 0
[root@kubernetes-01 ~]#
右面两列展示的是:
- buffers:用于块设备 I/O 缓冲的缓存。
- cached:用于文件系统的页缓存。
我们只想检测这些缓存的数值是否接近 0 。不为 0 的可能导致较高的磁盘 I/O(通过 iostat 命令来确认)和较差的性能问题。上面的例子看起来没问题,都还有很多 M 字节。
“-/+ buffers/cache” 这一行提供了对已使用和空闲内存明确的统计。Linux 用空闲内存作为缓存,如果应用程序需要,可以快速拿回去。所以应该包含空闲内存那一列,这里就是这么统计的。甚至有一个网站专门来介绍 Linux 内存消耗的问题:linuxatemyram。
如果在 Linux 上使用了 ZFS 文件系统,则可能会更乱,因为当我们在开发一些服务的时候,ZFS 有它自己的文件系统缓存,而这部分内存的消耗是不会在 free -m 这个命令中合理的反映的。显示了系统内存不足,但是 ZFS 的这部分缓存是可以被应用程序使用的。
sar -n DEV 1
[root@kubernetes-01 ~]# sar -n DEV 1
Linux 5.6.13-1.el7.elrepo.x86_64 (kubernetes-01) 05/24/2020 _x86_64_ (8 CPU)
12:05:53 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
12:05:54 AM lo 50.00 50.00 8.85 8.85 0.00 0.00 0.00
12:05:54 AM ens160 103.00 101.00 12.05 11.13 0.00 0.00 0.00
12:05:54 AM dummy0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:05:54 AM kube-ipvs0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:05:54 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:05:54 AM cali8ddf25b8472 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:05:54 AM cali0f66ba8ac54 4.00 4.00 0.35 1.07 0.00 0.00 0.00
12:05:54 AM calif6fc7f577a6 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:05:54 AM calib77e8e477e5 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:05:54 AM tunl0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
使用这个工具是可以检测网络接口的吞吐:rxkB/s 和 txkB/s,作为收发数据负载的度量,也是检测是否达到收发极限。在上面这个例子中,eth0 接收数据达到 22 M 字节/秒,也就是 176 Mbit/秒(网卡的上限是 1 Gbit/秒)。
这个版本的工具还有一个统计字段: %ifutil,用于统计设备利用率(全双工双向最大值),这个利用率也可以使用 Brendan 的 nicstat 工具来测量统计。在这个例子中 0.00 这种情况就似乎就是没有统计,这个和 nicstat 一样,这个值是比较难统计正确的。
sar -n TCP ,ETCP 1
[root@kubernetes-01 ~]# sar -n TCP,ETCP 1
Linux 5.6.13-1.el7.elrepo.x86_64 (kubernetes-01) 05/24/2020 _x86_64_ (8 CPU)
12:06:34 AM active/s passive/s iseg/s oseg/s
12:06:35 AM 2.00 1.00 142.00 144.00
12:06:34 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:06:35 AM 0.00 0.00 0.00 0.00 4.00
12:06:35 AM active/s passive/s iseg/s oseg/s
12:06:36 AM 0.00 0.00 277.00 281.00
这是对 TCP 关键指标的统计,它包含了以下内容:
- active/s:每秒本地发起的 TCP 连接数(例如通过 connect() 发起的连接)。
- passive/s:每秒远程发起的连接数(例如通过 accept() 接受的连接)。
- retrans/s:每秒TCP重传数。
这种主动和被动统计数通常用作对系统负载的粗略估计:新接受连接数(被动),下游连接数(主动)。可以把主动看作是外部的,被动的是内部,但是这个通常也不是非常准确(例如:当有本地到本地的连接时)。
重传是网络或者服务器有问题的一个信号;可能是一个不可靠的网络(例如:公网),或者可能是因为服务器过载了开始丢包。上面这个例子可以看出是每秒新建一个 TCP 连接。
top
[root@kubernetes-01 ~]# top
top - 00:07:24 up 1 day, 1:53, 1 user, load average: 0.12, 0.09, 0.09
Tasks: 227 total, 1 running, 134 sleeping, 1 stopped, 0 zombie
%Cpu(s): 3.3 us, 2.1 sy, 0.0 ni, 94.3 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
KiB Mem : 10205984 total, 6733624 free, 1266560 used, 2205800 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 8373580 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1530 root 20 0 634096 541644 64872 S 6.0 5.3 80:01.57 kube-apiserver
1531 root 20 0 7605900 231424 21984 S 5.3 2.3 60:20.23 etcd
1540 root 20 0 1871600 105740 61516 S 3.7 1.0 54:06.15 kubelet
1227 root 20 0 1199844 81396 38260 S 3.3 0.8 32:21.84 dockerd
1528 root 20 0 141164 40536 23940 S 3.3 0.4 2:55.86 kube-proxy
4427 root 20 0 146560 42256 28100 S 2.3 0.4 36:09.78 calico-node
820 root 20 0 48460 11592 11092 S 0.7 0.1 7:47.77 systemd-journal
top 命令包含了很多我们前面提到的指标。这个命令可以很容易看出指标的变化表示负载的变化,这个看起来和前面的命令有很大不同。top 的一个缺陷也比较明显,很难看出变化趋势,其它像 vmstat 和 pidstat 这样的工具就会很清晰,它们是以滚动的方式输出统计信息。所以如果你在看到有问题的信息时没有及时的暂停下来(Ctrl-S 是暂停, Ctrl-Q 是继续),那么这些有用的信息就会被清屏。