关于linux:1分钟内的Linux性能分析法

32次阅读

共计 8319 个字符，预计需要花费 21 分钟才能阅读完成。

来自公众号：新世界杂货铺

本着“拿来主义”的精力，排汇别人短处为己用。老许翻译一篇 Linux 性能剖析相干的文章分享给各位读者，同时也加深本人的印象。

你登录到具备性能问题的 Linux 服务器时，第一分钟要查看什么？

在 Netflix，咱们领有宏大的 Linux EC2 云实例，以及大量的性能剖析工具来监督和考察它们的性能。这些工具包含 Atlas 和Vector。Atlas用于全云监控，Vector用于按需实例剖析。这些工具能帮忙咱们解决大部分问题，但有时候咱们仍需登录实例并运行一些规范的 Linux 性能工具。

Atlas：依据 github 下面的文档老许简略说一下本人的认知。一个能够治理基于工夫维度数据的后端，同时具备内存存储性能能够十分疾速地收集和报告大量指标。

Vector：Vector 是一个主机上的性能监督框架，它能够将各种指标展现在工程师的浏览器下面。

总结

在这篇文章中，Netflix 性能工程团队将向您展现通过命令行进行性能剖析是，前 60 秒应该应用那些 Linux 规范工具。在 60 秒内，你能够通过以下 10 个命令来全面理解系统资源应用状况和正在运行的过程。首先寻找谬误和饱和指标，因为他们很容易了解，而后是资源利用率。饱和是指资源负载超出其解决能力，其能够体现为一个申请队列的长度或者等待时间。

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 Method（Utilization Saturation and Errors Method）——一种查找性能瓶颈的办法。这波及查看所有资源（CPU、内存、磁盘等）利用率，饱和度和谬误等指标。同时还需注意通过排除法能够逐渐放大资源查看范畴。

以下各节通过生产零碎中的示例总结了这些命令。这些命令的更多信息，请参考使用手册。

uptime

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

这是一种疾速查看均匀负载的办法，它批示了期待运行的过程数量。在 Linux 零碎上，这些数字包含要在 CPU 上运行的过程以及处于 I /O（通常是磁盘 I /O）阻塞的过程。这提供了资源负载的大略状态，没有其余工具就无奈了解更多。仅值得一看。

这三个数字别离代表着 1 分钟、5 分钟和 15 分钟内的均匀负载。这三个指标让咱们理解负载是如何随工夫变动的。例如，你被要求查看有问题的服务器，而 1 分钟的值远低于 15 分钟的值，则意味着你可能登录的太晚而错过了问题现场。

在下面的例子中，最近的均匀负载减少，一分钟值达到 30，而 15 分钟值达到 19。数字如此之大意味着很多：可能是 CPU 需要（能够通过后文中介绍的 vmstat 或 mpstat 命令来确认）。

dmesg | 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始终值得被查看。

vmstat 1

$ 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
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 是虚拟内存状态的缩写。它在每一行上打印要害服务的统计信息。

vmstat 在参数 1 下运行，以显示一秒钟的摘要。在某些版本中，第一行的某些列展现的是自启动以来的平均值，而不是前一秒的平均值。当初请跳过第一行，除非你想学习并记住那一列是那一列。

要查看的列：

  • r：在 CPU 上运行并期待切换的过程数。这为确定 CPU 饱和比均匀负载提供了更好的信号，因为它不包含 I /O。简略来说就是：r 的值大于 CPU 数量即为饱和状态。
  • free：可用内存以字节为单位，如果数字很大，则阐明你有足够的可用内存。free -m命令可能更好的形容此状态。
  • si, so：swap-ins 和 swap-outs. 如果这两个值不为 0，则阐明内存不足。
  • us, sy, id, wa, st：这是总 CPU 工夫的百分比。他们别离是用户工夫、零碎工夫（内核）、闲暇工夫（包含 I / O 期待）、I/ O 期待和被盗工夫（虚拟机所耗费的工夫）。

最初对于 us, sy, id, wa, st 的解释和原文不太一样，所以老许贴一下 vmstat 手册中的解释。

通过用户工夫 + 零碎工夫来确认 CPU 是否忙碌。如果有继续的期待 I /O，意味着磁盘瓶颈。这是 CPU 闲暇的时候，因为工作期待 I / O 被阻塞。你能够将 I / O 期待视为 CPU 闲暇的另一种模式，同时它也提供了 CPU 为什么闲暇的线索。

I/ O 解决须要耗费零碎工夫。一个零碎工夫占比拟高（比方超过 20%）值得进一步钻研，可能是内核解决 I / O 的效率低下。

在下面的例子中，CPU 工夫简直齐全处于用户级别，即 CPU 工夫简直被应用程序占用。CPU 均匀利用率也超过 90%，这不肯定是问题，还须要通过 r 列的值查看饱和度。

mpstat -P ALL 1

