Linux测试工具——（stress/fio/dd/blktrace/perf/time/strace/objdump）

一、Blktrace、Blkparse、Btt硬盘检测工具

1、关键指标

D2C和Q2C，一个是表现块设备性能的关键指标，另一个是客户发起请求到收到响应的时间。blktrace可以看出，
D2C 平均在0.024511184秒，即24.5毫秒，Q2C 平均在0.025524969 秒，即25.5毫秒；
无论是service time 还是客户感知到的await time，几乎相同。但是D2C花费的时间占整个Q2C的96%，表示性能瓶颈在D2C即磁盘侧。由于从主机通过网络到挂载设备/dev/mapper/vg1-lv_apps，业务量大会造成影响；
结合java、mysql进程和线程（265~275浮动）观察，CPU同步升高时，loadavg基本维持在10以上，所以大量的IO发送给磁盘，容易造成IO队列积压，CPU的IOwait升高和idle消耗、IOstat的（idle消耗、await和util升高）表现IO积压严重，可能存在磁盘瓶颈；
 
经观察，考虑从网络方面和磁盘性能方面着手，尝试沟通SRE再做进一步分析；
下载：

https://brick.kernel.dk/snaps/二、fio磁盘读写压测

1、问题现象：发现集群读延迟偏高，查看磁盘状态有大量的standby状态，该情况一般是物理磁盘休眠引起；

 
解决办法：
    通过fio实施预热操作，该问题判断为磁盘休眠问题；
读加压iops 1000
nohup fio -ioengine=rbd -pool=ebs_ceph_data -bs=4K -rw=randread -iodepth=128 -runtime=2592000 -numjobs=1 -rbdname=ebs_test50 -name='4k iops' -size=40G -time_based -direct=1 -rate_iops=1000
 2、测试要求：重点是了解SSD在使用D_SYNC时的性能，在投入生产时需要一直测试SSD硬盘性能。

测试方法一：
fio --filename=/dev/sda --direct=1 --sync=1 --rw=write --bs=4k --numjobs=1 --iodepth=1 --runtime=60 --time_based --group_reporting --name=journal-test
现在重要的是要了解我们传递的选项：

• --filename：我们要测试的设备；
  
• --direct：我们打开设备，这意味着我们正在绕过内核页面缓存O_DIRECT；
  
• --sync：我们打开设备，直到我们确定IO已经完全写入，我们才确认O_DSYNC；
  
• --rw：IO模式，这里我们用于顺序写入，日志写入始终是顺序的write；
  
• --bs：块大小，这里我们提交4K IO，这可能是最坏的情况，所以如果你知道你的工作负载，你可以随时更改这个值；
  
• --numjobs：将要运行的线程数，认为这有守护程序写入日志ceph-osd；
  
• --iodepth：我们正在逐个提交IO；
  
• --runtime：作业持续时间（以秒为单位）；
  
• --time_based：在指定的运行时持续时间内运行，即使文件已完全读取或写入；
  
• --group_reporting：如果设置，则在指定作业数时显示每组报告，而不是按作业显示；
  
• --name：运行的名称；
  

希捷、日立硬盘爬坡测试：
    通过每一次增加--numjobs数量，提高IO的交互量，测试固态硬盘可以达到的最大值；

• --numjobs=1报告带宽 23418KB/s 或 Iops=5854
  
• --numjobs=2报告 bw=43697KB/s 或 Iops=10924
  
• --numjobs=3报告 bw=63592KB/s 或 iops=15898
  
• --numjobs=4报告 bw=68500KB/s 或 Iops=17124
  

测试方法二：
dd if=/dev/urandom of=/data/randfile bs=1M count=1024 && sync
dd if=/data/randfile of=/dev/sda bs=4k count=100000 oflag=direct,dsync
3、随机读/dev/sde挂载目录文件/data02/test

fio -filename=/data02/test -direct=1 -rw=read -bs=128k -size=2G -iodepth=32 -ioengine=libaio -numjobs=1 -group_reporting -name=test -ramp_time=30 -time_based -runtime=60
测试结果：read: IOPS=7856, BW=982MiB/s (1030MB/s)(57.5GiB/60001msec)

 4、随机写/dev/sde挂载目录文件/data02/test

