linux性能分析命令 linux 性能分析
如何1分钟内对 Linux 性能快速分析（113资讯网）
当你在IDC主机商购买一台系统为 Linux 服务器之后，我想大家第一时间就是对主机进行一个性能分析，这里我跟大家分享几个命令，能让大家在一分钟以内对自己的性能有一个大致的鸟解?
创新互联专业为企业提供房山网站建设、房山做网站、房山网站设计、房山网站制作等企业网站建设、网页设计与制作、房山企业网站模板建站服务，十多年房山做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。
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
这10个命令到底是什么意思，我为大家一一解释一下：
1.uptime
# uptime
03:16:26 up 21:31, 1 user, load average: 10.02, 06.43, 09.02
在上面的例子中，平均负载显示是在不断增加的，1 分钟的值是 10，相比 15 分钟的值 09 来说是增加了。这个数字这么大就意味着有事情发生了.
2. dmesg | tail
# dmesg | tail
[ 14.102501] ISO 9660 Extensions: RRIP_1991A
[ 15.900216] ISO 9660 Extensions: Microsoft Joliet Level 3
[ 15.900234] ISO 9660 Extensions: RRIP_1991A
[ 17.030540] EXT4-fs (vda1): resizing filesystem from 5242619 to 13106939 blocks
[ 17.151434] random: crng init done
[ 17.151436] random: 7 urandom warning(s) missed due to ratelimiting
[ 18.314268] EXT4-fs (vda1): resized filesystem to 13106939
[ 20.394666] new mount options do not match the existing superblock, will be ignored
[ 38.405804] ISO 9660 Extensions: Microsoft Joliet Level 3
[ 38.407599] ISO 9660 Extensions: RRIP_1991A
这里展示的是最近 10 条系统消息日志，如果系统消息没有就不会展示。主要是看由于性能问题导致的错误。
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
1 0 0 324644 141184 1270628 0 0 10 40 207 431 1 1 99 0 0
0 0 0 324388 141184 1270628 0 0 0 0 130 280 1 1 98 0 0
0 0 0 324388 141184 1270628 0 0 0 0 89 169 0 0 100 0 0
0 0 0 324420 141184 1270628 0 0 0 0 118 225 1 0 99 0 0
0 0 0 324420 141184 1270628 0 0 0 32 125 254 0 0 99 1 0
1 1 0 324420 141184 1270628 0 0 0 68 96 171 0 0 96 4 0
0 0 0 324452 141184 1270628 0 0 0 184 127 166 0 1 96 3 0
^C
r: CPU 上的等待运行的可运行进程数。这个指标提供了判断 CPU 饱和度的数据，因为它不包含 I/O 等待的进程。可解释为：“r” 的值比 CPU 数大的时候就是饱和的。
free：空闲内存，单位是 k。如果这个数比较大，就说明你还有充足的空闲内存。“free -m” 和下面第 7 个命令，可以更详细的分析空闲内存的状态。
si，so：交换进来和交换出去的数据量，如果这两个值为非 0 值，那么就说明没有内存了。
us，sy，id，wa，st：这些是 CPU 时间的分解，是所有 CPU 的平均值。它们是用户时间，系统时间（内核），空闲，等待 I/O 时间，和被偷的时间（这里主要指其它的客户，或者使用 Xen，这些客户有自己独立的操作域）。
4. mpstat -P ALL 1
# mpstat -P ALL 1
Linux 4.15.0-88-generic (VM-0-17-ubuntu) 06/15/2020 _x86_64_ (1 CPU)
03:33:26 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
03:33:27 AM all 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 99.00
03:33:27 AM 0 0.00 0.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 99.00
这个命令打印各个 CPU 的时间统计，可以看出整体 CPU 的使用是不是均衡的。由于我使用的是1H2G主机看不出区别！
5. pidstat 1
# pidstat 1
Linux 4.15.0-88-generic (VM-0-17-ubuntu) 06/15/2020 _x86_64_ (1 CPU)
03:34:47 AM UID PID %usr %system %guest %wait %CPU CPU Command
03:34:48 AM 0 1120 1.00 0.00 0.00 0.00 1.00 0 sshd
pidstat 命令为每个 CPU 统计信息功能。由于我使用的是1H2G主机看不出区别！
6. iostat -xz 1
# iostat -xz 1
Linux 4.15.0-88-generic (VM-0-17-ubuntu) 06/15/2020 _x86_64_ (1 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.67 0.01 0.52 0.29 0.00 98.52
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
loop0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.22 0.00 0.00 9.64 0.00 0.00 0.00
scd0 0.02 0.00 0.48 0.00 0.00 0.00 0.00 0.00 0.21 0.00 0.00 27.72 0.00 0.19 0.00
vda 0.64 4.07 9.15 40.59 0.00 1.99 0.00 32.85 3.58 2.31 0.01 14.31 9.96 0.24 0.11
avg-cpu: %user %nice %system %iowait %steal %idle
0.00 0.00 0.00 0.00 0.00 100.00
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
r/s, w/s, rkB/s, wkB/s：这些表示设备上每秒钟的读写次数和读写的字节数（单位是k字节）。这些可以看出设备的负载情况。性能问题可能就是简单的因为大量的文件加载请求。
await：I/O 等待的平均时间（单位是毫秒）。这是应用程序所等待的时间，包含了等待队列中的时间和被调度服务的时间。过大的平均等待时间就预示着设备超负荷了或者说设备有问题了。
avgqu-sz：设备上请求的平均数。数值大于 1 可能表示设备饱和了（虽然设备通常都是可以支持并行请求的，特别是在背后挂了多个磁盘的虚拟设备）。
%util：设备利用率。是使用率的百分数，展示每秒钟设备工作的时间。这个数值大于 60% 则会导致性能很低（可以在 await 中看），当然这也取决于设备特点。这个数值接近 100% 则表示设备饱和了。
7. free -m/h
ubuntu@VM-0-17-ubuntu:~# free -m
total used free shared buff/cache available
Mem: 1833 137 313 5 1381 1506
Swap: 0 0 0
ubuntu@VM-0-17-ubuntu:~$ free -h
total used free shared buff/cache available
Mem: 1.8G 139M 311M 5.8M 1.3G 1.5G
Swap: 0B 0B 0B
这个命令我相信大家都熟悉，buffers：用于块设备 I/O 缓冲的缓存，cached：用于文件系统的页缓存。
8. sar -n DEV 1
ubuntu@VM-0-17-ubuntu:~# sar -n DEV 1
Linux 4.15.0-88-generic (VM-0-17-ubuntu) 06/15/2020 _x86_64_ (1 CPU)
03:43:35 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
03:43:36 AM eth0 11.00 10.00 0.79 1.06 0.00 0.00 0.00 0.00
03:43:36 AM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
使用这个工具是可以检测网络接口的吞吐：rxkB/s 和 txkB/s，作为收发数据负载的度量，也是检测是否达到收发极限。在上面这个例子中，eth0 接收数据达到 0.79 kb 字节/秒，发送数据达到1.06 字节/秒。
9. sar -n TCP,ETCP 1
ubuntu@VM-0-17-ubuntu:~# sar -n TCP,ETCP 1
Linux 4.15.0-88-generic (VM-0-17-ubuntu) 06/15/2020 _x86_64_ (1 CPU)
03:49:56 AM active/s passive/s iseg/s oseg/s
03:49:57 AM 0.00 0.00 5.05 3.03
03:49:56 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
03:49:57 AM 0.00 0.00 0.00 0.00 0.00
这是对 TCP 关键指标的统计，它包含了以下内容：
active/s：每秒本地发起的 TCP 连接数（例如通过 connect() 发起的连接）。
passive/s：每秒远程发起的连接数（例如通过 accept() 接受的连接）。
retrans/s：每秒TCP重传数。
10. top
ubuntu@VM-0-17-ubuntu:~# top
top - 03:53:20 up 1 day, 1:41, 1 user, load average: 0.01, 0.04, 0.00
Tasks: 89 total, 1 running, 52 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 0.3 sy, 0.0 ni, 99.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 1877076 total, 317436 free, 143420 used, 1416220 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 1540856 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3730 root 20 0 105688 6812 5840 S 0.3 0.4 0:00.01 sshd
7546 root 20 0 644608 14924 6776 S 0.3 0.8 2:48.99 YDService
1 root 20 0 159892 9260 6796 S 0.0 0.5 0:06.45 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
7 root 20 0 0 0 0 S 0.0 0.0 0:04.29 ksoftirqd/0
8 root 20 0 0 0 0 I 0.0 0.0 0:08.85 rcu_sched
9 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_bh
10 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
11 root rt 0 0 0 0 S 0.0 0.0 0:00.16 watchdog/0
12 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
top 命令包含了很多我们前面提到的指标。这个命令可以很容易看出指标的变化表示负载的变化，这个看起来和前面的命令有很大不同。
top 的一个缺陷也比较明显，很难看出变化趋势，其它像 vmstat 和 pidstat 这样的工具就会很清晰，它们是以滚动的方式输出统计信息。所以如果你在看到有问题的信息时没有及时的暂停下来（Ctrl-S 是暂停, Ctrl-Q 是继续），那么这些有用的信息就会被清屏。
文章原文： （来都来了，就去我博客看下！！）
Linux性能分析-CPU上下文切换
在 Linux性能分析-平均负载 中，提到过一种导致平均负载升高的情况，就是有大量进程或线程等待cpu调度。
为什么大量进程或者线程等待CPU调度会导致负载升高呢？
当大量进程或者线程等待调度时，cpu需要更加频繁的切换任务，在切换任务的过程中，需要保存上一个任务的context到内核中，并且恢复当前任务的context，这种保存和恢复的操作也是需要cpu来执行的，导致cpu都消耗在了 保存上文和恢复下文 这个过程中。
除了进程和线程导致的上下文切换以外，硬件产生的中断事件也会导致上下文切换。并且中断事件的优先级是高于线程和进程任务的。
这篇文章会模拟测试这种情况。
vmstat是一个观测总体上下文切换状况的命令。
下面指令可以每隔5秒输出一组数据。
重点关注列含义：
使用vmstat关注到了整体的情况，接下来可以使用pidstat关注具体线程的情况
注：pidstat -wt 可以输出线程的情况
重点关注列含义：
系统环境：
首先安装sysbench，使用sysbench，我们可以模拟一个进程内多线程调度引起的上下文切换问题。
安装好后，执行下面命令
查看下vmstat和pidstat
观察vmstat结果，可以看到
观察pidstat两类结果，可以发现
整体结果符合我们的预期。
针对in列显著提高，可以查看 /proc/interrupts 文件，里面记录了中断相关的数据，这些数据记录的是从上次启动到现在的累加值。
我们把系统重新启动下，看下空闲状态下的文件
当执行sysbench命令后，并运行一段时间后，该文件如下
其中，LOC和RES显著升高
RES表示，唤醒空闲状态的CPU来调度新的任务运行，和我们模拟的过多任务调度有关。
LOC不太理解，暂时先放在这里。
Linux中top命令输出指标详解
top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。top显示系统当前的进程和其他状况，是一个动态显示过程，可以自动或者通过用户按键来不断刷新当前状态。如果在前台执行该命令，它将独占前台,直到用户终止该程序为止.。比较准确的说，top命令提供了实时的对系统处理器的状态监控，显示系统中CPU最“敏感”的任务列表。top命令可以按CPU使用、内存使用和执行时间对任务进行排序。而且该命令的很多特性都可以通过交互式命令或者在个人定制文件中进行设定.。
下面详细介绍它的使用方法。
对于一个新手来说，如果从来没有使用过top命令，在命令行模式下直接输入top，可以查看到当前所有进程的信息。
输出结果中，有很多指标。下面介绍各个指标都代表什么含义。
top命令输出结果中，统计信息区前五行是系统整体的统计信息。
第一行是任务队列信息，同 uptime 命令的执行结果。其内容如下：
第二、三行为进程和CPU的信息。当有多个CPU时，这些内容可能会超过两行。内容如下：
最后两行为内存信息。内容如下：
进程信息区统计信息区域的下方显示了各个进程的详细信息。首先来认识一下各列的含义。
默认情况下仅显示比较重要的 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND 列。可以通过下面的快捷键来更改显示内容。
参考列表：
linux性能分析命令--pidstat
pidstat主要用于监控全部或指定进程占用系统资源的情况，如CPU，内存、设备IO、任务切换、线程等。pidstat首次运行时显示自系统启动开始的各项统计信息，之后运行pidstat将显示自上次运行该命令以后的统计信息。用户可以通过指定统计的次数和时间来获得所需的统计信息。pidstat可以监控到进程级别的信息；这就意味着我们更容易定位问题源头。
pidstat [ 选项 ] [ 时间间隔 ] [ 次数 ]
常用的参数：
等同于pidstat -u -p ALL，等同于pidstat -u
使用-r选项，pidstat将显示各活动进程的内存使用统计：
使用-d选项，我们可以查看进程IO的统计信息：
[root@vircent7 ~]# pidstat -w
Linux 3.10.0-1160.45.1.el7.x86_64 (vircent7.kyj) 2021年12月15日 x86_64 (4 CPU)
对监控对象进行筛选
以上所有命令结尾，加上两个数字，即可设定采样间隔和采样次数
表示每1秒采集一次数据，一共采集5次
网站标题：linux性能分析命令 linux 性能分析
URL标题：http://scyanting.com/article/dohohjh.html
