关于linux:如何诊断-Linux-服务器的性能

本文译者：开源中国社区，原文链接：https://urlify.cn/Y7nyqa

对 Linux 的性能诊断

当你为了解决一个性能问题登录到一台 Linux 服务器：在第一分钟你应该查看些什么？

在 Netflix，咱们有一个微小的 EC2 Linux 云，以及大量的性能剖析工具来监控和诊断其性能。其中包含用于云监控的 Atlas，以及用于按需实例剖析的 Vector。尽管这些工具能够帮忙咱们解决大多数问题，但咱们有时仍须要登录到一个服务器实例，并运行一些规范 Linux 性能工具。

在这篇文章中，Netflix Performance Engineering 团队将会向你解说在命令行中进行一次最佳的性能剖析的前 60 秒要做的事，应用的是你应该能够失去的规范 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 办法（一种用于定位性能瓶颈的办法），比方查看各种资源（如 CPU、内存、磁盘等）的使用率、饱和度和错误信息。另外在定位问题的过程中，你能够通过应用这些命令来排除某些导致问题的可能性，帮忙你放大查看范畴，为下一步查看指明方向。

上面的章节将以在一个生产环境上执行这些命令作为例子，简略介绍这些命令。若想具体理解这些工具的应用办法，请参考它们的 man 文档。

1uptime

$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02

这是一种用来疾速查看零碎均匀负载的办法，它表明了零碎中有多少要运行的工作（过程）。在 Linux 零碎中，这些数字蕴含了须要在 CPU 中运行的过程以及正在期待 I/O（通常是磁盘 I/O）的过程。它仅仅是对系统负载的一个粗略展现，略微看下即可。你还须要其余工具来进一步理解具体情况。

这三个数字展现的是一分钟、五分钟和十五分钟内零碎的负载总量平均值依照指数比例压缩失去的后果。从中咱们能够看到零碎的负载是如何随工夫变动的。比如你在查看一个问题，而后看到 1 分钟对应的值远小于 15 分钟的值，那么可能阐明这个问题曾经过来了，你没能及时察看到。

在下面这个例子中，零碎负载在随着工夫减少，因为最近一分钟的负载值超过了 30，而 15 分钟的均匀负载则只有 19。这样显著的差距蕴含了很多含意，比如 CPU 负载。若要进一步确认的话，则要运行 vmstat 或 mpstat 命令，这两个命令请参考前面的第 3 和第 4 章节。

2dmesg | tail