fio -filename=/data02/test -direct=1 -rw=randwrite -bs=4k -size=1G -iodepth=128 -ioengine=libaio -numjobs=1 -group_reporting -name=test -ramp_time=30 -time_based -runtime=60
测试结果：write: IOPS=15.3k, BW=59.6MiB/s (62.5MB/s)(3577MiB/60001msec)

 
三、dd磁盘读写压测

 1、写空数生成10M文件/root/202401030948

1. [root@localhost ~]# dd if=/dev/zero of=/root/202401030948 bs=1M count=10
2. 记录了10+0 的读入
3. 记录了10+0 的写出
4. 10485760 bytes (10 MB, 10 MiB) copied, 0.0527597 s, 199 MB/s
5. [root@localhost ~]# ll 202401030948
6. ---x--x--x 1 root root 10485760 1月   3 09:59 202401030948
7. [root@localhost ~]# find /root -size +1M  -size -50M   -perm 0111
8. /root/202401030948
9. [root@localhost ~]# find /root -size +1M  -size -50M   -perm 0111 -ls
10. 34204914  10240 ---x--x--x   1  root     root     10485760 1月  3 09:59 /root/202401030948

复制代码

 
四、Stress主机CPU压测

# Stress介绍使用
### 一、安装
#### 1、离线安装：
 
#### 2、yum安装：
 
#### 3、版本查询：
 
#### 4、基本语法：
```
语法格式：
stress
常用选项：
-c, --cpu N 产生N个进程，每个进程都反复不停的计算随机数的平方根
-i, --io N 产生N个进程，每个进程反复调用sync()将内存上的内容写到硬盘上
-m, --vm N 产生N个进程，每个进程不断分配和释放内存
--vm-bytes B 指定分配内存的大小
--vm-stride B 不断的给部分内存赋值，让COW(Copy On Write)发生
--vm-hang N 指示每个消耗内存的进程在分配到内存后转入睡眠状态N秒，然后释放内存，一直重复执行这个过程
--vm-keep 一直占用内存，区别于不断的释放和重新分配(默认是不断释放并重新分配内存)
-d, --hadd N 产生N个不断执行write和unlink函数的进程(创建文件，写入内容，删除文件)
--hadd-bytes B 指定文件大小
-t, --timeout N 在N秒后结束程序
--backoff N 等待N微妙后开始运行
-q, --quiet 程序在运行的过程中不输出信息
-n, --dry-run 输出程序会做什么而并不实际执行相关的操作
--version 显示版本号
-v, --verbose 显示详细的信息
```
 
