一次春节大促性能压测不达标的瓶颈推演

发表于 2020-11-23 更新于 2025-11-29 分类于 performance

一次春节大促性能压测不达标的瓶颈推演

本文示范了教科书式的在分布式应用场景下如何通过一个节点的状态来推演分析瓶颈出在上下游的哪个环节上。

场景描述

某客户通过PTS（一个打压力工具）来压选号业务(HTTP服务在9108端口上），一个HTTP请求对应一次select seq-id 和一次insert

PTS端看到RT900ms+，QPS大概5万（期望20万），数据库代理服务 rt 5ms，QPS 10万+

链路：

pts发起压力 -> 5个eip -> slb -> app(300个容器运行tomcat监听9108端口上） -> slb -> 数据库代理服务集群 -> RDS集群

性能不达标，怀疑数据库代理服务或者RDS性能不行，作为数据库需要自证清白，所以从RDS和数据库代理服务开始分析问题在哪里。

略过一系列在数据库代理服务、RDS上分析数据和监控图表都证明数据库代理服务和RDS没问题的过程。

在明确给出证据数据库代理服务和RDS都没问题后还是要解决问题，所以只能进一步帮助前面的app来分析为什么性能不达标。

在其中一个app应用上抓包（00:18秒到1:04秒），到数据库代理服务的一个连接分析：

数据库代理服务每个HTTP请求的响应时间都控制在15ms(一个前端HTTP请求对应一个select seq-id，一个 select readonly, 一个insert，这个响应时间符合预期）。一个连接每秒才收到20 tps（因为压力不够，压力加大的话这个单连接tps还可以增加）， 20*3000 = 6万，跟压测看到基本一致

300个容器，每个容器 10个连接到数据库代理服务

如果300个容器上的并发压力不够的话就没法将3000个连接跑满，所以看到的QPS是5万。

从300个容器可以计算得到这个集群能支持的tps： 300*10（10个连接）* 1000/15(每秒钟每个连接能处理的请求数）=20万个tps （关键分析能力）

也就是说通过单QPS 15ms，我们计算可得整个后端的吞吐能力在20万QPS。所以目前问题不在后端，而是压力没有打到后端就出现瓶颈了。

9108的HTTP服务端口上的抓包分析

9108服务的每个HTTP response差不多都是15ms（这个响应时间基本符合预期），一个HTTP连接上在45秒的抓包时间范围只收到23个HTTP Request。

或者下图：

统计9108端口在45秒总共收到的HTTP请求数量是6745（如下图），也就是每个app每秒钟收到的请求是150个，300*150=4.5万（理论值，300个app可能压力分布不一样？），从这里看app收到的压力还不够，所以压力还没有打到应用容器中的app，还在更前面

后来从容器app监控也确认了这个响应时间和抓包看到的一致，所以从抓包分析http响应时间也基本得到15ms的rt关键结论

从wireshark IO Graphs 也能看到RT 和 QPS

从应用容器上的netstat统计来看，也是压力端回复太慢

send-q表示回复从9108发走了，没收到对方的ack

ARMS监控分析9108端口上的RT

后来PTS的同学说ARMS可以捞到监控数据，如下是对rt时间降序排

中的rt平均时间，可以看到http的rt确实14.4ms，表现非常平稳，从这个监控也发现实际app是330个而不是用户自己描述的300个，这也就是为什么实际是tps是5万，但是按300个去算的话tps是4.5万（不要纠结客户为什么告诉你是300个容器而不是330个，有时候他们也搞不清楚，业务封装得太好了）

5分钟时间，QPS是5万+，HTTP的平均rt是15ms， HTTP的最大rt才79ms，和前面抓包分析一致。

从后端分析的总结

从9108端口响应时间15ms来看是符合预期的，为什么PTS看到的RT是900ms+，所以压力还没有打到APP上（也就是9108端口）

结论

最后发现是 eip 带宽不足，只有200M，调整到1G后 tps 也翻了5倍到了25万。

pts -> 5个eip(总带宽200M) -> slb -> app(330个HTTP容器） -> slb -> 数据库代理服务 -> RDS

这个案例有意思的地方是可以通过抓包就能分析出集群能扛的QPS20万（实际只有5万），那么可以把这个分析原则在每个角色上挨个分析一下，来看瓶颈出在了哪个环节。

应用端看到的rt是900ms，从后段开始往前面应用端来撸，看看每个环节的rt数据。

教训

搞清楚请求从发起端到DB的链路路径，比如 pts -> 5个eip(总带宽200M) -> slb -> app(330个HTTP容器） -> slb -> 数据库代理服务 -> RDS
压不上去得从发压力端开始往后端撸，撸每个产品的rt，每个产品给出自己的rt来自证清白
应用有arms的话学会看arms对平均rt和QPS的统计，不要纠结个别请求的rt抖动，看平均rt
通过抓包完全可以分析出来系统能扛多少并发，以及可能的瓶颈位置

一包在手万事无忧

活久见，TCP连接互串了

背景

应用每过一段时间总是会抛出几个连接异常的错误，需要查明原因。

排查后发现是TCP连接互串了，这个案例实在是很珍惜，所以记录一下。

抓包

业务结构：应用->MySQL(10.112.61.163)

在应用机器上抓包这个异常连接如下（3269为MySQL服务端口）：

粗一看没啥奇怪的，就是应用发查询给3269，但是一直没收到3269的ack，所以一直重传。这里唯一的解释就是网络不通。最后MySQL的3269还回复了一个rst，这个rst的id是42889，引起了我的好奇，跟前面的16439不连贯，正常应该是16440才对。（请记住上图中的绿框中的数字）

于是我过滤了一下端口61902上的所有包：

可以看到绿框中的查询从61902端口发给3269后，很奇怪居然收到了一个来自别的IP+3306端口的reset，这个包对这个连接来说自然是不认识（这个连接只接受3269的回包），就扔掉了。但是也没收到3269的ack，所以只能不停地重传，然后每次都收到3306的reset，reset包的seq、id都能和上图的绿框对应上。

明明他们应该是两个连接：

61902->10.141.16.0:3306

61902->10.112.61.163:3269

他们虽然用的本地ip端口（61902）是一样的，但是根据四元组不一样，还是不同的TCP连接，所以应该是不会互相干扰的。但是实际看起来seq、id都重复了，不会有这么巧，非常像是TCP互串了。

分析原因

10.141.16.0 这个ip看起来像是lvs的ip，查了一下系统，果然是lvs，然后这个lvs 后面的rs就是10.112.61.163

那么这个连结构就是10.141.16.0:3306：

应用 -> lvs(10.141.16.0:3306)-> 10.112.61.163:3269 跟应用直接连MySQL是一回事了

所以这里的疑问就变成了：10.141.16.0 这个IP的3306端口为啥能知道 10.112.61.163:3269端口的seq和id，也许是TCP连接串了

接着往下排查

先打个岔，分析下这里的LVS的原理

这里使用的是 full NAT模型(full NetWork Address Translation-全部网络地址转换)

基本流程（类似NAT）：

client发出请求（sip 200.200.200.2 dip 200.200.200.1）
请求包到达lvs，lvs修改请求包为**（sip 200.200.200.1， dip rip）** 注意这里sip/dip都被修改了
请求包到达rs， rs回复（sip rip，dip 200.200.200.1）
这个回复包的目的IP是VIP(不像NAT中是 cip)，所以LVS和RS不在一个vlan通过IP路由也能到达lvs
lvs修改sip为vip， dip为cip，修改后的回复包（sip 200.200.200.1，dip 200.200.200.2）发给client

注意上图中绿色的进包和红色的出包他们的地址变化

本来这个模型下都是正常的，但是为了Real Server能拿到client ip，也就是Real Server记录来源ip的时候希望记录的是client ip而不是LVS ip。这个时候LVS会将client ip放在tcp的options里面，然后在RealServer机器的内核里面将options中的client ip取出替换掉 lvs ip。所以Real Server上感知到的对端ip就是client ip。

回包的时候RealServer上的内核模块同样将目标地址从client ip改成lvs ip，同时将client ip放入options中。

回到问题

看完理论，再来分析这两个连接的行为

fulnat模式下连接经过lvs到达mysql后，mysql上看到的连接信息是，cip+port，也就是在MySQL上的连接

**lvs-ip:port -> 10.112.61.163:3269 被修改成了 **client-ip:61902 **-> 10.112.61.163:3269

那么跟不走LVS的连接：

client-ip:61902 -> 10.112.61.163:3269 (直连) 完全重复了。

MySQL端看到的两个连接四元组一模一样了：

10.112.61.163:3269 -> client-ip:61902 (走LVS，本来应该是lvs ip的，但是被替换成了client ip)

10.112.61.163:3269 -> client-ip:61902 (直连)

这个时候应用端看到的还是两个连接：

client-ip:61902 -> 10.141.16.0:3306 （走LVS）

client-ip:61902 -> 10.112.61.163:3269 (直连)

总结下，也就是这个连接经过LVS转换后在服务端（MYSQL）跟直连MySQL的连接四元组完全重复了，也就是MySQL会认为这两个连接就是同一个连接，所以必然出问题了

这个时候用 netstat 看到的应该是两个连接(vtoa 没有替换), 一个是client->rs, 一个是lvs->rs, 内核层面看到的还是两个连接, 只是get_peername接口被toa hook修改后, 两个连接返回的srcip是同一个

实际两个连接建立的情况：

和mysqlserver的61902是04:22建起来的，和lvs的61902端口是42:10建起来的，和lvs的61902建起来之后马上就出问题了

问题出现的条件

fulnat模式的LVS，RS上装有ip转换模块（RS上会将LVS ip还原成client ip）
client端正好重用一个相同的本地端口分别和RS以及LVS建立了两个连接

这个时候这两个连接在MySQL端就会变成一个，然后两个连接的内容互串，必然导致rst

这个问题还挺有意思的，估计没几个程序员一辈子能碰上一次。推荐另外一个好玩的连接：如何创建一个自己连自己的TCP连接

在很多容器场景也容易出现同样的问题，比如同时暴露 Nodeport 和 Loadbalance IP

其他场景

比如在 HA 场景下，需要通过直连节点去做心跳检查(B链路)；同时又要走A链路去跨机房检测，这两个链路下连接的目标IP一直、端口不一样，但是经过转换后都是MySQL-Server+3306端口，容易出现两条连接转换后变成一条连接

参考资料

就是要你懂负载均衡–lvs和转发模式

https://idea.popcount.org/2014-04-03-bind-before-connect/

no route to host

另一种形式的tcp连接互串，新连接重用了time_wait的port，导致命中lvs内核表中的维护的旧连接发给了老的realserver

类似场景汇总

下面罗列所有会导致这种问题的场景。

 ---
 场景总览

 ┌─────┬─────────────────────┬────────────────────────────────┬──────────────┐
 │  #  │        场景         │              根因              │   文中提及   │
 ├─────┼─────────────────────┼────────────────────────────────┼──────────────┤
 │ 1   │ LVS FNAT + TOA +    │ TOA 还原 client                │      ✅      │
 │     │ 直连并存             │ IP，与直连四元组重复              │              │
 ├─────┼─────────────────────┼────────────────────────────────┼──────────────┤
 │     │ K8s NodePort +      │                                │              │
 │ 2   │ LoadBalancer        │ 不同入口经 DNAT 后落到同一 Pod │      ✅      │
 │     │ 同时暴露            │                                │              │
 ├─────┼─────────────────────┼────────────────────────────────┼──────────────┤
 │ 3   │ Cloud NLB Client IP │ 不同 NLB IP 路由到同一后端，源 │      ✅      │
 │     │  保留 + 跨 AZ       │  IP 保留                       │              │
 ├─────┼─────────────────────┼────────────────────────────────┼──────────────┤
 │ 4   │ HA 多链路探测 + NAT │ 直连心跳 +                     │      ✅      │
 │     │  转换               │ 跨机房链路转换后四元组重合     │              │
 ├─────┼─────────────────────┼────────────────────────────────┼──────────────┤
 │     │ TIME_WAIT           │ 新连接复用了 TIME_WAIT         │              │
 │ 5   │ 端口复用命中旧      │ 端口，LVS 按旧表项转发         │ ✅(参考链接) │
 │     │ conntrack           │                                │              │
 ├─────┼─────────────────────┼────────────────────────────────┼──────────────┤
 │ 6   │ Docker/容器 DNAT +  │ 同一服务既通过 ClusterIP DNAT  │              │
 │     │ HostNetwork 直连    │ 又被直连                       │              │
 ├─────┼─────────────────────┼────────────────────────────────┼──────────────┤
 │ 7   │ 多层代理 Proxy      │ 代理还原 client IP             │              │
 │     │ Protocol 还原源 IP  │ 后与直连路径冲突               │              │
 ├─────┼─────────────────────┼────────────────────────────────┼──────────────┤
 │ 8   │ VPN/隧道 + 直连并存 │ VPN 内网 NAT                   │              │
 │     │                     │ 转换后与直连四元组重合         │              │
 └─────┴─────────────────────┴────────────────────────────────┴──────────────┘

 ---
 场景 1：LVS FNAT + TOA + 直连并存（上文案例）

                           客户端看到的：两条不同连接
                     ┌──────────────────────────────────────┐
                     │  连接A: client:61902 → LVS:3306      │
                     │  连接B: client:61902 → MySQL:3269    │
                     └──────────────────────────────────────┘

   ┌──────────┐            ┌──────────┐            ┌──────────────┐
   │  Client   │──连接A──→│   LVS    │──FNAT──→│   MySQL      │
   │           │            │ FNAT     │            │ 10.112:3269  │
   │           │            │ 10.141   │   TOA还原   │              │
   │           │            │ :3306    │──client IP→│  看到的连接A: │
   │           │            └──────────┘            │  client:61902│
   │           │                                    │  → MySQL:3269│
   │           │──连接B（直连）────────────────────→│              │
   │           │                                    │  看到的连接B: │
   └──────────┘                                    │  client:61902│
                                                   │  → MySQL:3269│
                                                   │              │
                                                   │  ⚠ 四元组完全 │
                                                   │    一样！互串！│
                                                   └──────────────┘

 触发条件：FNAT + TOA 还原 client IP + client 恰好复用同一本地端口分别连 LVS 和
 RS

 ---
 场景 2：K8s NodePort + LoadBalancer 同时暴露

   ┌──────────┐     NodePort (Node:30080)      ┌──────────┐     ┌─────────┐
   │  Client   │──连接A──→ DNAT ──────────────→│  Node    │────→│  Pod    │
   │           │                                │ kube-    │     │ 10.0.1.5│
   │           │     LoadBalancer (VIP:80)      │ proxy    │     │ :8080   │
   │           │──连接B──→ NLB ──→ DNAT ──────→│ iptables │────→│         │
   └──────────┘                                └──────────┘     └─────────┘

   Pod 侧看到（externalTrafficPolicy=Cluster，SNAT 场景）：

     连接A: NodeIP:random_port → Pod:8080
     连接B: NodeIP:random_port → Pod:8080
                      ↑
               如果 random_port 恰好相同 → 互串

 触发条件：同一 Service 同时暴露 NodePort 和
 LoadBalancer，externalTrafficPolicy=Cluster 做 SNAT 时源 IP 都变成 Node IP

 ---
 场景 3：Cloud NLB Client IP 保留 + 跨 AZ（Robinhood 案例）

                     NLB-a]                       ┌──────────────┐
               ┌──→ 10.98.98.50 ──────────────┐   │  API Server  │
   ┌────────┐  │   (client IP 保留)           │   │ 10.98.72.61  │
   │  KCM   │──┤                              ├──→│   :443       │
   │ :42852 │  │                              │   │              │
   └────────┘  │   NLB-b                      │   │ 看到两条连接：│
               └──→ 10.98.66.200 ─────────────┘   │ 都是         │
                   (client IP 保留)                │ KCM:42852    │
                                                   │ → API:443   │
                   跨AZ路由到同一后端               │              │
                                                   │ ⚠ 四元组重复 │
                                                   └──────────────┘

   客户端视角（不同五元组，合法复用端口）：
     KCM:42852 → NLB-a:443  ✅ 五元组不同
     KCM:42852 → NLB-b:443  ✅ 五元组不同

   服务端视角（Client IP 保留，NLB IP 被透传为 Client IP）：
     KCM:42852 → API:443  ⚠ 完全相同
     KCM:42852 → API:443  ⚠ 完全相同

 触发条件：Client IP 保留 + 跨 AZ 负载均衡 + tcp_tw_reuse=1 复用端口 + GOAWAY
 触发重连到不同 NLB 节点

 ---
 场景 4：HA 多链路探测 + NAT 转换

   ┌──────────┐                                      ┌──────────────┐
   │  HA 探测  │──B链路（直连心跳）────────────────────→│  MySQL       │
   │  Client   │    client:P → MySQL:3306             │  Server      │
   │           │                                      │  :3306       │
   │           │──A链路（跨机房，经NAT/LB）─────────────→│              │
   │           │    client:P → VIP:3307               │  经 NAT 转换 │
   │           │         ↓                            │  后变成：    │
   │           │    NAT 转成 client:P → MySQL:3306    │  client:P    │
   └──────────┘                                      │  → MySQL:3306│
                                                     │              │
                                                     │ ⚠ 两条链路在 │
                                                     │   MySQL侧重合│
                                                     └──────────────┘

 触发条件：HA 架构中同时存在直连和经 NAT 转换的链路，转换后目标 IP:Port 一致

 ---
 场景 5：TIME_WAIT 端口复用命中旧 LVS conntrack

   时间线：
   ──────────────────────────────────────────────────────────────→

   T1: client:9527 → LVS → RS-A:3306    (连接正常关闭，进入 TIME_WAIT)

   T2: client:9527 → LVS → ???
       │
       ├─ 内核 tcp_tw_reuse=1，复用了 9527 端口
       ├─ LVS 调度应该分给 RS-B
       ├─ 但 LVS conntrack 表中还有旧条目：client:9527 → RS-A
       └─ LVS 按旧表项把包发给了 RS-A ← ⚠ 连接串到了错误的后端

   RS-A 收到一个 SYN，但 conntrack 里这条连接还在
   → Challenge ACK → RST → 连接异常

 触发条件：tcp_tw_reuse=1 + LVS conntrack 超时 > TCP TIME_WAIT 时间 +
 端口被快速复用

 ---
 场景 6：容器 DNAT + HostNetwork 直连

   ┌──────────┐    ClusterIP (DNAT)        ┌──────────┐     ┌─────────────┐
   │  Pod-A   │──连接1──→ kube-proxy ─────→│  Node    │────→│  Pod-B      │
   │ (同Node) │          iptables DNAT     │          │     │ HostNetwork │
   │          │                            │          │     │ NodeIP:8080 │
   │          │──连接2──→ 直连 HostNetwork──────────────────→│             │
   └──────────┘                                             └─────────────┘

   如果 DNAT 后目标变成 NodeIP:8080，与直连路径完全一致
   且源端口碰撞 → 四元组重复 → 互串

 触发条件：Pod-B 使用 HostNetwork，同 Node 上的 Pod-A 同时通过
 ClusterIP（DNAT）和直连访问

 ---
 场景 7：多层代理 Proxy Protocol 还原源 IP

   ┌──────────┐      ┌──────────┐      ┌──────────┐      ┌──────────┐
   │  Client  │─────→│ Proxy-A  │─────→│ Proxy-B  │─────→│  Server  │
   │  :P      │      │ HAProxy  │      │ Nginx    │      │  :80     │
   └──────────┘      │ Proxy    │      │ 还原      │      │          │
                     │ Protocol │      │ client IP│      │ 看到:    │
                     └──────────┘      └──────────┘      │client:P  │
                                                         │→Server:80│
   ┌──────────┐                                          │          │
   │  Client  │──直连（不经过代理）────────────────────────→│client:P  │
   │  :P      │                                          │→Server:80│
   └──────────┘                                          │ ⚠ 重复   │
                                                         └──────────┘

 触发条件：代理链使用 Proxy Protocol / TOA 还原了真实 client IP + client
 同时有直连路径

 ---
 场景 8：VPN/隧道 + 直连并存

   ┌──────────┐     VPN 隧道                  ┌──────────┐
   │  Client   │──连接1──→ VPN Gateway ──NAT──→│  Server  │
   │  办公网   │    经隧道封装,出口NAT            │  内网    │
   │  :P      │    变成 client_inner:P         │  :3306   │
   │          │                                │          │
   │          │──连接2──→ 直连内网 ────────────→│          │
   │          │    client_inner:P → Server:3306│          │
   └──────────┘                                └──────────┘

   如果 VPN NAT 后的源 IP 恰好是 client 的内网 IP（split tunnel 场景）
   + 端口碰撞 → 四元组重复

 触发条件：Split tunnel VPN + NAT 后源 IP 与直连内网 IP 相同 + 端口碰撞

 ---
 共性规律总结

 所有场景的本质都是同一个模式：

   Client ──路径1（经过中间层转换）──→ Server
   Client ──路径2（直连或经另一中间层）──→ Server

   路径1 在 Server 侧的四元组 ══ 路径2 在 Server 侧的四元组

   ⚠ 互串！

 触发三要素：
   ┌─────────────────────────────────────────────────┐
   │  1. 存在多条路径到达同一后端                      │
   │  2. 中间层做了地址转换（NAT/FNAT/DNAT/IP保留）    │
   │  3. 转换后的四元组与另一路径的四元组碰撞          │
   └─────────────────────────────────────────────────┘

附录一篇 k8s 场景下的同样的问题：

[GOAWAY Chance——客户端连接丢失始末](https://robinhood.com/us/en/newsroom/goaway-chance-chronicles-of-client-connection-lo
st/)

作者： Eric Ngo
编辑： Nick Turner 与 Sujith Katakam
发布日期： 2024 年 5 月 23 日

分布式系统本已十分复杂，而各系统之间的交互更是如此。Kubernetes 就是这样一个典型——其采用率正在快速上升。随着
我们向集群中引入越来越多的组件（也带来了更多的复杂性），理解变更所产生的下游影响变得愈加困难。在 Robinhood
的软件平台团队，我们作为 Kubernetes 从业者，必须深入排查那些由最细微的配置变更所引发的系统问题。在这篇博客中
，我们将回顾一个近期的案例——我们深入钻研了内核设置、NLB 配置和开源代码，最终定位了一个看似无害的 Kubernetes
API Server 配置项所导致的连接问题。

问题

使用 client-go 的 Kubernetes 客户端在连接 API Server 时，默认使用 HTTP/2。HTTP/2 利用持久 TCP
连接和”流”（stream）的概念，将多个 HTTP 请求复用到同一条 TCP 连接上。相较于 HTTP 1.1 每次请求都需要重新建立
TCP 与 TLS 握手，HTTP/2 通过减少 RTT 实现了更高的性能。

然而我们观察到一个现象：由于这些长期存活的持久连接，API Server 之间的负载出现了不均衡。这会导致某些 API
Server 承受不成比例的负载，并对系统可靠性产生级联影响。当我们对控制平面节点执行滚动更新时——这是更新控制平面
组件或修改配置时的常规操作——这种不均衡现象尤为明显。

为了解决客户端”粘性”问题，我们决定配置 Kubernetes API Server 的 –goaway-chance 参数。该参数在 k8s 1.18
中引入，是一个 API Server HTTP 过滤器，它以一定概率向 HTTP/2 客户端发送 RST_STREAM，强制客户端在新建立的 TCP
连接上重新发起请求。通过启用此设置，我们实现了显著改善的连接均衡和负载分发。

在将 –goaway-chance 推送到预生产环境后，我们开始偶发性地观察到集群中出现节点被标记为 NotReady 的现象。

node ip-10-241-33-82.us-west-2.compute.internal hasn’t been updated for 40.956376745s. Last Ready is: …

进一步检查后，我们发现是 kube-controller-manager 在将节点标记为不健康。每个节点上的 kubelet 负责更新节点的
kube-node-lease，这是一种心跳机制，用于表明节点能否与 API Server 正常通信。kube-controller-manager
运行一个名为 node_lifecycle_controller 的控制循环，负责在节点未能及时续约 kube-node-lease 时更新其 Ready
状态条件。默认情况下，kubelet 每隔 renewInterval（10 秒）更新一次 Lease 对象，而 kube-controller-manager
则检查 Lease 是否在 nodeMonitorGracePeriod（40 秒）内完成了续约。

因此，当收到少量节点报告为 NotReady 时，可能有两种原因：少数节点确实不健康（kubelet 无法执行心跳），或者
kube-controller-manager 的 lease informer 未能接收到更新。

检查了某个被标记为不健康节点的 kubelet 日志和心跳更新审计日志后，我们很快排除了 kubelet
的嫌疑。于是我们将注意力集中到 kube-controller-manager 上，发现了一条颇为奇特的日志：

W1215 09:45:02.898142 1 reflector.go:441] k8s.io/client-go/informers/factory.go:134: watch of
*v1.Lease ended with: an error on the server (“unable to decode an event from the watch stream: http2:
client connection lost”) has prevented the request from succeeding

client connection lost 是什么意思，它又是如何导致 informer 超过 40 秒未收到任何更新的呢？

客户端连接丢失（Client Connection Lost）

还记得 HTTP/2 使用持久 TCP 连接这一点。由于是互联网，客户端与服务器之间可能发生各种各样的情况。因此，HTTP/2
允许通过健康检查来检测远端是否存在问题。在 Kubernetes 的 golang
客户端库（k8s.io/client-go）中，这些健康检查由 net/http2 库以 HTTP/2 ping 的形式执行。

// closes the client connection immediately. In-flight requests are interrupted.
func (cc *ClientConn) closeForLostPing() {
err := errors.New(“http2: client connection lost”)
if f := cc.t.CountError; f != nil {
f(“conn_close_lost_ping”)
}
cc.closeForError(err)
}

这些 ping 会在连接上超过 ReadIdleTimeout 秒未收到任何帧后触发。超过 PingTimeout 秒后，连接将被关闭。

// ReadIdleTimeout 是在连接上未收到任何帧后，
// 使用 ping 帧执行健康检查的超时时间。
// 注意，ping 响应也被视为已收到帧，
// 因此如果连接上没有其他流量，
// 健康检查将每隔 ReadIdleTimeout 间隔执行一次。
// 如果为零，则不执行健康检查。
ReadIdleTimeout time.Duration

// PingTimeout 是在未收到 Ping 响应时关闭连接的超时时间。
// 默认为 15 秒。
PingTimeout time.Duration

Kubernetes 默认的传输配置将 ReadIdleTimeout 设为 30 秒，PingTimeout 设为 15 秒。

func readIdleTimeoutSeconds() int {
ret := 30
if s := os.Getenv(“HTTP2_READ_IDLE_TIMEOUT_SECONDS”); len(s) > 0 {
i, err := strconv.Atoi(s)
if err != nil {
klog.Warningf(“Illegal HTTP2_READ_IDLE_TIMEOUT_SECONDS(%q): %v.”+
“ Default value %d is used”, s, err, ret)
return ret
}
ret = i
}
return ret
}

func pingTimeoutSeconds() int {
ret := 15
if s := os.Getenv(“HTTP2_PING_TIMEOUT_SECONDS”); len(s) > 0 {
i, err := strconv.Atoi(s)
if err != nil {
klog.Warningf(“Illegal HTTP2_PING_TIMEOUT_SECONDS(%q): %v.”+
“ Default value %d is used”, s, err, ret)
return ret
}
ret = i
}
return ret
}

readIdleTimeout 与 pingTimeout 之和为 45 秒，这可以解释为什么 lease informer 会超过 40
秒未收到任何更新，从而导致 kube-controller-manager 认为节点已超过 40 秒的 leaseDuration
未续约，进而将节点标记为 NotReady。但问题依然存在：连接为何会挂起 45 秒？

我们的环境

NLB

每个集群都有一个 NLB 对 API Server 的连接进行负载均衡。这些 NLB 配置了客户端 IP 保留（client-ip
preservation）和跨 AZ 负载均衡（cross zone load balancing）。启用客户端 IP 保留，是为了让通过 NLB
的并发连接数能够超过 NLB 约 65000 个的临时端口范围限制。启用跨 AZ
负载均衡，则是为了提升可靠性并增强对部分控制平面故障的抗风险能力。

API Server 与 kube-controller-manager

我们使用 kOps（一款 Kubernetes 集群管理工具）来引导集群的创建。每个集群有 5
个控制平面节点。kube-controller-manager、kube-scheduler
等所有控制平面组件都运行在控制平面节点上，并配置为通过 NLB 与 API Server 通信。

节点

我们的节点配置了 net.ipv4.tcp_tw_reuse = 1，这允许处于 TIME_WAIT
状态的套接字被复用，以及将端口复用到不同的目标。只要连接的五元组（协议、源 IP、源端口、目标
IP、目标端口）不同，使内核能够区分新旧连接，未绑定的端口就可以被复用。

了解了环境后，我们来看如何复现这个问题。

复现过程

原生集群

最初，我们认为问题仅由 goaway-chance 引起，于是尝试创建一个原生集群来复现——其中 kube-controller-manager 通过
localhost 直接与 API Server 通信，网络路径如下：

设置 goaway-chance 后，我们无法复现该问题。我们的原生集群与生产集群环境的唯一区别，是控制平面组件通过 NLB
路由到 API Server。因此我们决定在测试环境中也加入一个 NLB。

参考配置

以下是所用 IP 的配置情况：

NLB 由以下各可用区的实例提供支持。注意，由于启用了跨 AZ 负载均衡，每个 NLB 实例都可以访问任意 API Server
目标。

┌──────────────┬────────────┐
│ NLB IP │ NLB 可用区 │
├──────────────┼────────────┤
│ 10.98.35.159 │ us-west-2a │
├──────────────┼────────────┤
│ 10.98.66.200 │ us-west-2b │
├──────────────┼────────────┤
│ 10.98.98.50 │ us-west-2c │
└──────────────┴────────────┘

由于我们只关心 kube-controller-manager 与 kube-apiserver 之间的交互，相关实例如下：

┌─────────────────┬─────────────────────────────────────────┐
│ 控制平面主机 IP │ 运行进程 │
├─────────────────┼─────────────────────────────────────────┤
│ 10.98.102.166 │ kube-controller-manager, kube-apiserver │
├─────────────────┼─────────────────────────────────────────┤
│ 10.98.72.61 │ kube-apiserver │
└─────────────────┴─────────────────────────────────────────┘

通过 NLB 通信

我们通过设置 –master 参数，将 kube-controller-manager 配置为与 NLB 通信，很快就复现了 client connection
lost 问题。但 NLB 与 client connection lost 有什么关系呢？

为了更好地理解 net/http 包底层的行为，并了解 TCP 连接的状态，我们采取了以下措施：

设置 GODEBUG=http2debug=2 以开启详细的 HTTP/2 日志并输出帧转储；
在 kube-controller-manager 的 manifest 的环境变量中，添加 key 为 GODEBUG、value 为 http2debug=2 的配置。

这样我们就可以将 net/http2 的活动与 TCP 抓包进行关联，从而精确定位问题中的 TCP 流并加以分析。

分析 HTTP/2 调试日志

启用 http2debug 日志后，我们捕获到了一次 client connection lost 发生时的 HTTP/2 活动：

{“log”:”I0125 01:56:38.494896 1 log.go:184] http2: Framer 0xc00151c1c0: read DATA stream=5 len=2535 …
{“log”:”I0125 01:56:38.494946 1 log.go:184] http2: Framer 0xc00151c1c0: wrote WINDOW_UPDATE stream=5 len=4
incr=5066\n”,…}
{“log”:”I0125 01:57:08.495926 1 log.go:184] http2: Framer 0xc00151c1c0: wrote PING len=8
ping="x\x85ex\xc5*\xd1\xd5"\n”,…}
{“log”:”I0125 01:57:23.496850 1 log.go:184] http2: Framer 0xc00151c1c0: wrote RST_STREAM stream=5 len=4
ErrCode=CANCEL\n”,…}
{“log”:”I0125 01:57:23.496896 1 log.go:184] http2: Framer 0xc00151c1c0: wrote RST_STREAM stream=1 len=4
ErrCode=CANCEL\n”,…}
{“log”:”W0125 01:57:23.496885 1 reflector.go:441] k8s.io/client-go/informers/factory.go:134: watch of
*v1.Pod ended with: an error on the server ("unable to decode an event from the watch stream: http2: client
connection lost") has prevented the request from succeeding\n”,…}

在 1:56:38，负责单条 TCP 连接上请求复用的 framer 0xc00151c1c0 从服务器读取了一些数据并执行了
WINDOW_UPDATE。此后连接在 readIdleTimeout（30 秒）内未收到任何更新，于是客户端向服务器写入了一个
PING。又过了 pingTimeout（15 秒），客户端最终写入了 RST_STREAM 终止流，并记录了 client connection lost。

kube-controller-manager TCP 抓包分析

分析 10.98.102.166:42852 <> 10.98.66.200:443

在一次 client connection lost 发生期间，我们进行了数据包捕获，找到了一条与 http2 调试日志高度吻合的 TCP
流（tcp.stream eq 1110）。我们看到 KCM 主机 10.98.102.166 正在与 NLB 之一 10.98.66.200 通信。

我们看到在 15:56:38 收到了一个帧，30 秒后，客户端 10.98.102.166 在 15:57:08 发送了
PING。看起来有响应返回，但仔细查看报文后发现，第 138783 帧的确认号（acknowledgement number）与第 138772
帧的序列号（Sequence number）并不匹配。在 15:57:23 经过 15 秒的 pingTimeout 后，我们看到客户端发送了
RST_STREAM，随后连接关闭。

继续分析该流的其余部分，发现了一些可疑之处：

出现了 TCP 端口号被复用（tcp port number reused）的警告。同一端口是否还有其他流在使用？

分析 10.98.102.166:42852 <> 10.98.98.50:443

我们看到了另一条 TCP 流，客户端 10.98.102.166 正在使用与前面相同的端口 42852，与另一个 NLB 10.98.98.50
通信（目标端口 443）。注意，由于我们的节点设置了 tcp_tw_reuse = 1，只要五元组字段（协议、源 IP、源端口、目标
IP、目标端口）不同，端口就允许被复用。这看起来是正常的，但这条流是否也存在异常呢？

这条流同样出现了相同的症状：在 15:56:08 最后一次收到数据，30 秒后的 15:56:38 发送
PING，在多次重传失败后，最终于 15:56:53 发送 RST_STREAM 并终止连接。这条流同样收到了前面提到的 client
connection lost 错误。接下来，让我们以端口 42852 为单位，过滤出所有相关流。

以端口 42852 为维度的全局分析

找到了！看来在 10.98.102.166:42852 <> 10.98.98.50:443 这条连接断开的同时，客户端尝试复用端口 42852 与另一个
NLB 10.98.66.200 建立新连接。在第 36711 帧，客户端发送了 SYN。然而，由于服务器认为旧连接仍然存在，它返回的是
Challenge ACK 而非 SYN-ACK。客户端随即发送了 TCP RST
报文，彻底断开了双端的连接并完全重置了连接状态。此后，客户端 10.98.102.166:42852 得以成功与 NLB
10.98.66.200:443 完成 TCP 三次握手。

这究竟是怎么回事？

让我们简要回顾一下 NLB 在这里的行为。NLB 是一种四层（TCP/IP
层）负载均衡器，接收连接并在客户端与服务器之间充当代理。

我们为 API Server 前置的 NLB 启用了一项名为客户端 IP 保留的功能。该功能实质上是将 TCP 数据包的源 IP
和端口替换为发送方的真实 IP 和端口，而不是 NLB 自身的。这使目标端能够接受更多连接，同时保留了 IP
信息，便于追踪和审计等用途。除客户端 IP 保留外，我们还启用了跨 AZ 负载均衡，允许 NLB 路由至任意后端目标。

这意味着：从客户端视角来看，即便路由到不同的 NLB IP（且复用同一端口），NLB
背后的目标节点也可能是同一台主机。从服务器视角来看，它会在一条已建立的 socket 上收到一个新的连接请求，并发送
Challenge ACK，这将触发连接重置（RST）。

在这个具体案例中，客户端（10.98.102.166）复用了同一端口（42852），经过不同的 NLB（10.98.98.50:443 和
10.98.66.200:443），但最终都落到了同一个目标（10.98.72.61:443）。这就解释了：为什么在使用相同端口向
10.98.66.200 建立第二条连接时，我们收到了 Challenge ACK；以及为何在发送 RST 报文后，发往 10.98.98.50
的原始连接被切断，而发往 10.98.66.200 的新连接则得以建立。

完整流程如下：

最初，kube-controller-manager 和 kube-apiserver 的 socket 状态均为空。kube-controller-manager 首先以五元组
(tcp, 10.98.102.166, 42852, 10.98.98.50, 443) 建立了一条 socket 连接。NLB 将该连接路由至 API Server
10.98.72.61，其”连接表”中记录了 socket 状态 (tcp, 10.98.102.166, 42852, 10.98.72.61, 443)。

不久后，客户端收到 GOAWAY，复用端口 42852 建立了一条新连接，五元组变为 (tcp, 10.98.102.166, 42852,
10.98.66.200, 443)——注意这是相同的客户端 IP，但是不同的 NLB IP。NLB
尝试将该连接路由至同一目标。此时，由于启用了客户端 IP 保留，kube API Server
发现连接表中已存在该连接（因为端口复用导致客户端端口相同）。在一条已建立的连接中途收到 SYN 后，它发送了
Challenge ACK。当客户端发回 RST 时，服务器彻底重置了客户端 IP 与端口对 10.98.102.166:42852
的连接状态，完全切断了原始连接，并允许以相同的客户端端口建立新连接。

为了更完整地说明，我们再次复现了该问题，并在服务器端进行了 tcpdump 抓包，精确捕获到了我们所推断的过程：

服务器在一条 TCP 流中途收到了一个序列号/确认号异常的 SYN。它回应了 Challenge ACK，客户端随后回复了
RST，将服务器端的 TCP 连接彻底切断。

总结：启用了客户端 IP 保留与跨 AZ 负载均衡，节点设置了 tcp_tw_reuse=1，同一客户端（相同的源 IP
和源端口）通过不同的 NLB IP 路由后，落到了同一目标（相同的目标 IP
和目标端口）。这导致负载均衡目标节点在已建立的 TCP 连接上收到了意外的 SYN，并发送了 Challenge
ACK；客户端回复 RST，将服务器端的连接切断。这使现有的长连接 HTTP/2 流（例如 informer Watch 连接）在超时 45
秒后收到 client connection lost 错误。

NLB 官方文档

但这不就是 NLB 的 bug 吗？其实，这与其说是 bug，不如说是 NLB 启用客户端 IP 保留与跨 AZ
负载均衡后的一个既定特性。正如 AWS 在其 NLB “要求和注意事项”中所述：

当启用客户端 IP 保留时，不支持 NAT 回路（也称为 hairpinning）。启用后，当客户端或其前端的 NAT
设备在同时连接多个负载均衡器节点时使用相同的源 IP 地址和源端口，您可能会遇到与目标节点上的 socket 复用相关的
TCP/IP 连接限制。如果负载均衡器将这些连接路由到同一目标，目标节点会认为它们来自相同的源
socket，从而导致连接错误。如果发生这种情况，客户端可以重试（如果连接失败）或重新连接（如果连接中断）。您可以
通过增加源端临时端口数或增加负载均衡器目标数来减少此类连接错误。也可以通过禁用客户端 IP 保留或禁用跨 AZ
负载均衡来完全避免此类连接错误。

这里主要有两种考量：

禁用客户端 IP 保留——代价是将并发连接数限制在约 65000 个临时端口范围之内；
禁用跨 AZ 负载均衡——这将防止不同的负载均衡实例将连接路由到同一后端。

考虑到 –goaway-chance 的使用场景，我们决定将其值设得足够低，使端口复用的触发概率低于 1%。

在测试过程中，我们还遇到了上面提到的 NLB 回路超时问题——当 NLB 目标节点本身也是客户端时（即源 IP == 目标
IP），可能会使数据包失效。我们的解决方案是：在 kube-apiserver 的 GOAWAY 过滤器中忽略特定的
userAgent，以避免在重新连接时触发这种回路超时。

总结

在处理分布式系统时，变更往往会产生意想不到的影响。对我们这些管理这些系统的人来说，熟悉工具并敢于深入挖掘那些
尚不理解的行为，至关重要。这样的机会在我的 Robinhood 团队中时常出现。如果你对 Kubernetes
充满热情、热爱深入钻研，欢迎申请加入！我们目前正在招聘一名高级软件工程师加入我们的容器编排团队。

特别感谢我的队友 Nick Turner、Madhu CS 和 Palash Agrawal 的全力支持！

MySQL针对秒杀场景的优化

发表于 2020-11-18 更新于 2025-11-29 分类于 MySQL

MySQL针对秒杀场景的优化

背景

对于秒杀热点场景，MySQL官方版本500 TPS每秒，在对MySQL优化前只能用redis来扛，redis没有事务能力，比如一个item下有多个sku就搞不定了。同时在前端搞限流、答题等让秒杀流量控制在可以承受的范围内。

过程

对于秒杀热点场景，MySQL官方版本扣减只能做到 500 TPS每秒，扛不住大促的流量，需要优化。从控制并发量将500优化到1400，再通过新语法来消除网络rtt对加锁时间的控制这样达到了 4000 TPS。最后合并多个扣减到一个，累积比如10ms提交，能将TPS 能升到4万以上这个能力。

排队控制并发

拍减模式在整个交易过程中只有一次扣减交互，所以是不需要付款减库存那样的判重逻辑，就是说，拍减的减库存sql只有一条update语句就搞定了。而付减有两条，一条insert判重+一条update减库存（双十一拍减接口在高峰的rt约为8ms，而付减接口在高峰的rt约为15ms）；

其次，当大量请求（线程）落到mysql的同一条记录上进行减库存时，线程之间会存在竞争关系，因为要争夺InnoDB的行锁，当一个线程获得了行锁，其他并发线程就只能等待（InnoDB内部还有死锁检测等机制会严重影响性能），当并发度越高时，等待的线程就越多，此时tps会急剧下降，rt会飙升，性能就不能满足要求了。那如何减少锁竞争？答案是：排队！库存中心从几个层面做了排队策略。

首先，在应用端进行排队，因为很多商品都是有sku的，当sku库存变化时item的库存也要做相应变化，所以需要根据itemId来进行排队，相同itemId的减库存操作会进入串行化排队处理逻辑，不过应用端的排队只能做到单机内存排队，当应用服务器数量过多时，落到db的并发请求仍然很多，所以最好的办法是在db端也加上排队策略，今年库存中心db部署了两个的排队patch，一个叫“并发控制”，是做在InnoDB层的，另一个叫“queue on pk”，是做在mysql的server层的，两个patch各有优缺点，前者不需要应用修改代码，db自动判断，后者需要应用程序写特殊的sql hint，前者控制的全局的sql，后者是根据hint来控制指定sql，两个patch的本质和应用端的排队逻辑是一致的，具体实现不同。双十一库存中心使用的是“并发控制”的patch。

2013年的单减库存TPS最高记录是1381次每秒。

对于秒杀热点场景，官方版本500tps每秒，问题在于同时涌入的请求太多，每次取锁都要检查其它等锁的线程（防止死锁），这个线程队列太长的话导致这个检查时间太长；继续在前面增加能够进入到后面的并发数的控制，通过增加线程池、控制并发能到1400（no deadlock list check）；

热点更新下的死锁检测(no deadlock list check)

由于热点更新是分布式的客户端并发的向单点的数据库进行了并行更新一条记录，到数据库最后是把并行的线程转行成串行的操作。但在串行操作的时候，由于对同一记录的锁申请列表过大，死锁检测的机制在检测锁队列的时候，反而拖慢了每一个更新。

原生版本的MySQL对于正常业务链接没有拒绝机制（除了TDDL的链接池或者MySQL的user_connnection不够用），对于同一行记录到innodb层修改的时候，凡是到innodb层的任务都必须拿到innodb_thread_concurrency的槽位才能执行(当然这里也有很多细节，这里就说最主要的代码改动点)，举例来说：开启一个事务，对于id=1的行记录更新，进到innodb层，占着1个innodb_thread_concurrency，等到id=1的事务结束，会释放innodb_thread_concurrency,从而达到innodb_thread_concurrency的平衡；

再进一步，开启一个事务，对id=1的行记录更新进到innodb层，占着1个innodb_thread_concurrency，事务不提交（假设innodb_thread_concurrency=32)，如果有下一个对id=1记录来更新的话，进到innodb层，又占着1个innodb_thread_concurrency，检测发现是对id=1的更新，排到第1个对id=1的队列的后面，同时释放innodb_thread_concurrency;以此类推这个链表有可能会很长比如1024；执行的时候又需要做死锁检测等一系列工作，都需要用到一个叫做kernel_mutex的mutex（这是一个全局互斥量用来管理锁系统，事务系统，MVCC多版本控制），对于大并发，整个链表非常长的时候，可想而知kernel_metex的竞争多么激烈，从而在链表检测的时间变长。