$ dmesg | tail[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[…]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.

这条命令显式了最近的 10 条零碎音讯，如果它们存在的话。查找可能导致性能问题的谬误。下面的例子蕴含了 oom-killer，以及 TCP 抛弃一个申请。

千万不要错过这一步！dmesg 命令永远值得一试。

3vmstat 1

$ vmstat 1procs ———memory———- —swap– —–io—- -system– ——cpu—–
r b swpd free buff cache si so bi bo in cs us sy id wa st
34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0
32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0
32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0
32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0
32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0
^C

vmstat(8) 是虚拟内存统计的简称，其是一个常用工具（几十年前为了 BSD 所创立）。其在每行打印一条要害的服务器的统计摘要。

vmstat 命令指定一个参数 1 运行，来打印每一秒的统计摘要。（这个版本的 vmstat）输入的第一行的那些列，显式的是开机以来的平均值，而不是前一秒的值。当初，咱们跳过第一行，除非你想要理解并记住每一列。

查看这些列：

• r：CPU 中正在运行和期待运行的过程的数量。其提供了一个比均匀负载更好的信号来确定 CPU 是否饱和，因为其不蕴含 I/O。解释：“r”的值大于了 CPU 的数量就示意曾经饱和了。
• free：以 kb 为单位显式的闲暇内存。如果数字位数很多，阐明你有足够的闲暇内存。“free -m”命令，是上面的第七个命令，其能够更好的阐明闲暇内存的状态。
• si, so：Swap-ins 和 swap-outs。如果它们不是零，则代表你的内存不足了。
• us, sy, id, wa, st：这些都是均匀了所有 CPU 的 CPU 合成工夫。它们别离是用户工夫（user）、零碎工夫（内核）（system）、闲暇（idle）、期待 I/O（wait）、以及占用工夫（stolen）（被其余访客，或应用 Xen，访客本人独立的驱动域）。

CPU 合成工夫将会通过用户工夫加零碎工夫确认 CPU 是否为繁忙状态。期待 I/O 的工夫始终不变则表明了一个磁盘瓶颈；这就是 CPU 的闲置，因为工作都阻塞在期待挂起磁盘 I/O 上了。你能够把期待 I/O 当成是 CPU 闲置的另一种模式，其给出了为什么 CPU 闲置的一个线索。

对于 I/O 解决来说，零碎工夫是很重要的。一个高于 20% 的均匀零碎工夫，能够值得进一步的探讨：兴许内核在解决 I/O 时效率太低了。

在下面的例子中，CPU 工夫简直齐全花在了用户级，表明应用程序占用了太多 CPU 工夫。而 CPU 的均匀使用率也在 90% 以上。这不肯定是一个问题；检查一下“r”列中的饱和度。

4mpstat -P ALL 1

$ mpstat -P ALL 1Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 x86_64 (32 CPU)

07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99
07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00
07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00
07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03
[…]

这个命令打印每个 CPU 的 CPU 合成工夫，其可用于对一个不平衡的应用状况进行查看。一个独自 CPU 很繁忙则代表了正在运行一个单线程的应用程序。

5pidstat 1

$ pidstat 1Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 x86_64 (32 CPU)

07:41:02 PM UID PID %usr %system %guest %CPU CPU Command
07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0
07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave
07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java
07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java
07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java
07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat

07:41:03 PM UID PID %usr %system %guest %CPU CPU Command
07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave
07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java
07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java
07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass
07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat
^C

pidstat 命令有点像 top 命令对每个过程的统计摘要，但循环打印一个滚动的统计摘要来代替 top 的刷屏。其可用于实时查看，同时也可将你所看到的货色（复制粘贴）到你的考察记录中。

逆锋起笔 是一个专一于程序员圈子的技术平台，你能够播种 最新技术动静 、 最新内测资格 、BAT 等大厂的教训、 精品学习材料 、 职业路线 、 副业思维 ，微信搜寻 逆锋起笔 关注！

下面的例子表明两个 Java 过程正在耗费 CPU。%CPU 这列是所有 CPU 共计的；1591% 示意这个 Java 过程耗费了将近 16 个 CPU。

6iostat -xz 1

$ iostat -xz 1Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 x86_64 (32 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle

      73.96    0.00    3.73    0.03    0.06   22.21

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09
xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25
xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26
dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04
dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00
dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03
[…]
^C

这是用于查看块设施（磁盘）状况的一个很棒的工具，无论是对工作负载还是性能体现来说。查看个列：

• r/s, w/s, rkB/s, wkB/s：这些别离代表该设施每秒的读次数、写次数、读取 kb 数，和写入 kb 数。这些用于形容工作负载。性能问题可能仅仅是因为施加了过大的负载。
• await：以毫秒为单位的 I/O 均匀耗费工夫。这是应用程序耗费的理论工夫，因为它包含了排队工夫和解决工夫。比预期更大的均匀工夫可能意味着设施的饱和，或设施出了问题。
• avgqu-sz：向设施收回的申请的均匀数量。值大于 1 阐明曾经饱和了（虽说设施能够并行处理申请，尤其是由多个磁盘组成的虚构设施。）
• %util：设施利用率。这个值是一个显示出该设施在工作时每秒处于繁忙状态的百分比。若值大于 60%，通常表明性能不佳（能够从 await 中看出），尽管它取决于设施自身。值靠近 100% 通常意味着已饱和。

如果该存储设备是一个面向很多后端磁盘的逻辑磁盘设施，则 100% 利用率可能只是意味着以后正在解决某些 I/O 占用，然而，后端磁盘可能远未饱和，并且可能可能解决更多的工作。

请记住，磁盘 I/O 性能较差不肯定是程序的问题。许多技术通常是异步 I/O，使应用程序不会被阻塞并蒙受提早（例如，预读，以及写缓冲）。

7free -m

$ free -m

         total       used       free     shared    buffers     cached

Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap: 0 0 0

左边的两列显式：

• buffers：用于块设施 I/O 的缓冲区缓存。
• cached：用于文件系统的页面缓存。

咱们只是想要查看这些不靠近零的大小，其可能会导致更高磁盘 I/O（应用 iostat 确认），和更蹩脚的性能。下面的例子看起来还不错，每一列均有很多 M 个大小。

比起第一行，-/+ buffers/cache 提供的内存使用量会更加精确些。Linux 会把临时用不上的内存用作缓存，一旦利用须要的时候就立即重新分配给它。所以局部被用作缓存的内存其实也算是闲暇的内存。为了解释这一点，甚至有人专门建了个网站：linuxatemyram。

如果你在 Linux 上装置了 ZFS，这一点会变得更加困惑，因为 ZFS 它本人的文件系统缓存不算入 free -m。有时候发现零碎曾经没有多少闲暇内存可用了，其实内存却都待在 ZFS 的缓存里。

8sar -n DEV 1

$ sar -n DEV 1Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 x86_64 (32 CPU)

12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00
12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00
12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00
12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00
12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
^C

这个工具能够被用来查看网络接口的吞吐量：rxkB/s 和 txkB/s，以及是否达到限额。下面的例子中，eth0 接管的流量达到 22Mbytes/s，也即 176Mbits/sec（限额是 1Gbit/sec）

咱们用的版本中还提供了 %ifutil 作为设施使用率（接管和发送的最大值）的指标。咱们也能够用 Brendan 的 nicstat 工具计量这个值。一如 nicstat，sar 显示的这个值是很难准确获得的，在这个例子外面，它就没在失常的工作（0.00）。

9sar -n TCP,ETCP 1

$ sar -n TCP,ETCP 1Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 x86_64 (32 CPU)

12:17:19 AM active/s passive/s iseg/s oseg/s
12:17:20 AM 1.00 0.00 10233.00 18846.00

12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:20 AM 0.00 0.00 0.00 0.00 0.00

12:17:20 AM active/s passive/s iseg/s oseg/s
12:17:21 AM 1.00 0.00 8359.00 6039.00

12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:21 AM 0.00 0.00 0.00 0.00 0.00
^C

这是一些要害的 TCP 指标的汇总视图。这些包含：

• active/s：每秒本地发动 TCP 连接数（例如，通过 connect()）。
• passive/s：每秒近程发动的 TCP 连接数（例如，通过 accept()）。
• retrans/s：每秒重传 TCP 次数。

active 和 passive 的连接数往往对于形容一个粗略掂量服务器负载是十分有用的：新承受的连接数（passive），上行连接数（active）。能够了解为 active 连贯是对外的，而 passive 连贯是对内的，尽管严格来说并不完全正确（例如，一个 localhost 到 localhost 的连贯）。

重传是呈现一个网络和服务器问题的一个征兆。其可能是因为一个不牢靠的网络（例如，公网）造成的，或者也有可能是因为服务器过载并丢包。下面的例子显示了每秒只有一个新的 TCP 连贯。

10top

$ toptop – 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java
4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave
66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top
5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java
4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java

 1 root      20   0   33620   2920   1496 S   0.0  0.0   0:03.82 init
 2 root      20   0       0      0      0 S   0.0  0.0   0:00.02 kthreadd
 3 root      20   0       0      0      0 S   0.0  0.0   0:05.35 ksoftirqd/0
 5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
 6 root      20   0       0      0      0 S   0.0  0.0   0:06.94 kworker/u256:0
 8 root      20   0       0      0      0 S   0.0  0.0   2:38.05 rcu_sched

top 命令蕴含了很多咱们之前曾经查看过的指标。能够不便的执行它来查看相比于之前的命令输入的后果有很大不同，这表明负载是可变的。

top 的一个毛病是，很难看到数据随工夫变动的趋势。vmstat 和 pidstat 提供的滚动输入会更分明一些。如果你不以足够快的速度暂停输入（Ctrl-S 暂停，Ctrl-Q 持续），一些间歇性问题的线索也可能因为被清屏而失落。

后续的剖析

还有更多命令和办法能够用于更深刻的剖析。查看 Brendan 在 Velocity 2015 大会上的 Linux 性能工具教程，其中蕴含了超过 40 个命令，涵盖了可观测性、标杆治理、调优、动态性能调优、剖析，和跟踪等方面。

在全网规模应答零碎的可靠性和性能问题是咱们的喜好之一。

逆锋起笔 是一个专一于程序员圈子的技术平台，你能够播种 最新技术动静 、 最新内测资格 、BAT 等大厂的教训、 精品学习材料 、 职业路线 、 副业思维 ，微信搜寻 逆锋起笔 关注！