### 二、CPU加压：
#### 1、对2个CPU打满，并使用mpstat和pidstat观察
```
# stress -c N：调用sqrt()函数不停的对随机数求平方根
# stress -c 2 --timeout 60s
# mpstat -P ALL 1 100
Linux 3.10.0-1160.88.1.el7.x86_64 (CentOS7-Debug-1) 04/06/2023 _x86_64_ (4 CPU)
04:12:01 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
04:12:02 AM all 49.87 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 50.13
04:12:02 AM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
04:12:02 AM 1 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
04:12:02 AM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
04:12:02 AM 3 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
# 如图所示，CPU1、3消耗CPU资源大，且占用CPU资源多的是stress命令发起的进程
# pidstat -T ALL 1 100
Linux 3.10.0-1160.88.1.el7.x86_64 (CentOS7-Debug-1) 04/06/2023 _x86_64_ (4 CPU)
04:14:19 AM UID PID %usr %system %guest %CPU CPU Command
04:14:20 AM 0 2634 100.00 0.00 0.00 100.00 3 stress
04:14:20 AM 0 2635 100.00 0.00 0.00 100.00 1 stress
04:14:20 AM 0 2636 0.00 0.99 0.00 0.99 0 pidstat
# 根据进程号，查看单个进程：
# pidstat -p 2316
Linux 3.10.0-1160.88.1.el7.x86_64 (CentOS7-Debug-1) 04/06/2023 _x86_64_ (4 CPU)
11:33:39 PM UID PID %usr %system %guest %CPU CPU Command
11:33:39 PM 0 2316 3.44 0.00 0.00 3.44 1 stress
# 查询每个进程的IO情况：
# pidstat -d | head
Linux 3.10.0-1160.88.1.el7.x86_64 (CentOS7-Debug-1) 04/10/2023 _x86_64_ (4 CPU)
04:32:02 AM UID PID kB_rd/s kB_wr/s kB_ccwr/s Command
04:32:02 AM 0 1 4835.63 0.19 0.05 systemd
04:32:02 AM 0 5 0.00 0.00 0.00 kworker/u256:0
04:32:02 AM 0 46 0.00 0.00 0.00 kswapd0
04:32:02 AM 0 455 0.06 0.00 0.00 xfsaild/dm-0
04:32:02 AM 0 535 0.89 0.00 0.00 systemd-journal
04:32:02 AM 0 556 0.01 0.00 0.00 lvmetad
04:32:02 AM 0 570 1.63 0.00 0.00 systemd-udevd
# 查询某个进程的IO情况
# pidstat -d -p 2521
Linux 3.10.0-1160.88.1.el7.x86_64 (CentOS7-Debug-1) 04/10/2023 _x86_64_ (4 CPU)
04:33:07 AM UID PID kB_rd/s kB_wr/s kB_ccwr/s Command
04:33:07 AM 0 2521 0.00 0.00 0.00 stress
# 查询每个进程的上下文切换情况
# pidstat -w | head
Linux 3.10.0-1160.88.1.el7.x86_64 (CentOS7-Debug-1) 04/10/2023 _x86_64_ (4 CPU)
04:34:20 AM UID PID cswch/s nvcswch/s Command
04:34:20 AM 0 1 0.28 0.26 systemd
04:34:20 AM 0 2 0.02 0.00 kthreadd
04:34:20 AM 0 3 3.19 0.00 kworker/0:0
04:34:20 AM 0 4 0.00 0.00 kworker/0:0H
04:34:20 AM 0 5 0.32 0.01 kworker/u256:0
04:34:20 AM 0 6 3.22 0.00 ksoftirqd/0
04:34:20 AM 0 7 0.09 0.00 migration/0
# 查询特定进程的上下文切换情况
# pidstat -w -p 2521
Linux 3.10.0-1160.88.1.el7.x86_64 (CentOS7-Debug-1) 04/10/2023 _x86_64_ (4 CPU)
04:34:07 AM UID PID cswch/s nvcswch/s Command
04:34:07 AM 0 2521 0.00 0.00 stress
 
```
#### 2、对半数CPU打满加压：
```
# cat cpu_stress.sh
#! /bin/bash
# 查询本机逻辑CPU个数：
cpu=`cat /proc/cpuinfo | grep "processor" | wc -l`
echo $cpu
# 对半数CPU进行压测：
let count=$cpu/2
echo $count
stress -c $count
```
#### 3、创建CPU密集型进程（CPU资源利用率接近100%）：
```
# stress -c 5 --timeout 600s
# 输出所有CPU状态，每秒一次，输出三次
# mpstat -P ALL 1 3
Linux 3.10.0-1160.88.1.el7.x86_64 (CentOS7-Debug-1) 04/06/2023 _x86_64_ (4 CPU)
05:11:19 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
05:11:20 AM all 99.71 0.00 0.29 0.00 0.00 0.00 0.00 0.00 0.00 0.00
05:11:20 AM 0 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
05:11:20 AM 1 98.82 0.00 0.00 0.00 0.00 1.18 0.00 0.00 0.00 0.00
05:11:20 AM 2 98.84 0.00 1.16 0.00 0.00 0.00 0.00 0.00 0.00 0.00
05:11:20 AM 3 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
# 输出所有任务状态，每秒一次，输出三次
# pidstat -T ALL 1 3
Linux 3.10.0-1160.88.1.el7.x86_64 (CentOS7-Debug-1) 04/06/2023 _x86_64_ (4 CPU)
05:12:15 AM UID PID %usr %system %guest %CPU CPU Command
05:12:16 AM 0 42 0.00 0.97 0.00 0.97 0 kworker/0:1
05:12:16 AM 0 2507 0.00 4.85 0.00 4.85 2 kworker/2:1
05:12:16 AM 0 2792 0.00 2.91 0.00 2.91 1 kworker/1:2
05:12:16 AM 0 2795 89.32 0.00 0.00 89.32 1 stress
05:12:16 AM 0 2796 78.64 0.00 0.00 78.64 3 stress
05:12:16 AM 0 2797 71.84 0.00 0.00 71.84 1 stress
05:12:16 AM 0 2798 66.02 0.00 0.00 66.02 0 stress
05:12:16 AM 0 2799 82.52 0.97 0.00 83.50 2 stress
05:12:15 AM UID PID usr-ms system-ms guest-ms Command
05:12:16 AM 0 42 0 10 0 kworker/0:1
05:12:16 AM 0 2507 0 50 0 kworker/2:1
05:12:16 AM 0 2792 0 30 0 kworker/1:2
05:12:16 AM 0 2795 920 0 0 stress
05:12:16 AM 0 2796 810 0 0 stress
05:12:16 AM 0 2797 740 0 0 stress
05:12:16 AM 0 2798 680 0 0 stress
05:12:16 AM 0 2799 850 10 0 stress
```
 
