60,000毫秒诊断Linux性能当您登录到Linux服务器以解决性能问题时：您应该在第一分钟检查什么？在Netflix，我们有一个巨大的EC2Linux云，以及大量用于监控和诊断其性能的分析工具。其中包括用于云监控的Atlas和用于按需实例分析的Vector。虽然这些工具可以帮助我们解决大多数问题，但有时我们需要登录服务器实例并运行一些标准的Linux性能工具。在本文中，Netflix性能工程团队将引导您完成前60秒在命令行中运行可靠的性能分析，使用您应该能够掌握的标准Linux工具。前六十秒：概览通过运行以下十个命令，你可以大致了解六十秒内系统的运行进程和资源使用情况。通过查看这些命令的错误消息和资源饱和度输出（它们都很容易阅读），然后您可以优化资源。饱和是指资源的加载超出了它的处理能力。一旦发生饱和，通常会表现在请求队列的长度或等待时间上。正常运行时间dmesg|tailvmstat1mpstat-PALL1pidstat1iostat-xz1free-msar-nDEV1sar-nTCP,ETCP1top其中一些命令需要预先安装sysstat包。这些命令显示的信息可以帮助你实现USE方法（一种定位性能瓶颈的方法），比如查看各种资源（如CPU、内存、磁盘等）的使用情况、饱和度、错误信息等。另外，在定位问题的过程中，可以通过这些命令排除一些引起问题的可能性，帮助您缩小排查范围，为下一步排查指明方向。后续章节将以在生产环境中执行这些命令为例，对这些命令进行简要介绍。如果想详细了解这些工具的使用方法，请参考它们的man文档。1.uptime$uptime23:51:26up21:31,1user,loadaverage:30.02,26.43,19.02这是一种快速查看系统平均负载的方法，表示系统中有多少任务（进程）要运行.在Linux系统上，这些数字包括需要在CPU上运行的进程以及等待I/O（通常是磁盘I/O）的进程。这只是系统负载的粗略指示，稍微看一下就可以了。您还需要其他工具来了解更多细节。这三张图显示了在一分钟、五分钟和十五分钟内对系统的总平均负载进行指数压缩得到的结果。从这里我们可以看出系统的负载是如何随时间变化的。比如你在检查一个问题，看到1分钟对应的值比15分钟的值小很多，那么可能说明这个问题已经过去了，你没有及时观察。在上面的例子中，系统负载随着时间的推移而增加，因为最近一分钟的负载值超过了30，而15分钟的平均负载只有19。如此显着的差距有很多含义，例如CPU负载。进一步确认，运行vmstat或mpstat命令，这两个命令请参考后面的第3章和第4章。2.dmesg|尾巴$dmesg|尾部[1880957.563150]perlinvokedoom-killer：gfp_mask=0x280da，order=0，oom_score_adj=0[...][...][...][1880957.563400],anon-rss:1953348kB,file-rss:0kB[2320864.954447]TCP:PossibleSYNfloodingonport7001.Droppingrequest.CheckSNMPcounters。此命令显示最后10条系统消息（如果存在）。查找可能导致性能问题的错误。上面的例子包含oom-killer，TCP丢弃了一个请求。不要错过这一步！dmesg命令总是值得一试。3.vmstat1$vmstat1procs--------内存------------swap--------io-----system--------cpu-----rbswpdfreebuffcachesisobiboincsussyidwast3400200889792737085918280005610961300320020088992073708591860000592132844282981100320020089011273708591860000095012154991000320020088956873712591856000481190024599900003200200890208737125918600000158984840981100^Cvmstat(8)是虚拟内存统计的简称，其是一个常用工具（几十年前为了BSD所创建）。Itprintsasummaryofkeyserverstatisticsperline.vmstat命令以参数1运行，每秒打印一次统计摘要。（此版本的vmstat）输出的第一行的列是自引导以来的平均值，而不是前一秒的值。现在，让我们跳过第一行，除非您想理解并记住每一列。检查这些列：r：CPU中正在运行和等待运行的进程数。它提供比平均负载更好的信号来确定CPU是否饱和，因为它不包括I/O。解释：“r”的值大于CPU个数，表示已经饱和。free：以kb为单位的显式空闲内存。如果数字有很多数字，则您有足够的可用内存。“free-m”命令是下面的第七条命令，可以更好的说明freememory的状态。si,so：换入和换出。如果它们不为零，则说明内存不足。us,sy,id,wa,st：这些是所有CPU的平均CPU故障时间。它们是用户时间（user）、系统时间（kernel）（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”列中的饱和度。4.mpstat-PALL1$mpstat-PALL1Linux3.13.0-49-generic(titanclusters-xxxxx)07/14/2015_x86_64_(32CPU)07:38:49PMCPU%usr%nice%sys%iowait%irq%soft%steal%guest%gnice%idle07:38:50PMall98.470.000.750.000.000.000.000.000.000.7807:38:50PM096.040.002.970.000.000.000.000.000.000.9907:38:50PM197.000.001.000.000.000.000.000.000.002.0007:38:50PM298.000.001.000.000.000.000.000.000.001.0007:38:50PM396.970.000.000.000.000.000.000.000.003.03[…]此命令打印每个CPU的CPU拆分时间，这对于不平衡的使用很有用检查情况.单个CPU繁忙意味着单线程应用程序正在运行。5.pidstat1$pidstat1Linux3.13.0-49-generic(titanclusters-xxxxx)07/14/2015_x86_64_(32CPU)07:41:02PMUIDPID%usr%system%guest%CPPUCPUCommand07:41:03PM090.000.940.000.941rcuos/007:41:03PM042145.665.660.0011.3215mesos-slave07:41:03PM043540.940.940.001.898java07:41:03PM065211596.231.890.001598.1127java07:41:03PM065641571.707.550.001579.2528java07:41:03PM60004601540.944.720.005.669pidstat07:41:03PMUIDPID%usr%system%guest%CPUCPUCommand07:41:04PM042146.002.000.008.0015mesos-slave07:41:04PM065211590.001.000.001591.0027java07:41:04PM065641573.0010.000.001583.0028java07:41:04PM10867181.000.000.001.000snmp-pass07:41:04PM60004601541.004.000.005.009pidstat^Cpidstat这个命令有点像top命令对每个进程的统计汇总，但是它循环打印一个滚动的统计汇总，而不是top的屏幕刷新。它可用于实时查看，也可用于（复制粘贴）您在调查日志中看到的内容。上面的例子显示了两个Java进程正在消耗CPU。%CPU列是所有CPU的总和；1591%表示这个Java进程消耗了将近16个CPU。6.iostat-xz1$iostat-xz1Linux3.13.0-49-generic(titanclusters-xxxxx)07/14/2015_x86_64_(32CPU)avg-cpu:%user%nice%system%iowait%steal%idle73.960.003.730.030。0622.21Device:rrqm/swrqm/sr/sw/srkB/swkB/savgrq-szavgqu-szawaitr_awaitw_awaitsvctm%utilxvda0.000.230.210.184.522.0834.370.009.9813.805.422.440.09xvdb0.010.001.028.94127.97598.53145.790.000.431.780.280.250.25xvdc0.010.001.028.86127.79595.94146.500.000.451.820.300.270.26dm-00.000.000.692.3210.4731.6928.010.013.230.713.980.130.04dm-10.000.000.000.940.013.788.000.33345.840.04346.810.010.00dm-20.000.000.090.071.350.3622.500.002.550.235.621.780.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，这样应用程序就不会阻塞和遭受延迟（例如，预读和写缓冲）。7.free-m$free-mtotalusedfreesharedbufferscachedMem:245998245452214538359541-/+buffers/cache:23944222053Swap:000右边两列显示：bu??ffers：buffercacheforblockdeviceI/O。cached：文件系统的页面缓存。我们只想检查这些非零大小，这会导致更高的磁盘I/O（已通过iostat确认）和更差的性能。上面的例子看起来不错，每列有很多M大小。与第一行相比，-/+buffers/cache将提供更准确的内存使用情况。Linux会把暂时不用的内存作为缓存，应用需要的时候再重新分配。所以用作缓存的部分内存实际上是空闲内存。甚至还有一个专门解释这个的网站：linuxatemyram。如果您在Linux上安装了ZFS，这会变得更加混乱，因为ZFS自己的文件系统缓存不计入free-m。有时会发现系统并没有多少可用的空闲内存，但这些内存实际上是在ZFS缓存中。8.sar-nDEV1$sar-nDEV1Linux3.13.0-49-generic(titanclusters-xxxxx)07/14/2015_x86_64_(32CPU)12:16:48AMIFACEErxpck/stxpck/srxkB/stxkB/srxcmp/stxcmp/srxmcst/s%ifutil12:16:49AMeth018763.005032.0020686.42478.300.000.000.000.0012:16:49AMlo14.0014.001.361.360.000.000.000.0012:16:49AMdocker00.000.000.000.000.000.000.000.0012:16:49AMIFACErxpck/stxpck/srxkB/stxkb/srxcmp/stxcmp/srxmcst/s％ifutil12：16：50AMETH019763.005101.0021999.10482.560.000.000.000.000.000.000.000.000.0012：16：16：16：50AMLO20.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.000.00012;这个工具可以用来检查网络接口的吞吐量：rxkB/s和txkB/s，以及是否达到限制。在上面的例子中，eth0接收到的流量达到了22Mbytes/s，即176Mbits/sec（限制为1Gbit/sec）。我们使用的版本还提供了%ifutil作为deviceusage（接收和发送的最大值）的索引。我们还可以使用Brendan的nicstat工具测量该值。与nicstat一样，sar显示的值很难准确获取，在这种情况下它不能正常工作(0.00)。9.sar-nTCP,ETCP1$sar-nTCP,ETCP1Linux3.13.0-49-generic(titanclusters-xxxxx)07/14/2015_x86_64_(32CPU)12:17:19AMactive/spassive/siseg/soseg/s12:17:20AM1.000.0010233.0018846.0012:17:19AMatmptf/sestres/sretrans/sisegerr/sorsts/s12:17:20AM0.000.000.000.000.0012:17:20AMactive/spassive/siseg/soseg/s12:17:21AM17:020AM17:020/sestres/sretrans/sisegerr/sorsts/s12:17:21AM0.000.000.000.000.00^C这是一些关键TCP指标的摘要视图。其中包括：active/s：每秒本地启动的TCP连接数（例如，通过connect()）。passive/s：每秒远程发起的TCP连接数（例如，通过accept()）。retrans/s：TCP每秒重传次数。主动和被动连接数对于描述服务器负载的粗略度量通常非常有用：新接受的连接数（被动），下行连接数（主动）。可以理解为主动连接是外部的，被动连接是内部的，尽管严格来说这并不完全正确（例如，从本地主机到本地主机的连接）。重新传输是网络和服务器问题的征兆。可能是网络不可靠（比如公网），也可能是服务器过载丢包。上面的例子显示每秒只有一个新的TCP连接。10.top$toptop-00:15:40up21:56,1user,loadaverage:31.09,29.87,29.92Tasks:871total,1running,868sleeping,0stopped,2zombie%Cpu(s):96.8us,0.4sy,0.0ni,2.7id,0.1wa,0.0hi,0.0si,0.0stKiBMem:25190241+total,24921688used,22698073+free,60448buffersKiBSwap:0total,0used,0free.554208cachedMemPIDUSERPRNIVIRTRESSHRS%CPU%MEMTIME+COMMAND20248root2000.227t0.012t18748S30905.229812:58java4213root20027225446464044232S23.50.0233:35.37mesos-slave66128titancl+2002434423321172R1.00.00:00.07top5235root20038.227g54700449996S0.70.22:02.74java4299root20020.015g2.682g16836S0.31.133:14.42java1root2003362029201496S0.00.00:03.82init2root200000S0.00.00:00.02kthreadd3root200000S0.00.00:05.35ksoftirqd/05root0-20000S0.00.00:00.00kworker/0:0H6root200000S0.00.00:06.94kworker/u256:08root200000S0.00.02:38.05rcu_schedtop命令包括我们之前检查过的许多指标。方便的执行一下可以看到和之前命令的输出差别很大，说明负载是可变的。top的一个缺点是很难看到数据随时间变化的趋势。vmstat和pidstat提供的滚动输出更清晰一些。如果您暂停输出的速度不够快（Ctrl-S暂停，Ctrl-Q继续），一些间歇性问题的线索也可能会因清除屏幕而丢失。后续分析有更多的命令和方法可以用于更深入的分析。查看Velocity2015中Brendan的Linux性能工具教程，其中包括40多个命令，涵盖可观察性、基准测试、调优、静态性能调优、分析和跟踪。
