来自公众号：新世界杂货铺
本着“拿来主义”的精力，排汇别人短处为己用。老许翻译一篇Linux性能剖析相干的文章分享给各位读者，同时也加深本人的印象。
你登录到具备性能问题的Linux服务器时，第一分钟要查看什么？
在Netflix，咱们领有宏大的Linux EC2云实例，以及大量的性能剖析工具来监督和考察它们的性能。这些工具包含Atlas和Vector。Atlas用于全云监控，Vector用于按需实例剖析。这些工具能帮忙咱们解决大部分问题，但有时候咱们仍需登录实例并运行一些规范的Linux性能工具。
Atlas：依据github下面的文档老许简略说一下本人的认知。一个能够治理基于工夫维度数据的后端，同时具备内存存储性能能够十分疾速地收集和报告大量指标。
Vector：Vector是一个主机上的性能监督框架，它能够将各种指标展现在工程师的浏览器下面。
总结
在这篇文章中，Netflix性能工程团队将向您展现通过命令行进行性能剖析是，前60秒应该应用那些Linux规范工具。在60秒内，你能够通过以下10个命令来全面理解系统资源应用状况和正在运行的过程。首先寻找谬误和饱和指标，因为他们很容易了解，而后是资源利用率。饱和是指资源负载超出其解决能力，其能够体现为一个申请队列的长度或者等待时间。
<code class="bash">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
<code class="bash">$ 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
<code class="bash">$ 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
<code class="bash">$ 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
<code class="bash">$ 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
<code class="bash">$ 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
<code class="bash">$ 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
<code class="bash">$ 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
<code class="bash">$ 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
<code class="bash">$ 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
<code class="bash">$ 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…
转载请注明原文链接：1分钟内的Linux性能分析法