### 三、内存加压：
#### 1、
```
# 模拟2个进程，每个进程分配1000M的内存
# stress --vm 2 --vm-bytes 1000M --vm-keep
# top查询，消耗内存最高的是stress进程
# top
top - 21:42:34 up 10 min, 3 users, load average: 2.64, 1.58, 0.68
Tasks: 142 total, 6 running, 136 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.6 us, 52.2 sy, 0.0 ni, 24.1 id, 13.7 wa, 0.0 hi, 9.4 si, 0.0 st
KiB Mem : 1862820 total, 52208 free, 1781684 used, 28928 buff/cache
KiB Swap: 2097148 total, 1047804 free, 1049344 used. 10368 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1760 root 20 0 1031316 817656 12 R 67.0 43.9 2:50.75 stress
1761 root 20 0 1031316 814272 12 R 71.0 43.7 2:49.65 stress
# 检查进程，两个stress进程消耗CPU也高达77%，78%
# ps -elf | grep -P 'stress|TIME' | grep -v grep | column -t
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
0 S root 1828 1791 0 80 0 - 1828 do_wai 19:52 pts/0 00:00:00 stress --vm 2 --vm-bytes 1000M --vm-keep
1 D root 1829 1828 77 80 0 - 257829 wait_o 19:52 pts/0 00:03:47 stress --vm 2 --vm-bytes 1000M --vm-keep
1 D root 1830 1828 78 80 0 - 257829 wait_o 19:52 pts/0 00:03:50 stress --vm 2 --vm-bytes 1000M --vm-keep
# vmstat
```
#### 2、对半数内存进行加压耗尽：
```
# cat mem_stress.sh
#! /bin/bash
# 查询本机内存值：
mem=`cat /proc/meminfo | grep MemTotal | awk '{print $2}'`
echo $mem
# 对半数内存进行消耗：
let n=$mem/2
let num=$n/1024
echo $num
# 模拟1个进程，分配半数内存
stress --vm 1 --vm-bytes $num+M --vm-keep
```
 