$ mpstat -P ALL 1
Linux 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 可能是因为存在一个单线程利用。

pidstat 1

$ pidstat 1
Linux 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 的每个过程摘要，然而会打印滚动摘要，而不是革除屏幕。这对于察看随工夫变动的模式很有用，还能够将看到的内容记录下来。

下面的示例中，两个 java 过程耗费了大部分 CPU 工夫。%CPU 这一列是所有 CPU 的总和。1591%意味着 java 过程简直耗尽了 16 个 CPU。

iostat -xz 1

$ iostat -xz 1
Linux 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 数。这些能够形容设施的工作负载。性能问题可能仅仅是因为施加了过多的负载。
  • await：I/ O 解决工夫（毫秒为单位），这包含队列中申请所破费的工夫以及为申请服务所破费的工夫。如果值大于预期的均匀工夫，可能是因为设施曾经饱和或设施呈现问题。
  • avgqu-sz：发送给设施申请的均匀队列长度。该值大于 1 表明设施已达饱和状态（只管设施通常能够并行处理申请，尤其是有多个后端磁盘的虚构设施）。
  • %util：设施利用率。这是一个显示设施是否繁忙的百分比，其含意为设施每秒的工作工夫占比。该值大于 60% 时通常会导致性能不佳（能够在 await 中看进去），不过它也和具体的设施无关。值靠近 100% 时，意味着设施已饱和。

对于 avgqu-sz 的解释和原文不太一样，所以老许贴一下 iostat 手册中的解释。

如果存储设备是位于很多磁盘后面的逻辑磁盘设施，则 100% 利用率可能仅仅意味着所有工夫都在解决 I /O，然而后端磁盘可能远远还没有饱和，而且还能解决更多的工作。

请记住，磁盘 I / O 性能不佳不肯定是应用程序的问题。通常应用许多技术来异步执行 I /O，以保障应用程序不被阻塞或间接蒙受提早（例如，预读用于读取，缓冲用于写入）。

free -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：页缓存，用于文件系统。

咱们查看他们的值是否靠近 0，靠近 0 会导致更高的磁盘 I /O（能够通过 iostat 来确认）以及更蹩脚的磁盘性能。下面的示例看起来不错，每个值都有许多兆字节。

-/+ buffers/cache为已用内存和可用内存提供更加清晰的形容。Linux 将局部闲暇内存用作缓存，然而在应用程序须要时能够疾速回收。因而，用作缓存的内存应该应该以某种形式蕴含在 free 这一列，-/+ buffers/cache这一行就是做这个事件的。

下面这一段翻译，可能比拟形象，感觉说的不像人话，老许来转述成人能了解的话：

total = used + free

used = (-/+ buffers/cache 这一行 used 对应列) + buffers + cached

=> 24545 = 23944 + 59 + 541

free = (-/+ buffers/cache 这一行 free 对应列) – buffers – cached

=> 221453 = 222053 – 59 – 541

如果在 Linux 应用了 ZFS 会令人更加纳闷（就像咱们对某些服务所做的一样），因为 ZFS 有本人的文件系统缓存。而 free -m 并不能正确反应该文件系统缓存。它可能体现为，零碎可用内存有余，而实际上该内存可依据须要从 ZFS 缓存中应用。

ZFS: Zettabyte File System, 也叫动静文件系统，更多信息见百度百科

sar -n DEV 1

$ sar -n DEV 1
Linux 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 的承受速度达到 22Mbyte/s（176Mbit/s），该值远低于 1Gbit/ s 的限度。

原文中无 rxkB/ s 和 txkB/ s 的解释，老许特意找了使用手册中的阐明。

这个版本还有 %ifutil 作设施利用率，这也是咱们应用 Brendan 的 nicstat 工具来测量的。和 nicstat 工具一样，这很难正确，而且本例中看起来该值并不起作用。

老许试了一下本人的云服务发现 %ifutil 指标并不一定都有。

sar -n TCP,ETCP 1

$ sar -n TCP,ETCP 1
Linux 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 连接数通常用于服务器负载的粗略度量。将 active 视为向外的连贯，passive 视为向内的连贯可能会有帮忙，但这样辨别并不严格（例如，localhost 连贯到 localhost）。

重传是网络或服务器出问题的迹象。它可能是不牢靠的网络（例如，公共 Internet），也可能是因为服务器过载并抛弃了数据包。下面的示例显示每秒仅一个新的 TCP 连贯。

top

$ top
top - 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 持续），随着屏幕的革除间歇性问题的证据很有可能失落。

最初，衷心希望本文可能对各位读者有肯定的帮忙。

翻译原文

https://netflixtechblog.com/l…

正文完
linux
发表至： linux
2021-02-10
 0
关于linux:安装linux的问题
关于linux:centos7下docker安装记录
关于linux:故障分析-是谁偷走了我的-IO
小鸟初学Shell编程六变量赋值