Linux性能分析和工具
来源 https://zhuanlan.zhihu.com/p/304768833
上面这张神一样的图出自国外一个Lead Performance Engineer(Brendan Gregg)的一次分享，几乎涵盖了一个系统的方方面面，任何人，如果没有完善的计算系统知识，网络知识和操作系统的知识，这张图中列出的工具，是不可能全部掌握的。
出于本人对linux系统的极大兴趣，以及对底层知识的强烈渴望，并作为检验自己基础知识的一个指标，我决定将这里的所有工具学习一遍（时间不限），这篇文章将作为我学习这些工具的学习笔记。尽量组织得方便自己日后查阅，并希望对别人也有一定帮助。
这里所有的工具，都可以通过man 获得它的帮助文档，这里只介绍一些常规用法。
注意：文中所有的interval都是指收集数据的间隔时间，times是指采样次数。例如
vmstat interval times将命令中的interval和times替换成数字：
vmstat 3 5上面语句的意思就是每3秒中输出一次内存统计数据，共输出5次。
Tools: Basic & Intermediate
vmstat
我们先看一个vmstat 的例子。用下面的命令让它每5秒中打印一个报告。
可以用ctrl+c停止vmstat。vmstat的常规用法是vmstat interval times，即每隔interval秒采 样一次，共采样times次，如果省略times，则一直采集数据到用户手动停止。
第一行的值是显示了自系统启动以来的平均值，第二行开始展示现在正在发生的情况，接下来的行会显示每5秒的间隔内发生了什么。每一列的含义在头部，如下所示：
- procs
r这一列显示了多少进程正在等待cpu，b列显示多少进程正在不可中断的休眠（通常意味着它们在等待IO ，例如磁盘，网络，用户输入，等等）。
- memory
swapd列显示了多少块被换出到了磁盘（页面交换）。剩下的三个列显示了多少块是空闲的（未被使用），多少块正在被用作缓冲区，以及多少正在被用作操作系统的缓存。
- swap
这些列显示页面交换活动：每秒有多少块正在被换入（从磁盘）和换出（到磁盘）。它们比监控swpd列重要多了。大部分时间我们希望看到si 和so 列是0,并且我们很明确不希望看到每秒超过10个块。
- io
这些列显示了多少块从块设备读取(bi)和写出(bo)。这通常反映了硬盘I/O。
- system
这些列显示了每秒中断(in)和上下文切换(cs)的数量。除非上下文切换超过100 000次或更多，一般不用担心上下文切换。
- cpu
这些列显示所有的CPU时间花费在各类操作的百分比，包括执行用户代码（非内核），执行系统代码（内核），空闲以及等待IO。如果正在使用虚拟化，第5列可能是st，显示了从虚拟机中"偷走"的百分比。
内存不足的表现：free memory 急剧减少，回收buffer和cache也无济于事，大量使用交换分区（swpd），页面交换(swap)频繁，读写磁盘数量(io)增多，缺页中断(in)增多，上下文切换(cs)次数增多，等待IO的进程数(b)增多，大量CPU时间用于等待IO(wa)。
iostat
现在让我们转移到iostat 。默认情况下，它显示了与vmstat 相同的CPU 使用信息。我们通常只对I/O统计感兴趣，所以使用下面的命令只展示扩展的设备统计。
与vmstat一样，第一行报告显示的是自系统启动以来的平均值，（通常删掉它节省空间），然后接下来的报告显示了增量的平均值，每个设备一行。
有多种选项显示和隐藏列。官方文档有点难以理解，因此我们必须从源码中挖掘真正显示的内容是什么。说明的列信息如下：
为了看懂Linux的磁盘IO指标，先了解一些常见的缩写习惯：rq是request，r是read，w是write，qu是queue，sz是size的，a是average，tm是time，svc是service。
- rrqm/s 和 wrqm/s
每秒合并的读和写请求。"合并的"意味着操作系统从队列中拿出多个逻辑请求合并为一个请求到实际磁盘。 - r/s 和 w/s
每秒发送到设备的读和写请求数。 - rsec/s 和 wsec/s
每秒读和写的扇区数。有些系统也输出为rKB/s和wKB/s ，意味每秒读写的千字节数。(iostat -dkx interval times) - avgrq-sz
请求的扇区数。(读扇区数 + 写扇区数) / (读请求次数 + 写请求次数) - avgqu-sz
在设备队列中等待的请求数。即队列的平均长度。 - await
每个IO请求花费的时间，包括在队列中的等待时间和实际请求（服务）时间。 - svctm
实际请求（服务）时间，以毫秒为单位，不包括排队时间。 - %util
至少有一个活跃请求所占时间的百分比。更好的说法应该是，服务时间所占的百分比。以上面的输出为例。 一秒中内，读了2.5次，写了1.8次，每次请求的实际请求时间（不包括排队时间）为6.0ms,那么总的时间花费为(2.5+1.8)*6.0ms，即25.8ms，0.0258秒，转换成百分比再四舍五入就得到了util的值2.6%。
%util: When this figure is consistently approaching above 80% you will need to take any of the following actions - - increasing RAM so dependence on disk reduces
- increasing RAID controller cache so disk dependence decreases
- increasing number of disks so disk throughput increases (more spindles working parallely)
- horizontal partitioning
下面这个公式可以计算一个请求在整个请求期间，有多少时间用以等待。当这个值大于50%，说明整个请求期间，花费了更多时间在队列中等待；如果这个数很大，则应该采取相应措施。
- (await-svctim)/await*100: The percentage of time that IO operations spent waiting in queue in comparison to actually being serviced. If this figure goes above 50% then each IO request is spending more time waiting in queue than being processed. If this ratio skews heavily upwards (in the >75% range) you know that your disk subsystem is not being able to keep up with the IO requests and most IO requests are spending a lot of time waiting in queue. In this scenario you will again need to take any of the actions above
IO瓶颈的症状： 1. %util 很高 2. await 远大于svctm 3. avgqu-sz 比较大
下面解释了iowait的作用，需要注意的是，高速CPU也可能导致iowait取值较大。
- %iowait: This number shows the % of time the CPU is wasting in waiting for IO. A part of this number can result from network IO, which can be avoided by using an Async IO library. The rest of it is simply an indication of how IO-bound your application is. You can reduce this number by ensuring that disk IO operations take less time, more data is available in RAM, increasing disk throughput by increasing number of disks in a RAID array, using SSD (Check my post on Solid State drives vs Hard Drives) for portions of the data or all of the data etc
上面的解释主要参考《高性能mysql》和这篇博客。
cpu 密集型机器
cpu 密集型服务器的vmstat 输出通常在us 列会有一个很高的值，报告了花费在非内核代码上的cpu 时钟；也可能在sy 列有很高的值，表示系统cpu 利用率，超过20% 就足以令人不安了。在大部分情况下，也会有进程队列排队时间（在r列报告的）。下面是一个列子：
如果我们在同一台及其上观察iostat 的输出（再次剔除显示启动以来平均值的第一行），可以发现磁盘利用率低于50%：
这台机器不是IO密集型的，但是依然有相当数量的IO发生，在数据库服务器中这种情况很少见。另一方面，传统的Web 服务器会消耗掉大量的CPU 资源，但是很少发生IO,所以Web 服务器的输出不会像这个例子。
IO 密集型机器
在IO密集型工作负载下，CPU花费大量时间在等待IO请求完成。这意味着vmstat 会显示很多处理器在非中断休眠(b列)状态，并且在wa 这一列的值很高，下面是个例子：
这台机器的iostat 输出显示硬盘一直很忙：
%util的值可能因为四舍五入的错误超过100%。什么迹象意味着机器是IO密集的呢？只要有足够的缓冲来服务写请求，即使机器正在做大量的写操作，也可能可以满足，但是却通常意味着硬盘可能会无法满足读请求。这听起来好像违反直觉，但是如果思考读和写的本质，就不会这么认为了：
- 写请求能够缓冲或同步操作。
- 读请求就其本质而言都是同步的。当然，程序可以猜测到可能需要某些数据，并异步地提前读取（预读）。无论如何，通常程序在继续工作前必须得到它们需要的数据。这就强制读请求为同步操作：程序必须阻塞直到请求完成。
想想这种方式：你可以发出一个写请求到缓冲区的某个地方，然后过一会完成。甚至可以每秒发出很多这样的请求。如果缓冲区正确工作，并且有足够的空间，每个请求都可以很快完成，并且实际上写到物理硬盘是被重新排序后更有效地批量操作的。然而，没有办法对读操作这么做————不管多小或多少的请求，都不可能让硬盘响应说："这是你的数据，我等一会读它"。这就是为什么读需要IO等待是可以理解的原因。
发生内存交换的机器
一台正在发生内存交换的机器可能在swpd 列有一个很高的值，也可能不高。但是可以看到si 和 so 列有很高的值，这是我们不希望看到的。下面是一台内存交换严重的机器的vmstat 输出：
空闲的机器
下面是一台空闲机器上的vmstat输出。可以看到idle列显示CPU是100%的空闲。
dstat
dstat 显示了cpu使用情况，磁盘io 情况，网络发包情况和换页情况。
个人觉得，iostat和vmstat 的输出虽然详细，但是不够直观，不如dstat 好用。而且，dstat输出是彩色的，可读性更强。现在dstat作为我首选的，查看系统状态的工具。
dstat使用时，直接输入命令即可，不用任何参数。也可以通过指定参数来显示更加详细的信息。
dstat -cdlmnpsy
iotop
通过iostat和dstat我们可以知道系统的当前IO负载，但是IO负载具体是由哪个进程产生的呢？这时候我们需要的是iotop.
iotop是一个用来监视磁盘I/O使用状况的top类工具,具有与top相似的UI，其中包括PID、用户、I/O、进程等相关信息。 iotop使用Python语言编写而成，要求Python 2.5（及以上版本）和Linux kernel 2.6.20（及以上版本）。使用非常简单，在此不做过多介绍，详细信息参见官网：http://guichaz.free.fr/iotop/
这个命令也可以以非交互的方式使用：
iotop -bod interval查看每个进程的IO,也可以通过pidstat命令，不像iotop，且pidstat还不需要root权限。
pidstat -d interval
pidstat
了解系统IO的情况大多数是通过iostat来获取的，这个粒度只能精确到每个设备。通常我们会想了 解每个进程,线程层面发起了多少IO，在Linux 2.6.20之前除了用systemtap这样的工具来实现 是没有其他方法的，因为系统没有暴露这方面的统计。现在可以通过一个名为pidstat的工具， 它的使用方法如下：
pidstat -d interval此外，pidstat 还可以用以统计CPU使用信息。
pidstat -u interval统计内存信息：
pidstat -r interval
top
top 命令的汇总区域显示了五个方面的系统性能信息： 1. 负载：时间，登录用户数，系统平均负载 2. 进程：运行，睡眠，停止，僵尸 3. CPU ：用户态，核心态，NICE，空闲，等待IO，中断等 4. 内存：总量，已用，空闲（系统角度），缓冲，缓存 5. 交换分区：总量，已用，空闲
任务区域默认显示：进程ID，有效用户，进程优先级，NICE值，进程使用的虚拟内存，物理内存和共享内存，进程状态，CPU 占用率，内存占用率，累计CPU时间，进程命令行信息。
htop
另一个更好用的top的替代工具是htop,htop是Linux系统中的一个互动的进程查看器，一个文本模式的应用程序(在控制台或者X终端中)，需要ncurses。
与Linux传统的top相比，htop更加人性化。它可让用户交互式操作，支持颜色主题，可横向或纵向滚动浏览进程列表，并支持鼠标操作。
与top相比，htop有以下优点：
- 可以横向或纵向滚动浏览进程列表，以便看到所有的进程和完整的命令行。
- 在启动上，比top 更快。
- 杀进程时不需要输入进程号。
- htop 支持鼠标操作。
mpstat
mpstat 用来统计多核处理器中，每一个处理器的使用情况。mpstat使用方法很简单，常见用法如下：
mpstat -P ALL interval times不出意外，读者执行上面的命令，看不出个所以然来，试试在运行下面这条命令的同时，查看mpstat的输出。
sysbench --test=cpu --cpu-max-prime=20000 run注意：sysbench是一个基准测试工具，可以用来测试cpu,io,mutex,oltp等。在Debain系统下， 通过下面的命令安装：
sudo apt-get install sysbench
netstat
netstat用于显示与IP、TCP、UDP和ICMP协议相关的统计数据，一般用于检验本机各端口的网络连接情况。
就我自己而言，经常使用的用法如下：
netstat -npl上面这条命令可以查看你要打开的端口是否已经打开，以此来作为程序是否已经启动的依据。
netstat 还有很多其他的用法，在《TCP/IP详解》一书中，作者喜欢用netstat命令来打印路由表，使用方法如下：
netstat -rn其中，flag域的解释如下：
- U 该路由可用
- G 该路由是到一个到网关（路由器）。如果没有设置该标志，说明目的地址是直接相连的
- H 该路由是到一个主机
- D 该路由是由重定向报文创建
- M 该路由已被重定向报文修改
netstat 也可以提供系统上的接口信息：
netstat -in这个命令打印每个接口的MTU,输入分组数，输入错误，输出分组数，输出错误，冲突以及当前的输出队列的长度。
ps
最最常用的用法
ps aux #BSD
ps -ef #linuxps 参数太多，具体使用方法，请man ps，下面是两种相对常用的使用方式。
- 杀掉某一程序的方法。
ps aux | grep mysqld | grep -v grep | awk '{ print $2 }' | xargs kill -9 - 杀掉僵尸进程：
ps -eal | awk '{ if ($2 == "Z" ){ print $4}}' | xargs kill -9
strace
用我自己的理解来介绍strace:
我们写程序，会调用很多库函数，而这些库函数，只是对系统调用的封装，它们最后都会去调用操作系统提供的系统调用，通过系统调用去访问硬件设备。strace的作用就是显示出这些调用关系，让程序员知道调用一个函数，它到底做了些什么事情。当然，strace 远比上面的介绍灵活多变。
下面来看一个例子：
查看mysqld 在linux上加载哪种配置文件，可以通过运行下面的命令行：
strace -e stat64 mysqld --print-defaults > /dev/nullstrace太强大，内容也太多了，我找到一篇比较好的，介绍strace的文章，请点击这里。
uptime
uptime是最最最最简单的工具了，但是也有值得讨论的地方，那就是它最后输出的三个数字是怎么得来的，有什么含义？
这三个数字的含义分别是1分钟、5分钟、15分钟内系统的平均负荷，关于这些数字的含义和由来，推荐看阮一峰的文章《理解linux系统负荷这里》。
我想说的是，这三个数字我天天看，时时看，但是我从来不相信它。
此话怎讲呢？我之所以天天看，时时看，是因为我将这三个数字显示到了tmux 的状态栏上，所以，我任何时候都可以看到,而不用专门输入uptime这个命令。
为什么我不相信它呢，因为这几个数字只能说明有多少线程在等待cpu,如果我们的一个任务有很多线程，系统负载不是特别高，但是这几个数字会出奇的高，也就是不能完全相信uptime的原因。如果不信，可以执行下面这条语句，然后再看看uptime的输出结果。
sysbench --test=mutex --num-threads=1600 --mutex-num=2048 --mutex-locks=1000000 --mutex-loops=5000 run运行了5分钟以后，我的电脑上输出如下所示。需要强调的是，这个时候电脑一点不卡，看uptime来判断系统负载，跟听cpu风扇声音判断系统负载一样。只能作为线索，不能作为系统负载很高的依据。
20:32:39 up 10:21, 4 users, load average: 386.53, 965.37, 418.57《Linux Performance Analysis and Tools》里面也说了，This is only useful as a clue. Use other tools to investigate!
lsof
lsof（list open files）是一个列出当前系统打开文件的工具。在linux环境下，任何事物都以 文件的形式存在，通过文件不仅仅可以访问常规数据，还可以访问网络连接和硬件。所以如传输 控制协议(TCP)和用户数据报协议(UDP)套接字等，系统在后台都为该应用程序分配了一个文件描 述符，无论这个文件的本质如何，该文件描述符为应用程序与基础操作系统之间的交互提供了 通用接口。因为应用程序打开文件的描述符列表提供了大量关于这个应用程序本身的信息，因此 通过lsof工具能够查看这个列表对系统监测以及排错将是很有帮助的。
lsof 的使用方法可以参考这里。这里仅列出几种常见的用法。
- 查看文件系统阻塞 lsof /boot
- 查看端口号被哪个进程占用 lsof -i :3306
- 查看用户打开哪些文件 lsof -u username
- 查看进程打开哪些文件 lsof -p 4838
- 查看远程已打开的网络链接 lsof -i @192.168.34.128
参考资料：
---------------
Netflix性能分析模型：In 60 Seconds
来源 https://www.jianshu.com/p/fd6e35f529c1
Linux Performance Analysis in 60,000 Milliseconds
登陆一台 Linux 服务器排查性能问题：开始一分钟你该检查哪些呢？
在 Netflix 我们有一个庞大的 EC2 Linux集群，也有许多性能分析工具用于监视和检查它们的性能。它们包括用于云监测的Atlas (工具代号) ，用于实例分析的 Vector (工具代号) 。
尽管这些工具能帮助我们解决大部分问题，我们有时也需要登陆一台实例、运行一些标准的 Linux 性能分析工具。
在这篇文章，Netflix 性能工程团队将向您展示：在开始的60秒钟，利用标准的Linux命令行工具，执行一次充分的性能检查。
黄金60秒：概述
运行以下10个命令，你可以在60秒内，获得系统资源利用率和进程运行情况的整体概念。查看是否存在异常、评估饱和度，它们都非常易于理解，可用性强。饱和度表示资源还有多少负荷可以让它处理，并且能够展示请求队列的长度或等待的时间。
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包。
这些命令输出的指标，将帮助你掌握一些有效的方法：一整套寻找性能瓶颈的方法论。这些命令需要检查所有资源的利用率、饱和度和错误信息（CPU、内存、磁盘等）。同时，当你检查或排除一些资源的时候，需要注意在检查过程中，根据指标数据指引，逐步缩小目标范围。
接下来的章节，将结合生产环境的案例演示这些命令。如果希望了解这些工具的详细信息，可以查阅它们的操作文档。
1. uptime
$ uptime
23: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 将可以确认，本系列的第三和第四条命令。
2. 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-r
ss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP cou
nters.
这个结果输出了最近10条系统信息。
可以查看到引起性能问题的错误。上面的例子包含了oom-killer,以及TCP丢包。
PS:这个真的很容易忽略啊，真真的踩过坑！！ 另外，除了error级的日志，info级的也要留个心眼，可能包含一些隐藏信息。
[译者注：oom-killer]
一层保护机制，用于避免 Linux 在内存不足的时候不至于出太严重的问题，把无关紧要的进程杀掉，有些壮士断腕的意思
3. 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
vmstat 是一个获得虚拟内存状态概况的通用工具（最早创建于10年前的BSD）。它每一行记录了关键的服务器统计信息。
vmstat 运行的时候有一个参数1，用于输出一秒钟的概要数据。
第一行输出显示启动之后的平均值，用以替代之前的一秒钟数据。
现在，跳过第一行，让我们来学习并且记住每一列代表的意义。
r：正在CPU上运行或等待运行的进程数。
相对于平均负载来说，这提供了一个更好的、用于查明CPU饱和度的指标，它不包括I/O负载。注: “r”值大于CPU数即是饱和。
free: 空闲内存（kb)
如果这个数值很大，表明你还有足够的内存空闲。
包括命令7“free m”，很好地展现了空闲内存的状态。
si, so: swap入／出。
如果这个值非0，证明内存溢出了。
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 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，可以判断是属于单进程的应用程序。
5. 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 有一点像顶级视图－针对每一个进程，但是输出的时候滚屏，而不是清屏。
它非常有用，特别是跨时间段查看的模式，也能将你所看到的信息记录下来，以利于进一步的研究。
上面的例子识别出两个 java 进程引起的CPU耗尽。
“％CPU” 是对所有CPU的消耗；1591% 显示 java 进程占用了几乎16个CPU。
6. 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
[...]
这是一个理解块设备（磁盘）极好的工具，不论是负载评估还是作为性能测试成绩。
r/s, w/s, rkB/s, wkB/s: 这些是该设备每秒读％、写％、读Kb、写Kb。可用于描述工作负荷。一个性能问题可能只是简单地由于一个过量的负载引起。
await: I/O平均时间（毫秒）
这是应用程序需要的时间，它包括排队以及运行的时间。
远远大于预期的平均时间可以作为设备饱和，或者设备问题的指标。
avgqusz: 向设备发出的平均请求数。
值大于1可视为饱和（尽管设备能对请求持续运行，特别是前端的虚拟设备－后端有多个磁盘）。
%util: 设备利用率
这是一个实时的繁忙的百分比，显示设备每秒钟正在进行的工作。
值大于60%属于典型的性能不足（可以从await处查看），尽管它取决于设备。
值接近100% 通常指示饱和。
如果存储设备是一个前端逻辑磁盘、后挂一堆磁盘，那么100%的利用率也许意味着，一些已经处理的I/O此时占用100%，然而，后端的磁盘也许远远没有达到饱和，其实可以承担更多的工作。
切记：磁盘I/O性能低并不一定是应用程序问题。许多技术一贯使用异步I/O，所以应用程序并不会阻塞，以及遭受直接的延迟（例如提前加载，缓冲写入）。
7. 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: buffer cache,用于块设备I/O。
cached:page cache, 用于文件系统。
我们只是想检查这些指标值不为0，那样意味着磁盘I/O高、性能差（确认需要用iostat）。
上面的例子看起来不错，每一个都有很多Mbytes。
“/+ buffers/cache”: 提供了关于内存利用率更加准确的数值。
Linux可以将空闲内存用于缓存，并且在应用程序需要的时候收回。
所以应用到缓存的内存必须以另一种方式包括在内存空闲的数据里面。
甚至有一个网站linux ate my ram,专门探讨这个困惑。
它还有更令人困惑的地方，如果在Linux上使用ZFS,正如我们运行一些服务，ZFS拥有自己的文件系统混存，也不能在free -m 的输出里正确反映。
这种情况会显示系统空闲内存不足，但是内存实际上可用，通过回收 ZFS 的缓存。
8. 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 收包大道 22 Mbytes/s, 即176 Mbits/sec (就是说，在 1 Gbit/sec 的限制之内)。
此版本也有一个体现设备利用率的 “％ifutil” （两个方向最大值），我们也可以使用 Brendan的 nicstat 工具来度量。
和 nicstat 类似，这个值很难准确获取，看起来在这个例子中并没有起作用（0.00）。
9. 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重发数／每秒
这些活跃和被动的计数器常常作为一种粗略的服务负载度量方式：新收到的连接数 (被动的),以及下行流量的连接数 (活跃的)。
这也许能帮助我们理解，活跃的都是外向的，被动的都是内向的，但是严格来说这种说法是不准确的（例如，考虑到“本地－本地”的连接）。
重发数是网络或服务器问题的一个标志；它也许是因为不可靠的网络（如，公共互联网），也许是由于一台服务器已经超负荷、发生丢包。
上面的例子显示每秒钟仅有一个新的TCP连接。
10. 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命令包含了许多我们之前已经检查的指标。
它可以非常方便地运行，看看是否任何东西看起来与从前面的命令的结果完全不同，可以表明负载指标是不断变化的。
顶部下面的输出，很难按照时间推移的模式查看，可能使用如 vmstat 和 pidstat 等工具会更清晰，它们提供滚动输出。
如果你保持输出的动作不够快 （CtrlS 要暂停，CtrlQ 继续），屏幕将清除，间歇性问题的证据也会丢失。
追踪分析
你还可以尝试更多、更深的命令和方法。
详见Brendan的 Linux 性能工具辅导课，包括40多种命令，覆盖可观测性、标杆管理、调优、静态性能优化、监视和追踪。
============= End
标签：07,性能,CPU,vmstat,IO,Linux,工具,0.00 From： https://www.cnblogs.com/lsgxeva/p/17586680.html