### 四、IO加压：
#### 1、模拟4个进程压测IO：
```
# 模拟4个进程，调用sync()方法将系统内存上的内容写到磁盘上。
# 如果主机内存上的内容很少，将不会出现明显iowait
# sync是刷新内存缓冲区数据到磁盘中，以确保同步。如果内存缓冲区内没多少数据，读写到磁盘中的数据也就不多，没法产生IO压力
# stress -i 4
```
#### 2、压测磁盘
```
# stress -d N：模拟产生N个进程，每个进程往当前目录中写入固定大小的临时文件，然后执行unlink操作删除该临时文件。临时文件的大小默认为1G，但可以通过--hdd-bytes设置临时文件的大小
# 模拟8个进程，不断的在磁盘上创建1000M的文件，并写入内容
# stress -d 8 --hdd-bytes 1000M
# top
Tasks: 149 total, 1 running, 148 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.1 us, 1.3 sy, 0.0 ni, 3.1 id, 95.1 wa, 0.0 hi, 0.4 si, 0.0 st
KiB Mem : 1862820 total, 79836 free, 143644 used, 1639340 buff/cache
KiB Swap: 2097148 total, 2024636 free, 72512 used. 1549548 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
46 root 20 0 0 0 0 S 1.7 0.0 4:55.75 kswapd0
2080 root 20 0 0 0 0 D 1.3 0.0 0:27.28 kworker/u256:3
2222 root 20 0 8216 1128 32 D 1.0 0.1 0:03.37 stress
2223 root 20 0 8216 1128 32 D 1.0 0.1 0:03.35 stress
2224 root 20 0 8216 1128 32 D 1.0 0.1 0:03.35 stress
2225 root 20 0 8216 1128 32 D 1.0 0.1 0:03.37 stress
2226 root 20 0 8216 1128 32 D 1.0 0.1 0:03.27 stress
2227 root 20 0 8216 1128 32 D 1.0 0.1 0:03.39 stress
2229 root 20 0 8216 1128 32 D 1.0 0.1 0:03.38 stress
2228 root 20 0 8216 1128 32 D 0.7 0.1 0:03.41 stress

# iotop -P -o     （查看真个磁盘的当前读写速率，以及各个进程占用IO比例）
"-P":表示只看进程整体的，不然iotop默认查看每个线程；
"-o":表示只看有io操作的进程，不然iotop会查看所有进程；
Total DISK READ : 0.00 B/s | Total DISK WRITE : 75.30 M/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 78.60 M/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2223 be/4 root 0.00 B/s 9.67 M/s 0.00 % 99.99 % stress -d 8 --hdd-bytes 1000M
2224 be/4 root 0.00 B/s 9.44 M/s 0.00 % 99.88 % stress -d 8 --hdd-bytes 1000M
2226 be/4 root 0.00 B/s 9.44 M/s 0.00 % 99.48 % stress -d 8 --hdd-bytes 1000M
2225 be/4 root 0.00 B/s 9.44 M/s 0.00 % 99.40 % stress -d 8 --hdd-bytes 1000M
2222 be/4 root 0.00 B/s 9.21 M/s 0.00 % 98.66 % stress -d 8 --hdd-bytes 1000M
2229 be/4 root 0.00 B/s 9.44 M/s 0.00 % 98.46 % stress -d 8 --hdd-bytes 1000M
2227 be/4 root 0.00 B/s 9.44 M/s 0.00 % 98.38 % stress -d 8 --hdd-bytes 1000M
2228 be/4 root 0.00 B/s 9.21 M/s 0.00 % 97.56 % stress -d 8 --hdd-bytes 1000M
2080 be/4 root 0.00 B/s 0.00 B/s 0.00 % 89.46 % [kworker/u256:3]
```
 
### 五、组合测试：
#### 1、同时消耗CPU、内存、磁盘IO：
```
# stress -c 4 -m 2 -d 2
```
 
### 参考资料：
```
1、https://blog.csdn.net/A642960662/article/details/123030151
```
 
五、perf主机性能分析——火焰图

1、安装火焰图工具

1. <strong># github下载火焰图工具包</strong>
2. ## 通过windows下载该包FlameGraph-master.zip
3. https://codeload.github.com/brendangregg/FlameGraph/zip/refs/heads/master
4. <strong>
5. # 存放在/</strong><strong>opt目录</strong>
6. cd /opt
7. <strong>## 将FlameGraph</strong><strong>-master.zip文件上传到/</strong><strong>opt下</strong>
8. <strong>
9. # 解压github
10. </strong>unzip FlameGraph-master.zip<strong>
12. # 重命名
13. </strong>mv FlameGraph-master FlameGraph
15. <strong># perf指令调用FlameGraph</strong><strong>/stackcollapse-</strong><strong>perf.pl和flamegraph.pl写perf.data数据</strong>
16. perf script | /opt/FlameGraph/stackcollapse-perf.pl | /opt/FlameGraph/flamegraph.pl > /tmp/cpu0_30s.svg<br><strong># 在上述perf指令执行目录，生成火焰图文件perf.data和cpu0_30s.svg<br></strong><strong># 脚本<br></strong>

复制代码

[root@sysmt ~]# cat cpu_flame.sh
#!/bin/bash
# 用法：cpu0_flame.sh [cpu_id] [seconds] [out_name]
CPU=${1:-0}
SEC=${2:-30}
OUT=${3:-cpu${CPU}_${SEC}s}
FLAME=/opt/FlameGraph
[[ -x $FLAME/flamegraph.pl ]] || { echo "FlameGraph not found in $FLAME"; exit 1; }
echo "Recording CPU$CPU for $SEC seconds..."
perf record -F 99 -a -C $CPU -g -- sleep $SEC
perf script | $FLAME/stackcollapse-perf.pl | $FLAME/flamegraph.pl > ${OUT}.svg
echo "Done. svg=$OUT.svg samples=$(wc -l < perf.data)"

