在 Linux 运维过程中，经常会遇到某个应用的存储目录跑满，提前又没有做任何规划，目录或磁盘无法扩容，这个时候，我们常用的解决方法是做软链接，通过 ln，将原先存储的目录软链接到另外大的磁盘中的目录下，以此达到目的。

软链的弊端就是，多层软链之后，会被绕晕，很容易造成误操作，今天再介绍一种方法。

##  **mount --bind**

mount 命令运维小伙伴应该很熟悉，不做过多介绍

先来看下 man 里面的介绍

![image-20230420095355709](http://pic.nexopera.tech/image-20230420095355709.png)

通过 mount --bind 可以将文件目录结构重新挂载，连接两个目录，它是将前一个目录挂载到后一个目录上，所有对后一个目录的访问其实都是对前一个目录的访问

### **例子**

通过例子看下，分别创建两个不同的目录，并在两个不同的目录下创建不同的文件

![image-20230420095401411](http://pic.nexopera.tech/image-20230420095401411.png)

查看文件的 inode

![image-20230420095407604](http://pic.nexopera.tech/image-20230420095407604.png)

通过 mount --bind 将 test1 挂载到 test2 上，重新查看 inode 和目录下内容

![image-20230420095413362](http://pic.nexopera.tech/image-20230420095413362.png)

可以看到，inode 号和文件，都是 test1 的

然后对 test2 目录下的文件访问修改，实际上改动的就是 test1 目录，我们测试下，在 test2 目录创建文件

![image-20230420095421019](http://pic.nexopera.tech/image-20230420095421019.png)

然后接触 mount 之后，我们再查看下两个目录下的内容

![image-20230420095427347](http://pic.nexopera.tech/image-20230420095427347.png)

可以看到，test1 目录保持修改后的状态，test2 目录文件仍然存在，且保持原来的不变

### **原理**

以 mount --bind test1 test2 为例，当 mount --bind 命令执行后，Linux 将会把被挂载目录的目录项（也就是该目录文件的 block，记录了下级目录的信息）屏蔽，即 test2 的下级路径被隐藏起来了（注意，只是隐藏不是删除，数据都没有改变，只是访问不到了）。

同时，内核将挂载目录（test1）的目录项记录在内存里的一个 s_root 对象里，在 mount 命令执行时，VFS 会创建一个 vfsmount 对象，这个对象里包含了整个文件系统所有的 mount 信息，其中也会包括本次 mount 中的信息，这个对象是一个 HASH 值对应表（HASH 值通过对路径字符串的计算得来），表里就有 /test1 到 /test2 两个目录的 HASH 值对应关系

命令执行完后，当访问 /test2 下的文件时，系统会告知 /test2 的目录项被屏蔽掉了，自动转到内存里找 VFS，通过 vfsmount 了解到 /test2 和 /test1 的对应关系，从而读取到 /test1 的 inode，这样在 /test2 下读到的全是 /test1 目录下的文件

**注意**

两个目录的对应关系是存在于内存中的，一旦重启，挂载关系就没有了，所以需要将挂载关系，写入 / etc/fstab 中

##  **高级用法**

### **临时配置文件读取测试**

有些应用场景下，需要修改配置文件进行测试，但是又不能影响正在运行中的业务，在没有把握的情况下，不愿意直接修改原有配置文件的话，我们可以通过在 / tmp 等目录，写一个测试的配置文件，通过 mount --bind 的方式挂载到配置文件读取目录，运行程序读取该临时配置文件，测试完成后，只需要 umount，不影响原来的配置

### **只读挂载**

在一些场景下，比如需要给开发人员查看一些配置的权限，但是又不允许它们修改配置的情况下，可以通过 mount --bind,ro 挂载一个只读目录，原目录可写，挂载出来的目录只读，只需要将只读目录权限给开发人员即可

以上就是 mount --bind 的简单介绍，更多使用方法，各位小伙伴可以自行尝试。

Linux下如何做到一个文件即可读写，又只读?

所谓丢包，是指在网络数据的收发过程中，由于种种原因，数据包还没传输到应用程序中，就被丢弃了。这些被丢弃包的数量，除以总的传输包数，也就是我们常说的丢包率。丢包率是网络性能中最核心的指标之一。丢包通常会带来严重的性能下降，特别是对 TCP 来说，丢包通常意味着网络拥塞和重传，进而还会导致网络延迟增大、吞吐降低。

## 一、 哪里可能丢包

接下来，我就以最常用的反向代理服务器 Nginx 为例，带你一起看看如何分析网络丢包的问题。执行下面的 hping3 命令，进一步验证 Nginx 是不是可以正常访问。这里我没有使用 ping，是因为 ping 基于 ICMP 协议，而 Nginx 使用的是 TCP 协议。

```text
# -c表示发送10个请求，-S表示使用TCP SYN，-p指定端口为80
hping3 -c 10 -S -p 80 192.168.0.30
 
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=3 win=5120 rtt=7.5 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=4 win=5120 rtt=7.4 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=5 win=5120 rtt=3.3 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=7 win=5120 rtt=3.0 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=6 win=5120 rtt=3027.2 ms
 
--- 192.168.0.30 hping statistic ---
10 packets transmitted, 5 packets received, 50% packet loss
round-trip min/avg/max = 3.0/609.7/3027.2 ms
```

从 hping3 的输出中，我们可以发现，发送了 10 个请求包，却只收到了 5 个回复，50%的包都丢了。再观察每个请求的 RTT 可以发现，RTT 也有非常大的波动变化，小的时候只有 3ms，而大的时候则有 3s。根据这些输出，我们基本能判断，已经发生了丢包现象。可以猜测，3s 的 RTT ，很可能是因为丢包后重传导致的。

那到底是哪里发生了丢包呢？排查之前，我们可以回忆一下 Linux 的网络收发流程，先从理论上分析，哪里有可能会发生丢包。你不妨拿出手边的笔和纸，边回忆边在纸上梳理，思考清楚再继续下面的内容。在这里，为了帮你理解网络丢包的原理，我画了一张图，你可以保存并打印出来使用

![img](http://pic.nexopera.tech/v2-c03dfcb6212feb8c4cb64fbb47cd78c0_1440w.webp)

从图中你可以看出，可能发生丢包的位置，实际上贯穿了整个网络协议栈。换句话说，全程都有丢包的可能。

- 在两台 VM 连接之间，可能会发生传输失败的错误，比如网络拥塞、线路错误等；
- 在网卡收包后，环形缓冲区可能会因为溢出而丢包；
- 在链路层，可能会因为网络帧校验失败、QoS 等而丢包；
- 在 IP 层，可能会因为路由失败、组包大小超过 MTU 等而丢包；
- 在传输层，可能会因为端口未监听、资源占用超过内核限制等而丢包；
- 在套接字层，可能会因为套接字缓冲区溢出而丢包；
- 在应用层，可能会因为应用程序异常而丢包；
- 此外，如果配置了 iptables 规则，这些网络包也可能因为 iptables 过滤规则而丢包

当然，上面这些问题，还有可能同时发生在通信的两台机器中。不过，由于我们没对 VM2做任何修改，并且 VM2 也只运行了一个最简单的 hping3 命令，这儿不妨假设它是没有问题的。为了简化整个排查过程，我们还可以进一步假设， VM1 的网络和内核配置也没问题。接下来，就可以从协议栈中，逐层排查丢包问题。

## 二、 链路层

当链路层由于缓冲区溢出等原因导致网卡丢包时，Linux 会在网卡收发数据的统计信息中记录下收发错误的次数。可以通过 ethtool 或者 netstat ，来查看网卡的丢包记录。

```text
netstat -i
 
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       100       31      0      0 0             8      0      0      0 BMRU
lo       65536        0      0      0 0             0      0      0      0 LRU
```

RX-OK、RX-ERR、RX-DRP、RX-OVR ，分别表示接收时的总包数、总错误数、进入 Ring Buffer 后因其他原因（如内存不足）导致的丢包数以及 Ring Buffer 溢出导致的丢包数。

TX-OK、TX-ERR、TX-DRP、TX-OVR 也代表类似的含义，只不过是指发送时对应的各个指标。

这里我们没有发现任何错误，说明虚拟网卡没有丢包。不过要注意，如果用 tc 等工具配置了 QoS，那么 tc 规则导致的丢包，就不会包含在网卡的统计信息中。所以接下来，我们还要检查一下 eth0 上是否配置了 tc 规则，并查看有没有丢包。添加 -s 选项，以输出统计信息：

```text
tc -s qdisc show dev eth0
 
qdisc netem 800d: root refcnt 2 limit 1000 loss 30%
 Sent 432 bytes 8 pkt (dropped 4, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
```

可以看到， eth0 上配置了一个网络模拟排队规则（qdisc netem），并且配置了丢包率为 30%（loss 30%）。再看后面的统计信息，发送了 8 个包，但是丢了 4个。看来应该就是这里导致 Nginx 回复的响应包被 netem 模块给丢了。

既然发现了问题，解决方法也很简单，直接删掉 netem 模块就可以了。执行下面的命令，删除 tc 中的 netem 模块：

```text
tc qdisc del dev eth0 root netem loss 30%
```

删除后，重新执行之前的 hping3 命令，看看现在还有没有问题：

```text
hping3 -c 10 -S -p 80 192.168.0.30
 
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=0 win=5120 rtt=7.9 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=2 win=5120 rtt=1003.8 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=5 win=5120 rtt=7.6 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=6 win=5120 rtt=7.4 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=9 win=5120 rtt=3.0 ms
 
--- 192.168.0.30 hping statistic ---
10 packets transmitted, 5 packets received, 50% packet loss
round-trip min/avg/max = 3.0/205.9/1003.8 ms
```

不幸的是，从 hping3 的输出中可以看到还是 50% 的丢包，RTT 的波动也仍旧很大，从 3ms 到 1s。显然，问题还是没解决，丢包还在继续发生。不过，既然链路层已经排查完了，我们就继续向上层分析，看看网络层和传输层有没有问题。

## 三、 网络层和传输层

在网络层和传输层中，引发丢包的因素非常多。不过，其实想确认是否丢包，是非常简单的事，因为 Linux 已经为我们提供了各个协议的收发汇总情况。执行 netstat -s 命令，可以看到协议的收发汇总，以及错误信息：

```text
netstat -s
#输出
Ip:
    Forwarding: 1          //开启转发
    31 total packets received    //总收包数
    0 forwarded            //转发包数
    0 incoming packets discarded  //接收丢包数
    25 incoming packets delivered  //接收的数据包数
    15 requests sent out      //发出的数据包数
Icmp:
    0 ICMP messages received    //收到的ICMP包数
    0 input ICMP message failed    //收到ICMP失败数
    ICMP input histogram:
    0 ICMP messages sent      //ICMP发送数
    0 ICMP messages failed      //ICMP失败数
    ICMP output histogram:
Tcp:
    0 active connection openings  //主动连接数
    0 passive connection openings  //被动连接数
    11 failed connection attempts  //失败连接尝试数
    0 connection resets received  //接收的连接重置数
    0 connections established    //建立连接数
    25 segments received      //已接收报文数
    21 segments sent out      //已发送报文数
    4 segments retransmitted    //重传报文数
    0 bad segments received      //错误报文数
    0 resets sent          //发出的连接重置数
Udp:
    0 packets received
    ...
TcpExt:
    11 resets received for embryonic SYN_RECV sockets  //半连接重置数
    0 packet headers predicted
    TCPTimeouts: 7    //超时数
    TCPSynRetrans: 4  //SYN重传数
  ...
```

etstat 汇总了 IP、ICMP、TCP、UDP 等各种协议的收发统计信息。不过，我们的目的是排查丢包问题，所以这里主要观察的是错误数、丢包数以及重传数。可以看到，只有 TCP 协议发生了丢包和重传，分别是：

- 11 次连接失败重试（11 failed connection attempts）
- 4 次重传（4 segments retransmitted）
- 11 次半连接重置（11 resets received for embryonic SYN_RECV sockets）
- 4 次 SYN 重传（TCPSynRetrans）
- 7 次超时（TCPTimeouts）

这个结果告诉我们，TCP 协议有多次超时和失败重试，并且主要错误是半连接重置。换句话说，主要的失败，都是三次握手失败。不过，虽然在这儿看到了这么多失败，但具体失败的根源还是无法确定。所以，我们还需要继续顺着协议栈来分析。接下来的几层又该如何分析呢？

## 四、 iptables

首先，除了网络层和传输层的各种协议，iptables 和内核的连接跟踪机制也可能会导致丢包。所以，这也是发生丢包问题时我们必须要排查的一个因素。

先来看看连接跟踪，要确认是不是连接跟踪导致的问题，只需要对比当前的连接跟踪数和最大连接跟踪数即可。

```text
# 主机终端中查询内核配置
$ sysctl net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_max = 262144
$ sysctl net.netfilter.nf_conntrack_count
net.netfilter.nf_conntrack_count = 182
```

可以看到，连接跟踪数只有 182，而最大连接跟踪数则是 262144。显然，这里的丢包，不可能是连接跟踪导致的。

接着，再来看 iptables。回顾一下 iptables 的原理，它基于 Netfilter 框架，通过一系列的规则，对网络数据包进行过滤（如防火墙）和修改（如 NAT）。这些 iptables 规则，统一管理在一系列的表中，包括 filter、nat、mangle（用于修改分组数据） 和 raw（用于原始数据包）等。而每张表又可以包括一系列的链，用于对 iptables 规则进行分组管理。

对于丢包问题来说，最大的可能就是被 filter 表中的规则给丢弃了。要弄清楚这一点，就需要我们确认，那些目标为 DROP 和 REJECT 等会弃包的规则，有没有被执行到。可以直接查询 DROP 和 REJECT 等规则的统计信息，看看是否为0。如果不是 0 ，再把相关的规则拎出来进行分析。

```text
iptables -t filter -nvL
#输出
Chain INPUT (policy ACCEPT 25 packets, 1000 bytes)
 pkts bytes target     prot opt in     out     source               destination
    6   240 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            statistic mode random probability 0.29999999981
 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain OUTPUT (policy ACCEPT 15 packets, 660 bytes)
 pkts bytes target     prot opt in     out     source               destination
    6   264 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            statistic mode random probability 0.29999999981
```

从 iptables 的输出中，你可以看到，两条 DROP 规则的统计数值不是 0，它们分别在INPUT 和 OUTPUT 链中。这两条规则实际上是一样的，指的是使用 statistic 模块，进行随机 30% 的丢包。0.0.0.0/0 表示匹配所有的源 IP 和目的 IP，也就是会对所有包都进行随机 30% 的丢包。看起来，这应该就是导致部分丢包的“罪魁祸首”了。

执行下面的两条 iptables 命令，删除这两条 DROP 规则。

```text
root@nginx:/# iptables -t filter -D INPUT -m statistic --mode random --probability 0.30 -j DROP
root@nginx:/# iptables -t filter -D OUTPUT -m statistic --mode random --probability 0.30 -j DROP
```

再次执行刚才的 hping3 命令，看看现在是否正常

```text
hping3 -c 10 -S -p 80 192.168.0.30
#输出
HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=0 win=5120 rtt=11.9 ms
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=1 win=5120 rtt=7.8 ms
...
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=9 win=5120 rtt=15.0 ms
 
--- 192.168.0.30 hping statistic ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 3.3/7.9/15.0 ms
```

这次输出你可以看到，现在已经没有丢包了，并且延迟的波动变化也很小。看来，丢包问题应该已经解决了。

不过，到目前为止，我们一直使用的 hping3 工具，只能验证案例 Nginx 的 80 端口处于正常监听状态，却还没有访问 Nginx 的 HTTP 服务。所以，不要匆忙下结论结束这次优化，我们还需要进一步确认，Nginx 能不能正常响应 HTTP 请求。我们继续在终端二中，执行如下的 curl 命令，检查 Nginx 对 HTTP 请求的响应：

```text
$ curl --max-time 3 http://192.168.0.30
curl: (28) Operation timed out after 3000 milliseconds with 0 bytes received
```

奇怪，hping3 的结果显示Nginx 的 80 端口是正常状态，为什么还是不能正常响应 HTTP 请求呢？别忘了，我们还有个大杀器——抓包操作。看来有必要抓包看看了。

## 五、 tcpdump

执行下面的 tcpdump 命令，抓取 80 端口的包

```text
tcpdump -i eth0 -nn port 80
#输出
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
```

然后，切换到终端二中，再次执行前面的 curl 命令：

```text
curl --max-time 3 http://192.168.0.30
curl: (28) Operation timed out after 3000 milliseconds with 0 bytes received
```

等到 curl 命令结束后，再次切换回终端一，查看 tcpdump 的输出：

```text
14:40:00.589235 IP 10.255.255.5.39058 > 172.17.0.2.80: Flags [S], seq 332257715, win 29200, options [mss 1418,sackOK,TS val 486800541 ecr 0,nop,wscale 7], length 0
14:40:00.589277 IP 172.17.0.2.80 > 10.255.255.5.39058: Flags [S.], seq 1630206251, ack 332257716, win 4880, options [mss 256,sackOK,TS val 2509376001 ecr 486800541,nop,wscale 7], length 0
14:40:00.589894 IP 10.255.255.5.39058 > 172.17.0.2.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 486800541 ecr 2509376001], length 0
14:40:03.589352 IP 10.255.255.5.39058 > 172.17.0.2.80: Flags [F.], seq 76, ack 1, win 229, options [nop,nop,TS val 486803541 ecr 2509376001], length 0
14:40:03.589417 IP 172.17.0.2.80 > 10.255.255.5.39058: Flags [.], ack 1, win 40, options [nop,nop,TS val 2509379001 ecr 486800541,nop,nop,sack 1 {76:77}], length 0
```

从 tcpdump 的输出中，我们就可以看到：

- 前三个包是正常的 TCP 三次握手，这没问题；
- 但第四个包却是在 3 秒以后了，并且还是客户端（VM2）发送过来的 FIN 包，说明客户端的连接关闭了

根据 curl 设置的 3 秒超时选项，你应该能猜到，这是因为 curl 命令超时后退出了。用 Wireshark 的 Flow Graph 来表示，

你可以更清楚地看到上面这个问题：

![img](http://pic.nexopera.tech/v2-a243c9a0c4c6d84cde841e2ff6ef7e74_1440w.webp)

这里比较奇怪的是，我们并没有抓取到 curl 发来的 HTTP GET 请求。那究竟是网卡丢包了，还是客户端就没发过来呢？

可以重新执行 netstat -i 命令，确认一下网卡有没有丢包问题：

```text
netstat -i
 
Kernel Interface table
Iface      MTU    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       100      157      0    344 0            94      0      0      0 BMRU
lo       65536        0      0      0 0             0      0      0      0 LRU
```

从 netstat 的输出中，你可以看到，接收丢包数（RX-DRP）是 344，果然是在网卡接收时丢包了。不过问题也来了，为什么刚才用 hping3 时不丢包，现在换成 GET 就收不到了呢？还是那句话，遇到搞不懂的现象，不妨先去查查工具和方法的原理。我们可以对比一下这两个工具：

- hping3 实际上只发送了 SYN 包；
- curl 在发送 SYN 包后，还会发送 HTTP GET 请求。HTTP GET本质上也是一个 TCP 包，但跟 SYN 包相比，它还携带了 HTTP GET 的数据。

通过这个对比，你应该想到了，这可能是 MTU 配置错误导致的。为什么呢？

其实，仔细观察上面 netstat 的输出界面，第二列正是每个网卡的 MTU 值。eth0 的 MTU只有 100，而以太网的 MTU 默认值是 1500，这个 100 就显得太小了。当然，MTU 问题是很好解决的，把它改成 1500 就可以了。

```text
ifconfig eth0 mtu 1500
```

修改完成后，再切换到终端二中，再次执行 curl 命令，确认问题是否真的解决了：

```text
curl --max-time 3 http://192.168.0.30/
#输出
<!DOCTYPE html>
<html>
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
```

Linux性能优化实战-网络丢包问题分析

Linux命令总结

## 组网需求

如图1所示，FW部署在内网出口处，企业内网部署了Web服务器。经检测，Web服务器经常受到SYN Flood、UDP Flood和HTTP Flood攻击，为了保障Web服务器的正常运行，需要在FW上开启攻击防范功能，用来防范以上三种类型的DDoS攻击。

![图1 攻击防范组网图](http://pic.nexopera.tech/image-20230420093506200.png)

## 操作步骤

1. 选择“策略 > 安全防护 > 攻击防范 > Anti-DDoS”。

   ![image-20230420093533923](http://pic.nexopera.tech/image-20230420093533923.png)

2. 在“未绑定接口”中，双击GE0/0/1，“已绑定接口”中将显示GE0/0/1，表示绑定接口GE0/0/1成功，GE0/0/1将启用流量统计功能。

3. 在“DDoS”界面，单击“配置学习参数”，按如下参数配置阈值学习功能。 

   ![image-20230420093539797](http://pic.nexopera.tech/image-20230420093539797.png)

4. 单击“确定”。

5. 在“DDoS”页面，选中SYN Flood、UDP Flood、ICMP Flood和HTTP Flood对应的“启用”，各攻击防范对应的阈值先采用默认值。 

   ![image-20230420093543883](http://pic.nexopera.tech/image-20230420093543883.png)

6. 单击“应用”。

7. 单击界面右上角的“保存”，在弹出的对话框中单击“确定”。

## 结果验证

- 配置完成后，DDoS攻击防范采用的阈值为默认阈值，待阈值学习结束后才会采用学到的阈值。阈值学习过程结束后，在Web服务器上查看攻击防范的效果。如果Web服务器继续受到攻击，请调小对应攻击的阈值。
- 配置完成后，系统对检测到的攻击会记录威胁日志。选择“监控 > 日志 > 威胁日志”，可以查看详细的威胁日志。

华为设备配置DDoS攻击防范



##  **火焰图**

### **6.1 说明**

火焰图（Flame Graph 是 Bredan Gregg 创建的一种性能分析图表，因为它的样子近似 ? 而得名。

火焰图主要是用来展示 CPU 的调用栈。

y 轴表示调用栈，每一层都是一个函数。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。

x 轴表示抽样数，如果一个函数在 x 轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间长。注意，x 轴不代表时间，而是所有的调用栈合并后，按字母顺序排列的。

火焰图就是看顶层的哪个函数占据的宽度最大。只要有” 平顶”（plateaus），就表示该函数可能存在性能问题。颜色没有特殊含义，因为火焰图表示的是 CPU 的繁忙程度，所以一般选择暖色调。

常见的火焰图类型有 On-CPU、Off-CPU、Memory、Hot/Cold、Differential 等等。

### **6.2 安装依赖库**

//安装systemtap，默认系统已安装yum install systemtap systemtap-runtime
//内核调试库必须跟内核版本对应，例如：uname -r 2.6.18-308.el5kernel-debuginfo-2.6.18-308.el5.x86_64.rpmkernel-devel-2.6.18-308.el5.x86_64.rpmkernel-debuginfo-common-2.6.18-308.el5.x86_64.rpm
//安装内核调试库debuginfo-install --enablerepo=debuginfo search kerneldebuginfo-install --enablerepo=debuginfo search glibc

### **6.3 安装**

git clone https://github.com/lidaohang/quick_location.gitcd quick_location

### **6.4 CPU 级别火焰图**

cpu 占用过高，或者使用率提不上来，你能快速定位到代码的哪块有问题吗？

一般的做法可能就是通过日志等方式去确定问题。现在我们有了火焰图，能够非常清晰的发现哪个函数占用 cpu 过高，或者过低导致的问题。

#### **6.4.1 on-CPU**

cpu 占用过高，执行中的时间通常又分为用户态时间 user 和系统态时间 sys。

使用方式：

```
//on-CPU usersh ngx_on_cpu_u.sh pid
//进入结果目录 cd ngx_on_cpu_u
//on-CPU kernelsh ngx_on_cpu_k.sh pid
//进入结果目录 cd ngx_on_cpu_k
//开一个临时端口 8088 python -m SimpleHTTPServer 8088//打开浏览器输入地址127.0.0.1:8088/pid.svg
```


DEMO：

```
#include <stdio.h>
#include <stdlib.h>
void foo3()
{  
}
void foo2(){  
  int i;  
  for(i=0 ; i < 10; i++)      
    foo3();
}
void foo1()
{  
  int i;
  for(i = 0; i< 1000; i++)
      foo3();
}
int main(void)
{  
  int i;  
  for( i =0; i< 1000000000; i++){      
    foo1();      
    foo2();  
  }
}
```

DEMO 火焰图：

![image-20230420093147058](http://pic.nexopera.tech/image-20230420093147058.png)

#### **6.4.2 off-CPU**

cpu 过低，利用率不高。等待下一轮 CPU，或者等待 I/O、锁、换页等等，其状态可以细分为可执行、匿名换页、睡眠、锁、空闲等状态。

使用方式：

```
// off-CPU usersh ngx_off_cpu_u.sh pid
//进入结果目录cd ngx_off_cpu_u
//off-CPU kernelsh ngx_off_cpu_k.sh pid
//进入结果目录cd ngx_off_cpu_k
//开一个临时端口8088python -m SimpleHTTPServer 8088
//打开浏览器输入地址127.0.0.1:8088/pid.svg
```

官网 DEMO：

![image-20230420093152837](http://pic.nexopera.tech/image-20230420093152837.png)

### **6.5 内存级别火焰图**

如果线上程序出现了内存泄漏，并且只在特定的场景才会出现。这个时候我们怎么办呢？有什么好的方式和工具能快速的发现代码的问题呢？同样内存级别火焰图帮你快速分析问题的根源。

使用方式：

```
sh ngx_on_memory.sh pid
//进入结果目录cd ngx_on_memory
//开一个临时端口8088python -m SimpleHTTPServer 8088
//打开浏览器输入地址127.0.0.1:8088/pid.svg
```

官网 DEMO：

![image-20230420093159037](http://pic.nexopera.tech/image-20230420093159037.png)

### **6.6 性能回退 - 红蓝差分火焰图**

你能快速定位 CPU 性能回退的问题么？如果你的工作环境非常复杂且变化快速，那么使用现有的工具是来定位这类问题是很具有挑战性的。当你花掉数周时间把根因找到时，代码已经又变更了好几轮，新的性能问题又冒了出来。主要可以用到每次构建中，每次上线做对比看，如果损失严重可以立马解决修复。

通过抓取了两张普通的火焰图，然后进行对比，并对差异部分进行标色：红色表示上升，蓝色表示下降。差分火焰图是以当前（“修改后”）的 profile 文件作为基准，形状和大小都保持不变。因此你通过色彩的差异就能够很直观的找到差异部分，且可以看出为什么会有这样的差异。

使用方式：

```
cd quick_location
//抓取代码修改前的profile 1文件perf record -F 99 -p pid -g -- sleep 30perf script > out.stacks1
//抓取代码修改后的profile 2文件perf record -F 99 -p pid -g -- sleep 30perf script > out.stacks2
//生成差分火焰图:./FlameGraph/stackcollapse-perf.pl ../out.stacks1 > out.folded1./FlameGraph/stackcollapse-perf.pl ../out.stacks2 > out.folded2./FlameGraph/difffolded.pl out.folded1 out.folded2 | ./FlameGraph/flamegraph.pl > diff2.svg
```

DEMO：

```
//test.c
#include <stdio.h>
#include <stdlib.h>
void foo3()
{  
}
void foo2()
{  
  int i;  
  for(i=0 ; i < 10; i++)
      foo3();
}
void foo1()
{  
  int i;  
  for(i = 0; i< 1000; i++)
      foo3();
}
int main(void)
{  
  int i;
  for( i =0; i< 1000000000; i++){
      foo1();
      foo2();  
  }
}
//test1.c
#include <stdio.h>
#include <stdlib.h>
void foo3()
{
}
void foo2()
{
  int i;
  for(i=0 ; i < 10; i++)
         foo3();
}
void foo1()
{  
  int i;  
  for(i = 0; i< 1000; i++)    
    foo3();
}
void add()
{  
  int i;  
  for(i = 0; i< 10000; i++)    
  foo3();
}
int main(void)
{  
  int i;  
  for( i =0; i< 1000000000; i++){
    foo1();
    foo2();
    add();
  }
}
```

DEMO 红蓝差分火焰图：

![image-20230420093206388](http://pic.nexopera.tech/image-20230420093206388.png)

##   **案例分析**

### **7.1 接入层 nginx 集群异常现象**

通过监控插件发现在 2017.09.25 19 点 nginx 集群请求流量出现大量的 499，5xx 状态码。并且发现机器 cpu 使用率升高，目前一直持续中。

### **7.2 分析 nginx 相关指标**

**a)分析 nginx 请求流量：**

![image-20230420093212931](http://pic.nexopera.tech/image-20230420093212931.png)

结论：

通过上图发现流量并没有突增，反而下降了，跟请求流量突增没关系。

**b)分析 nginx 响应时间**
![image-20230420093218097](http://pic.nexopera.tech/image-20230420093218097.png)



结论：

通过上图发现 nginx 的响应时间有增加可能跟 nginx 自身有关系或者跟后端 upstream 响应时间有关系。

**c)分析 nginx upstream 响应时间**

![image-20230420093224500](http://pic.nexopera.tech/image-20230420093224500.png)



结论：

通过上图发现 nginx upstream 响应时间有增加，目前猜测可能后端 upstream 响应时间拖住 nginx，导致 nginx 出现请求流量异常。

### **7.3 分析系统 cpu 情况**

**a)通过 top 观察系统指标**

top

![image-20230420093229843](http://pic.nexopera.tech/image-20230420093229843.png)

结论：

发现 nginx worker cpu 比较高

**b)分析 nginx 进程内部 cpu 情况**

perf top -p pid

结论：

发现主要开销在 free,malloc,json 解析上面

### **7.4 火焰图分析 cpu**

**a)生成用户态 cpu 火焰图**

```
//on-CPU usersh ngx_on_cpu_u.sh pid
//进入结果目录cd ngx_on_cpu_u
//开一个临时端口8088python -m SimpleHTTPServer 8088
//打开浏览器输入地址127.0.0.1:8088/pid.svg
```

![image-20230420093235847](http://pic.nexopera.tech/image-20230420093235847.png)



结论：

发现代码里面有频繁的解析 json 操作，并且发现这个 json 库性能不高，占用 cpu 挺高。

### **7.5 案例总结**

a) 分析请求流量异常，得出 nginx upstream 后端机器响应时间拉长

b) 分析 nginx 进程 cpu 高，得出 nginx 内部模块代码有耗时的 json 解析以及内存分配回收操作

#### **7.5.1 深入分析**

根据以上两点问题分析的结论，我们进一步深入分析。

后端 upstream 响应拉长，最多可能影响 nginx 的处理能力。但是不可能会影响 nginx 内部模块占用过多的 cpu 操作。并且当时占用 cpu 高的模块，是在请求的时候才会走的逻辑。不太可能是 upstram 后端拖住 nginx，从而触发这个 cpu 的耗时操作。

#### **7.5.2 解决方式**

遇到这种问题，我们优先解决已知的，并且非常明确的问题。那就是 cpu 高的问题。解决方式先降级关闭占用 cpu 过高的模块，然后进行观察。经过降级关闭该模块 cpu 降下来了，并且 nginx 请求流量也正常了。之所以会影响 upstream 时间拉长，因为 upstream 后端的服务调用的接口可能是个环路再次走回到 nginx。

Linux运维故障排查思路（下）

Nexopera是一个专注于Linux、网络和运维等领域的博客网站。将为读者提供广泛的相关文章，涵盖操作系统、服务器管理、网络配置、安全性等多个主题。如果你是初学者，希望这里有适合你的内容。

1. 基本命令

组网需求

火焰图

6.1 说明