缩短锁时间

接下来的问题在于一个事务中有多条语句（最少也有一个update+一个commit），这样update(减库存，开始锁表），走网络，查询结果（走网络），commit，两次跨网络调用导致update锁行比较久，于是可以新造一个语法 select update一次搞定，继续优化 select update commit_on_success_or_fail_rollback，将所有操作一次网络操作全部搞定，能到4000；

比如库存扣减的业务逻辑可以简化为下面这个事务:

（1）begin;

（2）insert 交易流水表; – 交易流水对账

（3）update 库存明细表 where id in (sku_id，item_id);

（4）select 库存明细表;

（5）commit

SQL case：

4059550 Query   SET autocommit=0
4059550 Query   update ROLLBACK_ON_FAIL TARGET_AFFECT_ROW 1 trade set version = version+3 ,gmt_modified = now(), optype=2,feature =';abc;' where sub_biz_order_id='15' and biz_order_type =1 and id =5 and ti_id=1 and optype = 3 and root_id = 11
4059550 Query   select id,* from update COMMIT_ON_SUCCESS ROLLBACK_ON_FAIL TARGET_AFFECT_ROW 1 invetory set                     withholding_quantity = withholding_quantity + -1,  flag=flag &~ (1<<10) &~ (1<<11) , version=version+3,gmt_modified = now()         WHERE  root_id = 11 and status = 1 and id in    (     1    )  and (withholding_quantity + -1) >= 0
4059550 Query   commit

批量提交

其主要的核心思想是：针对应用层SQL做轻量化改造，带上”热点行SQL”的hint，当这种SQL进入内核后，在内存中维护一个hash表，将主键或唯一键相同的请求(一般也就是同一商品id)hash到同一个地方做请求的合并，经过一段时间后(默认100us)统一提交，从而实现了将串行处理变成了批处理，让每个热点行更新请求并不需要都去扫描和更新btree。

热点的自动识别:前面已经讲过了，库存的扣减SQL都会有commit on success标记。mysql内部分为普通通道和热点扣减通道。普通通道里是正常的事务。热点通道里收集带有commit on success标记的事务。在一定的时间区间段内(0.1ms)，将收集到的热点按照主键或者唯一键进行hash; hash到同一个桶中为相同的sku; 分批组提交这0.1ms收集到的热点商品。
轮询处理: 第一批进行提交时，第二批进行收集；当第一批完成了提交开始收集时，第二批就可以进行提交了。不断轮询，提高效率

通过内存合并库存减操作，干到100000（每个减库存操作生成一条独立的update binlog，不影响其他业务2016年双11），实际这里还可以调整批提交时间间隔来进一步提升扣减QPS

超卖：付款减库存会超卖，拍减库存要防止恶意拍不付款。拍减的话可以通过增加SQL新语法来进一步优化DB响应(select update)

innodb_buffer_pool_instance: 将buffer pool 分成几个（hash），避免高并发修改的时候一个大锁mutex导致性能不高

批量提交的压测效果：

业务优化

延迟扣减item，一般一个item下会有多个sku（比如 iPhone14 不同的颜色、配置就是一个不同的sku），而库存会有总库存（item），也有sku 库存，sku库存加起来就是item库存

导致扣减的时候 item库存更热

MySQL线程池导致的延时卡顿排查

发表于 2020-11-17 更新于 2025-11-16 分类于 MySQL

MySQL 线程池导致的卡顿

问题描述

简单小表的主键点查SQL，单条执行很快，但是放在业务端，有时快有时慢，取了一条慢sql，在MySQL侧查看，执行时间很短。

通过Tomcat业务端监控有显示慢SQL，取slow.log里显示有12秒执行时间的SQL，但是这次12秒的执行在MySQL上记录下来的执行时间都不到1ms。

所在节点的tsar监控没有异常，Tomcat manager监控上没有fgc，Tomcat实例规格 16C32g*8, MySQL 32c128g *32 。

5-28号现象复现，从监控图上CPU、内存、网络都没发现异常，MySQL侧查到的SQL依然执行很快，Tomcat侧记录12S执行时间，当时Tomcat节点的网络流量、CPU压力都很小。

所以客户怀疑Tomcat有问题或者Tomcat上的代码写得有问题导致了这个问题，需要排查和解决掉。

接下来我们会先分析这个问题出现的原因，然后会分析这类问题的共性同时拓展到其它场景下的类似问题。

Tomcat上抓包分析

慢的连接

经过抓包分析发现在慢的连接上，所有操作都很慢，包括set 命令，慢的时间主要分布在3秒以上，1-3秒的慢查询比较少，这明显不太符合分布规律。并且目前看慢查询基本都发生在MySQL的0库的部分连接上（后端有一堆MySQL组成的集群），下面抓包的4637端口是MySQL的服务端口：

以上两个连接都很慢，对应的慢查询在MySQL里面记录很快。

慢的SQL的response按时间排序基本都在3秒以上：

或者只看response time 排序，中间几个1秒多的都是 Insert语句。也就是1秒到3秒之间的没有，主要是3秒以上的查询

快的连接

同样一个查询SQL，发到同一个MySQL上(4637端口)，下面的连接上的所有操作都很快，下面是两个快的连接上的执行截图

别的MySQL上都比较快，比如5556分片上的所有response RT排序，只有偶尔极个别的慢SQL

MySQL相关参数

mysql> show variables like '%thread%';
+--------------------------------------------+-----------------+
| Variable_name                              | Value           |
+--------------------------------------------+-----------------+
| innodb_purge_threads                       | 1               |
| innodb_MySQL_thread_extra_concurrency        | 0               |
| innodb_read_io_threads                     | 16              |
| innodb_thread_concurrency                  | 0               |
| innodb_thread_sleep_delay                  | 10000           |
| innodb_write_io_threads                    | 16              |
| max_delayed_threads                        | 20              |
| max_insert_delayed_threads                 | 20              |
| myisam_repair_threads                      | 1               |
| performance_schema_max_thread_classes      | 50              |
| performance_schema_max_thread_instances    | -1              |
| pseudo_thread_id                           | 12882624        |
| MySQL_is_dump_thread                         | OFF             |
| MySQL_threads_running_ctl_mode               | SELECTS         |
| MySQL_threads_running_high_watermark         | 50000           |
| rocksdb_enable_thread_tracking             | OFF             |
| rocksdb_enable_write_thread_adaptive_yield | OFF             |
| rocksdb_signal_drop_index_thread           | OFF             |
| thread_cache_size                          | 100             |
| thread_concurrency                         | 10              |
| thread_handling                            | pool-of-threads |
| thread_pool_high_prio_mode                 | transactions    |
| thread_pool_high_prio_tickets              | 4294967295      |
| thread_pool_idle_timeout                   | 60              |
| thread_pool_max_threads                    | 100000          |
| thread_pool_oversubscribe                  | 10              |
| thread_pool_size                           | 96              |
| thread_pool_stall_limit                    | 30              |
| thread_stack                               | 262144          |
| threadpool_workaround_epoll_bug            | OFF             |
| tokudb_cachetable_pool_threads             | 0               |
| tokudb_checkpoint_pool_threads             | 0               |
| tokudb_client_pool_threads                 | 0               |
+--------------------------------------------+-----------------+
33 rows in set (0.00 sec)

综上结论

问题原因跟MySQL线程池比较相关，慢的连接总是慢，快的连接总是快。需要到MySQL Server下排查线程池相关参数。

同一个慢的连接上的回包，所有 ack 就很快（OS直接回，不需要进到MySQL），但是set就很慢，基本理解只要进到MySQL的就慢了，所以排除了网络原因（流量本身也很小，也没看到乱序、丢包之类的）

问题解决

18点的时候将4637端口上的MySQL thread_pool_oversubscribe 从10调整到20后，基本没有慢查询了：

当时从MySQL的观察来看，并发压力很小，很难抓到running thread比较高的情况（update: 可能是任务积压在队列中，只是96个thread pool中的一个thread全部running，导致整体running不高）

MySQL记录的执行时间是指SQL语句开始解析后统计，中间的等锁、等Worker都不会记录在执行时间中，所以当时对应的SQL在MySQL日志记录中很快。

thread_pool_stall_limit 会控制一个SQL过长时间（默认60ms）占用线程，如果出现stall_limit就放更多的SQL进入到thread pool中直到达到thread_pool_oversubscribe个

The thread_pool_stall_limit affects executing statements. The value is the amount of time a statement has to finish after starting to execute before it becomes defined as stalled, at which point the thread pool permits the thread group to begin executing another statement. The value is measured in 10 millisecond units, so the default of 6 means 60ms. Short wait values permit threads to start more quickly. Short values are also better for avoiding deadlock situations. Long wait values are useful for workloads that include long-running statements, to avoid starting too many new statements while the current ones execute.

类似案例

一个其它客户同样的问题的解决过程，最终发现是因为thread pool group中的active thread count 计数有泄漏，导致达到thread_pool_oversubscribe 的上限(实际没有任何线程运行)

问题：1）为什么调整到20后 active_thread_count 没变，但是不卡了？那以前卡着的10个 thread在干嘛？

2）卡住的根本原因是，升级能解决？

调整前的 thread pool 配置：

出问题时候的线程池 32个 group状态，有两个group queue count、active thread都明显到了瓶颈：select * from information_schema.THREAD_POOL_STATUS;

id 线程组id
thread_count // 当前线程组中的线程数量
active_thread_count //当前线程组中活跃线程数量，这个不包含dump线程
waiting_thread_count // 当前线程组中处于waiting状态的线程数量
dump_thread_count // dump类线程数量
slow_thread_timeout_count // 目前仅对DDL生效
connection_count // 当前线程组中的连接数量
low_queue_count // 低优先级队列中的请求数量
high_queue_count // 高优先级队列中的请求数量
waiting_thread_timeout_count // 处于waiting状态并且超时的线程数量

or: select sum(LOW_QUEUE_COUNT) from information_schema.thread_pool_status;

调整 thread_pool_oversubscribe由10到20后不卡了，这时的 pool status(重点注意 ACTIVE_THREAD_COUNT 数字没有任何变化)：

看起来像是 ACTIVE_THREAD 全假死了，没有跑任务也不去take新任务一直卡在那里，类似线程泄露。查看了一下所有MySQLD 线程都是 S 的正常状态，并无异常。

继续分析统计了一下mysqld线程数量(157)，远小于 thread pool 中的active线程数量(202)，看起来像是计数器在线程异常(磁盘故障时)忘记减减了，导致计数器虚高进而无法新创建新线程：

#top -H -b -n 1 -p 130650 |grep mysqld | wc -l
157

# mysql -e "select sum(THREAD_COUNT), sum(ACTIVE_THREAD_COUNT)  from information_schema.THREAD_POOL_STATUS"
+-------------------+--------------------------+
| sum(THREAD_COUNT) | sum(ACTIVE_THREAD_COUNT) |
+-------------------+--------------------------+
|                71 |                      206 |
+-------------------+--------------------------+
# mysql -e "select sum(THREAD_COUNT), sum(ACTIVE_THREAD_COUNT)  from information_schema.THREAD_POOL_STATUS"
+-------------------+--------------------------+
| sum(THREAD_COUNT) | sum(ACTIVE_THREAD_COUNT) |
+-------------------+--------------------------+
|                75 |                      202 |
+-------------------+--------------------------+
# mysql_secbox  --exe-path=mysql -A -uroot -h127.0.0.1 -P3054 -e  "select ID,THREAD_COUNT,ACTIVE_THREAD_COUNT AS ATC,CONNECTION_COUNT AS CC,LOW_QUEUE_COUNT,HIGH_QUEUE_COUNT  from information_schema.THREAD_POOL_STATUS"
+----+--------------+-----+----+-----------------+------------------+
| ID | THREAD_COUNT | ATC | CC | LOW_QUEUE_COUNT | HIGH_QUEUE_COUNT |
+----+--------------+-----+----+-----------------+------------------+
|  0 |            3 |   7 | 13 |               0 |                0 |
| 19 |            3 |  10 | 14 |               0 |                0 |
| 20 |            3 |   8 | 13 |               0 |                0 |
| 21 |            2 |   5 |  9 |               0 |                0 |
| 28 |            2 |   6 |  6 |               0 |                0 |
//增加了一个active count,执行完毕后active thread count会减下去
| 29 |            2 |  12 | 14 |               0 |                0 | 
| 30 |            2 |   4 | 11 |               0 |                0 | 
| 31 |            2 |   8 | 10 |               0 |                0 |
+----+--------------+-----+----+-----------------+------------------+

正常的thread_pool状态, ACTIVE_THREAD_COUNT极小且小于 THREAD_COUNT：

mysql> select ID,THREAD_COUNT,ACTIVE_THREAD_COUNT AS ATC,CONNECTION_COUNT AS CC,LOW_QUEUE_COUNT,HIGH_QUEUE_COUNT from information_schema.THREAD_POOL_STATUS;
+----+--------------+-----+----+-----------------+------------------+
| ID | THREAD_COUNT | ATC | CC | LOW_QUEUE_COUNT | HIGH_QUEUE_COUNT |
+----+--------------+-----+----+-----------------+------------------+
|  0 |            2 |   0 |  3 |               0 |                0 |
|  1 |            2 |   0 |  2 |               0 |                0 |
|  2 |            2 |   0 |  2 |               0 |                0 |
|  3 |            2 |   0 |  2 |               0 |                0 |
|  4 |            2 |   0 |  4 |               0 |                0 |
|  5 |            2 |   0 |  3 |               0 |                0 |
|  6 |            2 |   0 |  4 |               0 |                0 |
|  7 |            2 |   0 |  4 |               0 |                0 |
+----+--------------+-----+----+-----------------+------------------+

Thread Pool原理

MySQL 原有线程调度方式有每个连接一个线程(one-thread-per-connection)和所有连接一个线程（no-threads）。

no-threads一般用于调试，生产环境一般用one-thread-per-connection方式。one-thread-per-connection 适合于低并发长连接的环境，而在高并发或大量短连接环境下，大量创建和销毁线程，以及线程上下文切换，会严重影响性能。另外 one-thread-per-connection 对于大量连接数扩展也会影响性能。

为了解决上述问题，MariaDB、Percona、Aliyun RDS、Oracle MySQL 都推出了线程池方案，它们的实现方式大体相似，这里以 Percona 为例来简略介绍实现原理，同时会介绍我们在其基础上的一些改进。

线程池由一系列 worker 线程组成，这些worker线程被分为thread_pool_size个group。用户的连接按 round-robin 的方式映射到相应的group 中，一个连接可以由一个group中的一个或多个worker线程来处理。

thread_pool_oversubscribe 一个group中活跃线程和等待中的线程超过thread_pool_oversubscribe时，不会创建新的线程。此参数可以控制系统的并发数，同时可以防止调度上的死锁，考虑如下情况，A、B、C三个事务，A、B 需等待C提交。A、B先得到调度，同时活跃线程数达到了thread_pool_max_threads上限，随后C继续执行提交，此时已经没有线程来处理C提交，从而导致A、B一直等待。thread_pool_oversubscribe控制group中活跃线程和等待中的线程总数，从而防止了上述情况。

MySQL Thread Pool之所以分成多个小的Thread Group Pool而不是一个大的Pool，是为了分解锁（每个group中都有队列，队列需要加锁。类似ConcurrentHashMap提高并发的原理），提高并发效率。另外如果对每个Pool的 Worker做CPU 亲和性绑定也会对cache更友好、效果更高

group中又有多个队列，用来区分优先级的，事务中的语句会放到高优先队列（非事务语句和autocommit 都会在低优先队列）；等待太久的SQL也会挪到高优先队列，防止饿死。

比如启用Thread Pool后，如果出现多个慢查询，容易导致拨测类请求超时，进而出现Server异常的判断（类似Nginx 边缘触发问题）；或者某个group满后导致慢查询和拨测失败之类的问题

thread_pool_size 过小的案例

应用出现大量1秒超时报错：

分析代码，这个Druid报错堆栈是数据库连接池在创建到MySQL的连接后或者从连接池取一个连接给业务使用前会发送一个ping来验证下连接是否有效，有效后才给应用使用。说明TCP连接创建成功，但是MySQL 超过一秒钟都没有响应这个 ping，说明 MySQL处理指令缓慢。

继续分析MySQL的参数：

可以看到thread_pool_size是1，太小了，将所有MySQL线程都放到一个buffer里面来抢锁，锁冲突的概率太高。调整到16后可以明显看到MySQL的RT从原来的12ms下降到了3ms不到，整个QPS大概有8%左右的提升。这是因为pool size为1的话所有sql都在一个队列里面，多个worker thread加锁等待比较严重，导致rt延迟增加。

这个问题发现是因为压力一上来的时候要创建大量新的连接，这些连结创建后会去验证连接的有效性，也就是Druid给MySQL发一个ping指令，一般都很快，同时Druid对这个valid操作设置了1秒的超时时间，从实际看到大量超时异常堆栈，从而发现MySQL内部响应有问题。

MySQL ping 和 MySQL 协议相关知识

Ping use the JDBC method Connection.isValid(int timeoutInSecs). Digging into the MySQL Connector/J source, the actual implementation uses com.mysql.jdbc.ConnectionImpl.pingInternal() to send a simple ping packet to the DB and returns true as long as a valid response is returned.

MySQL ping protocol是发送了一个 0e 的byte标识给Server，整个包加上2byte的Packet Length（内容为：1），2byte的Packet Number（内容为：0），总长度为5 byte。Druid、DRDS默认都会 testOnBorrow，所以每个连接使用前都会先做ping。

public class MySQLPingPacket implements CommandPacket {
    private final WriteBuffer buffer = new WriteBuffer();
    public MySQLPingPacket() {
        buffer.writeByte((byte) 0x0e);
    }
    public int send(final OutputStream os) throws IOException {
        os.write(buffer.getLengthWithPacketSeq((byte) 0)); // Packet Number
        os.write(buffer.getBuffer(),0,buffer.getLength()); // Packet Length 固定为1
        os.flush();
        return 0;
    }
}

也就是一个TCP包中的Payload为 MySQL协议中的内容长度 + 4（Packet Length+Packet Number）：https://dev.mysql.com/doc/dev/mysql-server/8.4.2/page_protocol_com_ping.html

线程池卡死案例：show stats导致集群3406监控卡死

现象

应用用于获取监控信息的端口 3406卡死，监控脚本无法连接上3406，监控没有数据（需要从3406采集）、DDL操作、show processlist、show stats操作卡死（需要跟整个集群的3406端口同步）。

通过jstack看到应用进程的3406端口线程池都是这样:

"ManagerExecutor-1-thread-1" #47 daemon prio=5 os_prio=0 tid=0x00007fe924004000 nid=0x15c runnable [0x00007fe9034f4000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
    at java.net.SocketInputStream.read(SocketInputStream.java:171)
    at java.net.SocketInputStream.read(SocketInputStream.java:141)
    at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
    at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
    at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
    - locked <0x0000000722538b60> (a com.mysql.jdbc.util.ReadAheadInputStream)
    at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3005)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3466)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3456)
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3897)
    at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2524)
    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2677)
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2545)
    - locked <0x00000007432e19c8> (a com.mysql.jdbc.JDBC4Connection)
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2503)
    at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1369)
    - locked <0x00000007432e19c8> (a com.mysql.jdbc.JDBC4Connection)
    at com.alibaba.druid.pool.ValidConnectionCheckerAdapter.isValidConnection(ValidConnectionCheckerAdapter.java:44)
    at com.alibaba.druid.pool.DruidAbstractDataSource.testConnectionInternal(DruidAbstractDataSource.java:1298)
    at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:1057)
    at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:997)
    at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:987)
    at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:103)
    at com.taobao.tddl.atom.AbstractTAtomDataSource.getConnection(AbstractTAtomDataSource.java:32)
    at com.alibaba.cobar.ClusterSyncManager$1.run(ClusterSyncManager.java:60)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627)
    at java.lang.Thread.run(Thread.java:882)

