当你因为一个问题登录Linux服务器做性能分析时：第一分钟你会做哪些测试？在Netflix，我们有很多EC2Linux机器，我们也需要很多性能分析工具来监控和检查它们的性能。它包括云监控工具Atlas和按需执行实例分析的Vector。虽然这些工具可以帮助我们解决大部分问题，但有时我们需要登录机器实例来运行一些标准的Linux性能分析工具。前60秒：总结在本文中，Netflix的性能分析工程师团队将向您展示如何使用现有的Linux标准工具在命令行模式下执行前60秒的性能优化检测。只需在60秒内运行以下10条命令，您就可以深入了解系统资源使用情况和正在运行的进程。查找错误消息和饱和度指示器，并且可以显示为请求队列的长度或等待时间。因为它们都很容易理解，然后就是资源利用。饱和是指资源超出其容量。uptimedmesg|tailvmstat1mpstat-PALL1pidstat1iostat-xz1free-msar-nDEV1sar-nTCP,ETCP1top部分命令需要安装sysstat工具包。这些命令显示的指标会帮助你完成一些USE（Utilization、Saturation、Errors）方法：一种定位性能瓶颈的方法论。包括检查所有资源（如CPU、内存、磁盘等）的利用率（Utilization）、饱和度（Saturation）、错误指标（Errors）。还要注意何时检查和解决资源问题，因为排除会缩小分析范围并指导任何后续检查。以下部分将通过生产系统中的示例介绍这些命令。要了解有关这些工具的更多信息，您还可以查看它们的帮助手册。1.uptime$uptime23:51:26up21:31,1user,loadaverage:30.02,26.43,19.02这是显示系统平均负载的快速方法，它还指示等待运行的进程数。在Linux系统上，这些数字包括等待CPU运行的进程，以及被不间断I/O（通常是磁盘I/O）阻塞的进程。这提供了一个非常直接的资源负载视图，无需其他工具的帮助就可以更好地理解数据。这是查看系统负载的唯一快捷方式。这三个数字是过去1分钟、5分钟和15分钟的恒定平均值，按降序排列。这三个数字为我们提供了系统负载如何随时间变化的直观表示。例如，如果您被叫去检查有问题的服务器，而1分钟代表的值比15分钟低得多，您可能因为太晚登录机器而错过了问题发生的时间点。在上面的示例中，显示平均负载正在增加，1分钟的值为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问题的进程和丢弃TCP请求。所以记得用这个命令，dmesg命令值得一用。3.vmstat1$vmstat1procs--------内存------------swap--------io-----system--------cpu-----rbswpdfreebuffcachesisobiboincsussyidwast3400200889792737085918280005610961300320020088992073708591860000592132844282981100320020089011273708591860000095012154991000320020088956873712591856000481190024599900003200200890208737125918600000158984840981100^C对虚拟内存统计的简短展示，vmstat是一个常用工具(最早是几十年前为BSD创建的)。Itprintsasummaryofkeyservicestatisticsperline.当vmstat以参数1运行时，它每1秒打印一次统计信息。在此版本的vmstat中，第一行输出显示自引导以来的平均值，而不是前一秒。所以现在，您可以跳过第一行，除非您想查看标题中字段的含义。各列含义解释：r：等待在CPU上运行的可运行进程数。该指标提供了判断CPU饱和度的数据，因为它不包括等待I/O的进程。可以理解为：当“r”的值大于CPU数量时，就饱和了。free：空闲内存，单位为k。如果这个数字比较大，说明你还有足够的空闲内存。“free-m”和下面的第七条命令可以更详细地分析空闲内存的状态。si,so：交换进出的数据量。如果这两个值不为零，则表示没有内存。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”列检查饱和度。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命令中统计每个CPU信息的功能，但它是以滚动更新的方式打印信息，而不是每次都清屏。这对于随着时间的推移观察模式很有用，同时将您看到的信息记录（复制粘贴）到您的调查笔记中。从上面的例子可以看出有2个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：表示读写次数和设备每秒读写的字节数（单位为k字节）。这些都可以看出设备的负载情况。性能问题可能仅仅是由于大量的文件加载请求。await：I/O等待的平均时间（以毫秒为单位）。这是应用程序等待的时间，包括在等待队列中的时间和预定服务的时间。平均等待时间过大说明设备过载或设备有问题。avgqu-sz：设备上的平均请求数。大于1的值可能表示设备已饱和（尽管设备通常能够支持并行请求，尤其是背面挂有多个磁盘的虚拟设备）。%util：设备利用率。是利用率的百分比，表示设备每秒工作的时间。如果这个值大于60%，性能会很低（可以在await中看到），当然也要看设备的特性。接近100%的值表示设备已饱和。如果存储设备是一个逻辑磁盘设备，后面挂载了多个磁盘，那么100%的利用率只是意味着一些I/O正在以100%的速度处理，但后端磁盘可能还远未饱和，可以处理更多要求。请记住，低磁盘I/O性能不一定是应用程序问题。许多技术通常用于异步执行I/O，因此应用程序不会直接阻塞和遭受延迟（例如：预读和写缓冲技术）。7.free-m$free-mtotalusedfreesharedbufferscachedMem:245998245452214538359541-/+buffers/cache:23944222053Swap:右边两列显示：bu??ffers：用于块设备I/O缓冲的缓存。cached：文件系统的页面缓存。我们只想检查这些缓存的值是否接近于0。除0之外的任何值都可能导致高磁盘I/O（通过iostat命令确认）和性能不佳的问题。上面的例子看起来不错，两者都有很多Mbytes。“-/+buffers/cache”行提供了关于已用和空闲内存的明确统计信息。Linux使用空闲内存作为缓存，如果应用程序需要它可以快速取回。所以空闲内存这一列应该包括在内，这里就是这样计算的。甚至还有一个专门介绍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:48AMIFACErxpck/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.0012：16：16：50AMLOLLOE这个工具可以检测网络接口的吞吐量：rxkB/s和txkB/s，作为发送和接收数据负载的衡量标准，它还会检测是否已经达到发送和接收限制。在上面的例子中，eth0以22Mbytes/sec的速度接收数据，也就是176Mbit/sec（网卡的上限是1Gbit/sec）。该版本的工具还有一个统计字段：%ifutil，用于统计设备利用率（全双工双向最大值），也可以使用Brendan的nicstat工具进行测量。在此示例中，0.00似乎没有统计信息。这个和nicstat是一样的，这个值很难统计正确。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：每秒远程发起的连接数（比如通过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是继续），那么这些有用的信息就会被清除掉。Follow-onAnalysis还有许多命令和技术可用于更深入地挖掘系统问题。你可以看看Brendan在2015年谈到的Linux性能工具的介绍，它描述了40多个命令，涵盖了可观察性和基准测试。、调优、静态性能调优、剖析和跟踪等诸多方面。原文：https://netflixtechblog.com/linux-performance-analysis-in-60-000-milliseconds-accc10403c55