1. <br><strong># </strong><strong>cpu0_30s.svg文件在windows主机上通过浏览器打开<br></strong>

复制代码

• 宽度 = CPU 时间（样本数），越宽越耗 CPU
  
• 高度 = 调用链深度，从下往上是“父函数 → 子函数”
  

• 最宽的两座山
  
  
  
  • e1000_clean → net_rx_action → do_IRQ
    
  • scheduler_tick → update_process_times
    
  样本占比超过 60%，说明 CPU 大部分时间花在 网卡中断收包 和 时钟中断做进程调度。
  
• 为什么 e1000_clean 这么宽？
  
  
  
  • 网络小包突发 → 每来一个包就触发一次中断 → 不断进入 do_IRQ → net_rx_action → 驱动 e1000_clean。
    
  • 如果柱子里还看到 ksoftirqd 很宽，表示 软中断积压，内核线程在拼命补收队列。
    
  
  
• 业务代码去哪儿了？
  图里几乎看不到 main* / java* / python* 等用户态符号 → 用户态 CPU 只占个位数，瓶颈不在业务逻辑，而在中断处理。
  
• 下一步优化动作
  
  
  
  • 临时：ethtool -G eth0 rx 4096 tx 4096  # 加大环形缓冲区
    
  • 永久：
    – 打开 NAPI 权重或切换到 busy-polling（ethtool -C eth0 adaptive-rx on rx-usecs 8）
    – 多队列网卡 + RPS/RFS 把软中断分散到更多 CPU
    – 如果虚拟机，改用 virtio/vmxnet3 替代 e1000
    
  
  

 

一座“平顶山” + 顶上是 native_safe_halt	CPU 空闲，在跑 idle 循环	正常
宽柱子 __softirqentry_text_start → net_rx_action	网络中断风暴	调网卡/中断亲和
宽柱子 __schedule → schedule_idle	上下文切换过多	线程数爆炸、锁竞争
宽柱子 copy_user_enhanced_fast_string	用户态  内核态大量拷贝	减少系统调用、零拷贝

1. <strong> </strong>

复制代码

1. 问题1： Message from syslogd@sysmt at Sep 15 23:50:33 ... kernel:Dazed and confused, but trying to continue <br>[ perf record: Woken up 5 times to write data ] [ perf record: Captured and wrote 1.477 MB perf.data (6363 samples) ] <br>./cpu01_flame.sh: line 7: /stackcollapse-perf.pl: No such file or directory ./cpu01_flame.sh: line 7: /flamegraph.pl: No such file or directory Done. Open cpu0_30s.svg in browser. <br>perf.data 已正常生成（1.477 MB，6363 个样本），但火焰图工具链（FlameGraph）没装或路径不对，导致 stackcollapse-perf.pl / flamegraph.pl 找不到，最终 cpu0_30s.svg 大小为 0 <br><strong>解决办法：根据上面安装火焰图工具；</strong><br>

复制代码

 

1. <strong>问题2：perf.data 里</strong><strong>没有调用栈，火焰图打开报错：“ERROR: No valid input provided to flamegraph.pl.”</strong>
   
2. <strong>报错1：“打开火焰图cpu1_30s.svg报错：ERROR: No valid input provided to flamegraph.pl.”</strong>
   
3. <strong>报错2：“perf工具执行报ERROR: No stack counts found”</strong>

复制代码

1. 解决办法：脚本里 perf record 添加参数 “-g”，同时缺符号、缺 dwarf/fp 支持。

复制代码

六、time主机执行指令时延分析

七、Strace分析

1、概述

# Strace概述——系统调用追踪工具

strace是一个使用于Linux带有传统命令行的诊断、调试和指导用户空间的实用程序。它用于监视和干预进程与Linux内核之间的交互，包括系统调用、信号传递和进程状态的改变。strace的操作是被总所周知的ptrace的内核特性实现。
也可以追踪/bin和/sbin指令指定过程中，当用户进程通过Open系统调用，发现内核态syscall_open()函数中的write（）和read（）读写操作函数的异常状态。
2、下载

1. git clone https://gitlab.com/strace/strace.git

复制代码

 
 

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！