原因

用户监控采集数据通过访问3306端口上的show stats，这个show stats命令要访问集群下所有节点的3406端口来执行show stats，3406端口上是一个大小为8个的Manager 线程池在执行这些show stats命令，导致占满了manager线程池的8个线程，每个3306的show stats线程都在wait 所有节点3406上的子任务的返回
每个子任务的线程，都在等待向集群所有节点3406端口的manager建立连接，建连接后会先执行testValidatation操作验证连接的有效性，这个验证操作会执行SQL Query：select 1，这个query请求又要申请一个manager线程才能执行成功
默认isValidConnection操作没有超时时间，如果Manager线程池已满后需要等待至socketTimeout后才会返回，导致这里出现卡死，还不如快速返回错误，可以增加超时来改进

从线程栈来说，就是出现了活锁

解决方案

增加manager线程池大小
代码逻辑上优化3406 jdbc连接池参数，修改jdbc默认的socketTimeout超时时间以及替换默认checker（一般增加一个1秒超时的checker）

对于checker，参考druid的实现，com/alibaba/druid/pool/vendor/MySqlValidConnectionChecker.java：

//druid的MySqlValidConnectionChecker设定了valid超时时间为1秒
    public boolean isValidConnection(Connection conn, String validateQuery, int validationQueryTimeout) throws Exception {
        if (conn.isClosed()) {
            return false;
        }

        if (usePingMethod) {
            if (conn instanceof DruidPooledConnection) {
                conn = ((DruidPooledConnection) conn).getConnection();
            }

            if (conn instanceof ConnectionProxy) {
                conn = ((ConnectionProxy) conn).getRawObject();
            }

            if (clazz.isAssignableFrom(conn.getClass())) {
                if (validationQueryTimeout <= 0) {
                    validationQueryTimeout = DEFAULT_VALIDATION_QUERY_TIMEOUT;// 默认值1ms
                }

                try {
                    ping.invoke(conn, true, validationQueryTimeout * 1000); //1秒
                } catch (InvocationTargetException e) {
                    Throwable cause = e.getCause();
                    if (cause instanceof SQLException) {
                        throw (SQLException) cause;
                    }
                    throw e;
                }
                return true;
            }
        }

        String query = validateQuery;
        if (validateQuery == null || validateQuery.isEmpty()) {
            query = DEFAULT_VALIDATION_QUERY;
        }

        Statement stmt = null;
        ResultSet rs = null;
        try {
            stmt = conn.createStatement();
            if (validationQueryTimeout > 0) {
                stmt.setQueryTimeout(validationQueryTimeout);
            }
            rs = stmt.executeQuery(query);
            return true;
        } finally {
            JdbcUtils.close(rs);
            JdbcUtils.close(stmt);
        }

    }

//使用如上validation
public final static String DEFAULT_DRUID_MYSQL_VALID_CONNECTION_CHECKERCLASS =
        "com.alibaba.druid.pool.vendor.MySqlValidConnectionChecker";

 String validConnnectionCheckerClassName =
                    TAtomConstants.DEFAULT_DRUID_MYSQL_VALID_CONNECTION_CHECKERCLASS;
                try {
                    Class.forName(validConnnectionCheckerClassName);
                    localDruidDataSource.setValidConnectionCheckerClassName(validConnnectionCheckerClassName);

这种线程池打满特别容易在分布式环境下出现，除了以上案例比如还有:

分库分表业务线程池，接收一个逻辑 SQL，如果需要查询1024分片的sort merge join，相当于派生了一批子任务，每个子任务占用一个线程，父任务等待子任务执行后返回数据。如果这样的逻辑SQL同时来一批并发，就会出现父任务都在等子任务，子任务又因为父任务占用了线程，导致子任务也在等着从线程池中取线程，这样父子任务就进入了死锁

比如并行执行的SQL MPP线程池也有这个问题，多个查询节点收到SQL，拆分出子任务做并行，互相等待资源

X应用对分布式任务打挂线程池的优化

对如下这种案例：

X 应用通过线程池来接收一个逻辑SQL并处理，如果需要查询1024分片的sort merge join，相当于派生了1024个子任务，每个子任务占用一个线程，父任务等待子任务执行后返回数据。如果这样的逻辑SQL同时来一批并发，就会出现父任务都在等子任务，子任务又因为父任务占用了线程，导致子任务也在等着从线程池中取线程，这样父子任务就进入了死锁

首先X对执行SQL 的线程池分成了多个bucket，每个SQL只跑在一个bucket里面的线程上，同时通过滑动窗口向线程池提交任务数，来控制并发量，进而避免线程池的死锁、活锁问题。

public static final ServerThreadPool create(String name, int poolSize, int deadLockCheckPeriod, int bucketSize) {
    return new ServerThreadPool(name, poolSize, deadLockCheckPeriod, bucketSize); //bucketSize可以设置
}

public ServerThreadPool(String poolName, int poolSize, int deadLockCheckPeriod, int bucketSize) {
    this.poolName = poolName;
    this.deadLockCheckPeriod = deadLockCheckPeriod;

    this.numBuckets = bucketSize;
    this.executorBuckets = new ThreadPoolExecutor[bucketSize];
    int bucketPoolSize = poolSize / bucketSize; //将整个pool分成多个bucket
    this.poolSize = bucketPoolSize;
    for (int bucketIndex = 0; bucketIndex < bucketSize; bucketIndex++) {
        ThreadPoolExecutor executor = new ThreadPoolExecutor(bucketPoolSize,
            bucketPoolSize,
            0L,
            TimeUnit.MILLISECONDS,
            new LinkedBlockingQueue<Runnable>(),
            new NamedThreadFactory(poolName + "-bucket-" + bucketIndex, true));

        executorBuckets[bucketIndex] = executor;
    }

    this.lastCompletedTaskCountBuckets = new long[bucketSize];
    // for check thread
    if (deadLockCheckPeriod > 0) {
        this.timer = new Timer(SERVER_THREAD_POOL_TIME_CHECK, true);
        buildCheckTask();
        this.timer.scheduleAtFixedRate(checkTask, deadLockCheckPeriod, deadLockCheckPeriod);
    }
}

通过bucketSize将一个大的线程池分成多个小的线程池，每个SQL 控制跑在一个小的线程池中，这里和MySQL的thread_pool是同样的设计思路，当然MySQL 的thread_pool主要是为了改进大锁的问题。

另外DRDS上线程池拆分后性能也有提升：

测试结果说明：(以全局线程池为基准，分别关注：关日志、分桶线程池、协程)

关日志，整体性能提升在20%左右 (8core最好成绩在6.4w qps)

协程，整体性能15%左右

关日志+协程，整体提升在35%左右 (8core最好成绩在7w qps)

分桶，整体性能提升在18%左右

分桶+关日志，整体提升在39%左右 (8core最好成绩在7.4w qps)

分桶+协程，整体提升在36%左右

分桶+关日志+协程，整体提升在60%左右 (8core最好成绩在8.3w qps)

线程池拆成多个bucket优化分析

拆分前锁主要是：

Started [lock] profiling
--- Execution profile ---
Total samples:         496

Frame buffer usage:    0.0052%

--- 352227700 ns (53.09%), 248 samples
  [ 0] java.util.Properties
  [ 1] java.util.Hashtable.get
  [ 2] java.util.Properties.getProperty
  [ 3] com.taobao.tddl.common.properties.SystemPropertiesHelper.getPropertyValue
  [ 4] com.taobao.tddl.executor.MatrixExecutor.configMppExecutionContext
  [ 5] com.taobao.tddl.executor.MatrixExecutor.optimize
  [ 6] com.taobao.tddl.matrix.jdbc.TConnection.optimizeThenExecute
  [ 7] com.taobao.tddl.matrix.jdbc.TConnection.executeSQL
  [ 8] com.taobao.tddl.matrix.jdbc.TPreparedStatement.executeSQL
  [ 9] com.taobao.tddl.matrix.jdbc.TStatement.executeInternal
  [10] com.taobao.tddl.matrix.jdbc.TPreparedStatement.execute
  [11] com.alibaba.cobar.server.ServerConnection.innerExecute
  [12] com.alibaba.cobar.server.ServerConnection.innerExecute
  [13] com.alibaba.cobar.server.ServerConnection$1.run
  [14] com.taobao.tddl.common.utils.thread.FlowControlThreadPool$RunnableAdapter.run
  [15] java.util.concurrent.Executors$RunnableAdapter.call
  [16] java.util.concurrent.FutureTask.run
  [17] java.util.concurrent.ThreadPoolExecutor.runWorker
  [18] java.util.concurrent.ThreadPoolExecutor$Worker.run
  [19] java.lang.Thread.run

--- 307781689 ns (46.39%), 243 samples
  [ 0] java.util.Properties
  [ 1] java.util.Hashtable.get
  [ 2] java.util.Properties.getProperty
  [ 3] com.taobao.tddl.common.properties.SystemPropertiesHelper.getPropertyValue
  [ 4] com.taobao.tddl.config.ConfigDataMode.isDrdsMasterMode
  [ 5] com.taobao.tddl.matrix.jdbc.TConnection.updatePlanManagementInfo
  [ 6] com.alibaba.cobar.server.ServerConnection.innerExecute
  [ 7] com.alibaba.cobar.server.ServerConnection.innerExecute
  [ 8] com.alibaba.cobar.server.ServerConnection$1.run
  [ 9] com.taobao.tddl.common.utils.thread.FlowControlThreadPool$RunnableAdapter.run
  [10] java.util.concurrent.Executors$RunnableAdapter.call
  [11] java.util.concurrent.FutureTask.run
  [12] java.util.concurrent.ThreadPoolExecutor.runWorker
  [13] java.util.concurrent.ThreadPoolExecutor$Worker.run
  [14] java.lang.Thread.run

--- 3451038 ns (0.52%), 4 samples
  [ 0] java.lang.Object
  [ 1] sun.nio.ch.SocketChannelImpl.ensureReadOpen
  [ 2] sun.nio.ch.SocketChannelImpl.read
  [ 3] com.alibaba.cobar.net.AbstractConnection.read
  [ 4] com.alibaba.cobar.net.NIOReactor$R.read
  [ 5] com.alibaba.cobar.net.NIOReactor$R.run
  [ 6] java.lang.Thread.run

--- 4143 ns (0.00%), 1 sample
  [ 0] com.taobao.tddl.common.IdGenerator
  [ 1] com.taobao.tddl.common.IdGenerator.nextId
  [ 2] com.alibaba.cobar.server.ServerConnection.genTraceId
  [ 3] com.alibaba.cobar.server.ServerQueryHandler.query
  [ 4] com.alibaba.cobar.net.FrontendConnection.query
  [ 5] com.alibaba.cobar.net.handler.FrontendCommandHandler.handle
  [ 6] com.alibaba.cobar.net.FrontendConnection$1.run
  [ 7] java.util.concurrent.ThreadPoolExecutor.runWorker
  [ 8] java.util.concurrent.ThreadPoolExecutor$Worker.run
  [ 9] java.lang.Thread.run

          ns  percent  samples  top
  ----------  -------  -------  ---
   660009389   99.48%      491  java.util.Properties
     3451038    0.52%        4  java.lang.Object
        4143    0.00%        1  com.taobao.tddl.common.IdGenerator

com.taobao.tddl.matrix.jdbc.TConnection.optimizeThenExecute调用对应代码逻辑：

if (InsertSplitter.needSplit(sql, policy, extraCmd)) {
             executionContext.setDoingBatchInsertBySpliter(true);
             InsertSplitter insertSplitter = new InsertSplitter(executor);
                        // In batch insert, update transaction policy in writing
                        // broadcast table is also needed.
     resultCursor = insertSplitter.execute(sql,executionContext,policy,
         (String insertSql) -> optimizeThenExecute(insertSql, executionContext,trxPolicyModified));
                    } else {
       resultCursor = optimizeThenExecute(sql, executionContext,trxPolicyModified);
                    }
                    
 最终会访问到：
 protected void configMppExecutionContext(ExecutionContext executionContext) {

        String instRole = (String) SystemPropertiesHelper.getPropertyValue(SystemPropertiesHelper.INST_ROLE);
        SqlType sqlType = executionContext.getSqlType();
        
 相当于执行每个SQL都要加锁访问HashMap(SystemPropertiesHelper.getPropertyValue)，这里排队比较厉害

实际以上测试结果显示bucket对性能有提升这么大是不对的，刚好这个版本把对HashMap的访问去掉了，这才是提升的主要原因，当然如果线程池入队出队有等锁的话改成多个肯定是有帮助的，但是从等锁观察是没有这个问题的。

在这个代码基础上将bucket改成1，在4core机器下经过反复对比测试性能基本没有明显的差异，可能core越多这个问题会更明显些。总结

回到最开始部分查询卡顿这个问题，本质在于 MySQL线程池开启后，因为会将多个连接分配在一个池子中共享这个池子中的几个线程。导致一个池子中的线程特别慢的时候会影响这个池子中所有的查询都会卡顿。即使别的池子很空闲也不会将任务调度过去。

MySQL线程池设计成多个池子（Group）的原因是为了将任务队列拆成多个，这样每个池子中的线程只是内部竞争锁，跟其他池子不冲突，类似ConcurrentHashmap的实现，当然这个设计带来的问题就是多个池子中的任务不能均衡了。

同时从案例我们也可以清楚地看到这个池子太小会造成锁冲突严重的卡顿，池子太大（每个池子中的线程数量就少）容易造成等线程的卡顿。

**类似地这个问题也会出现在Nginx的多worker中，一旦一个连接分发到了某个worker，就会一直在这个worker上处理，如果这个worker上的某个连接有一些慢操作，会导致这个worker上的其它连接的所有操作都受到影响，特别是会影响一些探活任务的误判。**Nginx的worker这么设计也是为了将单worker绑定到固定的cpu，然后避免多核之间的上下文切换。

如果池子卡顿后，调用方有快速fail，比如druid的MySqlValidConnectionChecker，那么调用方从堆栈很快能发现这个问题，如果没有异常一直死等的话对问题的排查不是很友好。

另外可以看到分布式环境下死锁、活锁还是很容易产生的，想要一次性提前设计好比较难，需要不断踩坑爬坑。

参考文章

记一次诡异的数据库故障的排查过程

http://mysql.taobao.org/monthly/2016/02/09/

https://dbaplus.cn/news-11-1989-1.html

慢查询触发kill后导致集群卡死 把queryTimeout换成socketTimeout，这个不会发送kill，只会断开连接

青海湖、天津医保 RDS线程池过小导致DRDS查询卡顿问题排查

Linux内存--HugePage

发表于 2020-11-15 更新于 2025-11-16 分类于 Memory

Linux内存–HugePage

本系列有如下几篇

[Linux 内存问题汇总](/2020/01/15/Linux 内存问题汇总/)

/proc/buddyinfo

/proc/buddyinfo记录了内存的详细碎片情况。

#cat /proc/buddyinfo 
Node 0, zone      DMA      1      1      1      0      2      1      1      0      1      1      3 
Node 0, zone    DMA32      2      5      3      6      2      0      4      4      2      2    404 
Node 0, zone   Normal 243430 643847 357451  32531   9508   6159   3917   2960  17172   2633  22854

Normal行的第二列表示： 643847*2^1*Page_Size(4K) ; 第三列表示： 357451*2^2*Page_Size(4K) ，高阶内存指的是2^3及更大的内存块。

应用申请大块连续内存（高阶内存，一般之4阶及以上, 也就是64K以上–2^4*4K）时，容易导致卡顿。这是因为大块连续内存确实系统需要触发回收或者碎片整理，需要一定的时间。

slabtop和/proc/slabinfo

slabtop和/proc/slabinfo 查看cached使用情况主要是：pagecache（页面缓存）， dentries（目录缓存）， inodes

关于hugetlb

This is an entry in the TLB that points to a HugePage (a large/big page larger than regular 4K and predefined in size). HugePages are implemented via hugetlb entries, i.e. we can say that a HugePage is handled by a “hugetlb page entry”. The ‘hugetlb” term is also (and mostly) used synonymously with a HugePage.

hugetlb 是TLB中指向HugePage的一个entry(通常大于4k或预定义页面大小)。 HugePage 通过hugetlb entries来实现，也可以理解为HugePage 是hugetlb page entry的一个句柄。

Linux下的大页分为两种类型：标准大页（Huge Pages）和透明大页（Transparent Huge Pages）

标准大页管理是预分配的方式，而透明大页管理则是动态分配的方式

目前透明大页与传统HugePages联用会出现一些问题，导致性能问题和系统重启。Oracle 建议禁用透明大页（Transparent Huge Pages）

hugetlbfs比THP要好，开thp的机器碎片化严重（不开THP会有更严重的碎片化问题），最后和没开THP一样 https://www.atatech.org/articles/152660

Linux 中的 HugePages 都被锁定在内存中，所以哪怕是在系统内存不足时，它们也不会被 Swap 到磁盘上，这也就能从根源上杜绝了重要内存被频繁换入和换出的可能。

Transparent Hugepages are similar to standard HugePages. However, while standard HugePages allocate memory at startup, Transparent Hugepages memory uses the khugepaged thread in the kernel to allocate memory dynamically during runtime, using swappable HugePages.

HugePage要求OS启动的时候提前分配出来，管理难度比较大，所以Enterprise Linux 6增加了一层抽象层来动态创建管理HugePage，这就是THP，而这个THP对应用透明，由khugepaged thread在后台动态将小页组成大页给应用使用，这里会遇上碎片问题导致需要compact才能得到大页，应用感知到的就是SYS CPU飙高，应用卡顿了。

虽然 HugePages 的开启大都需要开发或者运维工程师的额外配置，但是在应用程序中启用 HugePages 却可以在以下几个方面降低内存页面的管理开销：

更大的内存页能够减少内存中的页表层级，这不仅可以降低页表的内存占用，也能降低从虚拟内存到物理内存转换的性能损耗；
更大的内存页意味着更高的缓存命中率，CPU 有更高的几率可以直接在 TLB（Translation lookaside buffer）中获取对应的物理地址；
更大的内存页可以减少获取大内存的次数，使用 HugePages 每次可以获取 2MB 的内存，是 4KB 的默认页效率的 512 倍；

HugePage

为什么需要Huge Page 了解CPU Cache大致架构的话，一定听过TLB Cache。Linux系统中，对程序可见的，可使用的内存地址是Virtual Address。每个程序的内存地址都是从0开始的。而实际的数据访问是要通过Physical Address进行的。因此，每次内存操作，CPU都需要从page table中把Virtual Address翻译成对应的Physical Address，那么对于大量内存密集型程序来说page table的查找就会成为程序的瓶颈。

所以现代CPU中就出现了TLB(Translation Lookaside Buffer) Cache用于缓存少量热点内存地址的mapping关系。然而由于制造成本和工艺的限制，响应时间需要控制在CPU Cycle级别的Cache容量只能存储几十个对象。那么TLB Cache在应对大量热点数据Virual Address转换的时候就显得捉襟见肘了。我们来算下按照标准的Linux页大小(page size) 4K，一个能缓存64元素的TLB Cache只能涵盖4K*64 = 256K的热点数据的内存地址，显然离理想非常遥远的。于是Huge Page就产生了。

Huge pages require contiguous areas of memory, so allocating them at boot is the most reliable method since memory has not yet become fragmented. To do so, add the following parameters to the kernel boot command line:

Huge pages kernel options

hugepages

Defines the number of persistent huge pages configured in the kernel at boot time. The default value is 0. It is only possible to allocate (or deallocate) huge pages if there are sufficient physically contiguous free pages in the system. Pages reserved by this parameter cannot be used for other purposes.

Default size huge pages can be dynamically allocated or deallocated by changing the value of the /proc/sys/vm/nr_hugepages file.

In a NUMA system, huge pages assigned with this parameter are divided equally between nodes. You can assign huge pages to specific nodes at runtime by changing the value of the node’s /sys/devices/system/node/node_id/hugepages/hugepages-1048576kB/nr_hugepages file.

For more information, read the relevant kernel documentation, which is installed in /usr/share/doc/kernel-doc-kernel_version/Documentation/vm/hugetlbpage.txt by default. This documentation is available only if the kernel-doc package is installed.
hugepagesz

Defines the size of persistent huge pages configured in the kernel at boot time. Valid values are 2 MB and 1 GB. The default value is 2 MB.
default_hugepagesz

Defines the default size of persistent huge pages configured in the kernel at boot time. Valid values are 2 MB and 1 GB. The default value is 2 MB.

应用程序想要利用大页优势，需要通过hugetlb文件系统来使用标准大页。操作步骤

1.预留大页

echo 20 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

2.挂载hugetlb文件系统

mount hugetlbfs /mnt/huge -t hugetlbfs

3.映射hugetbl文件

fd = open(“/mnt/huge/test.txt”, O_CREAT|O_RDWR);

addr = mmap(0, MAP_LENGTH, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

4.hugepage统计信息

通过hugepage提供的sysfs接口，可以了解大页使用情况

HugePages_Total: 预先分配的大页数量

HugePages_Free：空闲大页数量

HugePages_Rsvd: mmap申请大页数量(还没有产生缺页)

HugePages_Surp: 多分配的大页数量(由nr_overcommit_hugepages决定)

5 hugpage优缺点

缺点:

1.需要提前预估大页使用量，并且预留的大页不能被其他内存分配接口使用。

2.兼容性不好，应用使用标准大页，需要对代码进行重构才能有效的使用标准大页。

优点:因为内存是预留的，缺页延时非常小

针对Hugepage的不足，内核又衍生出了THP大页(Transparent Huge pages)

工具

yum install libhugetlbfs-utils -y

//列出
hugeadm --pool-list
      Size  Minimum  Current  Maximum  Default
   2097152    12850    12850    12850        *
1073741824        0        0        0

hugeadm --list-all-mounts
Mount Point          Options
/dev/hugepages       rw,relatime,pagesize=2M

大页和 MySQL 性能 case

MySQL的页都是16K, 当查询的行不在内存中时需要按照16K为单位从磁盘读取页,而文件系统中的页是4k，也就是一次数据库请求需要有4次磁盘IO，如过查询比较随机，每次只需要一个页中的几行数据，存在很大的读放大。

那么我们是否可以把MySQL的页设置为4K来减少读放大呢？

在5.7里收益不大，因为每次IO存在 fil_system 的锁，导致IO的并发上不去

8.0中总算优化了这个场景，测试细节可以参考这篇

16K VS 4K 性能对比（4K接近翻倍）

4K会带来的问题：顺序insert慢了10%（因为fsync更多了）；DDL更慢；二级索引更多的场景下4K性能较差；大BP下，刷脏代价大。

HugePage 带来的问题

CPU对同一个Page抢占增多

对于写操作密集型的应用，Huge Page会大大增加Cache写冲突的发生概率。由于CPU独立Cache部分的写一致性用的是MESI协议，写冲突就意味：

通过CPU间的总线进行通讯，造成总线繁忙
同时也降低了CPU执行效率。
CPU本地Cache频繁失效

类比到数据库就相当于，原来一把用来保护10行数据的锁，现在用来锁1000行数据了。必然这把锁在线程之间的争抢概率要大大增加。

连续数据需要跨CPU读取

Page太大，更容易造成Page跨Numa/CPU 分布。

从下图我们可以看到，原本在4K小页上可以连续分配，并因为较高命中率而在同一个CPU上实现locality的数据。到了Huge Page的情况下，就有一部分数据为了填充统一程序中上次内存分配留下的空间，而被迫分布在了两个页上。而在所在Huge Page中占比较小的那部分数据，由于在计算CPU亲和力的时候权重小，自然就被附着到了其他CPU上。那么就会造成：本该以热点形式存在于CPU2 L1或者L2 Cache上的数据，不得不通过CPU inter-connect去remote CPU获取数据。假设我们连续申明两个数组，Array A和Array B大小都是1536K。内存分配时由于第一个Page的2M没有用满，因此Array B就被拆成了两份，分割在了两个Page里。而由于内存的亲和配置，一个分配在Zone 0，而另一个在Zone 1。那么当某个线程需要访问Array B时就不得不通过代价较大的Inter-Connect去获取另外一部分数据。

Java进程开启HugePage

从perf数据来看压满后tlab miss比较高，得想办法降低这个值

修改JVM启动参数

JVM启动参数增加如下三个(-XX:LargePageSizeInBytes=2m, 这个一定要，有些资料没提这个，在我的JDK8.0环境必须要)：

-XX:+UseLargePages -XX:LargePageSizeInBytes=2m -XX:+UseHugeTLBFS

修改机器系统配置

设置HugePage的大小

cat /proc/sys/vm/nr_hugepages

nr_hugepages设置多大参考如下计算方法：

If you are using the option -XX:+UseSHM or -XX:+UseHugeTLBFS, then specify the number of large pages. In the following example, 3 GB of a 4 GB system are reserved for large pages (assuming a large page size of 2048kB, then 3 GB = 3 * 1024 MB = 3072 MB = 3072 * 1024 kB = 3145728 kB and 3145728 kB / 2048 kB = 1536):

echo 1536 > /proc/sys/vm/nr_hugepages

透明大页是没有办法减少系统tlab，tlab是对应于进程的，系统分给进程的透明大页还是由物理上的4K page组成。

对于c++来说，他malloc经常会散落得全地址都是，因为会触发各种mmap，冷热区域。所以THP和hugepage都可能导致大量内存被浪费了，进而导致内存紧张，性能下滑。jvm的连续内存布局，加上gc会使得内存密度很紧凑。THP的问题是，他是逻辑页，不是物理页，tlb依旧要N份，所以他的收益来自page fault减少，是一次性的收益。

hugepage的在减少page_fault上和thp效果一样第二个作用是，他只需要一份TLB了，hugepage是真正的大页内存，thp是逻辑上的，物理上还是需要很多小的page。

如果TLB miss，则可能需要额外三次内存读取操作才能将线性地址翻译为物理地址。

code_hugepage 代码大页

代码大页特性主要为大代码段业务服务，可以降低程序的iTLB miss，从而提升程序性能。针对倚天这一类跨numa访存开销大的芯片有比较好的性能提升效果

1 2	// 1 表示仅打开二进制和动态库大页 2 仅打开可执行匿名大页 3 相当于1+2，0 表示关闭 echo 1 > /sys/kernel/mm/transparent_hugepage/hugetext_enabled //1 可以改成2/3

是否启用代码大页，可以查看/proc//smaps中FilePmdMapped字段可确定是否使用了代码大页。扫描进程代码大页使用数量（单位KB）：

1	cat /proc/<pid>/smaps \| grep FilePmdMapped \| awk '{sum+=$2}END{print"Sum= ",sum}'

THP

Linux kernel在2.6.38内核增加了Transparent Huge Pages (THP)特性，支持大内存页(2MB)分配，默认开启。当开启时可以降低fork子进程的速度，但fork之后，每个内存页从原来4KB变为2MB，会大幅增加重写期间父进程内存消耗。同时每次写命令引起的复制内存页单位放大了512倍，会拖慢写操作的执行时间，导致大量写操作慢查询。例如简单的incr命令也会出现在慢查询中。因此Redis日志中建议将此特性进行禁用。

THP 的目的是用一个页表项来映射更大的内存（大页），这样可以减少 Page Fault，因为需要的页数少了。当然，这也会提升 TLB（Translation Lookaside Buffer，由存储器管理单元用于改进虚拟地址到物理地址的转译速度）命中率，因为需要的页表项也少了。如果进程要访问的数据都在这个大页中，那么这个大页就会很热，会被缓存在 Cache 中。而大页对应的页表项也会出现在 TLB 中，从上一讲的存储层次我们可以知道，这有助于性能提升。但是反过来，假设应用程序的数据局部性比较差，它在短时间内要访问的数据很随机地位于不同的大页上，那么大页的优势就会消失。

大页在使用的时候需要清理512个4K页面，再返回给用户，这里的清理动作可能会导致卡顿。另外碎片化严重的时候触发内存整理造成卡顿

大页分配: 在缺页处理函数__handle_mm_fault中判断是否使用大页大页生成: 主要通过在分配大页内存时是否带__GFP_DIRECT_RECLAIM 标志来控制大页的生成.

1.异步生成大页: 在缺页处理中，把需要异步生成大页的VMA注册到链表，内核态线程khugepaged 动态为vma分配大页(内存回收，内存归整)

2.madvise系统调用只是给VMA加了VM_HUGEPAGE,用来标记这段虚拟地址需要使用大页

THP 原理

大页分配: 在缺页处理函数__handle_mm_fault中判断是否使用大页大页生成: 主要通过在分配大页内存时是否带__GFP_DIRECT_RECLAIM 标志来控制大页的生成.

1.异步生成大页: 在缺页处理中，把需要异步生成大页的VMA注册到链表，内核态线程khugepaged 动态为vma分配大页(内存回收，内存归整)

2.madvise系统调用只是给VMA加了VM_HUGEPAGE,用来标记这段虚拟地址需要使用大页

THP 对redis、mongodb 这种cache类推荐关闭，对drds这种java应用最好打开

#cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

grep "Huge" /proc/meminfo
AnonHugePages:   1286144 kB
ShmemHugePages:        0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB

$grep -e AnonHugePages  /proc/*/smaps | awk  '{ if($2>4) print $0} ' |  awk -F "/"  '{print $0; system("ps -fp " $3)} '

$grep -e AnonHugePages  /proc/*/smaps | awk  '{ if($2>4) print $0} ' |  awk -F "/"  '{print $0; system("ps -fp " $3)} '

//查看pagesize（默认4K） 
$getconf PAGESIZE

在透明大页功能打开时，造成系统性能下降的主要原因可能是 khugepaged 守护进程。该进程会在（它认为）系统空闲时启动，扫描系统中剩余的空闲内存，并将普通 4k 页转换为大页。该操作会在内存路径中加锁，而该守护进程可能会在错误的时间启动扫描和转换大页的操作，从而影响应用性能。

此外，当缺页异常(page faults)增多时，透明大页会和普通 4k 页一样，产生同步内存压缩(direct compaction)操作，以节省内存。该操作是一个同步的内存整理操作，如果应用程序会短时间分配大量内存，内存压缩操作很可能会被触发，从而会对系统性能造成风险。https://yq.aliyun.com/articles/712830

#查看系统级别的 THP 使用情况，执行下列命令：
cat /proc/meminfo  | grep AnonHugePages
#类似地，查看进程级别的 THP 使用情况，执行下列命令：
cat /proc/1730/smaps | grep AnonHugePages |grep -v "0 kB"
#是否开启了hugepage
$cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

/proc/sys/vm/nr_hugepages 中存储的数据就是大页面的数量，虽然在默认情况下它的值都是 0，不过我们可以通过更改该文件的内容申请或者释放操作系统中的大页：

$ echo 1 > /proc/sys/vm/nr_hugepages
$ cat /proc/meminfo | grep HugePages_
HugePages_Total:       1
HugePages_Free:        1

THP和perf

thp on后比off性能稳定好 10-15%，开启THP最显著的指标是 iTLB命中率显著提升了

//on 419+E5-2682， thp never
9,145,128,732      branch-instructions       #  229.068 M/sec                    (10.65%)
       555,518,878      branch-misses             #    6.07% of all branches          (14.24%)
     3,951,535,475      bus-cycles                #   98.979 M/sec                    (14.29%)
       372,477,068      cache-misses              #    7.733 % of all cache refs      (14.34%)
     4,816,702,013      cache-references          #  120.649 M/sec                    (14.36%)
   114,521,174,305      cpu-cycles                #    2.869 GHz                      (14.36%)
    48,969,565,344      instructions              #    0.43  insn per cycle           (17.93%)
    98,728,666,922      ref-cycles                # 2472.967 M/sec                    (21.52%)
         39,922.47 msec cpu-clock                 #    7.898 CPUs utilized
     1,848,336,574      L1-dcache-load-misses     #   13.31% of all L1-dcache hits    (21.51%)
    13,889,399,043      L1-dcache-loads           #  347.903 M/sec                    (21.51%)
     7,055,617,648      L1-dcache-stores          #  176.730 M/sec                    (21.50%)
     2,017,950,458      L1-icache-load-misses                                         (21.50%)
        88,802,885      LLC-load-misses           #    9.86% of all LL-cache hits     (14.35%)
       900,379,398      LLC-loads                 #   22.553 M/sec                    (14.33%)
       162,711,813      LLC-store-misses          #    4.076 M/sec                    (7.13%)
       419,869,955      LLC-stores                #   10.517 M/sec                    (7.14%)
       553,257,955      branch-load-misses        #   13.858 M/sec                    (10.71%)
     9,195,874,519      branch-loads              #  230.339 M/sec                    (14.29%)
       176,112,524      dTLB-load-misses          #    1.28% of all dTLB cache hits   (14.29%)
    13,739,965,115      dTLB-loads                #  344.160 M/sec                    (14.28%)
        33,087,849      dTLB-store-misses         #    0.829 M/sec                    (14.28%)
     6,992,863,588      dTLB-stores               #  175.158 M/sec                    (14.26%)
       170,555,902      iTLB-load-misses          #  107.90% of all iTLB cache hits   (14.24%)
       158,070,998      iTLB-loads                #    3.959 M/sec                    (14.24%)

//on 419+E5-2682， thp always
    12,958,974,094      branch-instructions       #  227.392 M/sec                    (10.68%)
       850,468,837      branch-misses             #    6.56% of all branches          (14.27%)
     5,639,495,284      bus-cycles                #   98.957 M/sec                    (14.29%)
       526,744,798      cache-misses              #    7.324 % of all cache refs      (14.32%)
     7,192,328,925      cache-references          #  126.204 M/sec                    (14.34%)
   163,419,436,811      cpu-cycles                #    2.868 GHz                      (14.33%)
    68,638,583,038      instructions              #    0.42  insn per cycle           (17.90%)
   140,882,455,768      ref-cycles                # 2472.076 M/sec                    (21.48%)
         56,987.52 msec cpu-clock                 #    7.932 CPUs utilized
     2,471,392,118      L1-dcache-load-misses     #   12.69% of all L1-dcache hits    (21.47%)
    19,480,914,771      L1-dcache-loads           #  341.833 M/sec                    (21.48%)
    10,059,893,871      L1-dcache-stores          #  176.522 M/sec                    (21.46%)
     3,184,073,065      L1-icache-load-misses                                         (21.46%)
       128,467,945      LLC-load-misses           #   10.83% of all LL-cache hits     (14.31%)
     1,186,653,892      LLC-loads                 #   20.822 M/sec                    (14.30%)
       224,877,539      LLC-store-misses          #    3.946 M/sec                    (7.15%)
       628,574,746      LLC-stores                #   11.030 M/sec                    (7.15%)
       848,830,289      branch-load-misses        #   14.894 M/sec                    (10.71%)
    13,074,297,582      branch-loads              #  229.416 M/sec                    (14.28%)
       109,223,171      dTLB-load-misses          #    0.56% of all dTLB cache hits   (14.27%)
    19,418,657,165      dTLB-loads                #  340.741 M/sec                    (14.29%)
        13,930,402      dTLB-store-misses         #    0.244 M/sec                    (14.28%)
    10,047,511,003      dTLB-stores               #  176.305 M/sec                    (14.28%)
       194,902,860      iTLB-load-misses          #   61.23% of all iTLB cache hits   (14.27%)
       318,292,771      iTLB-loads                #    5.585 M/sec                    (14.26%)

//on 310+8269 thp never
        90,790,778      dTLB-load-misses          #    0.67% of all dTLB cache hits   (16.66%)
    13,639,069,352      dTLB-loads                                                    (16.66%)
         6,553,693      dTLB-store-misses                                             (16.63%)
     6,494,274,815      dTLB-stores                                                   (20.28%)
        76,175,883      iTLB-load-misses          #   40.53% of all iTLB cache hits   (20.80%)
       187,932,292      iTLB-loads                                                    (20.76%)

//on 310+8269 thp always
     7,199,483,512      branch-instructions       #  338.269 M/sec                    (11.46%)
        81,893,729      branch-misses             #    1.14% of all branches          (14.95%)
       532,919,206      bus-cycles                #   25.039 M/sec                    (14.85%)
       253,267,167      cache-misses              #   11.507 % of all cache refs      (14.81%)
     2,201,001,946      cache-references          #  103.414 M/sec                    (14.15%)
    63,971,073,336      cpu-cycles                #    3.006 GHz                      (14.55%)
    37,214,341,673      instructions              #    0.58  insns per cycle          (18.09%)
    52,209,823,072      ref-cycles                # 2453.086 M/sec                    (17.23%)
     1,098,964,315      L1-dcache-load-misses     #   10.17% of all L1-dcache hits    (14.22%)
    10,808,109,191      L1-dcache-loads           #  507.820 M/sec                    (14.31%)
     5,092,652,478      L1-dcache-stores          #  239.279 M/sec                    (14.38%)
     4,338,580,209      L1-icache-load-misses     #  203.849 M/sec                    (14.40%)
        60,262,584      LLC-load-misses           #   21.81% of all LL-cache hits     (14.35%)
       276,321,779      LLC-loads                 #   12.983 M/sec                    (14.31%)
        62,982,184      LLC-store-misses          #    2.959 M/sec                    (10.76%)
       105,448,227      LLC-stores                #    4.954 M/sec                    (8.08%)
        81,163,187      branch-load-misses        #    3.813 M/sec                    (11.67%)
     7,111,481,940      branch-loads              #  334.134 M/sec                    (14.37%)
         4,527,406      dTLB-load-misses          #    0.04% of all dTLB cache hits   (14.30%)
    10,726,725,791      dTLB-loads                #  503.997 M/sec                    (17.33%)
         1,066,097      dTLB-store-misses         #    0.050 M/sec                    (17.37%)
     5,090,008,144      dTLB-stores               #  239.155 M/sec                    (17.34%)
        18,715,797      iTLB-load-misses          #   18.97% of all iTLB cache hits   (17.33%)
        98,684,189      iTLB-loads                #    4.637 M/sec                    (14.29%)

MySQL 场景下代码大页对性能的影响

不只是数据可以用HugePage，代码段也可以开启HugePage, 无论在x86还是arm（arm下提升更明显）下，都可以得到大页优于透明大页，透明大页优于正常的4K page

收益：代码大页 > anon THP > 4k

arm下，对32core机器用32并发的sysbench来对比，代码大页带来的性能提升大概有11%，iTLB miss下降了10倍左右。

x86下，性能提升只有大概3-5%之间，iTLB miss下降了1.5-3倍左右。

TLAB miss高的案例

程序运行久了之后会变慢大概10%

刚开始运行的时候perf各项数据:

长时间运行后：

内存的利用以页为单位，当时分析认为，在此4k连续的基础上，页的碎片不应该对64 byte align的cache有什么影响。当时guest和host都没有开THP。

既然无法理解这个结果，那就只有按部就班的查看内核执行路径上各个函数的差别了，祭出ftrace:

echo kerel_func_name1 > /sys/kernel/debug/tracing/set_ftrace_filter

echo kerel_func_name2 > /sys/kernel/debug/tracing/set_ftrace_filter

echo kerel_func_name3 > /sys/kernel/debug/tracing/set_ftrace_filter
echo 1 > /sys/kernel/debug/tracing/function_profile_enabled

在CPU#20上执行代码:

taskset -c 20 ./b

代码执行完后:

1 2	echo 0 > /sys/kernel/debug/tracing/function_profile_enabled cat /sys/kernel/debug/tracing/trace_stat/function20

这个时候就会打印出在各个函数上花费的时间，比如:

经过调试后，逐步定位到主要时间差距在 __mem_cgroup_commit_charge() (58%).

在阅读代码的过程中，注意到当前内核使能了CONFIG_SPARSEMEM_VMEMMAP=y

原因就是机器运行久了之后内存碎片化严重，导致TLAB Miss严重。

解决：开启THP后，性能稳定

碎片化

内存碎片严重的话会导致系统hang很久(回收、压缩内存）

尽量让系统的free多一点(比例高一点）可以调整 vm.min_free_kbytes(128G 以内 2G，256G以内 4G/8G), 线上机器直接修改vm.min_free_kbytes会触发回收，导致系统hang住 https://www.atatech.org/articles/163233 https://www.atatech.org/articles/97130

compact: 在进行 compcation 时，线程会从前往后扫描已使用的 movable page，然后从后往前扫描 free page，扫描结束后会把这些 movable page 给迁移到 free page 里，最终规整出一个 2M 的连续物理内存，这样 THP 就可以成功申请内存了。

一次THP compact堆栈：

java          R  running task        0 144305 144271 0x00000080
 ffff88096393d788 0000000000000086 ffff88096393d7b8 ffffffff81060b13
 ffff88096393d738 ffffea003968ce50 000000000000000e ffff880caa713040
 ffff8801688b0638 ffff88096393dfd8 000000000000fbc8 ffff8801688b0640

Call Trace:
 [<ffffffff81060b13>] ? perf_event_task_sched_out+0x33/0x70
 [<ffffffff8100bb8e>] ? apic_timer_interrupt+0xe/0x20
 [<ffffffff810686da>] __cond_resched+0x2a/0x40
 [<ffffffff81528300>] _cond_resched+0x30/0x40
 [<ffffffff81169505>] compact_checklock_irqsave+0x65/0xd0
 [<ffffffff81169862>] compaction_alloc+0x202/0x460
 [<ffffffff811748d8>] ? buffer_migrate_page+0xe8/0x130
 [<ffffffff81174b4a>] migrate_pages+0xaa/0x480
 [<ffffffff81169660>] ? compaction_alloc+0x0/0x460                 //compact and migrate
 [<ffffffff8116a1a1>] compact_zone+0x581/0x950
 [<ffffffff8116a81c>] compact_zone_order+0xac/0x100
 [<ffffffff8116a951>] try_to_compact_pages+0xe1/0x120
 [<ffffffff8112f1ba>] __alloc_pages_direct_compact+0xda/0x1b0
 [<ffffffff8112f80b>] __alloc_pages_nodemask+0x57b/0x8d0
 [<ffffffff81167b9a>] alloc_pages_vma+0x9a/0x150
 [<ffffffff8118337d>] do_huge_pmd_anonymous_page+0x14d/0x3b0        //huge page
 [<ffffffff8152a116>] ? rwsem_down_read_failed+0x26/0x30
 [<ffffffff8114b350>] handle_mm_fault+0x2f0/0x300
 [<ffffffff810ae950>] ? wake_futex+0x40/0x60
 [<ffffffff8104a8d8>] __do_page_fault+0x138/0x480
 [<ffffffff810097cc>] ? __switch_to+0x1ac/0x320
 [<ffffffff81527910>] ? thread_return+0x4e/0x76e
 [<ffffffff8152d45e>] do_page_fault+0x3e/0xa0                       //page fault
 [<ffffffff8152a815>] page_fault+0x25/0x30

查看pagetypeinfo

#cat /proc/pagetypeinfo
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    0, zone      DMA, type    Unmovable      1      1      1      0      2      1      1      0      1      0      0
Node    0, zone      DMA, type  Reclaimable      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone      DMA, type      Movable      0      0      0      0      0      0      0      0      0      1      3
Node    0, zone      DMA, type      Reserve      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone      DMA, type          CMA      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone      DMA, type      Isolate      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone    DMA32, type    Unmovable     89    144     98     42     21     14      5      2      1      0      1
Node    0, zone    DMA32, type  Reclaimable     28     22      9      8      0      0      0      0      0      1      7
Node    0, zone    DMA32, type      Movable    402     50     21      8    880    924    321     51      4      1    227
Node    0, zone    DMA32, type      Reserve      0      0      0      0      0      0      0      0      0      0      1
Node    0, zone    DMA32, type          CMA      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone    DMA32, type      Isolate      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone   Normal, type    Unmovable  13709  15231   6637   2646    816    181     46      4      4      1      0
Node    0, zone   Normal, type  Reclaimable      1      5      6   3293   1295    128     29      7      5      0      0
Node    0, zone   Normal, type      Movable   6396 1383350 1301956 1007627 670102 366248 160232  54894  13126   1482     37
Node    0, zone   Normal, type      Reserve      0      0      0      2      1      1      0      0      0      0      0
Node    0, zone   Normal, type          CMA      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable  Reclaimable      Movable      Reserve          CMA      Isolate
Node 0, zone      DMA            1            0            7            0            0            0
Node 0, zone    DMA32           24           38          889            1            0            0
Node 0, zone   Normal         1568          795       127683            2            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    1, zone   Normal, type    Unmovable   3938   8735   5469   3221   2097    989    202      6      0      0      0
Node    1, zone   Normal, type  Reclaimable      1      7      7      8      7      2      2      2      1      0      0
Node    1, zone   Normal, type      Movable  18623 1001037 2084894 1261484 631159 276096  87272  17169   1389    797      0
Node    1, zone   Normal, type      Reserve      0      0      0      8      0      0      0      0      0      0      0
Node    1, zone   Normal, type          CMA      0      0      0      0      0      0      0      0      0      0      0
Node    1, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable  Reclaimable      Movable      Reserve          CMA      Isolate
Node 1, zone   Normal         1530          637       128903            2            0            0

每个zone都有自己的min low high,如下，但是单位是page, 计算案例：

[root@jiangyi01.sqa.zmf /home/ahao.mah]
#cat /proc/zoneinfo  |grep "Node"
Node 0, zone      DMA
Node 0, zone    DMA32
Node 0, zone   Normal
Node 1, zone   Normal

[root@jiangyi01.sqa.zmf /home/ahao.mah]
#cat /proc/zoneinfo  |grep "Node 0, zone" -A10
Node 0, zone      DMA
  pages free     3975
        min      20
        low      25
        high     30
        scanned  0
        spanned  4095
        present  3996
        managed  3975
    nr_free_pages 3975
    nr_alloc_batch 5
--
Node 0, zone    DMA32
  pages free     382873
        min      2335
        low      2918
        high     3502
        scanned  0
        spanned  1044480
        present  513024
        managed  450639
    nr_free_pages 382873
    nr_alloc_batch 584
--
Node 0, zone   Normal
  pages free     11105097
        min      61463
        low      76828
        high     92194
        scanned  0
        spanned  12058624
        present  12058624
        managed  11859912
    nr_free_pages 11105097
    nr_alloc_batch 12344
    
    low = 5/4 * min
high = 3/2 * min

[root@jiangyi01.sqa.zmf /home/ahao.mah]
#T=min;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=499 MB

[root@jiangyi01.sqa.zmf /home/ahao.mah]
#T=low;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=624 MB

[root@jiangyi01.sqa.zmf /home/ahao.mah]
#T=high;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=802 MB

内存碎片化导致rt升高的诊断

判定方法如下：

运行 sar -B 观察 pgscand/s，其含义为每秒发生的直接内存回收次数，当在一段时间内持续大于 0 时，则应继续执行后续步骤进行排查；
运行 cat /sys/kernel/debug/extfrag/extfrag_index 观察内存碎片指数，重点关注 order >= 3 的碎片指数，当接近 1.000 时，表示碎片化严重，当接近 0 时表示内存不足；
运行 cat /proc/buddyinfo, cat /proc/pagetypeinfo 查看内存碎片情况，指标含义参考（https://man7.org/linux/man-pages/man5/proc.5.html），同样关注 order >= 3 的剩余页面数量，pagetypeinfo 相比 buddyinfo 展示的信息更详细一些，根据迁移类型（伙伴系统通过迁移类型实现反碎片化）进行分组，需要注意的是，当迁移类型为 Unmovable 的页面都聚集在 order < 3 时，说明内核 slab 碎片化严重，我们需要结合其他工具来排查具体原因，在本文就不做过多介绍了；
对于 CentOS 7.6 等支持 BPF 的 kernel 也可以运行我们研发的 drsnoop，compactsnoop 工具对延迟进行定量分析，使用方法和解读方式请参考对应文档；
(Opt) 使用 ftrace 抓取 mm_page_alloc_extfrag 事件，观察因内存碎片从备用迁移类型“盗取”页面的信息。

参考资料

https://www.atatech.org/articles/66885

https://cloud.tencent.com/developer/article/1087455

https://www.cnblogs.com/xiaolincoding/p/13719610.html

Linux内存--PageCache

发表于 2020-11-15 更新于 2025-11-16 分类于 Memory

Linux内存–PageCache

本系列有如下几篇

[Linux 内存问题汇总](/2020/01/15/Linux 内存问题汇总/)

read/write

read(2)/write(2) 是 Linux 系统中最基本的 I/O 读写系统调用，我们开发操作 I/O 的程序时必定会接触到它们，而在这两个系统调用和真实的磁盘读写之间存在一层称为 Kernel buffer cache 的缓冲区缓存。在 Linux 中 I/O 缓存其实可以细分为两个：Page Cache 和 Buffer Cache，这两个其实是一体两面，共同组成了 Linux 的内核缓冲区（Kernel Buffer Cache），Page Cache 是在应用程序读写文件的过程中产生的：

读磁盘：内核会先检查 Page Cache 里是不是已经缓存了这个数据，若是，直接从这个内存缓冲区里读取返回，若否，则穿透到磁盘去读取，然后再缓存在 Page Cache 里，以备下次缓存命中；
写磁盘：内核直接把数据写入 Page Cache，并把对应的页标记为 dirty，添加到 dirty list 里，然后就直接返回，内核会定期把 dirty list 的页缓存 flush 到磁盘，保证页缓存和磁盘的最终一致性。

在 Linux 还不支持虚拟内存技术之前，还没有页的概念，因此 Buffer Cache 是基于操作系统读写磁盘的最小单位 – 块（block）来进行的，所有的磁盘块操作都是通过 Buffer Cache 来加速，Linux 引入虚拟内存的机制来管理内存后，页成为虚拟内存管理的最小单位，因此也引入了 Page Cache 来缓存 Linux 文件内容，主要用来作为文件系统上的文件数据的缓存，提升读写性能，常见的是针对文件的 read()/write() 操作，另外也包括了通过 mmap() 映射之后的块设备，也就是说，事实上 Page Cache 负责了大部分的块设备文件的缓存工作。而 Buffer Cache 用来在系统对块设备进行读写的时候，对块进行数据缓存的系统来使用。

在 Linux 2.4 版本之后，kernel 就将两者进行了统一，Buffer Cache 不再以独立的形式存在，而是以融合的方式存在于 Page Cache 中

融合之后就可以统一操作 Page Cache 和 Buffer Cache：处理文件 I/O 缓存交给 Page Cache，而当底层 RAW device 刷新数据时以 Buffer Cache 的块单位来实际处理。

pagecache 的产生和释放

标准 I/O 是写的 (write(2)) 用户缓冲区 (Userpace Page 对应的内存)，然后再将用户缓冲区里的数据拷贝到内核缓冲区 (Pagecache Page 对应的内存)；如果是读的 (read(2)) 话则是先从内核缓冲区拷贝到用户缓冲区，再从用户缓冲区读数据，也就是 buffer 和文件内容不存在任何映射关系。
对于存储映射 I/O（Memory-Mapped I/O）而言，则是直接将 Pagecache Page 给映射到用户地址空间，用户直接读写 Pagecache Page 中内容，效率相对标准IO更高一些

当 将用户缓冲区里的数据拷贝到内核缓冲区 (Pagecache Page 对应的内存) 最容易发生缺页中断，OS需要先分配Page（应用感知到的就是卡顿了）

Page Cache 是在应用程序读写文件的过程中产生的，所以在读写文件之前你需要留意是否还有足够的内存来分配 Page Cache；
Page Cache 中的脏页很容易引起问题，你要重点注意这一块；
在系统可用内存不足的时候就会回收 Page Cache 来释放出来内存，可以通过 sar 或者 /proc/vmstat 来观察这个行为从而更好的判断问题是否跟回收有关

缺页后kswapd在短时间内回收不了足够多的 free 内存，或kswapd 还没有触发执行，操作系统就会进行内存页直接回收。这个过程中，应用会进行自旋等待直到回收的完成，从而产生巨大的延迟。

如果page被swapped，那么恢复进内存的过程也对延迟有影响，当匿名内存页被回收后，如果下次再访问就会产生IO的延迟。

min 和 low的区别

min下的内存是保留给内核使用的；当到达min，会触发内存的direct reclaim （vm.min_free_kbytes）
low水位比min高一些，当内存可用量小于low的时候，会触发 kswapd回收内存，当kswapd慢慢的将内存回收到high水位，就开始继续睡眠

内存回收方式

内存回收方式有两种，主要对应low ，min

kswapd reclaim : 达到low水位线时执行 – 异步（实际还有，只是比较危险了，后台kswapd会回收，不会卡顿应用）
direct reclaim : 达到min水位线时执行 – 同步

为了减少缺页中断，首先就要保证我们有足够的内存可以使用。由于Linux会尽可能多的使用free的内存，运行很久的应用free的内存是很少的。下面的图中，紫色表示已经使用的内存，白色表示尚未分配的内存。当我们的内存使用达到水位的low值的时候，kswapd就会开始回收工作，而一旦内存分配超过了min，就会进行内存的直接回收。

针对这种情况，需要采用预留内存的手段，系统参数vm.extra_free_kbytes就是用来做这个事情的。这个参数设置了系统预留给应用的内存，可以避免紧急需要内存时发生内存回收不及时导致的高延迟。从下面图中可以看到，通过vm.extra_free_kbytes的设置，预留内存可以让内存的申请处在一个安全的水位。需要注意的是，因为内核的优化，在3.10以上的内核版本这个参数已经被取消。

三个watermark的计算方法：

watermark[min] = vm.min_free_kbytes换算为page单位即可，假设为vm.min_free_kbytes。

watermark[low] = watermark[min] * 5 / 4

watermark[high] = watermark[min] * 3 / 2

比如默认 vm.min_free_kbytes = 65536是64K，很容易导致应用的毛刺，可以适当改大

或者禁止： vm.swappiness 来避免swapped来减少延迟

direct IO

绕过page cache，直接读写硬盘

cache回收

系统内存大体可分为三块，应用程序使用内存、系统Cache 使用内存（包括page cache、buffer，内核slab 等）和Free 内存。

应用程序使用内存：应用使用都是虚拟内存，应用申请内存时只是分配了地址空间，并未真正分配出物理内存，等到应用真正访问内存时会触发内核的缺页中断，这时候才真正的分配出物理内存，映射到用户的地址空间，因此应用使用内存是不需要连续的，内核有机制将非连续的物理映射到连续的进程地址空间中（mmu），缺页中断申请的物理内存，内核优先给低阶碎内存。
系统Cache 使用内存：使用的也是虚拟内存，申请机制与应用程序相同。
Free 内存，未被使用的物理内存，这部分内存以4k 页的形式被管理在内核伙伴算法结构中，相邻的2^n 个物理页会被伙伴算法组织到一起，形成一块连续物理内存，所谓的阶内存就是这里的n (0<= n <=10)，高阶内存指的就是一块连续的物理内存，在OSS 的场景中，如果3阶内存个数比较小的情况下，如果系统有吞吐burst 就会触发Drop cache 情况。

echo 1/2/3 >/proc/sys/vm/drop_caches

查看回收后：

cat /proc/meminfo

当我们执行 echo 2 来 drop slab 的时候，它也会把 Page Cache(inode可能会有对应的pagecache，inode释放后对应的pagecache也释放了)给 drop 掉

在系统内存紧张的时候，运维人员或者开发人员会想要通过 drop_caches 的方式来释放一些内存，但是由于他们清楚 Page Cache 被释放掉会影响业务性能，所以就期望只去 drop slab 而不去 drop pagecache。于是很多人这个时候就运行 echo 2 > /proc/sys/vm/drop_caches，但是结果却出乎了他们的意料：Page Cache 也被释放掉了，业务性能产生了明显的下降。

查看 drop_caches 是否执行过释放：

$ grep drop /proc/vmstat
drop_pagecache 1
drop_slab 0

$ grep inodesteal /proc/vmstat 
pginodesteal 114341
kswapd_inodesteal 1291853

在内存紧张的时候会触发内存回收，内存回收会尝试去回收 reclaimable（可以被回收的）内存，这部分内存既包含 Page Cache 又包含 reclaimable kernel memory(比如 slab)。inode被回收后可以通过 grep inodesteal /proc/vmstat 观察到

kswapd_inodesteal 是指在 kswapd 回收的过程中，因为回收 inode 而释放的 pagecache page 个数；

pginodesteal 是指 kswapd 之外其他线程在回收过程中，因为回收 inode 而释放的 pagecache page 个数;

Page回收–缺页中断

从图里你可以看到，在开始内存回收后，首先进行后台异步回收（上图中蓝色标记的地方），这不会引起进程的延迟；如果后台异步回收跟不上进程内存申请的速度，就会开始同步阻塞回收，导致延迟（上图中红色和粉色标记的地方，这就是引起 load 高的地址 – Sys CPU 使用率飙升/Sys load 飙升）。

那么，针对直接内存回收引起 load 飙高或者业务 RT 抖动的问题，一个解决方案就是及早地触发后台回收来避免应用程序进行直接内存回收，那具体要怎么做呢？

它的意思是：当内存水位低于 watermark low 时，就会唤醒 kswapd 进行后台回收，然后 kswapd 会一直回收到 watermark high。

那么，我们可以增大 min_free_kbytes 这个配置选项来及早地触发后台回收，该选项最终控制的是内存回收水位，不过，内存回收水位是内核里面非常细节性的知识点，我们可以先不去讨论。

对于大于等于 128G 的系统而言，将 min_free_kbytes 设置为 4G 比较合理，这是我们在处理很多这种问题时总结出来的一个经验值，既不造成较多的内存浪费，又能避免掉绝大多数的直接内存回收。

该值的设置和总的物理内存并没有一个严格对应的关系，我们在前面也说过，如果配置不当会引起一些副作用，所以在调整该值之前，我的建议是：你可以渐进式地增大该值，比如先调整为 1G，观察 sar -B 中 pgscand 是否还有不为 0 的情况；如果存在不为 0 的情况，继续增加到 2G，再次观察是否还有不为 0 的情况来决定是否增大，以此类推。

sar -B : Report paging statistics.

pgscand/s Number of pages scanned directly per second.

系统中脏页过多引起 load 飙高

直接回收过程中，如果存在较多脏页就可能涉及在回收过程中进行回写，这可能会造成非常大的延迟，而且因为这个过程本身是阻塞式的，所以又可能进一步导致系统中处于 D 状态的进程数增多，最终的表现就是系统的 load 值很高。

可以通过 sar -r 来观察系统中的脏页个数：

$ sar -r 1
07:30:01 PM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
09:20:01 PM   5681588   2137312     27.34         0   1807432    193016      2.47    534416   1310876         4
09:30:01 PM   5677564   2141336     27.39         0   1807500    204084      2.61    539192   1310884        20
09:40:01 PM   5679516   2139384     27.36         0   1807508    196696      2.52    536528   1310888        20
09:50:01 PM   5679548   2139352     27.36         0   1807516    196624      2.51    536152   1310892        24

kbdirty 就是系统中的脏页大小，它同样也是对 /proc/vmstat 中 nr_dirty 的解析。你可以通过调小如下设置来将系统脏页个数控制在一个合理范围:

vm.dirty_background_bytes = 0

vm.dirty_background_ratio = 10

vm.dirty_bytes = 0

vm.dirty_expire_centisecs = 3000

vm.dirty_ratio = 20

至于这些值调整大多少比较合适，也是因系统和业务的不同而异，我的建议也是一边调整一边观察，将这些值调整到业务可以容忍的程度就可以了，即在调整后需要观察业务的服务质量 (SLA)，要确保 SLA 在可接受范围内。调整的效果可以通过 /proc/vmstat 来查看：

1
2
3

#grep "nr_dirty_" /proc/vmstat
nr_dirty_threshold 3071708
nr_dirty_background_threshold 1023902

在4.20的内核并且sar 的版本为12.3.3可以看到PSI（Pressure-Stall Information）

1 2	some avg10=45.49 avg60=10.23 avg300=5.41 total=76464318 full avg10=40.87 avg60=9.05 avg300=4.29 total=58141082

重点关注 avg10 这一列，它表示最近 10s 内存的平均压力情况，如果它很大（比如大于 40）那 load 飙高大概率是由于内存压力，尤其是 Page Cache 的压力引起的。

通过tracepoint分析内存卡顿问题

我们继续以内存规整 (memory compaction) 为例，来看下如何利用 tracepoint 来对它进行观察：

#首先来使能compcation相关的一些tracepoing
$ echo 1 >
/sys/kernel/debug/tracing/events/compaction/mm_compaction_begin/enable
$ echo 1 >
/sys/kernel/debug/tracing/events/compaction/mm_compaction_end/enable 

#然后来读取信息，当compaction事件触发后就会有信息输出
$ cat /sys/kernel/debug/tracing/trace_pipe
           <...>-49355 [037] .... 1578020.975159: mm_compaction_begin: 
zone_start=0x2080000 migrate_pfn=0x2080000 free_pfn=0x3fe5800 
zone_end=0x4080000, mode=async
           <...>-49355 [037] .N.. 1578020.992136: mm_compaction_end: 
zone_start=0x2080000 migrate_pfn=0x208f420 free_pfn=0x3f4b720 
zone_end=0x4080000, mode=async status=contended

从这个例子中的信息里，我们可以看到是 49355 这个进程触发了 compaction，begin 和 end 这两个 tracepoint 触发的时间戳相减，就可以得到 compaction 给业务带来的延迟，我们可以计算出这一次的延迟为 17ms。

或者用 perf script 脚本来分析, 基于 bcc(eBPF) 写的direct reclaim snoop来观察进程因为 direct reclaim 而导致的延迟。

参考资料

https://www.atatech.org/articles/66885

https://cloud.tencent.com/developer/article/1087455

https://www.cnblogs.com/xiaolincoding/p/13719610.html

Linux内存--零拷贝

发表于 2020-11-15 更新于 2025-11-16 分类于 Memory

Linux内存–零拷贝

本系列有如下几篇

[Linux 内存问题汇总](/2020/01/15/Linux 内存问题汇总/)

零拷贝

“Zero-copy“ describes computer operations in which the CPU does not perform the task of copying data from one memory area to another. This is frequently used to save CPU cycles and memory bandwidth when transmitting a file over a network.

零拷贝技术是指计算机执行操作时，CPU不需要先将数据从某处内存复制到另一个特定区域。这种技术通常用于通过网络传输文件时节省 CPU 和内存带宽。

零拷贝可以做到用户空间和内核空间共用同一块内存（Java中的DirectBuffer），这样少做一次拷贝。普通Buffer是在JVM堆上分配的内存，而DirectBuffer是堆外分配的（内核和JVM可以同时读写），这样不需要再多一次内核到用户Buffer的拷贝

比如通过网络下载文件，普通拷贝的流程会复制4次并有4次上下文切换，上下文切换是因为读写慢导致了IO的阻塞，进而线程被内核挂起，所以发生了上下文切换。在极端情况下如果read/write没有导致阻塞是不会发生上下文切换的：

NoOptimization

改成零拷贝后，也就是将read和write合并成一次，直接在内核中完成磁盘到网卡的数据复制

零拷贝就是操作系统提供的新函数(sendfile)，同时接收文件描述符和 TCP socket 作为输入参数，这样执行时就可以完全在内核态完成内存拷贝，既减少了内存拷贝次数，也降低了上下文切换次数。

而且，零拷贝取消了用户缓冲区后，不只降低了用户内存的消耗，还通过最大化利用 socket 缓冲区中的内存，间接地再一次减少了系统调用的次数，从而带来了大幅减少上下文切换次数的机会！

应用读取磁盘写入网络的时候还得考虑缓存的大小，一般会设置的比较小，这样一个大文件导致多次小批量的读取，每次读取伴随着多次上下文切换。

零拷贝使我们不必关心 socket 缓冲区的大小（socket缓冲区大小本身默认就是动态调整、或者应用代码指定大小）。比如，调用零拷贝发送方法时，尽可以把发送字节数设为文件的所有未发送字节数，例如 320MB，也许此时 socket 缓冲区大小为 1.4MB，那么一次性就会发送 1.4MB 到客户端，而不是只有 32KB。这意味着对于 1.4MB 的 1 次零拷贝，仅带来 2 次上下文切换，而不使用零拷贝且用户缓冲区为 32KB 时，经历了 176 次（4 * 1.4MB/32KB）上下文切换。

read+write 和零拷贝优化

1 2	read(file, tmp_buf, len); write(socket, tmp_buf, len);

通过mmap替换read优化一下

用 mmap() 替换原先的 read()，mmap() 也即是内存映射（memory map）：把用户进程空间的一段内存缓冲区（user buffer）映射到文件所在的内核缓冲区（kernel buffer）上。

通过使用 mmap() 来代替 read()，可以减少一次数据拷贝的过程。

但这还不是最理想的零拷贝，因为首先仍然需要通过 CPU 把内核缓冲区的数据拷贝到 socket 缓冲区里，而且仍然需要 4 次上下文切换，因为系统调用还是 2 次；另外内存映射技术是一个开销很大的虚拟存储操作：这种操作需要修改页表以及用内核缓冲区里的文件数据汰换掉当前 TLB 里的缓存以维持虚拟内存映射的一致性。

sendfile

在 Linux 内核版本 2.1 中，提供了一个专门发送文件的系统调用函数 sendfile()，函数形式如下：

1 2	#include <sys/socket.h> ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

它的前两个参数分别是目的端和源端的文件描述符，后面两个参数是源端的偏移量和复制数据的长度，返回值是实际复制数据的长度。

首先，它可以替代前面的 read() 和 write() 这两个系统调用，这样就可以减少一次系统调用，也就减少了 2 次上下文切换的开销。

其次，该系统调用，可以直接把内核缓冲区里的数据拷贝到 socket 缓冲区里，不再拷贝到用户态，这样就只有 2 次上下文切换，和 3 次数据拷贝。如下图：

当然这里还是有一次CPU来拷贝内存的过程，仍然有文件截断的问题。sendfile() 依然是一个适用性很窄的技术，最适合的场景基本也就是一个静态文件服务器了。

然而 sendfile() 本身是有很大问题的，从不同的角度来看的话主要是：

首先一个是这个接口并没有进行标准化，导致 sendfile() 在 Linux 上的接口实现和其他类 Unix 系统的实现并不相同；
其次由于网络传输的异步性，很难在接收端实现和 sendfile() 对接的技术，因此接收端一直没有实现对应的这种技术；
最后从性能方面考量，因为 sendfile() 在把磁盘文件从内核缓冲区（page cache）传输到到套接字缓冲区的过程中依然需要 CPU 参与，这就很难避免 CPU 的高速缓存被传输的数据所污染。

SG-DMA（The Scatter-Gather Direct Memory Access）技术

上一小节介绍的 sendfile() 技术已经把一次数据读写过程中的 CPU 拷贝的降低至只有 1 次了，但是人永远是贪心和不知足的，现在如果想要把这仅有的一次 CPU 拷贝也去除掉，有没有办法呢？

当然有！通过引入一个新硬件上的支持，我们可以把这个仅剩的一次 CPU 拷贝也给抹掉：Linux 在内核 2.4 版本里引入了 DMA 的 scatter/gather – 分散/收集功能，并修改了 sendfile() 的代码使之和 DMA 适配。scatter 使得 DMA 拷贝可以不再需要把数据存储在一片连续的内存空间上，而是允许离散存储，gather 则能够让 DMA 控制器根据少量的元信息：一个包含了内存地址和数据大小的缓冲区描述符，收集存储在各处的数据，最终还原成一个完整的网络包，直接拷贝到网卡而非套接字缓冲区，避免了最后一次的 CPU 拷贝：

如果网卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技术（和普通的 DMA 有所不同），我们可以进一步减少通过 CPU 把内核缓冲区里的数据拷贝到 socket 缓冲区的过程。

这就是所谓的零拷贝（Zero-copy）技术，因为我们没有在内存层面去拷贝数据，也就是说全程没有通过 CPU 来搬运数据，所有的数据都是通过 DMA 来进行传输的。 数据传输过程就再也没有 CPU 的参与了，也因此 CPU 的高速缓存再不会被污染了，也不再需要 CPU 来计算数据校验和了，CPU 可以去执行其他的业务计算任务，同时和 DMA 的 I/O 任务并行，此举能极大地提升系统性能。

零拷贝技术的文件传输方式相比传统文件传输的方式，减少了 2 次上下文切换和数据拷贝次数，只需要 2 次上下文切换和数据拷贝次数，就可以完成文件的传输，而且 2 次的数据拷贝过程，都不需要通过 CPU，2 次都是由 DMA 来搬运。

所以，总体来看，零拷贝技术可以把文件传输的性能提高至少一倍以上。

splice()

sendfile() + DMA Scatter/Gather 的零拷贝方案虽然高效，但是也有两个缺点：

这种方案需要引入新的硬件支持；
虽然 sendfile() 的输出文件描述符在 Linux kernel 2.6.33 版本之后已经可以支持任意类型的文件描述符，但是输入文件描述符依然只能指向文件。

这两个缺点限制了 sendfile() + DMA Scatter/Gather 方案的适用场景。为此，Linux 在 2.6.17 版本引入了一个新的系统调用 splice()，它在功能上和 sendfile() 非常相似，但是能够实现在任意类型的两个文件描述符时之间传输数据；而在底层实现上，splice()又比 sendfile() 少了一次 CPU 拷贝，也就是等同于 sendfile() + DMA Scatter/Gather，完全去除了数据传输过程中的 CPU 拷贝。

splice() 所谓的写入数据到管道其实并没有真正地拷贝数据，而是玩了个 tricky 的操作：只进行内存地址指针的拷贝而不真正去拷贝数据。所以，数据 splice() 在内核中并没有进行真正的数据拷贝，因此 splice() 系统调用也是零拷贝。

还有一点需要注意，前面说过管道的容量是 16 个内存页，也就是 16 * 4KB = 64 KB，也就是说一次往管道里写数据的时候最好不要超过 64 KB，否则的话会 splice() 会阻塞住，除非在创建管道的时候使用的是 pipe2() 并通过传入 O_NONBLOCK 属性将管道设置为非阻塞。

send() with MSG_ZEROCOPY

Linux 内核在 2017 年的 v4.14 版本接受了来自 Google 工程师 Willem de Bruijn 在 TCP 网络报文的通用发送接口 send() 中实现的 zero-copy 功能 (MSG_ZEROCOPY) 的 patch，通过这个新功能，用户进程就能够把用户缓冲区的数据通过零拷贝的方式经过内核空间发送到网络套接字中去，这个新技术和前文介绍的几种零拷贝方式相比更加先进，因为前面几种零拷贝技术都是要求用户进程不能处理加工数据而是直接转发到目标文件描述符中去的。Willem de Bruijn 在他的论文里给出的压测数据是：采用 netperf 大包发送测试，性能提升 39%，而线上环境的数据发送性能则提升了 5%~8%，官方文档陈述说这个特性通常只在发送 10KB 左右大包的场景下才会有显著的性能提升。一开始这个特性只支持 TCP，到内核 v5.0 版本之后才支持 UDP。

这个技术是基于 redhat 红帽在 2010 年给 Linux 内核提交的 virtio-net zero-copy 技术之上实现的，至于底层原理，简单来说就是通过 send() 把数据在用户缓冲区中的分段指针发送到 socket 中去，利用 page pinning 页锁定机制锁住用户缓冲区的内存页，然后利用 DMA 直接在用户缓冲区通过内存地址指针进行数据读取，实现零拷贝

目前来说，这种技术的主要缺陷有：

只适用于大文件 (10KB 左右) 的场景，小文件场景因为 page pinning 页锁定和等待缓冲区释放的通知消息这些机制，甚至可能比直接 CPU 拷贝更耗时；
因为可能异步发送数据，需要额外调用 poll() 和 recvmsg() 系统调用等待 buffer 被释放的通知消息，增加代码复杂度，以及会导致多次用户态和内核态的上下文切换；
MSG_ZEROCOPY 目前只支持发送端，接收端暂不支持。

零拷贝应用

kafka就利用了「零拷贝」技术，从而大幅提升了 I/O 的吞吐率，这也是 Kafka 在处理海量数据为什么这么快的原因之一(利用磁盘顺序写；PageCache)。

非零拷贝代码：

1 2	File.read(fileDesc, buf, len); Socket.send(socket, buf, len);

Traditional data copying approach：

Traditional data copying approach

Traditional context switches：

Traditional context switches

如果你追溯 Kafka 文件传输的代码，你会发现，最终它调用了 Java NIO 库里的 transferTo 方法：

@Overridepublic 
long transferFrom(FileChannel fileChannel, long position, long count) throws IOException { 
    return fileChannel.transferTo(position, count, socketChannel);
}

Data copy with transferTo()

Context switching with transferTo()：

Context switching when using transferTo()

Data copies when transferTo() and gather operations are used

如果 Linux 系统支持 sendfile() 系统调用，那么 transferTo() 实际上最后就会使用到 sendfile() 系统调用函数。

Nginx 也支持零拷贝技术，一般默认是开启零拷贝技术，这样有利于提高文件传输的效率，是否开启零拷贝技术的配置如下：

http {
...
    sendfile on
...
}

sendfile 配置的具体意思:

设置为 on 表示，使用零拷贝技术来传输文件：sendfile ，这样只需要 2 次上下文切换，和 2 次数据拷贝。
设置为 off 表示，使用传统的文件传输技术：read + write，这时就需要 4 次上下文切换，和 4 次数据拷贝。

如果是大文件很容易消耗非常多的PageCache，不推荐使用PageCache（或者说零拷贝），建议使用异步IO+直接IO。

在 nginx 中，我们可以用如下配置，来根据文件的大小来使用不同的方式：

location /video/ { 
    sendfile on; 
    aio on; 
    directio 1024m; 
}

当文件大小大于 directio 值后，使用「异步 I/O + 直接 I/O」，否则使用「零拷贝技术」。

零拷贝性能

如果用零拷贝和不用零拷贝来做一个文件服务器，来对比下他们的性能

Performance comparison: Traditional approach vs. zero copy

File size	Normal file transfer (ms)	transferTo (ms)
7MB	156	45
21MB	337	128
63MB	843	387
98MB	1320	617
200MB	2124	1150
350MB	3631	1762
700MB	13498	4422
1GB	18399	8537

DMA

什么是 DMA 技术？简单理解就是，在进行 I/O 设备和内存的数据传输的时候，数据搬运的工作全部交给 DMA 控制器，而 CPU 不再参与任何与数据搬运相关的事情，这样 CPU 就可以去处理别的事务

RDMA

remote DMA

参考资料

https://www.atatech.org/articles/66885

https://cloud.tencent.com/developer/article/1087455

https://www.cnblogs.com/xiaolincoding/p/13719610.html

https://mp.weixin.qq.com/s/dZNjq05q9jMFYhJrjae_LA 从Linux内存管理到零拷贝

Efficient data transfer through zero copy

CPU：一个故事看懂DMA

Linux内存--管理和碎片

发表于 2020-11-15 更新于 2025-11-16 分类于 Memory

Linux内存–管理和碎片

本系列有如下几篇

[Linux 内存问题汇总](/2020/01/15/Linux 内存问题汇总/)

物理结构分析

内存从物理结构上面分为：Channel > DIMM（对应物理上售卖的内存条） >Rank > Chip > Bank > Row/Column。

Chip就是DRAM芯片，一个chip里面会有很多bank。每个bank就是数据存储的实体，相当于一个二维矩阵，只要声明了column和row就可以从每个bank中取出8bit的数据。

具体可以看如下图，一个通道Channel可以是一个DIMM也可以是两个DIMM，甚至3个DIMM，图中是2个DIMM。

虚拟内存和物理内存

进程所操作的内存是一个虚拟内存，由OS来将这块虚拟内存映射到实际的物理内存上，这样做的好处是每个进程可以独占 128T 内存，任意地使用，系统上还运行了哪些进程已经与我们完全没有关系了（不需要考虑和其它进程之间的地址会冲突）。为变量和函数分配地址的活，我们交给链接器去自动安排就可以了。这一切都是因为虚拟内存能够提供内存地址空间的隔离，极大地扩展了可用空间。

操作系统管理着这种映射关系，所以你在写代码的时候，就不用再操心物理内存的使用情况了，你看到的内存就是虚拟内存。无论一个进程占用的内存资源有多大，在任一时刻，它需要的物理内存都是很少的。在这个推论的基础上，CPU 为每个进程只需要保留很少的物理内存就可以保证进程的正常执行了。

当程序中使用 malloc 等分配内存的接口时会将内存从待分配状态变成已分配状态，此时这块分配好的内存还没有真正映射到对应的物理内存上，这块内存就是未映射状态，因为它并没有被映射到相应的物理内存，直到对该块内存进行读写时，操作系统才会真正地为它分配物理内存。然后这个页面才能成为正常页面。

i7 处理器的页表也是存储在内存页里的，每个页表项都是 4 字节。所以，人们就将 1024 个页表项组成一张页表。这样一张页表的大小就刚好是 4K，占据一个内存页，这样就更加方便管理。而且，当前市场上主流的处理器也都选择将页大小定为 4K。

虚拟地址在计算机体系结构里可以评为特优的一项技术；超线程、流水线、多发射只是优；cache则只是良好（成本高）

CPU 如何找到真实地址

第一步是确定页目录基址。每个 CPU 都有一个页目录基址寄存器，最高级页表的基地址就存在这个寄存器里。在 X86 上，这个寄存器是 CR3。每一次计算物理地址时，MMU 都会从 CR3 寄存器中取出页目录所在的物理地址。
第二步是定位页目录项（PDE）。一个 32 位的虚拟地址可以拆成 10 位，10 位和 12 位三段，上一步找到的页目录表基址加上高 10 位的值乘以 4，就是页目录项的位置。这是因为，一个页目录项正好是 4 字节，所以 1024 个页目录项共占据 4096 字节，刚好组成一页，而 1024 个页目录项需要 10 位进行编码。这样，我们就可以通过最高 10 位找到该地址所对应的 PDE 了。
第三步是定位页表项（PTE）。页目录项里记录着页表的位置，CPU 通过页目录项找到页表的位置以后，再用中间 10 位计算页表中的偏移，可以找到该虚拟地址所对应的页表项了。页表项也是 4 字节的，所以一页之内刚好也是 1024 项，用 10 位进行编码。所以计算公式与上一步相似，用页表基址加上中间 10 位乘以 4，可以得到页表项的地址。
最后一步是确定真实的物理地址。上一步 CPU 已经找到页表项了，这里存储着物理地址，这才真正找到该虚拟地址所对应的物理页。虚拟地址的低 12 位，刚好可以对一页内的所有字节进行编码，所以我们用低 12 位来代表页内偏移。计算的公式是物理页的地址直接加上低 12 位。

前面我们分析的是 32 位操作系统，那对于 64 位机器是不是有点不同呢？在 64 位的机器上，使用了 48 位的虚拟地址，所以它需要使用 4 级页表。它的结构与 32 位的 3 级页表是相似的，只是多了一级页目录，定位的过程也从 32 位的 4 步变成了 5 步。

8086最开始是按不同的作用将内存分为代码段、数据段等，386开始按页开始管理内存（混合有按段管理）。现代的操作系统都是采用段式管理来做基本的权限管理，而对于内存的分配、回收、调度都是依赖页式管理。

tlab miss

tlb：从各级cache里分配的一块专用空间，用来存放页表(虚拟地址和物理地址的对应关系)–存放在CPU cache里的索引

#x86info -c
Monitor/Mwait: min/max line size 64/64, ecx bit 0 support, enumeration extension
SVM: revision 1, 32768 ASIDs
Address Size: 48 bits virtual, 48 bits physical
The physical package has 96 of 32768 possible cores implemented.
L1 Data TLB (1G):           Fully associative. 64 entries.
L1 Instruction TLB (1G):    Fully associative. 64 entries.
L1 Data TLB (2M/4M):        Fully associative. 64 entries.
L1 Instruction TLB (2M/4M): Fully associative. 64 entries.
L1 Data TLB (4K):           Fully associative. 64 entries.
L1 Instruction TLB (4K):    Fully associative. 64 entries.
L1 Data cache:
	Size: 32Kb	8-way associative.
	lines per tag=1	line size=64 bytes.
L1 Instruction cache:
	Size: 32Kb	8-way associative.
	lines per tag=1	line size=64 bytes.
L2 Data TLB (1G):           Fully associative. 64 entries.
L2 Instruction TLB (1G):    Disabled. 0 entries.
L2 Data TLB (2M/4M):        4-way associative. 2048 entries.
L2 Instruction TLB (2M/4M): 2-way associative. 512 entries.
L2 Data TLB (4K):           8-way associative. 2048 entries.
L2 Instruction TLB (4K):    4-way associative. 512 entries.
L2 cache:
	Size: 512Kb	8-way associative.
	lines per tag=1	line size=64 bytes.

 running at an estimated 2.55GHz

TLB(Translation Lookaside Buffer) Cache用于缓存少量热点内存地址的mapping关系。TLB和L1一样每个core独享，由于制造成本和工艺的限制，响应时间需要控制在CPU Cycle级别的Cache容量只能存储几十个对象。那么TLB Cache在应对大量热点数据Virual Address转换的时候就显得捉襟见肘了。我们来算下按照标准的Linux页大小(page size) 4K，一个能缓存64元素的TLB Cache只能涵盖4K*64 = 256K的热点数据的内存地址，显然离理想非常遥远的。于是Huge Page就产生了。

These are typical performance levels of a TLB:

Size: 12 bits – 4,096 entries
Hit time: 0.5 – 1 clock cycle
Miss penalty: 10 – 100 clock cycles
Miss rate: 0.01 – 1% (20–40% for sparse/graph applications)

TLB也分为iTLB和dTLB, 分别顶在L1i和L1d前面（比L1更小更快，每个core独享tlb）

以intel x86为例，一个cpu也就32到64个tlb, 超出这个范畴，就得去查页表。每个型号的cpu都不一样，需要查看spec

进程分配到的不是内存的实际物理地址，而是一个经过映射后的虚拟地址，这么做的原因是为了让每个应用可以独享完整的虚拟地址，而不需要每个进程互相考虑使用内存的协调。

但是虚拟地址到物理地址的映射需要巨大的映射空间，如何用更少的内存消耗来管理庞大的内存（如果没有分级，4G内存对应着4MB的索引空间，一级比如使用4K就够了，多个二级使总共用4M，但是这4M大部分时候不用提前分配），Linux通过四级表项来做虚拟地址到物理地址的映射，这样4Kb就能管理256T内存，4级映射是时间换空间的典型案例。不过一般而言一个进程是远远用不了256T内存的，那么这四级映射大部分时候都是没必要的，所以实际用不了那么大的PageTable。

虚拟内存的核心原理是：为每个程序设置一段”连续”的虚拟地址空间，把这个地址空间分割成多个具有连续地址范围的页 (page)，并把这些页和物理内存做映射，在程序运行期间动态映射到物理内存。当程序引用到一段在物理内存的地址空间时，由硬件立刻执行必要的映射；而当程序引用到一段不在物理内存中的地址空间时，由操作系统负责将缺失的部分装入物理内存并重新执行失败的指令：

在内存管理单元（Memory Management Unit，MMU）进行地址转换时，如果页表项的 “在/不在” 位是 0，则表示该页面并没有映射到真实的物理页框，则会引发一个缺页中断，CPU 陷入操作系统内核，接着操作系统就会通过页面置换算法选择一个页面将其换出 (swap)，以便为即将调入的新页面腾出位置，如果要换出的页面的页表项里的修改位已经被设置过，也就是被更新过，则这是一个脏页 (dirty page)，需要写回磁盘更新改页面在磁盘上的副本，如果该页面是”干净”的，也就是没有被修改过，则直接用调入的新页面覆盖掉被换出的旧页面即可。

还需要了解的一个概念是转换检测缓冲器（Translation Lookaside Buffer，TLB，每个core一个TLB，类似L1 cache），也叫快表，是用来加速虚拟地址映射的，因为虚拟内存的分页机制，页表一般是保存内存中的一块固定的存储区，导致进程通过 MMU 访问内存比直接访问内存多了一次内存访问，性能至少下降一半，因此需要引入加速机制，即 TLB 快表，TLB 可以简单地理解成页表的高速缓存，保存了最高频被访问的页表项，由于一般是硬件实现的，因此速度极快，MMU 收到虚拟地址时一般会先通过硬件 TLB 查询对应的页表号，若命中且该页表项的访问操作合法，则直接从 TLB 取出对应的物理页框号返回，若不命中则穿透到内存页表里查询，并且会用这个从内存页表里查询到最新页表项替换到现有 TLB 里的其中一个，以备下次缓存命中。

如果没有TLB那么每一次内存映射都需要查表四次然后才是一次真正的内存访问，代价比较高。

有了TLB之后，CPU访问某个虚拟内存地址的过程如下

CPU产生一个虚拟地址
MMU从TLB中获取页表，翻译成物理地址
MMU把物理地址发送给L1/L2/L3/内存
L1/L2/L3/内存将地址对应数据返回给CPU

由于第2步是类似于寄存器的访问速度，所以如果TLB能命中，则虚拟地址到物理地址的时间开销几乎可以忽略。tlab miss比较高的话开启内存大页对性能是有提升的，但是会有一定的内存浪费。

内存布局

代码段：CPU 运行一个程序，实质就是在顺序执行该程序的机器码。一个程序的机器码会被组织到同一个地方。
数据段：程序在运行过程中必然要操作数据。这其中，对于有初值的变量，它的初始值会存放在程序的二进制文件中，而且，这些数据部分也会被装载到内存中，即程序的数据段。数据段存放的是程序中已经初始化且不为 0 的全局变量和静态变量。
BSS 段: 对于未初始化的全局变量和静态变量，因为编译器知道它们的初始值都是 0，因此便不需要再在程序的二进制映像中存放这么多 0 了，只需要记录他们的大小即可，这便是BSS段。BSS 段这个缩写名字是 Block Started by Symbol，但很多人可能更喜欢把它记作 Better Save Space 的缩写。
堆是程序员可以自由申请的空间，当我们在写程序时要保存数据，优先会选择堆；
栈是函数执行时的活跃记录，这将是我们下一节课要重点分析的内容。

数据段和 BSS 段里存放的数据也只能是部分数据，主要是全局变量和静态变量，但程序在运行过程中，仍然需要记录大量的临时变量，以及运行时生成的变量，这里就需要新的内存区域了，即程序的堆空间跟栈空间。与代码段以及数据段不同的是，堆和栈并不是从磁盘中加载，它们都是由程序在运行的过程中申请，在程序运行结束后释放。

总的来说，一个程序想要运行起来所需要的几块基本内存区域：代码段、数据段、BSS 段、堆空间和栈空间。下面就是内存布局的示意图：

其它内存形态：

存放加载的共享库的内存空间：如果一个进程依赖共享库，那对应的，该共享库的代码段、数据段、BSS 段也需要被加载到这个进程的地址空间中。
共享内存段：我们可以通过系统调用映射一块匿名区域作为共享内存，用来进行进程间通信。
内存映射文件：我们也可以将磁盘的文件映射到内存中，用来进行文件编辑或者是类似共享内存的方式进行进程通信。

32位 x86机器下，通过 cat /proc/pid/maps 看到的进程所使用的内存分配空间：

64位 x86机器下，通过 cat /proc/pid/maps 看到的进程所使用的内存分配空间：

目前的 64 系统下的寻址空间是 2^48(太多用不完，高16位为Canonical空间），即 256TB。而且根据 canonical address 的划分，地址空间天然地被分割成两个区间，分别是 0x0 - 0x00007fffffffffff 和 0xffff800000000000 - 0xffffffffffffffff。这样就直接将低 128T 的空间划分为用户空间，高 128T 划分为内核空间。

brk:内核维护指向堆的顶部

Java程序对应的maps：

#cat /proc/14011/maps
00400000-00401000 r-xp 00000000 08:03 3935494                            /opt/taobao/install/ajdk-8.3.6_fp9-b30/bin/java
00600000-00601000 rw-p 00000000 08:03 3935494                            /opt/taobao/install/ajdk-8.3.6_fp9-b30/bin/java
ed400000-1001e0000 rw-p 00000000 00:00 0
1001e0000-140000000 ---p 00000000 00:00 0
7f86e8000000-7f8a7fc00000 rw-p 00000000 00:00 0
..
7f8aaecfa000-7f8aaeff8000 rw-p 00000000 00:00 0
7f8aaeff8000-7f8aaf000000 r-xp 00000000 08:03 3935973                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libmanagement.so
7f8aaf000000-7f8aaf1ff000 ---p 00008000 08:03 3935973                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libmanagement.so
7f8aaf1ff000-7f8aaf200000 rw-p 00007000 08:03 3935973                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libmanagement.so
..
7f8ad8cea000-7f8ad8cec000 r--s 00004000 08:05 7078938                    /home/admin/drds-worker/lib/netty-handler-proxy-4.1.17.Final.jar
7f8ad8cec000-7f8ad8cf5000 r--s 0006f000 08:05 7078952                    /home/admin/drds-worker/lib/log4j-1.2.17.jar
7f8ad8cf5000-7f8ad8cf7000 r--s 00005000 08:05 7078960                    /home/admin/drds-worker/lib/objenesis-1.0.jar
7f8ad8cf7000-7f8ad8cff000 r--s 0004b000 08:05 7078929                    /home/admin/drds-worker/lib/spring-aop-3.2.18.RELEASE.jar
7f8ad8cff000-7f8ad8d00000 ---p 00000000 00:00 0
7f8ad8d00000-7f8ad9000000 rw-p 00000000 00:00 0
7f8ad90e3000-7f8ad90ef000 r--s 000b6000 08:05 7079066                    /home/admin/drds-worker/lib/transmittable-thread-local-2.5.1.jar
7f8ad9dd8000-7f8ad9dfe000 r--s 0026f000 08:05 7078997                    /home/admin/drds-worker/lib/druid-1.1.7-preview_12.jar
7f8ad9dfe000-7f8ad9dff000 ---p 00000000 00:00 0
7f8ad9dff000-7f8ad9eff000 rw-p 00000000 00:00 0
7f8ad9eff000-7f8ad9f00000 ---p 00000000 00:00 0
7f8ad9f00000-7f8ada200000 rw-p 00000000 00:00 0
7f8ada200000-7f8ada202000 r--s 00003000 08:05 7078944                    /home/admin/drds-worker/lib/liberate-rest-1.0.2.jar
7f8ada202000-7f8ada206000 r--s 00036000 08:05 7078912                    /home/admin/drds-worker/lib/jackson-core-lgpl-1.9.6.jar
7f8ada289000-7f8ada28b000 r--s 00001000 08:05 7078998                    /home/admin/drds-worker/lib/opencensus-contrib-grpc-metrics-0.10.0.jar
7f8ada2b5000-7f8ada2b9000 r--s 0003a000 08:05 7079099                    /home/admin/drds-worker/lib/tddl-repo-mysql-5.2.7-2-EXTEND-HOTMAPPING-SNAPSHOT.jar
7f8ada2b9000-7f8ada2c6000 r--s 0007d000 08:05 7078982                    /home/admin/drds-worker/lib/grpc-core-1.9.0.jar
7f8ada2c6000-7f8ada2d6000 r--s 00149000 08:05 7079000                    /home/admin/drds-worker/lib/protobuf-java-3.5.1.jar
7f8ada2d6000-7f8ada2db000 r--s 0002b000 08:05 7078927                    /home/admin/drds-worker/lib/tddl-net-5.2.7-2-EXTEND-HOTMAPPING-SNAPSHOT.jar
7f8ada2db000-7f8ada2e0000 r--s 0002a000 08:05 7078939                    /home/admin/drds-worker/lib/grpc-netty-1.9.0.jar
7f8ada2e0000-7f8ada2ff000 r--s 00150000 08:05 7078965                    /home/admin/drds-worker/lib/mockito-core-1.9.5.jar
7f8ada2ff000-7f8ada300000 ---p 00000000 00:00 0
7f8ada300000-7f8ada600000 rw-p 00000000 00:00 0
7f8ada600000-7f8ada601000 r--s 00003000 08:05 7079089                    /home/admin/drds-worker/lib/ushura-1.0.jar
7f8ae9ba2000-7f8ae9baa000 r-xp 00000000 08:03 3935984                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libzip.so
7f8ae9baa000-7f8ae9da9000 ---p 00008000 08:03 3935984                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libzip.so
7f8ae9da9000-7f8ae9daa000 rw-p 00007000 08:03 3935984                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libzip.so
7f8ae9daa000-7f8ae9db6000 r-xp 00000000 08:03 1837851                    /usr/lib64/libnss_files-2.17.so;614d5f07 (deleted)
7f8ae9db6000-7f8ae9fb5000 ---p 0000c000 08:03 1837851                    /usr/lib64/libnss_files-2.17.so;614d5f07 (deleted)
7f8ae9fb5000-7f8ae9fb6000 r--p 0000b000 08:03 1837851                    /usr/lib64/libnss_files-2.17.so;614d5f07 (deleted)
7f8ae9fb6000-7f8ae9fb7000 rw-p 0000c000 08:03 1837851                    /usr/lib64/libnss_files-2.17.so;614d5f07 (deleted)
7f8ae9fb7000-7f8ae9fbd000 rw-p 00000000 00:00 0
7f8ae9fbd000-7f8ae9fe7000 r-xp 00000000 08:03 3935961                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libjava.so
7f8aebc03000-7f8aebc05000 r--s 00008000 08:05 7079098                    /home/admin/drds-worker/lib/grpc-stub-1.9.0.jar
7f8aebc05000-7f8aebc07000 r--s 00020000 08:05 7078930                    /home/admin/drds-worker/lib/tddl-group-5.2.7-2-EXTEND-HOTMAPPING-SNAPSHOT.jar
7f8aebc07000-7f8aebc1f000 r--s 001af000 08:05 7079085                    /home/admin/drds-worker/lib/aspectjweaver-1.8.5.jar
7f8aebc1f000-7f8aebc20000 ---p 00000000 00:00 0
7f8aebc20000-7f8aebd20000 rw-p 00000000 00:00 0
7f8aebd20000-7f8aebd35000 r-xp 00000000 08:03 1837234                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8aebd35000-7f8aebf34000 ---p 00015000 08:03 1837234                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8aebf34000-7f8aebf35000 r--p 00014000 08:03 1837234                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8aebf35000-7f8aebf36000 rw-p 00015000 08:03 1837234                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8aebf36000-7f8aec037000 r-xp 00000000 08:03 1837579                    /usr/lib64/libm-2.17.so;614d5f07 (deleted)
7f8aec037000-7f8aec236000 ---p 00101000 08:03 1837579                    /usr/lib64/libm-2.17.so;614d5f07 (deleted)
7f8aeca17000-7f8aeca18000 rw-p 0000d000 08:03 3936057                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/lib/amd64/jli/libjli.so
7f8aeca18000-7f8aeca2d000 r-xp 00000000 08:03 1836998                    /usr/lib64/libz.so.1.2.7
7f8aeca2d000-7f8aecc2c000 ---p 00015000 08:03 1836998                    /usr/lib64/libz.so.1.2.7
7f8aecc2c000-7f8aecc2d000 r--p 00014000 08:03 1836998                    /usr/lib64/libz.so.1.2.7
7f8aecc2d000-7f8aecc2e000 rw-p 00015000 08:03 1836998                    /usr/lib64/libz.so.1.2.7
7f8aecc2e000-7f8aecc45000 r-xp 00000000 08:03 1836993                    /usr/lib64/libpthread-2.17.so;614d5f07 (deleted)
7f8aecc45000-7f8aece44000 ---p 00017000 08:03 1836993                    /usr/lib64/libpthread-2.17.so;614d5f07 (deleted)
7f8aece44000-7f8aece45000 r--p 00016000 08:03 1836993                    /usr/lib64/libpthread-2.17.so;614d5f07 (deleted)
7f8aece45000-7f8aece46000 rw-p 00017000 08:03 1836993                    /usr/lib64/libpthread-2.17.so;614d5f07 (deleted)
7f8aece46000-7f8aece4a000 rw-p 00000000 00:00 0
7f8aece4a000-7f8aecea1000 r-xp 00000000 08:03 3936059                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/lib/amd64/libjemalloc.so.2
7f8aecea1000-7f8aed0a0000 ---p 00057000 08:03 3936059                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/lib/amd64/libjemalloc.so.2
7f8aed0a0000-7f8aed0a3000 rw-p 00056000 08:03 3936059                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/lib/amd64/libjemalloc.so.2
7f8aed0a3000-7f8aed0b5000 rw-p 00000000 00:00 0
7f8aed0b5000-7f8aed0d7000 r-xp 00000000 08:03 1837788                    /usr/lib64/ld-2.17.so;614d5f07 (deleted)
7f8aed0d7000-7f8aed0dc000 r--s 00038000 08:05 7079012                    /home/admin/drds-worker/lib/org.osgi.core-4.2.0.jar
7f8aed0dc000-7f8aed0e1000 r--s 00038000 08:05 7079018                    /home/admin/drds-worker/lib/commons-beanutils-1.9.3.jar
7f8aed0e1000-7f8aed0e3000 r--s 00001000 08:05 7079033                    /home/admin/drds-worker/lib/j2objc-annotations-1.1.jar
7f8aed0e3000-7f8aed0e8000 r--s 00017000 08:05 7079056                    /home/admin/drds-worker/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar
7f8aed1be000-7f8aed1c6000 rw-s 00000000 08:04 393222                     /tmp/hsperfdata_admin/14011
7f8aed1c6000-7f8aed1ca000 ---p 00000000 00:00 0
7f8aed1ca000-7f8aed2cd000 rw-p 00000000 00:00 0
7f8aed2cd000-7f8aed2ce000 r--s 00005000 08:05 7079029                    /home/admin/drds-worker/lib/jersey-apache-connector-2.26.jar
7f8aed2ce000-7f8aed2d1000 r--s 0000a000 08:05 7079027                    /home/admin/drds-worker/lib/metrics-jvm-1.7.4.jar
7f8aed2d1000-7f8aed2d3000 r--s 00006000 08:05 7078961                    /home/admin/drds-worker/lib/tddl-client-5.2.7-2-EXTEND-HOTMAPPING-SNAPSHOT.jar
7f8aed2d3000-7f8aed2d4000 rw-p 00000000 00:00 0
7f8aed2d4000-7f8aed2d5000 r--p 00000000 00:00 0
7f8aed2d5000-7f8aed2d6000 rw-p 00000000 00:00 0
7f8aed2d6000-7f8aed2d7000 r--p 00021000 08:03 1837788                    /usr/lib64/ld-2.17.so;614d5f07 (deleted)
7f8aed2d7000-7f8aed2d8000 rw-p 00022000 08:03 1837788                    /usr/lib64/ld-2.17.so;614d5f07 (deleted)
7f8aed2d8000-7f8aed2d9000 rw-p 00000000 00:00 0
7fff087e0000-7fff08801000 rw-p 00000000 00:00 0                          [stack]
7fff089c2000-7fff089c4000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

内存管理和使用

malloc

malloc()分配内存时：

如果用户分配的内存小于 128 KB，则通过 brk() 申请内存–在堆顶分配；
如果用户分配的内存大于 128 KB，则通过 mmap() 申请内存–从文件映射区域分配；

对于「malloc 申请的内存，free 释放内存会归还给操作系统吗？」：

malloc 通过 brk() 方式申请的内存，free 释放内存的时候，并不会把内存归还给操作系统，而是缓存在 malloc 的内存池中，待下次使用–小内存分配避免反复调用系统操作导致上下文切换，缺点是没回收容易导致内存碎片进而浪费内存。brk分配出来的内存在maps中显示有heap字样；
malloc 通过 mmap() 方式申请的内存，free 释放内存的时候，会把内存归还给操作系统，内存得到真正的释放。并且mmap分配的虚拟内存都是缺页状态的。

malloc和mmap

glibc中的malloc/free 负责向内核批发内存（不需要每次分配都真正地去调用内核态来分配），分配好的内存按大小分成不同的桶，每次malloc的时候实际到对应的桶上摘取对应的块(slab)就好，用完free的时候挂回去。

mmap映射内存

私有匿名映射常用于分配内存，也就是申请堆内存

分桶式内存管理比简单算法无论是在算法效率方面，还是在碎片控制方面都有很大的提升。但它的缺陷也很明显：区域内部的使用率不够高和动态扩展能力不够好。例如，4 字节的区域提前消耗完了，但 8 字节的空闲区域还有很多，此时就会面临两难选择，如果直接分配 8 字节的区域，则区域内部浪费就比较多，如果不分配，则明明还有空闲区域，却无法成功分配。

为了解决以上问题所以搞了buddy

node->zone->buddy->slab

假如需要分配一块 4 字节大小的空间，但是在 4 字节的 free list 上找不到空闲区域，系统就会往上找，假如 8 字节和 16 字节的 free list 中也没有空闲区域，就会一直向上找到 32 字节的 free list。

伙伴系统不会直接把 32 的空闲区域分配出去，因为这样做的话，会带来巨大的浪费。它会先把 32 字节分成两个 16 字节，把后边一个挂入到 16 字节的 free list 中。然后继续拆分前一半。前一半继续拆成两个 8 字节，再把后一半挂入到 8 字节的 free list，最后，把前一半 8 字节拿去分配，当然这里也要继续拆分成两个 4 字节的空闲区域，其中一个用于本次 malloc 分配，另一个则挂入到 4 字节的 free list。分配后的内存的状态如下所示：

查看zone

The zones are:

DMA is the low 16 MBytes of memory. At this point it exists for historical reasons; once upon what is now a long time ago, there was hardware that could only do DMA into this area of physical memory.
DMA32 exists only in 64-bit Linux; it is the low 4 GBytes of memory, more or less. It exists because the transition to large memory 64-bit machines has created a class of hardware that can only do DMA to the low 4 GBytes of memory.(This is where people mutter about everything old being new again.)
Normal is different on 32-bit and 64-bit machines. On 64-bit machines, it is all RAM from 4GB or so on upwards. On 32-bit machines it is all RAM from 16 MB to 896 MB for complex and somewhat historical reasons. Note that this implies that machines with a 64-bit kernel can have very small amounts of Normal memory unless they have significantly more than 4GB of RAM. For example, a 2 GB machine running a 64-bit kernel will have no Normal memory at all while a 4 GB machine will have only a tiny amount of it.
HighMem exists only on 32-bit Linux; it is all RAM above 896 MB, including RAM above 4 GB on sufficiently large machines.

每个zone下很多pages(大小为4K)，buddy就是这些Pages的组织管理者

# cat /proc/zoneinfo |grep Node -A10
Node 0, zone      DMA
  pages free     3972
        min      0
        low      0
        high     0
        scanned  0
        spanned  4095
        present  3993
        managed  3972
    nr_free_pages 3972
    nr_alloc_batch 0
--
Node 0, zone    DMA32
  pages free     361132
        min      30
        low      37
        high     45
        scanned  0
        spanned  1044480
        present  430773
        managed  361133
    nr_free_pages 361132
    nr_alloc_batch 8
--
Node 0, zone   Normal
  pages free     96017308
        min      16864
        low      21080
        high     25296
        scanned  0
        spanned  200736768
        present  200736768
        managed  197571780
    nr_free_pages 96017308
    nr_alloc_batch 3807
    
# free -g
              total        used        free      shared  buff/cache   available
Mem:            755         150         367           3         236         589
Swap:             0           0           0

每个页面大小是4K，很容易可以计算出每个 zone 的大小。比如对于上面 Node0 的 Normal， 197571780 * 4K/(1024*1024) = 753 GB。

dmidecode 可以查看到服务器上插着的所有内存条，也可以看到它是和哪个CPU直接连接的。每一个CPU以及和他直连的内存条组成了一个 node（节点）

/proc/buddyinfo

/proc/buddyinfo记录了可用内存的情况。

Normal那行之后的第二列表示： 643847*2^1*Page_Size(4K) ; 第三列表示： 357451*2^2*Page_Size(4K) ，高阶内存指的是2^3及更大的内存块。

#cat /proc/buddyinfo 
Node 0, zone      DMA      1      1      1      0      2      1      1      0      1      1      3 
Node 0, zone    DMA32      2      5      3      6      2      0      4      4      2      2    404 
Node 0, zone   Normal 243430 643847 357451  32531   9508   6159   3917   2960  17172   2633  22854

如果是多node机器：
#cat /proc/buddyinfo
Node 0, zone      DMA      4      6      3      2      3      3      1      1      2      3      1
Node 0, zone    DMA32   1607   1619   1552   1520   1370   1065    827    576    284    105     13
Node 0, zone   Normal  38337 145731 222145 199776 151452  91969  38086  10037   1762    104      1
Node 1, zone   Normal  21521 147637 299185 245533 172451  81459  19451   7198    579      3      0
Node 2, zone   Normal  68427 538670 446906 229138 123555  62539  21161   4407   1122    166    274
Node 3, zone   Normal  27353  54601 114355 123568 101892  79098  48610  21036   5021    475      6
Node 4, zone   Normal  45802  42758   8573 184548 148397  70540  20772   4147    381    148    109
Node 5, zone   Normal  19514  39583 140493 167901 134774  61888  22998   6326    457     32      0
Node 6, zone   Normal 104493 378362 355158  93138  12928   2248   1019    663    172     40    121
Node 7, zone   Normal  34185 256886 249560  95547  54526  51022  28180   9757   2038   1351    280

[root@hygon8 15:50 /root]
#numactl -H
available: 8 nodes (0-7)
node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
node 0 size: 64083 MB
node 0 free: 49838 MB
node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
node 1 size: 64480 MB
node 1 free: 43596 MB
node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
node 2 size: 64507 MB
node 2 free: 44216 MB
node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
node 3 size: 64507 MB
node 3 free: 51095 MB
node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100 101 102 103
node 4 size: 64507 MB
node 4 free: 32877 MB
node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109 110 111
node 5 size: 64507 MB
node 5 free: 33430 MB
node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117 118 119
node 6 size: 64507 MB
node 6 free: 14233 MB
node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125 126 127
node 7 size: 63483 MB
node 7 free: 36577 MB
node distances:
node   0   1   2   3   4   5   6   7
  0:  10  16  16  16  28  28  22  28
  1:  16  10  16  16  28  28  28  22
  2:  16  16  10  16  22  28  28  28
  3:  16  16  16  10  28  22  28  28
  4:  28  28  22  28  10  16  16  16
  5:  28  28  28  22  16  10  16  16
  6:  22  28  28  28  16  16  10  16
  7:  28  22  28  28  16  16  16  10
  
[root@hygon8 15:51 /root]
#cat /proc/pagetypeinfo
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    0, zone      DMA, type    Unmovable      1      2      1      1      3      2      0      0      1      0      0
Node    0, zone      DMA, type      Movable      0      0      0      0      0      0      0      0      0      3      1
Node    0, zone      DMA, type  Reclaimable      3      4      2      1      0      1      1      1      1      0      0
Node    0, zone      DMA, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone      DMA, type      Isolate      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone    DMA32, type    Unmovable    151    164    162    165    140     78     19      8      0      0      0
Node    0, zone    DMA32, type      Movable   1435   1430   1374   1335   1214    974    798    563    281     98     12
Node    0, zone    DMA32, type  Reclaimable     21     25     16     20     16     13     10      5      3      7      1
Node    0, zone    DMA32, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone    DMA32, type      Isolate      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone   Normal, type    Unmovable   4849   6607   4133   1629    654    121     15      3      0      0      0
Node    0, zone   Normal, type      Movable  21088 >100000 >100000 >100000 >100000  90231  37197   9379   1552     83      1
Node    0, zone   Normal, type  Reclaimable    153    139   3012   3113   2437   1617    874    655    210     21      0
Node    0, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 0, zone      DMA            1            6            1            0            0
Node 0, zone    DMA32           27          974           15            0            0
Node 0, zone   Normal          856        30173          709            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    1, zone   Normal, type    Unmovable    842   2898   2495   1316    490    102     23      1      2      0      0
Node    1, zone   Normal, type      Movable  22484 >100000 >100000 >100000 >100000  80084  18922   6889     48      4      0
Node    1, zone   Normal, type  Reclaimable      1   2022   3850   3534   2582   1273    506    308    529      0      0
Node    1, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    1, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 1, zone   Normal          810        31221          737            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    2, zone   Normal, type    Unmovable   2833   6802   3888   1636    329      3      1      2      0      0      0
Node    2, zone   Normal, type      Movable  72017 >100000 >100000 >100000 >100000  61710  20764   4242    841     55    239
Node    2, zone   Normal, type  Reclaimable    114      8   2056   2221   1544    826    396    163    281    111     35
Node    2, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    2, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 2, zone   Normal         1066        31063          639            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    3, zone   Normal, type    Unmovable   2508   6171   3802   1502    365     93     30      1      2      0      0
Node    3, zone   Normal, type      Movable  23396  48450 >100000 >100000  99802  77850  47910  20587   4796    428      5
Node    3, zone   Normal, type  Reclaimable     10      0    609   2111   1726   1155    670    448    223     46      1
Node    3, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    3, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 3, zone   Normal          768        31425          575            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    4, zone   Normal, type    Unmovable   3817   3739   1716    992    261     39      4      1      0      0      1
Node    4, zone   Normal, type      Movable  27857  39138   6875 >100000 >100000  70501  20752   4115    362     49    104
Node    4, zone   Normal, type  Reclaimable      1      8      3      5      0      0     16     31     19     97      4
Node    4, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    4, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 4, zone   Normal          712        31706          350            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    5, zone   Normal, type    Unmovable   4875   4728   3165   1202    464     67      3      0      0      0      0
Node    5, zone   Normal, type      Movable  18382  34874 >100000 >100000 >100000  61296  22711   6235    348     32      0
Node    5, zone   Normal, type  Reclaimable     16      0      1      7      2    525    284     91    109      0      0
Node    5, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    5, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 5, zone   Normal          736        31716          316            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    6, zone   Normal, type    Unmovable  10489   6842   2821    434    257     22      1      1      1      3      0
Node    6, zone   Normal, type      Movable  90841 >100000 >100000  92129  11336   1526    704    552    141     34    118
Node    6, zone   Normal, type  Reclaimable    434     41      0    576   1338    700    314    110     30      5      3
Node    6, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    6, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 6, zone   Normal          807        31686          275            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    7, zone   Normal, type    Unmovable   1516   1894   2285    908    633    121     16      7      4      2      0
Node    7, zone   Normal, type      Movable  18209 >100000 >100000  93283  52811  50349  27973   9703   2026   1341    248
Node    7, zone   Normal, type  Reclaimable      0      1      0   1341   1082    552    191     47      8      8     32
Node    7, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    7, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 7, zone   Normal         1262        31265          241            0            0

/proc/pagetypeinfo

cat /proc/pagetypeinfo, 你可以看到当前系统里伙伴系统里各个尺寸的可用连续内存块数量。unmovable pages是不可以被迁移的，比如slab等kmem都不可以被迁移，因为内核里面对这些内存很多情况下是通过指针来访问的，而不是通过页表，如果迁移的话，就会导致原来的指针访问出错。

当迁移类型为 Unmovable 的页面都聚集在 order < 3 时，说明内核 slab 碎片化严重

alloc_pages分配内存的时候就到上面对应大小的free_area的链表上寻找可用连续页面。alloc_pages是怎么工作的呢？我们举个简单的小例子。假如要申请8K-连续两个页框的内存。为了描述方便，我们先暂时忽略UNMOVEABLE、RELCLAIMABLE等不同类型

基于伙伴系统的内存分配中，有可能需要将大块内存拆分成两个小伙伴。在释放中，可能会将两个小伙伴合并再次组成更大块的连续内存。

伙伴系统中的伙伴指的是两个内存块，大小相同，地址连续，同属于一个大块区域。

对于应用来说基本分配单位是4K(开启大页后一般是2M)，对于内核来说4K有点浪费。所以内核又专门给自己定制了一个更精细的内存管理系统slab。

slab

对于内核运行中实际使用的对象来说，多大的对象都有。有的对象有1K多，但有的对象只有几百、甚至几十个字节。如果都直接分配一个 4K的页面来存储的话也太浪费了，所以伙伴系统并不能直接使用。

在伙伴系统之上，内核又给自己搞了一个专用的内存分配器，叫slab。

这个分配器最大的特点就是，一个slab内只分配特定大小、甚至是特定的对象。这样当一个对象释放内存后，另一个同类对象可以直接使用这块内存。通过这种办法极大地降低了碎片发生的几率。

#cat /proc/meminfo
Slab:             102076 kB
SReclaimable:      70816 kB
SUnreclaim:        31260 kB

Slab 内核通过slab分配管理的内存总数。
SReclaimable 内核通过slab分配的可回收的内存（例如dentry），通过echo 2 > /proc/sys/vm/drop_caches回收。
SUnreclaim 内核通过slab分配的不可回收的内存。

kmem cache

slabtop和/proc/slabinfo 查看cached使用情况主要是：pagecache（页面缓存）， dentries（目录缓存）， inodes

通过查看 /proc/slabinfo 我们可以查看到所有的 kmem cache。

slabtop 按占用内存从大往小进行排列。用来分析 slab 内存开销。

0d8a26db-3663-40af-b215-f8601ef23676.png (1388×1506)

无论是 /proc/slabinfo，还是 slabtop 命令的输出。里面都包含了每个 cache 中 slab的如下几个关键属性。

objsize：每个对象的大小
objperslab：一个 slab 里存放的对象的数量
pagesperslab：一个slab 占用的页面的数量，每个页面4K，这样也就能算出每个 slab 占用的内存大小。

比如如下TCP slabinfo中可以看到每个slab占用8(pagesperslab)个Page(8*4096=32768)，每个对象的大小是1984(objsize)，每个slab存放了16(objperslab)个对象. 那么1984 *16=31744，现在的空间基本用完，剩下接近1K，又放不下一个1984大小的对象，算是额外开销了。

#cat /proc/slabinfo |grep -E "active_objs|TCP"
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
tw_sock_TCP         5372   5728    256   32    2 : tunables    0    0    0 : slabdata    179    179      0
TCP                 6090   6144   1984   16    8 : tunables    0    0    0 : slabdata    384    384      0

内存分配和延迟

内存不够、脏页太多、碎片太多，都会导致分配失败，从而触发回收，导致卡顿。

系统中脏页过多引起 load 飙高

可以通过 sar -r 来观察系统中的脏页个数：

$ sar -r 1
07:30:01 PM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
09:20:01 PM   5681588   2137312     27.34         0   1807432    193016      2.47    534416   1310876         4
09:30:01 PM   5677564   2141336     27.39         0   1807500    204084      2.61    539192   1310884        20
09:40:01 PM   5679516   2139384     27.36         0   1807508    196696      2.52    536528   1310888        20
09:50:01 PM   5679548   2139352     27.36         0   1807516    196624      2.51    536152   1310892        24

kbdirty 就是系统中的脏页大小，它同样也是对 /proc/vmstat 中 nr_dirty 的解析。你可以通过调小如下设置来将系统脏页个数控制在一个合理范围:

vm.dirty_background_bytes = 0

vm.dirty_background_ratio = 10

vm.dirty_bytes = 0

vm.dirty_expire_centisecs = 3000

vm.dirty_ratio = 20

至于这些值调整大多少比较合适，也是因系统和业务的不同而异，我的建议也是一边调整一边观察，将这些值调整到业务可以容忍的程度就可以了，即在调整后需要观察业务的服务质量 (SLA)，要确保 SLA 在可接受范围内。调整的效果你可以通过 /proc/vmstat 来查看：

1
2
3

#grep "nr_dirty_" /proc/vmstat
nr_dirty_threshold 3071708
nr_dirty_background_threshold 1023902

在4.20的内核并且sar 的版本为12.3.3可以看到PSI（Pressure-Stall Information）

1 2	some avg10=45.49 avg60=10.23 avg300=5.41 total=76464318 full avg10=40.87 avg60=9.05 avg300=4.29 total=58141082

你需要重点关注 avg10 这一列，它表示最近 10s 内存的平均压力情况，如果它很大（比如大于 40）那 load 飙高大概率是由于内存压力，尤其是 Page Cache 的压力引起的。

容器中的内存回收

kswapd线程(每个node一个kswapd进程，负责本node）回收内存时，可以先对脏页进行回写（writeback）再进行回收，而直接内存回收只回收干净页。也叫同步回收.

直接内存回收是在当前进程的上下文中进行的，要等内存回收完成才能继续尝试进行分配，所以是阻塞了当前进程的执行，会导致响应延迟增加

如果是在容器里，也就是在某个子memory cgroup 中，那么在分配内存后，还有一个记账（charge）的步骤，就是要把这次分配的内存页记在某个memory cgroup的账上，这样才能控制这个容器里的进程所能使用的内存数量。

在开源社区的linux代码中，如果charge 失败，也就是说，当新分配的内存加上原先的usage超过了limit，就会触发内存回收，try_to_free_mem_cgroup_pages，这个也是同步回收，等同于直接内存回收（发生在当前进程的上下文忠），所以会对应用的响应造成影响（表现为卡顿）。

碎片化

内存碎片严重的话会导致系统hang很久(回收、压缩内存）

每个zone都有自己的min low high,如下，但是单位是page, 计算案例：

#cat /proc/zoneinfo  |grep "Node"
Node 0, zone      DMA
Node 0, zone    DMA32
Node 0, zone   Normal
Node 1, zone   Normal

#cat /proc/zoneinfo  |grep "Node 0, zone" -A10
Node 0, zone      DMA
  pages free     3975
        min      20
        low      25
        high     30
        scanned  0
        spanned  4095
        present  3996
        managed  3975
    nr_free_pages 3975
    nr_alloc_batch 5
--
Node 0, zone    DMA32
  pages free     382873
        min      2335
        low      2918
        high     3502
        scanned  0
        spanned  1044480
        present  513024
        managed  450639
    nr_free_pages 382873
    nr_alloc_batch 584
--
Node 0, zone   Normal
  pages free     11105097
        min      61463
        low      76828
        high     92194
        scanned  0
        spanned  12058624
        present  12058624
        managed  11859912
    nr_free_pages 11105097
    nr_alloc_batch 12344
    
    low = 5/4 * min
high = 3/2 * min


#T=min;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=499 MB

#T=low;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=624 MB

#T=high;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=802 MB

内存碎片化导致rt升高的诊断

判定方法如下：

运行 sar -B 观察 pgscand/s，其含义为每秒发生的直接内存回收次数，当在一段时间内持续大于 0 时，则应继续执行后续步骤进行排查；
运行 cat /sys/kernel/debug/extfrag/extfrag_index 观察内存碎片指数，重点关注 order >= 3 的碎片指数，当接近 1.000 时，表示碎片化严重，当接近 0 时表示内存不足；
运行 cat /proc/buddyinfo, cat /proc/pagetypeinfo 查看内存碎片情况，指标含义参考，同样关注 order >= 3 的剩余页面数量，pagetypeinfo 相比 buddyinfo 展示的信息更详细一些，根据迁移类型（伙伴系统通过迁移类型实现反碎片化）进行分组，需要注意的是，当迁移类型为 Unmovable 的页面都聚集在 order < 3 时，说明内核 slab 碎片化严重，我们需要结合其他工具来排查具体原因，在本文就不做过多介绍了；
对于 CentOS 7.6 等支持 BPF 的 kernel 也可以运行我们研发的 drsnoop，compactsnoop 工具对延迟进行定量分析，使用方法和解读方式请参考对应文档；
(Opt) 使用 ftrace 抓取 mm_page_alloc_extfrag 事件，观察因内存碎片从备用迁移类型“盗取”页面的信息。

一个阿里云ECS 因为宿主机碎片导致性能衰退的案例

LVS后面三个RS在同样压力流量下，其中一个节点CPU非常高，通过top看起来是所有操作都很慢，像是CPU被降频了一样，但是直接跑CPU Prime性能又没有问题

原因：ECS所在的宿主机内存碎片比较严重，导致分配到的内存主要是4K Page，在ECS中大页场景下会慢很多

通过 openssl speed aes-256-ige 能稳定重现 在大块的加密上慢很多

小块上性能一致，这也就是为什么算Prime性能没问题。导致慢只涉及到大块内存分配的场景，这里需要映射到宿主机，但是碎片多分配慢导致了问题。

如果reboot ECS的话实际只是就地重启ECS，仍然使用的reboot前分配好的宿主机内存，不会解决问题。重启ECS中的进程也不会解决问题，只有将ECS迁移到别的物理机（也就是通过控制台重启，会重新选择物理机）才有可能解决这个问题。

或者购买新的ECS机型（比如第6代之后ECS）能避免这个问题。

ECS内部没法查看到这个碎片，只能在宿主机上通过命令查看大页情况：

有问题NC上buddyinfo信息
$cat /proc/buddyinfo
Node 0, zone      DMA      1      1      0      0      2      1      1      0      1      1      3
Node 0, zone    DMA32     23     23     17     15     13      9      8      8      4      3    367
Node 0, zone   Normal 295291 298652 286048 266597 218191 156837  93156  45930  25856      0      0

最新建的vm，大页不多
$sudo cat /proc/9550/smaps |grep AnonHuge |awk '{sum+=$2}END{print sum}'
210944
------------------------
第一台正常ECS所在的NC
$cat /proc/buddyinfo
Node 0, zone      DMA      1      1      0      0      2      1      1      0      1      1      3
Node 0, zone    DMA32      7      5      5      9      8      4      6     10      5      5    366
Node 0, zone   Normal 203242 217888 184465 176280 148612 102122  55787  26642  24824      0      0

早期的vm，大页充足
$sudo cat /proc/87369/smaps |grep AnonHuge |awk '{sum+=$2}END{print sum}'
8275968

近期的vm，大页不够
$sudo cat /proc/22081/smaps |grep AnonHuge |awk '{sum+=$2}END{print sum}'
251904

$sudo cat /proc/44073/smaps |grep AnonHuge |awk '{sum+=$2}END{print sum}'
10240

内存使用分析

pmap

pmap -x 24282 | less
24282:   /usr/sbin/rsyslogd -n
Address           Kbytes     RSS   Dirty Mode  Mapping
000055ce1a99f000     596     580       0 r-x-- rsyslogd
000055ce1ac34000      12      12      12 r---- rsyslogd
000055ce1ac37000      28      28      28 rw--- rsyslogd
000055ce1ac3e000       4       4       4 rw---   [ anon ]
000055ce1c1f1000     364     204     204 rw---   [ anon ]
00007fff8b5a4000     132      20      20 rw---   [ stack ]
00007fff8b5e6000      12       0       0 r----   [ anon ]
00007fff8b5e9000       8       4       0 r-x--   [ anon ]
---------------- ------- ------- -------
total kB          620060   17252    3304

Address：占用内存的文件的内存起始地址。
Kbytes：占用内存的字节数。
RSS：实际占用内存大小。
Dirty：脏页大小。
Mapping：占用内存的文件，[anon] 为已分配的内存，[stack] 为程序堆栈

/proc/pid/

/proc/[pid]/ 下面与进程内存相关的文件主要有maps , smaps, status。
maps：文件可以查看某个进程的代码段、栈区、堆区、动态库、内核区对应的虚拟地址
smaps: 显示每个分区更详细的内存占用数据，能看到一个动态库被共享了几次
status: 包含了所有CPU活跃的信息，该文件中的所有值都是从系统启动开始累计到当前时刻

Java内存使用分析

创建1000个线程，ss为2M
java -XX:NativeMemoryTracking=detail -Xms10g -Xmx10g -Xmn5g -XX:ReservedCodeCacheSize=512m -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -XX:MaxDirectMemorySize=1g -Xss2048K ThreadPoolExample

分析结果：
#jcmd 81849 VM.native_memory summary
81849:

Native Memory Tracking:

Total: reserved=14737064KB, committed=13157168KB
-                 Java Heap (reserved=10485760KB, committed=10485760KB)
                            (mmap: reserved=10485760KB, committed=10485760KB)

-                     Class (reserved=1102016KB, committed=50112KB)
                            (classes #416)
                            (malloc=45248KB #1420)
                            (mmap: reserved=1056768KB, committed=4864KB)

//committed 已向OS提请分配，实际要到使用时page fault才会实际分配物理内存并在RSS中反应出来
-                    Thread (reserved=2134883KB, committed=2134883KB)//reserved还没分配,不能访问
                            (thread #1070) //1000个应用线程，加70个JVM native线程
                            (stack: reserved=2128820KB, committed=2128820KB) //需要2G多点
                            (malloc=3500KB #5390)
                            (arena=2563KB #2138)

-                      Code (reserved=532612KB, committed=4620KB)
                            (malloc=132KB #528)
                            (mmap: reserved=532480KB, committed=4488KB)

-                        GC (reserved=430421KB, committed=430421KB)
                            (malloc=50737KB #235)
                            (mmap: reserved=379684KB, committed=379684KB)

-                  Compiler (reserved=137KB, committed=137KB)
                            (malloc=6KB #53)
                            (arena=131KB #3)

-                  Internal (reserved=48901KB, committed=48901KB)
                            (malloc=48869KB #14030)
                            (mmap: reserved=32KB, committed=32KB)

-                    Symbol (reserved=1479KB, committed=1479KB)
                            (malloc=959KB #110)
                            (arena=520KB #1)

-    Native Memory Tracking (reserved=608KB, committed=608KB)
                            (malloc=193KB #2556)
                            (tracking overhead=415KB)

-               Arena Chunk (reserved=248KB, committed=248KB)
                            (malloc=248KB)

We can see two types of memory:

Reserved — the size which is guaranteed to be available by a host’s OS (but still not allocated and cannot be accessed by JVM) — it’s just a promise
Committed — already taken, accessible, and allocated by JVM

page fault

内核给用户态申请的内存，默认都只是一段虚拟地址空间而已，并没有分配真正的物理内存。在第一次读写的时候才触发物理内存的分配，这个过程叫做page fault。那么，为了访问到真正的物理内存，page fault的时候，就需要更新对应的page table了。

参考资料

https://www.atatech.org/articles/66885

https://cloud.tencent.com/developer/article/1087455

https://www.cnblogs.com/xiaolincoding/p/13719610.html

rsyslog占用内存高

https://sunsea.im/rsyslogd-systemd-journald-high-memory-solution.html

鸟哥 journald 介绍

说出来你可能不信，内核这家伙在内存的使用上给自己开了个小灶！

socket 与 slab dentry

如何在工作中学习--V2.0

发表于 2020-11-11 更新于 2026-04-06 分类于技巧

如何在工作中学习–V2.0

本文被网友翻译的英文版（medium 需要梯子）

先说一件值得思考的事情：高考的时候大家都是一样的教科书，同一个教室，同样的老师辅导，时间精力基本差不多，可是最后别人考的是清华北大或者一本，而你的实力只能考个三本，为什么？当然这里主要是智商的影响，那么其他因素呢？智商解决的问题能不能后天用其他方式来补位一下？

大家平时都看过很多方法论的文章，看的时候很爽觉得非常有用，但是一两周后基本还是老样子了。其中有很大一部分原因那些方法对脑力有要求、或者方法论比较空缺少落地的步骤。下文中描述的方式方法是不需要智商也能学会的，非常具体的。

关键问题点

为什么你的知识积累不了？

有些知识看过就忘、忘了再看，实际碰到问题还是联系不上这个知识，这其实是知识的积累出了问题，没有深入的理解自然就不能灵活运用，也就谈不上解决问题了。这跟大家一起看相同的高考教科书但是高考结果不一样是一个原因。问题出在了理解上，每个人的理解能力不一样（智商），绝大多数人对知识的理解要靠不断地实践（做题）来巩固。

同样实践效果不一样？

同样工作一年碰到了10个问题（或者说做了10套高考模拟试卷），但是结果不一样，那是因为在实践过程中方法不够好。或者说你对你为什么做对了、为什么做错了没有去复盘

假如碰到一个问题，身边的同事解决了，而我解决不了。那么我就去想这个问题他是怎么解决的，他看到这个问题后的逻辑和思考是怎么样的，有哪些知识指导了他这么逻辑推理，这些知识哪些我也知道但是我没有想到这么去运用推理（说明我对这个知识理解的不到位导致灵活运用缺乏）；这些知识中又有哪些是我不知道的（知识缺乏，没什么好说的快去Google什么学习下–有场景案例和目的加持，学习理解起来更快）。

等你把这个问题基本按照你同事掌握的知识和逻辑推理想明白后，需要再去琢磨一下他的逻辑推理解题思路中有没有不对的，有没有啰嗦的地方，有没有更直接的方式（对知识更好地运用）。

我相信每个问题都这么去实践的话就不应该再抱怨灵活运用、举一反三，同时知识也积累下来了，这种场景下积累到的知识是不会那么容易忘记的。

这就是向身边的牛人学习，同时很快超过他的办法。这就是为什么高考前你做了10套模拟题还不如其他人做一套的效果好

知识+逻辑基本等于你的能力，知识让你知道那个东西，逻辑让你把东西和问题联系起来

这里的问题你可以理解成方案、架构、设计等

系统化的知识哪里来？

知识之间是可以联系起来的并且像一颗大树一样自我生长，但是当你都没理解透彻，自然没法产生联系，也就不能够自我生长了。

真正掌握好的知识点会慢慢生长连接最终组成一张大网

但是我们最容易陷入的就是掌握的深度、系统化（工作中碎片时间过多，学校里缺少时间）不够，所以一个知识点每次碰到花半个小时学习下来觉得掌握了，但是3个月后就又没印象了。总是感觉自己在懵懵懂懂中，或者一个领域学起来总是不得要领，根本的原因还是在于：宏观整体大图了解不够（缺乏体系，每次都是盲人摸象）；关键知识点深度不够，理解不透彻，这些关键点就是这个领域的骨架、支点、抓手。缺了抓手自然不能生长，缺了宏观大图容易误入歧途。

我们有时候发现自己在某个领域学起来特别快，但是换个领域就总是不得要领，问题出在了上面，即使花再多时间也是徒然。这也就是为什么学霸看两个小时的课本比你看两天效果还好，感受下来还觉得别人好聪明，是不是智商比我高啊。

所以新进入一个领域的时候要去找他的大图和抓手。

好的同事总是能很轻易地把这个大图交给你，再顺便给你几个抓手，你就基本入门了，这就是培训的魅力，这种情况肯定比自学效率高多了。但是目前绝大部分的培训都做不到这点

好的逻辑又怎么来？

实践、复盘

讲个前同事的故事

有一个前同事是5Q过来的，负责技术（所有解决不了的问题都找他），这位同学从chinaren出道，跟着王兴一块创业5Q，5Q在学校靠鸡腿打下大片市场，最后被陈一舟的校内收购（据说被收购后5Q的好多技术都走了，最后王兴硬是呆在校内网把合约上的所有钱都拿到了）。这位同学让我最佩服的解决问题的能力，好多问题其实他也不一定就擅长，但是他就是有本事通过Help、Google不停地验证尝试就把一个不熟悉的问题给解决了，这是我最羡慕的能力，在后面的职业生涯中一直不停地往这个方面尝试。

应用刚启动连接到数据库的时候比较慢，但又不是慢查询

这位同学的解决办法是通过tcpdump来分析网络包，看网络包的时间戳和网络包的内容，然后找到了具体卡在了哪里。
如果是专业的DBA可能会通过show processlist 看具体连接在做什么，比如看到这些连接状态是 authentication 状态，然后再通过Google或者对这个状态的理解知道创建连接的时候MySQL需要反查IP、域名这里比较耗时，通过配置参数 skip-name-resolve 跳过去就好了。
如果是MySQL的老司机，一上来就知道连接慢的话跟 skip-name-resolve 关系最大。

在我眼里这三种方式都解决了问题，最后一种最快但是纯靠积累和经验，换个问题也许就不灵了；第一种方式是最牛逼和通用的，只需要最少的知识就把问题解决了。

我当时跟着他从sudo、ls等linux命令开始学起。当然我不会轻易去打搅他问他，每次碰到问题我尽量让他在我的电脑上来操作，解决后我再自己复盘，通过history调出他的所有操作记录，看他在我的电脑上用Google搜啥了，然后一个个去学习分析他每个动作，去想他为什么搜这个关键字，复盘完还有不懂的再到他面前跟他面对面的讨论他为什么要这么做，指导他这么做的知识和逻辑又是什么。

有哪些好的行为帮你更好地掌握知识

笔记+写博客

看东西的时候要做笔记，要不当时看得再爽也很容易忘记，我们需要反复复习来加深印象和理解，复习的根据就是笔记（不可能再完整又看一次），笔记整理出里面的要点和你的盲点。

一段时间后把相关的笔记整理成一篇体系性的博客文章，这样既加深了理解又系统化了相关知识。以后再看到跟这篇博客相关的案例、知识点时不断地更新博客（完善你的知识点）

场景式学习、体感的来源、面对问题学习

前面提到的对知识的深入理解这有点空，如何才能做到深入理解？

举个学习TCP三次握手例子

经历稍微丰富点的工程师都觉得TCP三次握手看过很多次、很多篇文章了，但是文章写得再好似乎当时理解了，但是总是过几个月就忘了或者一看就懂，过一阵子被人一问就模模糊糊了，或者两个为什么就答不上了，自己都觉得自己的回答是在猜或者不确定

为什么会这样呢？而学其它知识就好通畅多了，我觉得这里最主要的是我们对TCP缺乏体感，比如没有几个工程师去看过TCP握手的代码，也没法想象真正的TCP握手是如何在电脑里运作的（打电话能给你一些类似的体感，但是细节覆盖面不够）。

如果这个时候你一边学习的时候一边再用wireshark抓包看看三次握手具体在干什么，比抽象的描述实在多了，你能看到具体握手的一来一回，并且看到一来一回带了哪些内容，这些内容又是用来做什么、为什么要带，这个时候你再去看别人讲解的理论顿时会觉得好理解多了，以后也很难忘记。

但是这里很多人执行能力不强，想去抓包，但是觉得要下载安装wireshark，要学习wireshark就放弃了。只看不动手当然是最舒适的，但是这个最舒适给了你在学习的假象，没有结果。

这是不是跟你要解决一个难题非常像，这个难题需要你去做很多事，比如下载源代码（翻不了墙，放弃）；比如要编译（还要去学习那些编译参数，放弃）；比如要搭建环境（太琐屑，放弃）。你看这中间九九八十一难你放弃了一难都取不了真经。这也是为什么同样学习、同样的问题，他能学会，他能解决，你不可以。

再来看一个解决问题的例子

会员系统双11优化这个问题对我来说，我是个外来者，完全不懂这里面的部署架构、业务逻辑。但是在问题的关键地方（会员认为自己没问题–压力测试正常的；淘宝API更是认为自己没问题，alimonitor监控显示正常），结果就是会员的同学说我们没有问题，淘宝API肯定有问题，然后就不去思考自己这边可能出问题的环节了。思想上已经甩包了，那么即使再去review流程、环节也就不会那么仔细，自然更是发现不了问题了。

但是我的经验告诉我要有证据地甩包，或者说拿着证据优雅地甩包，这迫使我去找更多的细节证据（证据要给力哦，不能让人家拍回来）。如果我是这么说的，这个问题在淘宝API这里，你看理由是…………，我做了这些实验，看到了这些东东。那么淘宝API那边想要证明我的理由错了就会更积极地去找一些数据。

事实上我就是做这些实验找证据过程中发现了会员的问题，这就是态度、执行力、知识、逻辑能力综合下来拿到的一个结果。我最不喜欢的一句话就是我的程序没问题，因为我的逻辑是这样的，不会错的。你当然不会写你知道的错误逻辑，程序之所以有错误都是在你的逻辑、意料之外的东西。有很多次一堆人电话会议中扯皮的时候，我一般把电话静音了，直接上去人肉一个个过对方的逻辑，一般来说电话会议还没有结束我就给出来对方逻辑之外的东西。

钉子式学习方法和系统性学习方法

系统性学习方法就是想掌握MySQL，那么搞几本MySQL专著和MySQL 官方DOC看下来，一般课程设计的好的话还是比较容易掌握下来，绝大部分时候都是这种学习方法，可是在种学习方法的问题在于学完后当时看着似乎理解了，但是很容易忘记，一片一片地系统性的忘记，并且缺少应用能力（理解不深）。这是因为一般人对知识的理解没那么容易真正理解（掌握或者说应用）。

钉子式的学习方式，就是在一大片知识中打入几个桩，反复演练将这个桩不停地夯实，夯稳，做到在这个知识点上用通俗的语言跟小白都能讲明白，然后再这几个桩中间发散像星星之火燎原一样把整个一片知识都掌握下来。这种学习方法的缺点就是很难找到一片知识点的这个点，然后没有很好整合的话知识过于零散。

钉子式学习方法看着慢但是因为这样掌握的更透彻和牢固实际最终反而快。

我们常说的一个人很聪明，就是指系统性的看看书就都理解了，是真的理解那种，还能灵活运用，但是大多数普通人就不是这样的，看完书似乎理解了，实际几周后基本都忘记了，真正实践需要用的时候还是用不好。

举个Open-SSH的例子

为了做通 SSH 的免密登陆，大家都需要用到 ssh-keygen/ssh-copy-id，如果我们把这两个命令当一个小的钉子的话，会去了解ssh-keygen做了啥（生成了密钥对），或者ssh-copy-id 的时候报错了（原来是需要秘钥对），然后将 ssh-keygen 生成的pub key复制到server的~/.ssh/authorized_keys 中。

然后你应该会对这个原理要有一些理解（更大的钉子），于是理解了密钥对，和ssh验证的流程，顺便学会怎么看ssh debug信息，那么接下来网络上各种ssh攻略、各种ssh卡顿的解决都是很简单的事情了。

比如你通过SSH可以解决这些问题：

免密登陆
ssh卡顿
怎么去掉ssh的时候需要手工多输入yes
我的ssh怎么很快就断掉了
我怎么样才能一次通过跳板机ssh到目标机器
我怎么样通过ssh科学上网
我的ansible（底层批量命令都是基于ssh）怎么这么多问题，到底是为什么
我的git怎么报网络错误了
X11 forward我怎么配置不好
https为什么需要随机数加密，还需要签名
…………

这些问题都是一步步在扩大ssh的外延，让这个钉子变成一个巨大的桩。

然后就会学习到一些高级一些的ssh配置，比如干掉经常ssh的时候要yes一下(StrictHostKeyChecking=no), 或者怎么配置一下ssh就不会断线了（ServerAliveInterval=15），或者将 ssh跳板机->ssh server的过程做成 ssh server一步就可以了(ProxyCommand)，进而发现用 ssh的ProxyCommand很容易科学上网了，或者git有问题的时候轻而易举地把ssh debug打开，对git进行debug了……

这基本都还是ssh的本质范围，像ansible、git在底层都是依赖ssh来通讯的，你会发现学、调试X11、ansible和git简直太容易了。

另外理解了ssh的秘钥对，也就理解了非对称加密，同时也很容易理解https流程（SSL），同时知道对称和非对称加密各自的优缺点，SSL为什么需要用到这两种加密算法了。

你看一个简单日常的知识我们只要沿着它用钉子精神，深挖细挖你就会发现知识之间的连接，这个小小的知识点成为你知识体系的一根结实的柱子。

我见过太多的老的工程师、年轻的工程师，天天在那里ssh 密码，ssh 跳板机，ssh 目标机，一小会ssh断了，重来一遍；或者ssh后卡住了，等吧……

在这个问题上表现得没有求知欲、没有探索精神、没有一次把问题搞定的魄力，所以就习惯了

空洞的口号

很多老师和文章都会教大家：举一反三、灵活运用、活学活用、多做多练。但是只有这些口号是没法落地的，落地的基本步骤就是前面提到的，却总是被忽视了。

什么是工程效率，什么是知识效率

有些人纯看理论就能掌握好一门技能，还能举一反三，这是知识效率，这种人非常少；

大多数普通人都是看点知识然后结合实践来强化理论，要经过反反复复才能比较好地掌握一个知识，这就是工程效率，讲究技巧、工具来达到目的。

肯定知识效率最牛逼，但是拥有这种技能的人毕竟非常少（天生的高智商吧）。从小我们周边那种不怎么学的学霸型基本都是这类，这种学霸都还能触类旁通非常快的掌握一个新知识，非常气人。剩下的绝大部分只能拼时间+方法+总结等也能掌握一些知识

非常遗憾我就是工程效率型，只能羡慕那些知识效率型的学霸。但是这事又不能独立看待有些人在某些方向上是工程效率型，有些方向就又是知识效率型（有一种知识效率型是你掌握的实在太多也就比较容易触类旁通了，这算灰色知识效率型）

使劲挖掘自己在知识效率型方面的能力吧，两者之间当然没有明显的界限，知识积累多了逻辑训练好了在别人看来你的智商就高了

知识分两种

一种是通用知识（不是说对所有人通用，而是说在一个专业领域去到哪个公司都能通用）；另外一种是跟业务公司绑定的特定知识

通用知识没有任何疑问碰到后要非常饥渴地扑上去掌握他们（受益终生，这还有什么疑问吗？）。对于特定知识就要看你对业务需要掌握的深度了，肯定也是需要掌握一些的，特定知识掌握好的一般在公司里混的也会比较好。

一个具体知识体系里面又有一些核心知识点（抓手、essential knowledge），也就是掌握可以快速帮你膨胀、延伸到其他相关知识的知识点。

还有一些知识、工具一旦掌握就能帮你贯穿、具象、理解别的知识点，比如网络知识体系中的wireshark；理工科中的数学；知识体系中的学习方法、行为方式。我们要多去发现这些知识、工具（how？）

哪些品质能够决定一个人学习好坏

排在第一名的品质是复盘、总结能力

简单的说，这个能力就是这个孩子心里是否有个“小教练”，能够每次跳脱出当前任务，帮助自己分析，失败在哪里，成功在哪里，如何进阶，如何训练等等。

举几个例子：

如果写不出作文，这个“小教练”能告诉孩子，是没有素材，还是文字能力不强。

如果是文字能力不强，应该如何训练（是造句，还是拆段落）
如果数学题做不出来，这个“小教练”能告诉孩子，我的弱点在哪里，哪个类型题我有重大问题，是因为哪里没有理解和打通。

有内化的“自我教练”，这个能力系数是1.67。也就是其他能力相当，学习效果可以翻1.67倍。

排在第二名的是建构能力。简单的说是逻辑推理，做事顺序等等

在内心“小教练”能把问题进行拆解之后，建构能力能把这些问题进行排序，应该怎么做更合理。

最终怎么把训练步骤整合。遇见一个问题，先干什么，再干什么等等。

有很强的顺序能力，系数为1.44。也就是其他能力相当，学习效果可以翻1.44倍。

排在第三名的能力是智商和过去成绩

这个毋庸置疑，聪明做事就会简单一些。平均效应系数为0.67。

也就是说，其他能力相当，智商高和过去成绩好，学习效果提升67%

智商重要程度应该比这里更高，但是实际高智商的太少，大多都是因为基础知识好给人产生了智商高的误解！

排在第四名的能力是自我驱动力

简单的说，知道自己为什么学习，能够自我鼓励，遇见失败能抗挫，有很强的心理驱动力。

平均效应系数为0.48。也就是说，其他能力相当，有自我驱动力的人，学习效果提升48%。

排在第五名的才是集中注意力

也就是说，注意力强。注意力对学习影响，并没有很多家长想象的那么大。

注意力的平均效应系数为0.44

也就是说，其他能力相当，注意力好的孩子，效果能提升44%

———总结一下——-

学习提升的个人因素：

自我分析，自我教练的元认知能力》逻辑排序与制定计划的建构能力》智商和过去成绩》自我驱动力》集中注意力。

很多家长痴迷于“专注力”。当然专注力是一个效应量很强的学习力，但是从整体数据看，对学习的提升效果，仅仅排到第五名。

帮助孩子建立元认知能力和建构能力的培训，才能给他们对终身学习有帮助的技能包

以上缺少了对方法的落地执行能力的评估，实际这是影响最大的

为什么一直努力却没有结果

人生不是走斜坡，你持续走就可以走到巅峰；人生像走阶梯（有时候需要跳上台阶），每一阶有每一阶的难点，学物理有物理的难点，学漫画有漫画的难点，你没有克服难点，再怎么努力都是原地跳。所以当你克服难点，你跳上去就不会下来了。

这里的克服难点可以理解成真正掌握知识点，大多时候只是似是而非，所以一直在假忙碌、假学习，只有真正掌握后才像是上了个台阶。

这句话本身就是对知识的具象化理解，本来要描述的是有些人很容易达到目的、有些人则很难，我们很容易归结到天赋等原因，但是还是不能完全理解这个事情，知道天赋差异也不会帮助到我们跳楼梯，而这句话给出了一个形象的描述，一下子就会记住并在日常中尽量尝试跳上去和脱离假忙碌的状态。

在上述截图中，温伯格拿他自己玩弹子球游戏的经验，来描述”跃迁模式”。
　为啥在跃迁之前会出现一个【低谷】捏？温伯格认为：要想提升到一个新的 level，你需要放弃某些你擅长的技能，然后尝试你所【不】擅长的技能。
温伯格以他的弹子球游戏举例说：
为了得到更高的分数，他必须放弃以前熟悉的【低】难度技巧，转而尝试某种【高】难度技巧。在练习高难度技巧的过程中，他的分数会跌得比原先更低（也就是截图中下凹的低谷）。经过了一段时间的练习，当他掌握了高难度技巧，他的游戏得分就突然飞跃到一个新的 level。

举三反一--从理论知识到实际问题的推导

发表于 2020-11-02 更新于 2025-11-16 分类于 TCP

举三反一–从理论知识到实际问题的推导

怎么样才能获取举三反一的秘籍，普通人为什么要案例来深化对理论知识的理解。

什么是工程效率，什么是知识效率

有些人纯看理论就能掌握好一门技能，还能举三反一，这是知识效率，这种人非常少；

大多数普通人都是看点知识然后结合实践来强化理解理论，要经过反反复复才能比较好地掌握一个知识，这就是工程效率，讲究技巧、工具来达到目的。

对于费曼（参考费曼学习法）这样的聪明人就是很容易看到一个理论知识就能理解这个理论知识背后的本质。

肯定知识效率最牛逼，但是拥有这种能力的人毕竟非常少。从小我们周边那种不怎么学的学霸型基本都是这类，这种学霸都还能触类旁通非常快地掌握一个新知识。剩下的绝大部分只能拼时间(刷题)+方法+总结等也能掌握一些知识

但是这事又不能独立看待有些人在某些方向上是工程效率型，有些方向就又是知识效率型（有一种知识效率型是你掌握的实在太多也就比较容易触类旁通了，这算灰色知识效率型）

使劲挖掘自己在知识效率型方面的能力吧，即使灰色地带也行啊。

接下来看看TCP状态中的CLOSE_WAIT状态的含义

先看TCP连接状态图

这是网络、书本上凡是描述TCP状态一定会出现的状态图，理论上看这个图能解决任何TCP状态问题。

反复看这个图的右下部分的CLOSE_WAIT ，从这个图里可以得到如下结论：

CLOSE_WAIT是被动关闭端在等待应用进程的关闭

基本上这一结论要能帮助解决所有CLOSE_WAIT相关的问题，如果不能说明对这个知识点理解的不够。

server端大量close_wait案例

用实际案例来检查自己对CLOSE_WAIT 理论（CLOSE_WAIT是被动关闭端在等待应用进程的关闭）的掌握 – 能不能用这个结论来解决实际问题。同时也可以看看自己从知识到问题的推理能力（跟前面的知识效率呼应一下）。

问题描述：

服务端出现大量CLOSE_WAIT 个数正好等于somaxconn（调整somaxconn大小后 CLOSE_WAIT 也会跟着变成一样的值）

根据这个描述先不要往下看，自己推理分析下可能的原因。

我的推理如下：

从这里看起来，client跟server成功建立了somaxconn个连接（somaxconn小于backlog，所以accept queue只有这么大），但是应用没有accept这个连接，导致这些连接一直在accept queue中。但是这些连接的状态已经是ESTABLISHED了，也就是client可以发送数据了，数据发送到server后OS ack了，并放在os的tcp buffer中，应用一直没有accept也就没法读取数据。client于是发送fin（可能是超时、也可能是简单发送数据任务完成了得结束连接），这时Server上这个连接变成了CLOSE_WAIT .

也就是从开始到结束这些连接都在accept queue中，没有被应用accept，很快他们又因为client 发送 fin 包变成了CLOSE_WAIT ，所以始终看到的是服务端出现大量CLOSE_WAIT 并且个数正好等于somaxconn（调整somaxconn后 CLOSE_WAIT 也会跟着变成一样的值）。

如下图所示，在连接进入accept queue后状态就是ESTABLISED了，也就是可以正常收发数据和fin了。client是感知不到server是否accept()了，只是发了数据后server的os代为保存在OS的TCP buffer中，因为应用没来取自然在CLOSE_WAIT 后应用也没有close()，所以一直维持CLOSE_WAIT 。

得检查server 应用为什么没有accept。

Recv-Q和Send-Q

如上是老司机的思路靠经验缺省了一些理论推理，缺省还是对理论理解不够，这个分析抓住了大量CLOSE_WAIT 个数正好等于somaxconn（调整somaxconn后 CLOSE_WAIT 也会跟着变成一样的值）但是没有抓住 CLOSE_WAIT 背后的核心原因

更简单的推理

如果没有任何实战经验，只看上面的状态图的学霸应该是这样推理的：

看到server上有大量的CLOSE_WAIT说明client主动断开了连接，server的OS收到client 发的fin，并回复了ack，这个过程不需要应用感知，进而连接从ESTABLISHED进入CLOSE_WAIT，此时在等待server上的应用调用close连关闭连接（处理完所有收发数据后才会调close()） —- 结论：server上的应用一直卡着没有调close().

同时这里很奇怪的现象：服务端出现大量CLOSE_WAIT 个数正好等于somaxconn，进而可以猜测是不是连接建立后很快accept队列满了（应用也没有accept() ), 导致大量CLOSE_WAIT 个数正好等于somaxconn —- 结论： server 上的应用不但没有调close(), 连close() 前面必须调用 accept() 都一直卡着没调（这个结论需要有accept()队列的理论知识)

从上面两个结论可以清楚地看到 server的应用卡住了

实际结论：

这个case的最终原因是因为OS的open files设置的是1024,达到了上限，进而导致server不能accept，但这个时候的tcp连接状态已经是ESTABLISHED了（这个状态变换是取决于内核收发包，跟应用是否accept()无关）。

同时从这里可以推断 netstat 即使看到一个tcp连接状态是ESTABLISHED也不能代表占用了 open files句柄。此时client可以正常发送数据了，只是应用服务在accept之前没法receive数据和close连接。

这个结论的图解如下：

假如全连接队列满了，握手第三步后对于client端来说是无法感知的，client端只需要回复ack后这个连接对于client端就是ESTABLISHED了，这时client是可以发送数据的。但是Server会扔掉收到的ack，回复syn+ack给client。

如果全连接队列没满，但是fd不够，那么在Server端这个Socket也是ESTABLISHED，但是只是暂存在全连接队列中，等待应用来accept，这个时候client端同样无法感知这个连接没有被accept，client是可以发送数据的，这个数据会保存在tcp receive memory buffer中，等到accept后再给应用。

如果自己无法得到上面的分析，那么再来看看如果把 CLOSE_WAIT 状态更细化地分析下(类似有老师帮你把知识点揉开跟实际案例联系下—-未必是上面的案例)，看完后再来分析下上面的案例。

CLOSE_WAIT 状态拆解

通常，CLOSE_WAIT 状态在服务器停留时间很短，如果你发现大量的 CLOSE_WAIT 状态，那么就意味着被动关闭的一方没有及时发出 FIN 包，一般有如下几种可能：

程序问题：如果代码层面忘记了 close 相应的 socket 连接，那么自然不会发出 FIN 包，从而导致 CLOSE_WAIT 累积；或者代码不严谨，出现死循环之类的问题，导致即便后面写了 close 也永远执行不到。
响应太慢或者超时设置过小：如果连接双方不和谐，一方不耐烦直接 timeout，另一方却还在忙于耗时逻辑，就会导致 close 被延后。响应太慢是首要问题，不过换个角度看，也可能是 timeout 设置过小。
BACKLOG 太大：此处的 backlog 不是 syn backlog，而是 accept 的 backlog，如果 backlog 太大的话，设想突然遭遇大访问量的话，即便响应速度不慢，也可能出现来不及消费的情况，导致多余的请求还在队列里就被对方关闭了。

如果你通过「netstat -ant」或者「ss -ant」命令发现了很多 CLOSE_WAIT 连接，请注意结果中的「Recv-Q」和「Local Address」字段，通常「Recv-Q」会不为空，它表示应用还没来得及接收数据，而「Local Address」表示哪个地址和端口有问题，我们可以通过「lsof -i:」来确认端口对应运行的是什么程序以及它的进程号是多少。

如果是我们自己写的一些程序，比如用 HttpClient 自定义的蜘蛛，那么八九不离十是程序问题，如果是一些使用广泛的程序，比如 Tomcat 之类的，那么更可能是响应速度太慢或者 timeout 设置太小或者 BACKLOG 设置过大导致的故障。

看完这段 CLOSE_WAIT 更具体深入点的分析后再来分析上面的案例看看，能否推导得到正确的结论。

一些疑问

连接都没有被accept(), client端就能发送数据了？

答：是的。只要这个连接在OS看来是ESTABLISHED的了就可以，因为握手、接收数据都是由内核完成的，内核收到数据后会先将数据放在内核的tcp buffer中，然后os回复ack。另外三次握手之后client端是没法知道server端是否accept()了。

CLOSE_WAIT与accept queue有关系吗？

答：没有关系。只是本案例中因为open files不够了，影响了应用accept(), 导致accept queue满了，同时因为即使应用不accept（三次握手后，server端是否accept client端无法感知），client也能发送数据和发 fin断连接，这些响应都是os来负责，跟上层应用没关系，连接从握手到ESTABLISHED再到CLOSE_WAIT都不需要fd，也不需要应用参与。CLOSE_WAIT只跟应用不调 close() 有关系。

CLOSE_WAIT与accept queue为什么刚好一致并且联动了？

答：这里他们的数量刚好一致是因为所有新建连接都没有accept，堵在queue中。同时client发现问题后把所有连接都fin了，也就是所有queue中的连接从来没有被accept过，但是他们都是ESTABLISHED，过一阵子之后client端发了fin所以所有accept queue中的连接又变成了 CLOSE_WAIT, 所以二者刚好一致并且联动了

openfiles和accept()的关系是？

答：accept()的时候才会创建文件句柄，消耗openfiles

一个连接如果在accept queue中了，但是还没有被应用 accept，那么这个时候在server上看这个连接的状态他是ESTABLISHED的吗？

答：是

如果server的os参数 open files到了上限（就是os没法打开新的文件句柄了）会导致这个accept queue中的连接一直没法被accept对吗？

答：对

如果通过gdb attach 应用进程，故意让进程accept，这个时候client还能连上应用吗？

答：能，这个时候在client和server两边看到的连接状态都是 ESTABLISHED，只是Server上的全连接队列占用加1。连接握手并切换到ESTABLISHED状态都是由OS来负责的，应用不参与，ESTABLISHED后应用才能accept，进而收发数据。也就是能放入到全连接队列里面的连接肯定都是 ESTABLISHED 状态的了

接着上面的问题，如果新连接继续连接进而全连接队列满了呢？

答：那就连不上了，server端的OS因为全连接队列满了直接扔掉第一个syn握手包，这个时候连接在client端是SYN_SENT，Server端没有这个连接，这是因为syn到server端就直接被OS drop 了。

1
2
3

//如下图，本机测试，只有一个client端发起的syn_send, 3306的server端没有任何连接
$netstat -antp  |grep -i 127.0.0.1:3306
tcp     0   1 127.0.0.1:61106      127.0.0.1:3306    SYN_SENT    21352/telnet

能进入到accept queue中的连接都是 ESTABLISHED，不管用户态有没有accept，用户态accept后队列大小减1

如果一个连接握手成功进入到accept queue但是应用accept前被对方RESET了呢？

答：如果此时收到对方的RESET了，那么OS会释放这个连接。但是内核认为所有 listen 到的连接, 必须要 accept 走, 因为用户有权利知道有过这么一个连接存在过。所以OS不会到全连接队列拿掉这个连接，全连接队列数量也不会减1，直到应用accept这个连接，然后read/write才发现这个连接断开了，报communication failure异常

什么时候连接状态变成 ESTABLISHED

三次握手成功就变成 ESTABLISHED 了，不需要用户态来accept，如果握手第三步的时候OS发现全连接队列满了，这时OS会扔掉这个第三次握手ack，并重传握手第二步的syn+ack, 在OS端这个连接还是 SYN_RECV 状态的，但是client端是 ESTABLISHED状态的了。

这是在4000（tearbase）端口上全连接队列没满，但是应用不再accept了，nc用12346端口去连4000（tearbase）端口的结果

# netstat -at |grep ":12346 "
tcp   0      0 dcep-blockchain-1:12346 dcep-blockchai:terabase ESTABLISHED //server
tcp   0      0 dcep-blockchai:terabase dcep-blockchain-1:12346 ESTABLISHED //client
[root@dcep-blockchain-1 cfl-sm2-sm3]# ss -lt
State       Recv-Q Send-Q      Local Address:Port         Peer Address:Port   
LISTEN      73     1024            *:terabase                 *:*

这是在4000（tearbase）端口上全连接队列满掉后，nc用12346端口去连4000（tearbase）端口的结果

# netstat -at |grep ":12346 "  
tcp   0      0 dcep-blockchai:terabase dcep-blockchain-1:12346 SYN_RECV    //server
tcp   0      0 dcep-blockchain-1:12346 dcep-blockchai:terabase ESTABLISHED //client
# ss -lt
State       Recv-Q Send-Q      Local Address:Port       Peer Address:Port   
LISTEN      1025   1024             *:terabase              *:*