关于本博

发表于 2117-06-07 更新于 2025-11-16 分类于 others

关于本博

find me on twitter: @plantegg

知识星球：https://t.zsxq.com/0cSFEUh2J

Github: 欢迎star

关注基础知识，一次把问题搞清楚，从案例出发深挖相关知识。

以前觉得自己一看就懂，实际是一问就打鼓，一用就糊涂。所以现在开始记录并总结再联系案例，一般是先把零散知识记录下来（看到过），慢慢地相关知识积累更多，直到碰到实践案例或是有点领悟到于是发现这块知识可以整理成一篇系统些的文章（基本快懂了）。

“技术变化太快，容易过时”，我的看法是网络知识、操作系统、计算机原理等核心概念知识的寿命会比你的职业生涯还长。这些都是40岁之后还会还会很有用

如何在工作中学习所有方法我都记录在这篇文章中了，希望对你能有所帮助。

所有新文章从这里可以看到，即使再简单的一篇总结我可以持续总结三五年，有新的发现、感悟都是直接在原文上增减，不会发表新的文章。

为什么写博客而不是公众号，我见过20年前的互联网，深度依赖搜索引擎，所以还是喜欢博客。另外技术类文章更适合电脑阅读（随时摘录、实验）

精华文章推荐

在2010年前后MySQL、PG、Oracle数据库在使用NUMA的时候碰到了性能问题，流传最广的这篇 MySQL – The MySQL “swap insanity” problem and the effects of the NUMA architecture http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/ 文章描述了性能问题的原因(文章中把原因找错了)以及解决方案：关闭NUMA。实际这个原因是kernel实现的一个低级bug，这个Bug在2014年修复了https://github.com/torvalds/linux/commit/4f9b16a64753d0bb607454347036dc997fd03b82，但是修复这么多年后仍然以讹传讹，这篇文章希望正本清源、扭转错误的认识。

CPU的制造和概念从最底层的沙子开始用8篇文章来回答关于CPU的各种疑问以及大量的实验对比案例和测试数据来展示了CPU的各种原理，比如多核、超线程、NUMA、睿频、功耗、GPU、大小核再到分支预测、cache_line失效、加锁代价、IPC等各种指标（都有对应的代码和测试数据）。

《Intel PAUSE指令变化是如何影响自旋锁以及MySQL的性能的》从一个参数引起的rt抖动定位到OS锁等待再到CPU Pause指令，以及不同CPU型号对Pause使用cycles不同的影响，最终反馈到应用层面的rt全过程。在MySQL内核开发的时候考虑了Pause，但是没有考虑不同的CPU型号，所以换了CPU型号后性能差异比较大

10倍性能提升全过程在双11的紧张流程下，将系统tps从500优化到5500，从网络到snat、再到Spring和StackTrace，一次全栈性能优化过程的详细记录和分析。

就是要你懂TCP–半连接队列和全连接队列：偶发性的连接reset异常、重启服务后短时间的连接异常，通过一篇文章阐明TCP连接的半连接队列和全连接队大小是怎么影响连接创建的，以及用什么工具来观察队列有没有溢出、连接为什么会RESET

就是要你懂TCP–性能和发送接收Buffer的关系：发送窗口大小(Buffer)、接收窗口大小(Buffer)对TCP传输速度的影响，以及怎么观察窗口对传输速度的影响。BDP、RT、带宽对传输速度又是怎么影响的

就是要你懂网络–一个网络包的旅程：教科书式地阐述书本中的路由、网关、子网、Mac地址、IP地址是如何一起协作让网络包最终传输到目标机器上。同时可以跟讲这块的RFC1180比较一下，RFC1180 写的确实很好，清晰简洁，图文并茂，结构逻辑合理，但是对于90%的程序员没有什么卵用，看完几周后就忘得差不多，因为他不是从实践的角度来阐述问题，中间没有很多为什么，所以一般资质的程序员看完当时感觉很好，实际还是不会灵活运用

国产CPU和Intel、AMD性能PK 从Intel、AMD、海光、鲲鹏920、飞腾2500 等CPU在TPCC、sysbench下的性能对比来分析他们的性能差距，同时分析内存延迟对性能的影响

从网络路由连通性的原理上来看负载均衡lvs的DR、NAT、FullNAT到底搞了些什么鬼，以及为什么要这么搞，和带来的优缺点：《就是要你懂负载均衡–lvs和转发模式》

LVS 20倍的负载不均衡，原来是内核的这个Bug，这个内核bug现在还在，可以稳定重现，有兴趣的话去重现一下，然后对照源代码以及抓包分析一下就清楚了。

就是要你懂TCP–握手和挥手，不是你想象中三次握手、四次挥手就理解了TCP，本文从握手的本质–握手都做了什么事情、连接的本质是什么等来阐述握手、挥手的原理

nslookup OK but ping fail–看看老司机是如何解决问题的，解决问题的方法肯定比知识点重要多了，同时透过一个问题怎么样通篇来理解一大块知识，让这块原理真正在你的只是提示中扎根下来

如何在工作中学习一篇很土但是很务实可以复制的方法论文章。不要讲举一反三、触类旁通，谁都知道要举一反三、触类旁通，但是为什么我总是不能够举一反三、触类旁通？

举三反一–从理论知识到实际问题的推导坚决不让思路跑偏，如何从一个理论知识点推断可能的问题

性能相关（2015-2018年）

就是要你懂TCP–半连接队列和全连接队列偶发性的连接reset异常、重启服务后短时间的连接异常

就是要你懂TCP–性能和发送接收Buffer的关系：发送窗口大小(Buffer)、接收窗口大小(Buffer)对TCP传输速度的影响，以及怎么观察窗口对传输速度的影响。BDP、RT、带宽对传输速度又是怎么影响的发送窗口大小(Buffer)、接收窗口大小(Buffer)对TCP传输速度的影响，以及怎么观察窗口对传输速度的影响

就是要你懂TCP–TCP性能问题 Nagle算法和delay ack

10倍性能提升全过程在双11的紧张流程下，将系统tps从500优化到5500，从网络到snat、再到Spring和StackTrace，看看一个性能全栈工程师如何在各种工具加持下发现各种问题的。

CPU系列文章（2021年完成）

[Intel PAUSE指令变化是如何影响自旋锁以及MySQL的性能的](/2019/12/16/Intel PAUSE指令变化是如何影响自旋锁以及MySQL的性能的/)

[Perf IPC以及CPU性能](/2021/05/16/Perf IPC以及CPU利用率/)

[CPU 性能和Cache Line](/2021/05/16/CPU Cache Line 和性能/)

AMD Zen CPU 架构以及 AMD、海光、Intel、鲲鹏的性能对比

网络相关基础知识（2017年完成）

wireshark-dup-ack-issue and keepalive

[kubernetes service 和 kube-proxy详解](/2020/09/22/kubernetes service 和 kube-proxy详解/)

DNS相关

LVS 负载均衡

网络工具

netstat timer keepalive explain

TCP 网络性能排查实战：两个经典案例的深度学习总结

概述

本文总结了两个真实的 TCP 网络性能问题排查案例，涉及 Kafka 消息队列在跨机房和同机房场景下的延迟问题。两个案例从不同角度揭示了 TCP 缓冲区、拥塞控制、内核参数对应用性能的深远影响。

案例一：跨机房 Kafka 消费延迟高达 10 分钟

问题描述

每天上午 9:30 开盘后，位于 Region-B 的 Kafka 消费者从 Region-A 的 Kafka Broker 拉取消息时，延迟不断增高到 10 多分钟，持续数小时才恢复。而 Region-A 同机房的消费者拉取同一 Topic 完全正常。

排查过程

整个排查经历了多个阶段，逐步逼近根因：

阶段一：排除基础设施问题

Broker/Client 进程状态、机器资源（CPU/内存/磁盘）均正常
网络带宽充足，丢包率正常，wget 测试带宽足够
初步怀疑方向：网络链路本身

阶段二：发现拥塞窗口异常（TCP 层面）

在客户端机器上抓包分析，发现关键线索：

# 查看 TCP 连接的拥塞窗口
ss -itmpn dst "x.x.x.x"

# 关键输出（问题连接）
cwnd:2 ssthresh:2    ← 拥塞窗口极小，只有 2 个 MSS
send 170.0Kbps       ← 发送速率极低

RTT 约 130ms，拥塞窗口只有 2（约 2.9KB），理论吞吐量：2 × 1448 / 0.13 ≈ 22KB/s，远不够传输开盘时的行情数据。

尝试通过 wget 大文件把 ssthresh 撑大，然后重启客户端新建连接，问题暂时缓解。但第二天又复发。

阶段三：发现内核虚假重传（深入内核层面）

通过 Wireshark 分析抓包文件，发现一个异常现象：

Broker 发送响应后，如果 10ms 内没收到 ACK，就触发重传。而正常的 RTO 应该是 200ms+。

这种 10ms 的重传远低于 RTO，也不是快速重传或 TLP。最终定位到 Linux 3.10 内核的 tcp_early_retrans 参数：

# 查看当前值
sysctl net.ipv4.tcp_early_retrans
# 输出: net.ipv4.tcp_early_retrans = 3

# 这是 3.10 内核 backport 新版本 early retrans 功能时引入的 bug
# 导致大量虚假重传，进而让拥塞控制算法误判网络拥塞，不断缩小 cwnd

修复方法：

1	sysctl -w net.ipv4.tcp_early_retrans=0

修改后，全网 TCP 重传率从万分之 5 降到正常水平。

阶段四：发现 Send Buffer 限制

解决虚假重传后，抓包发现新的瓶颈：

Broker 发送一批数据包后，在途字节（Bytes in flight）达到约 50KB 就停止发送，等一个 RTT（~130ms）收到 ACK 后才继续。

原因：Kafka Broker 默认配置 socket.send.buffer.bytes=102400（100KB），内核实际分配约一半（~50KB），限制了发送窗口。

阶段五：定位根因 — 客户端接收 Buffer

将 Broker Send Buffer 限制去掉后仍然不行。最终在客户端日志中找到关键配置：

1	receive.buffer.bytes = 65536 ← Kafka 客户端默认只有 64KB 接收缓冲区

TCP 三次握手时，客户端根据 receive.buffer.bytes 通告接收窗口（rwnd）。64KB 的 rwnd 意味着：

1	最大吞吐量 = rwnd / RTT = 64KB / 130ms ≈ 490KB/s

而开盘高峰期需要数十 MB/s 的吞吐量，64KB 的接收窗口成为致命瓶颈。

根因与解决方案

根因：Kafka 客户端默认接收缓冲区 64KB 太小，叠加跨机房 130ms 的 RTT，导致 TCP 吞吐量被严重限制。

解决方案：

# Kafka Consumer 配置
receive.buffer.bytes = 2097152    # 从 64KB 调整到 2MB（或设为 -1 让 OS 自动调优）

# Kafka Broker 配置
socket.send.buffer.bytes = -1     # 去掉 100KB 限制，让 OS 自动调优
socket.receive.buffer.bytes = -1

# Linux 内核参数（3.10 内核）
net.ipv4.tcp_early_retrans = 0    # 关闭有 bug 的 early retrans

效果：传输延迟从 10-60 分钟降低到 1-4 秒，性能提升约 1000 倍。

调整前后的 Wireshark 抓包对比：

1 2	调整前：485KB 数据需要 8 个 RTT（8 × 130ms = 1040ms）分批传输调整后：485KB 数据在 3ms 内一次性传输完毕

案例二：同机房 TCP 订阅客户端异常缓慢

问题描述

同机房 4 台机器部署了相同的行情订阅服务，其中 1 台拉取行情数据异常缓慢。

排查过程

第一步：抓包发现 TCP Zero Window

在客户端抓包，发现大量 TCP Zero Window 通告——客户端在告诉服务端”我的接收缓冲区满了，别再发了”。

第二步：确认 Recv Buffer 堆满

1 2	netstat -ant \| grep <server_port> # 发现 Recv-Q 持续满载

第三步：发现 CPU 异常

1 2	top -Hp <java_pid> # 发现一个线程 CPU 持续接近 100%，像死循环

第四步：定位代码问题

# 用 top 看到的线程 ID（十进制）转十六进制
printf '%x\n' <thread_id>

# 在 jstack 中查找对应线程堆栈
jstack <java_pid> | grep -A 30 <hex_thread_id>

找到问题代码：一个 for 循环中调用 read()，每次只读很少的数据（参数配置过小），导致：

应用层读取速度跟不上网络数据到达速度
OS TCP Recv Buffer 被填满
TCP 通告 Zero Window，服务端停止发送
该线程 CPU 100%（不停地循环读取微量数据）

根因与解决方案

根因：业务代码中 read() 的缓冲区参数配置过小，导致应用层消费速度远低于网络数据到达速度，TCP Recv Buffer 堆满触发 Zero Window。

解决方案：修复代码，增大 read() 的缓冲区大小。

效果：

网络吞吐量恢复正常（流量曲线从”平台”变为正常波动）
CPU 使用率从 40% 降到 20%

两个案例的关联与对比

维度	案例一（跨机房延迟）	案例二（同机房 Zero Window）
场景	跨机房，RTT ~130ms	同机房，RTT <1ms
表现	消费延迟 10+ 分钟	TCP Zero Window，数据停滞
瓶颈层	TCP 接收窗口 + 内核参数	应用层读取速度
根因	Kafka 默认 receive buffer 64KB 太小	业务代码 read() 缓冲区配置过小
为什么同机房没问题	RTT 小，64KB 窗口也够用	其他机器代码/配置正常
解决方式	调大 buffer + 修复内核参数	修复业务代码

两个案例本质上都是 TCP 接收端处理能力不足 导致发送端被限速：

1
2

案例一：接收窗口太小 → 发送端每个 RTT 只能发 64KB → 跨机房 RTT 大放大了问题
案例二：应用层读取太慢 → Recv Buffer 堆满 → Zero Window → 发送端完全停止

TCP 缓冲区与窗口的核心原理

发送方应用 write()
       ↓
  Send Buffer (sk_sndbuf)
       ↓  受发送窗口限制
  发送窗口 = min(拥塞窗口 cwnd, 接收窗口 rwnd)
       ↓
  网络传输 (in-flight data)
       ↓
  Receive Buffer (sk_rcvbuf)
       ↓  通告 rwnd = buffer_size - 已占用空间
  接收方应用 read()

关键关系：

接收窗口 rwnd：由接收端 Recv Buffer 剩余空间决定，通过 ACK 通告给发送端
拥塞窗口 cwnd：由发送端拥塞控制算法（如 CUBIC）动态调整
发送窗口：取 rwnd 和 cwnd 的较小值
最大吞吐量：min(rwnd, cwnd) / RTT

为什么 RTT 大时 Buffer 小的问题会被放大？

1 2	同机房 (RTT=1ms): 吞吐量 = 64KB / 1ms = 64MB/s ← 够用跨机房 (RTT=130ms): 吞吐量 = 64KB / 130ms = 490KB/s ← 严重不足

这就是案例一中”同机房正常、跨机房延迟”的根本原因。

关键排查命令速查

TCP 连接状态分析

# 查看 TCP 连接详细信息（拥塞窗口、RTT、重传等）
ss -itmpn dst "x.x.x.x"

# 关键字段解读
# cwnd:10        拥塞窗口（MSS 数量）
# ssthresh:2     慢启动阈值
# rtt:130/0.5    RTT 均值/方差（ms）
# rto:330        重传超时（ms）
# send 850Kbps   当前发送速率
# unacked:38     未确认的包数量
# retrans:0/3    当前重传/累计重传

# 查看 TCP 缓存指标
ip tcp_metrics show | grep <ip>

# 查看连接队列
netstat -ant | grep <port>
# Recv-Q: 接收队列（应用未读取的数据）
# Send-Q: 发送队列（已发送未确认的数据）

网络重传监控

# 实时观察 TCP 重传
watch -n 1 'nstat -az | grep TcpRetransSegs'

# 检查 early retrans 参数（3.10 内核）
sysctl net.ipv4.tcp_early_retrans

抓包分析

# 抓取指定端口的包
tcpdump -i eth0 port 9092 -w capture.pcap

# Wireshark 中关键过滤器
tcp.analysis.zero_window          # Zero Window 事件
tcp.analysis.retransmission       # 重传包
tcp.analysis.bytes_in_flight      # 在途字节数

Java 应用排查

# 查看 Java 进程中各线程 CPU 使用
top -Hp <java_pid>

# 线程 ID 转十六进制
printf '%x\n' <thread_id>

# 导出线程堆栈并查找
jstack <java_pid> | grep -A 30 <hex_thread_id>

经验教训

1. 不要信任中间件的默认配置

Kafka 客户端默认 receive.buffer.bytes=64KB、Broker 默认 socket.send.buffer.bytes=100KB，这些值在同机房低延迟环境下够用，但在跨机房高 RTT 场景下会成为致命瓶颈。

建议：跨机房部署时，将 buffer 相关配置设为 -1（让 OS 自动调优），或根据 BDP = 带宽 × RTT 计算合理值。

2. 内核参数可能是隐藏的定时炸弹

Linux 3.10 内核的 tcp_early_retrans=3 导致大量虚假重传，拉高全网重传率到万分之 5，掩盖了真实的网络问题。这种问题平时不显现，只在高负载时爆发。

建议：关注内核版本差异，定期检查 TCP 重传率是否异常。

3. 学会用 Wireshark 做对比分析

排查网络问题最有效的方法是：抓一份有问题的包、一份正常的包，在 Wireshark 中对比分析。关注：

Bytes in flight 的变化曲线
ACK 之间的间隔（是否有等待平台）
是否有异常重传

4. 应用层的 Bug 也会表现为网络问题

案例二中，业务代码 read() 缓冲区配置过小导致 TCP Zero Window，表面看是”网络问题”，实际是应用层 Bug。排查时不要只盯着网络层，要结合 top -Hp + jstack 看应用层行为。

5. 理解 BDP（带宽延迟积）

1	BDP = 带宽 × RTT

这是网络管道中能容纳的最大数据量。TCP Buffer 至少要等于 BDP 才能充分利用带宽。例如：

带宽 100Mbps, RTT 130ms:
BDP = 100Mbps × 0.13s = 13Mb = 1.6MB

→ TCP Buffer 至少需要 1.6MB 才能跑满带宽
→ 64KB 的 Buffer 只能利用 64KB/1.6MB ≈ 4% 的带宽

6. 排查要有层次感

应用层 → 是否有代码 Bug、配置错误
   ↓
中间件层 → Kafka/MySQL 等的 Buffer 配置是否合理
   ↓
TCP 层 → 拥塞窗口、接收窗口、重传情况
   ↓
内核层 → tcp_early_retrans 等内核参数
   ↓
网络层 → 带宽、丢包、RTT

从上到下逐层排查，每一层都可能是瓶颈。

网络知识学习方法与技巧

发表于 2026-01-20 更新于 2026-02-06 分类于 network

网络知识学习方法与技巧

一、学习路径：从理论到实战

1. 系统化学习框架

plantegg 博客提供了三大核心系列，构建完整的网络知识体系：

Understanding TCP 系列 - TCP 协议全方位解析
Understanding Network 系列 - 网络基础概念深入
Understanding Load Balancing 系列 - 负载均衡策略与实践

学习建议：不要孤立学习理论，而是将理论与生产案例结合。plantegg 的内容强调从实际问题出发，通过案例理解原理。

2. 问题驱动的学习方法

plantegg 博客的核心特点是问题导向：

从生产环境的真实故障入手
通过排查过程学习工具使用
在解决问题中理解底层原理
积累可复用的诊断方法论

实践路径：

遇到问题 → 2. 抓包分析 → 3. 定位根因 → 4. 理解原理 → 5. 总结方法

二、核心知识领域

1. TCP 连接管理

连接队列监控

理解 TCP 连接的两个关键队列：

SYN 队列（半连接队列）：存储 SYN_RECV 状态的连接
Accept 队列（全连接队列）：存储 ESTABLISHED 但未被 accept() 的连接

实时监控工具：

1 2	# 使用 bpftrace 工具包中的 tcpaccept tcpaccept

输出示例解读：

PID/COMM：接受连接的进程信息
RADDR/RPORT：远程地址和端口
LADDR/LPORT：本地地址和端口
Accept Queue：当前队列大小/最大队列大小

关键洞察：

队列满时会导致连接被丢弃（SYN 丢弃或 ACK 丢弃）
通过监控队列状态可以提前发现性能瓶颈
队列大小受 somaxconn 和应用层 backlog 参数影响

Socket 选项优化

SO_REUSEPORT - 多进程负载均衡：

int listenfd;
int reuse = 1;
setsockopt(listenfd, SOL_SOCKET, SO_REUSEPORT, 
           (const void *)&reuse, sizeof(int));

核心价值：

允许多个进程绑定同一 IP:Port
内核通过哈希分发连接，实现负载均衡
解决”惊群效应”（thundering herd）
提升多核 CPU 利用率

适用场景：

Nginx 多 worker 进程同时监听
高并发服务器提升连接接收能力
避免单一监听 socket 成为瓶颈

SO_REUSEADDR vs SO_REUSEPORT：

SO_REUSEADDR：允许 TIME_WAIT 状态下快速重启服务
SO_REUSEPORT：多进程负载均衡，性能优化

2. Buffer 与内存管理

Socket 内存信息解读

使用 ss -m 查看 socket 内存状态：

ss -m

输出字段含义：

r：接收缓冲区已分配内存
rb：接收缓冲区大小（sk_rcvbuf）
t：发送缓冲区已分配内存
tb：发送缓冲区大小（sk_sndbuf）
f：forward allocation（预分配内存）
w：发送队列中的数据
o：选项内存（如 TCP options）
bl：backlog 队列长度
d：丢弃的包数量

内核实现（参考）：

void sk_get_meminfo(const struct sock *sk, u32 *mem)
{
    mem[SK_MEMINFO_RMEM_ALLOC] = sk_rmem_alloc_get(sk);
    mem[SK_MEMINFO_RCVBUF] = sk->sk_rcvbuf;
    mem[SK_MEMINFO_WMEM_ALLOC] = sk_wmem_alloc_get(sk);
    mem[SK_MEMINFO_SNDBUF] = sk->sk_sndbuf;
    mem[SK_MEMINFO_FWD_ALLOC] = sk->sk_forward_alloc;
    mem[SK_MEMINFO_WMEM_QUEUED] = sk->sk_wmem_queued;
    mem[SK_MEMINFO_OPTMEM] = atomic_read(&sk->sk_omem_alloc);
    mem[SK_MEMINFO_BACKLOG] = sk->sk_backlog.len;
    mem[SK_MEMINFO_DROPS] = atomic_read(&sk->sk_drops);
}

诊断技巧：

r 接近 rb：接收缓冲区快满，应用层消费慢
t 接近 tb：发送缓冲区快满，网络发送慢或对端接收慢
d 持续增长：socket 丢包，需检查缓冲区大小和应用处理速度
bl 持续非零：backlog 队列有积压，应用 accept() 速度慢

内核参数调优

关键参数：

# 查看网络软中断预算
sysctl -a | grep net.core.netdev_budget

# 临时调整（重启失效）
sysctl -w net.core.netdev_budget=400

常见调优参数：

net.core.netdev_budget：单次软中断处理的最大包数
net.core.somaxconn：listen() 的最大 backlog
net.ipv4.tcp_rmem：TCP 接收缓冲区（min/default/max）
net.ipv4.tcp_wmem：TCP 发送缓冲区（min/default/max）
net.ipv4.tcp_max_syn_backlog：SYN 队列最大长度

调优原则：

先监控，后调优（避免盲目调整）
理解参数含义和影响范围
在测试环境验证效果
记录调优前后的性能指标

3. TCP 性能指标

关键性能指标

RTT（Round-Trip Time）：

衡量网络延迟的核心指标
影响 TCP 吞吐量：Throughput ≈ Window Size / RTT
通过 tcp.analysis.ack_rtt 字段分析

重传率：

反映网络质量和拥塞情况
类型：超时重传、快速重传
高重传率可能原因：网络丢包、接收端处理慢、拥塞

窗口大小：

接收窗口（rwnd）：接收端通告的可用缓冲区
拥塞窗口（cwnd）：发送端的拥塞控制窗口
实际窗口 = min(rwnd, cwnd)

丢包与重传分析：

tcp.analysis.retransmission：重传包
tcp.analysis.fast_retransmission：快速重传
tcp.analysis.duplicate_ack：重复 ACK
tcp.analysis.lost_segment：丢失的段

TCP 选项优化

TCP_CORK：

1
2
3

当设置 TCP_CORK 时，会将非满帧排队，直到清除该选项。
适用场景：先发送 HTTP 头部，再用 sendfile() 发送数据体。
TCP_CORK 可与 TCP_NODELAY 同时设置，且优先级更高。

应用场景：

减少小包发送，提升网络效率
适合批量数据传输
与 sendfile() 配合使用

4. 负载均衡与高可用

SO_REUSEPORT 实现负载均衡

工作原理：

内核通过哈希算法分发连接到不同进程
每个进程独立 listen() 和 accept()
避免进程间锁竞争

性能提升：

多核 CPU 并行处理连接
消除单一监听 socket 瓶颈
提升高并发场景下的吞吐量

Nginx 配置示例：

worker_processes 4;
worker_cpu_affinity 00000000000000000000000000001111;

events {
    use epoll;
    accept_mutex off;  # 关闭 accept 互斥锁
    worker_connections 102400;
}

http {
    access_log off;
    sendfile on;
    sendfile_max_chunk 512k;
    tcp_nopush on;
    keepalive_timeout 60;
    keepalive_requests 100000000000;
    
    # 短连接 RPS 优化
    open_file_cache max=10240000 inactive=60s;
    open_file_cache_valid 80s;
    open_file_cache_min_uses 1;
}

优化要点：

accept_mutex off：配合 SO_REUSEPORT 使用
sendfile：零拷贝技术，减少 CPU 消耗
tcp_nopush：与 TCP_CORK 类似，批量发送
open_file_cache：缓存文件描述符，提升短连接性能

三、实战诊断方法论

1. 性能问题排查流程

第一步：确定问题现象

延迟高？吞吐量低？连接失败？
收集监控数据：CPU、内存、网络流量、连接数

第二步：抓包分析

使用 tcpdump 捕获流量
用 tshark/Wireshark 分析关键指标

第三步：定位瓶颈

网络层：RTT、丢包率、重传率
传输层：窗口大小、队列状态
应用层：响应时间、处理速度

第四步：验证假设

调整参数或代码
对比调整前后的性能数据
确认问题是否解决

2. 常见问题模式

模式 1：高延迟

可能原因：

网络 RTT 高（物理距离、路由跳数）
应用层处理慢（数据库查询、计算密集）
队列积压（accept 队列、backlog 队列）

诊断方法：

分析 tcp.analysis.ack_rtt 确定网络延迟
分析应用层响应时间（如 MySQL query time）
检查队列状态（tcpaccept、ss -l）

模式 2：高重传率

可能原因：

网络丢包（链路质量差、拥塞）
接收端处理慢（窗口满、应用消费慢）
发送端突发流量（超过网络容量）

诊断方法：

统计重传类型（超时 vs 快速重传）
检查窗口大小变化
分析丢包位置（发送端、中间网络、接收端）

模式 3：连接失败

可能原因：

SYN 队列满（半连接队列溢出）
Accept 队列满（全连接队列溢出）
防火墙/安全组规则
端口耗尽

诊断方法：

检查 netstat -s | grep -i listen
监控队列状态（tcpaccept）
检查可用端口范围

3. 分层诊断策略

应用层：

响应时间分布（P50/P95/P99）
慢查询分析
业务逻辑性能

传输层（TCP）：

连接建立时间
数据传输效率
连接关闭状态（TIME_WAIT 数量）

网络层（IP）：

路由路径
MTU 设置
分片情况

链路层：

网卡队列
软中断分布
丢包统计

四、工具链与技能树

1. 必备工具

抓包与分析：

tcpdump：流量捕获
tshark：命令行分析
Wireshark：图形化深度分析

连接监控：

ss：socket 统计（替代 netstat）
tcpaccept：连接队列监控（bpftrace）
netstat：传统网络统计

性能分析：

perf：CPU 性能分析
sar：系统活动报告
iftop：实时流量监控

内核调试：

sysctl：内核参数查看/设置
bpftrace/eBPF：内核动态追踪
SystemTap：内核探测

2. 技能进阶路径

初级（理解基础）：

TCP 三次握手、四次挥手
常见状态（ESTABLISHED、TIME_WAIT、CLOSE_WAIT）
基本抓包和过滤

中级（诊断问题）：

重传、丢包、窗口分析
内核参数调优
应用层协议解析（HTTP、MySQL）

高级（性能优化）：

拥塞控制算法
零拷贝技术（sendfile、splice）
内核网络栈优化
eBPF 自定义追踪

专家级（架构设计）：

高性能网络架构设计
负载均衡策略
容错与降级方案
大规模分布式系统网络优化

五、学习资源与实践建议

1. plantegg 博客特色

理论与实践结合：

每个概念都有生产案例支撑
提供完整的命令和代码示例
强调可复现的实验方法

问题驱动：

从真实故障出发
展示完整的排查过程
总结可复用的方法论

工具导向：

详细的工具使用指南
参数含义和适用场景
输出结果的解读方法

2. 实践建议

搭建实验环境：

使用虚拟机或容器模拟网络场景
用 tc（traffic control）模拟延迟、丢包
搭建简单的客户端-服务器程序

动手实验：

复现博客中的案例
修改参数观察效果
记录实验结果和心得

建立知识库：

整理常用命令和参数
记录典型问题的排查步骤
积累自己的案例库

持续学习：

关注内核版本更新（新特性、新参数）
学习新工具（eBPF、XDP）
阅读内核源码（理解实现细节）

3. 避免的误区

误区 1：只学理论不实践

网络知识必须通过实验验证
理论与实际环境可能有差异

误区 2：盲目调优参数

先理解参数含义和影响
在测试环境验证效果
记录调优前后的对比数据

误区 3：忽视应用层

很多”网络问题”实际是应用层问题
要结合应用日志和业务逻辑分析

误区 4：过度依赖工具

工具是手段，理解原理才是目的
学会从工具输出推导底层行为

六、总结

plantegg 博客的核心价值在于：

系统化：完整的知识体系，从基础到高级
实战化：真实案例，可复现的实验
工具化：详细的工具使用指南
方法论：可复用的问题排查流程

学习网络知识的最佳路径：

理论学习 → 动手实验 → 问题排查 → 性能优化 → 架构设计

持续提升的关键：

保持好奇心，深入理解原理
多动手实践，积累经验
建立自己的知识体系和工具链
关注技术演进，学习新技术

文档生成时间：2026-01-18
来源：plantegg.github.io (Context7 库)
适用对象：系统工程师、SRE、后端开发、网络工程师

MySQL PreparedStatement Performance Issue Reproduction Report

发表于 2025-12-25 更新于 2026-02-06 分类于 MySQL

MySQL PreparedStatement Performance Issue Reproduction Report

1. Executive Summary

1.1 Issue Description

A severe performance issue was reported when MySQL processes PreparedStatement IN queries with a large number of parameters (50,000) using useServerPrepStmts=true. According to the original report, server-side prepared statements were 190-207 times slower than client-side prepared statements.

1.2 Issue Source

GitHub Repository: https://github.com/plantegg/MySQLPrepared
Original Discovery Version: MySQL 5.7.29
JDBC Driver: mysql-connector-j-8.0.33

1.3 Root Cause (Original Report)

When MySQL server processes PreparedStatement with large number of parameters:

Excessive memory reallocation: 50,000 parameter replacement operations
String operation complexity: O(SQL length) × number of parameters
Memory fragmentation: Frequent large memory block allocation and deallocation

2. Test Environment

2.1 AWS Resource Information

Resource	Configuration
AWS Account	872515255872
Region	ap-southeast-1
VPC	vpc-084114e405054a5b7

2.2 RDS MySQL 8.0 Instance

Configuration	Value
Instance Identifier	mysql-prepared-test
Instance Type	db.t3.medium (2vCPU, 4GB)
Storage	50GB gp3
Engine Version	MySQL 8.0.43
Endpoint	mysql-prepared-test.cfsoq6muu0jv.ap-southeast-1.rds.amazonaws.com

2.3 RDS MySQL 5.7 Instance

Configuration	Value
Instance Identifier	mysql57-prepared-test
Instance Type	db.t3.medium (2vCPU, 4GB)
Storage	50GB gp3
Engine Version	MySQL 5.7.44-rds.20240408
Endpoint	mysql57-prepared-test.cfsoq6muu0jv.ap-southeast-1.rds.amazonaws.com

2.4 EC2 Test Client

Configuration	Value
Instance ID	i-0b26f3cb781bae059
Instance Type	t3.medium
AMI	Amazon Linux 2023
Public IP	18.141.185.36
Java	Amazon Corretto 17
Maven	3.8.4

3. Test Methodology

3.1 Test Code

git clone https://github.com/plantegg/MySQLPrepared.git
cd MySQLPrepared
./run_test.sh --host <mysql-host> --port 3306 --database test \
    --user admin --password '<password>' --rounds 3

3.2 Test Parameters

Parameter	Value
IN query parameter count	50,000
Parameter type	15-digit large integers
SQL length (spaces=128)	~6.5MB
Test rounds	3

3.3 AWS CLI Commands

Create RDS MySQL 8.0 Instance

aws rds create-db-instance \
    --profile default --region ap-southeast-1 \
    --db-instance-identifier mysql-prepared-test \
    --db-instance-class db.t3.medium \
    --engine mysql \
    --engine-version 8.0 \
    --master-username admin \
    --master-user-password '<password>' \
    --allocated-storage 50 \
    --storage-type gp3 \
    --db-subnet-group-name mysql-benchmark-subnet-group \
    --vpc-security-group-ids sg-01541b078e0b483d0 \
    --no-multi-az \
    --publicly-accessible \
    --backup-retention-period 0 \
    --no-auto-minor-version-upgrade

Create RDS MySQL 5.7 Instance

aws rds create-db-instance \
    --profile default --region ap-southeast-1 \
    --db-instance-identifier mysql57-prepared-test \
    --db-instance-class db.t3.medium \
    --engine mysql \
    --engine-version 5.7.44-rds.20240408 \
    --master-username admin \
    --master-user-password '<password>' \
    --allocated-storage 50 \
    --storage-type gp3 \
    --db-subnet-group-name mysql-benchmark-subnet-group \
    --vpc-security-group-ids sg-01541b078e0b483d0 \
    --no-multi-az \
    --publicly-accessible \
    --backup-retention-period 0 \
    --no-auto-minor-version-upgrade

Create EC2 Test Instance

aws ec2 run-instances \
    --profile default --region ap-southeast-1 \
    --image-id ami-0d1c0ec9903f7b01f \
    --instance-type t3.medium \
    --key-name renxijun-ec2-key \
    --security-group-ids sg-0706d5fbe75649370 \
    --subnet-id subnet-09d864b724dce6434 \
    --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=mysql-prepared-test-ec2}]'

4. Test Results

4.1 MySQL 8.0.43 Test Results

Compact Format (spaces=0, SQL length ~100KB)

Configuration	Average Execution Time	Com_stmt_prepare
useServerPrepStmts=false	129.6ms	0
useServerPrepStmts=true	115.6ms	1
Performance Difference	true is 1.1x faster	-

With Spaces Format (spaces=128, SQL length ~6.5MB)

Configuration	Average Execution Time	Com_stmt_prepare
useServerPrepStmts=false	400.7ms	0
useServerPrepStmts=true	101.0ms	1
Performance Difference	true is 4.0x faster	-

4.2 MySQL 5.7.44 Test Results

With Spaces Format (spaces=128, SQL length ~6.5MB)

Configuration	Average Execution Time	Com_stmt_prepare
useServerPrepStmts=false	600.0ms	0
useServerPrepStmts=true	90.0ms	1
Performance Difference	true is 6.7x faster	-

4.3 Comparison with Original Report

Version	Original Report (5.7.29)	This Test (5.7.44)	This Test (8.0.43)
false avg time	~52ms	600ms	400.7ms
true avg time	~27,839ms	90ms	101ms
Performance Diff	true 535x slower	true 6.7x faster	true 4.0x faster

5. Conclusions

5.1 Reproduction Results

The performance issue described in the original report could NOT be reproduced on MySQL 5.7.44 and 8.0.43.

Test results show:

On both versions, useServerPrepStmts=true is actually faster than false
MySQL 5.7.44: Server-side prepared statements are 6.7x faster
MySQL 8.0.43: Server-side prepared statements are 4.0x faster

5.2 Possible Explanations

MySQL Version Differences
- Original issue was discovered on MySQL 5.7.29
- This test used MySQL 5.7.44 and 8.0.43
- The issue may have been fixed in versions after 5.7.29
AWS RDS Optimizations
- AWS RDS may include specific performance optimizations
- Behavior may differ from native MySQL installations
JDBC Driver Version
- Test used mysql-connector-j-8.0.33
- Driver may have optimized parameter handling logic

5.3 Recommendations

To Reproduce the Original Issue
- Use MySQL 5.7.29 or earlier versions
- Use native MySQL instead of AWS RDS
Production Environment Recommendations
- On newer MySQL versions, useServerPrepStmts=true performs better
- Conduct performance testing with actual business scenarios
- For IN queries with large parameter counts, consider batch queries or temporary table approaches

6. Appendix

6.1 Test Logs

MySQL 8.0.43 Complete Output

=== MySQL PreparedStatement Performance Comparison Test ===
Connection: mysql-prepared-test.cfsoq6muu0jv.ap-southeast-1.rds.amazonaws.com:3306/test
Parameter count: 50000
Test rounds: 3

Configuration: useServerPrepStmts=false
Parameter spaces: 128
SQL length: 6500023 characters
Executing query 1...
Query 1: 571ms (0 records returned)
Executing query 2...
Query 2: 317ms (0 records returned)
Executing query 3...
Query 3: 314ms (0 records returned)

=== useServerPrepStmts=false Test Results ===
Total execution time: 1202ms
Average execution time: 400.7ms
Records returned: 0
Com_stmt_prepare: 0 -> 0

Configuration: useServerPrepStmts=true
Parameter spaces: 128
SQL length: 6500023 characters
Executing query 1...
Query 1: 138ms (0 records returned)
Executing query 2...
Query 2: 92ms (0 records returned)
Executing query 3...
Query 3: 73ms (0 records returned)

=== useServerPrepStmts=true Test Results ===
Total execution time: 303ms
Average execution time: 101.0ms
Records returned: 0
Com_stmt_prepare: 0 -> 1

MySQL 5.7.44 Complete Output

=== MySQL PreparedStatement Performance Comparison Test ===
Connection: mysql57-prepared-test.cfsoq6muu0jv.ap-southeast-1.rds.amazonaws.com:3306/test
Parameter count: 50000
Test rounds: 3

Configuration: useServerPrepStmts=false
Parameter spaces: 128
SQL length: 6500023 characters
Executing query 1...
Query 1: 639ms (0 records returned)
Executing query 2...
Query 2: 681ms (0 records returned)
Executing query 3...
Query 3: 480ms (0 records returned)

=== useServerPrepStmts=false Test Results ===
Total execution time: 1800ms
Average execution time: 600.0ms
Records returned: 0
Com_stmt_prepare: 0 -> 0

Configuration: useServerPrepStmts=true
Parameter spaces: 128
SQL length: 6500023 characters
Executing query 1...
Query 1: 117ms (0 records returned)
Executing query 2...
Query 2: 77ms (0 records returned)
Executing query 3...
Query 3: 76ms (0 records returned)

=== useServerPrepStmts=true Test Results ===
Total execution time: 270ms
Average execution time: 90.0ms
Records returned: 0
Com_stmt_prepare: 0 -> 1

6.2 Original Issue Stack Trace (from original report)

The original report included a pstack analysis showing the server spending excessive time in string replacement operations:

Thread 1 (Thread 0x7feeb8043640 (LWP 2508284)):
#0 __memmove_avx512_unaligned_erms () from /lib64/libc.so.6
#1 my_realloc () at mysys/my_malloc.c:112
#2 String::mem_realloc () at sql-common/sql_string.cc:128
#3 String::replace () at sql-common/sql_string.cc:804
#4 String::replace () at sql-common/sql_string.cc:783
#5 Prepared_statement::insert_params () at sql/sql_prepare.cc:924
#6 Prepared_statement::set_parameters () at sql/sql_prepare.cc:3496
#7 Prepared_statement::execute_loop () at sql/sql_prepare.cc:3559
#8 mysqld_stmt_execute () at sql/sql_prepare.cc:2582
...

This stack trace indicates the server was performing extensive memory reallocation and string manipulation operations during parameter substitution.

6.3 References

7. Submission Notes for MySQL Community

7.1 Summary for Bug Report

Title: Performance regression with useServerPrepStmts=true for large IN queries appears to be fixed in MySQL 5.7.44+

Description:
A previously reported performance issue where server-side prepared statements (useServerPrepStmts=true) were significantly slower than client-side prepared statements for IN queries with 50,000 parameters could not be reproduced on MySQL 5.7.44 and 8.0.43.

Original Behavior (MySQL 5.7.29):

useServerPrepStmts=true: ~27,839ms average
useServerPrepStmts=false: ~52ms average
Performance difference: 535x slower with server-side

Current Behavior (MySQL 5.7.44 / 8.0.43):

useServerPrepStmts=true: ~90-101ms average
useServerPrepStmts=false: ~400-600ms average
Performance difference: 4-6.7x faster with server-side

Request:
Could the MySQL team confirm if this issue was intentionally fixed in a specific version? If so, please document the fix in the release notes for user awareness.

Report Generated: 2026-01-12
Test Executor: Kiro CLI
AWS Account: 872515255872

云盘和本地盘谁强？各家云厂商云盘谁更强？

发表于 2025-11-29 更新于 2026-02-06 分类于 MySQL

MySQL Sysbench 性能测试综合报告

测试代码开源：https://github.com/plantegg/sysbench_report ，包含自动生成下面的测试报告，对每个测试场景自动列出压测当时的 CPU/磁盘负载

📊 执行摘要

本报告汇总了10 多个不同环境下的MySQL性能测试结果，涵盖了IDC自建机房、华为云/阿里云ECS/AWS EC2，自建 MySQL(非云实例)。测试使用sysbench工具进行标准化性能评估，包含点查询、只读、读写混合、只写四种典型业务场景。

点评

测试场景故意用 16*1000 万行50G 数据，MySQL 配置 16Gbuffer，考验磁盘性能
警惕 AWS 云盘，即使换成很贵的 io1/io2 云盘，性能较其他家有很大的差距，尤其是在没有压力的时延上是阿里云的 5 倍，是 IDC 的 10 倍，
相对来说 aliyun 的表现很优秀，云盘有很大的 iops 弹性，可以买更便宜的，关键时刻享受自动弹性
不管怎么样，云盘还是非常昂贵，一个实例上云盘的价格会是机器的一半到一倍
CPU 计算性能大差不差，其中 aliyun 买的是今年最新一代，占点优势

测试环境概览

说明：

trx1 表示innodb_flush_log_at_trx_commit 为 1；默认配置的 2；表示刷盘频率
gp3/io1/io2 表示 aws 的三款不同性能的云盘(io2 最好最贵)(2T 云盘的价格是 8C32G 机器的 8 倍)
trx1.repl 的 repl 表示开启半同步复制，看看网络 replication 带来的时延
ali.repl.rtt0.7 的 repl 表示开启半同步复制，rtt0.7ms 表示网络延时，模拟跨可用区
idc 表示在我们自己的机房搭建 MySQL(测试默认不含主从复制，repl 除外)
云厂商都是购买 ECS 搭建 MySQL
超过 8 核的机器，通过绑核的形式限制只能用 8 核

环境	CPU型号	核数	内存	Buffer Pool	Flush Log
idc	INTEL(R) XEON(R) SILVER 4510	48	376G	16GB	2
idc.trx1	INTEL(R) XEON(R) SILVER 4510	48	376G	16GB	1
huawei	Intel(R) Xeon(R) Gold 6348 CPU @ 2.60GHz	64	251G	16GB	2
aliyun	Intel(R) Xeon(R) 6982P-C	8	30Gi	16GB	2
aliyun.trx1	Intel(R) Xeon(R) 6982P-C	8	30Gi	16GB	1
aliyun.trx1.repl	Intel(R) Xeon(R) 6982P-C	8	30Gi	16GB	1
ali.repl.rtt0.7	Intel(R) Xeon(R) 6982P-C	8	30Gi	16GB	2
aws.io2.trx1	Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz	8	30Gi	16GB	1
aws.io2	Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz	8	30Gi	16GB	2
aws.io1	Intel(R) Xeon(R) Platinum 8488C	8	30Gi	16GB	2
aws.gp3	Intel(R) Xeon(R) Platinum 8488C	8	30Gi	16GB	2

测试配置

测试工具: sysbench + tsar
测试数据集: 16表 × 1000万行
测试时长: 每场景30秒
测试场景: 点查询、只读、读写混合、只写
并发级别: 1, 8, 16, 32, 64, 128 线程

🏆 性能排名

点查询性能对比 (oltp_point_select)

环境	1线程	8线程	16线程	32线程	64线程	128线程
idc	24,725	159,877	252,082	304,631	299,555	287,407
idc.trx1	15,153	129,671	231,142	296,421	297,696	285,109
huawei	6,019	45,989	86,219	155,542	196,915	190,484
aliyun	15,750	109,914	196,497	301,160	328,098	309,373
aliyun.trx1	15,625	113,189	195,783	302,140	326,549	310,429
aliyun.trx1.repl	17,027	109,505	190,769	287,309	329,548	301,471
ali.repl.rtt0.7	14,484	96,810	168,662	254,690	271,234	235,929
aws.io2.trx1	11,888	75,291	127,179	161,447	162,516	155,947
aws.io2	12,004	75,171	126,712	160,866	157,480	153,448
aws.io1	1,835	56,871	170,296	251,905	249,718	236,283
aws.gp3	2,316	60,437	162,670	232,535	228,321	217,381

只写性能对比 (oltp_write_only)

环境	1线程	8线程	16线程	32线程	64线程	128线程
idc	19,282	77,540	94,457	88,015	103,249	115,778
idc.trx1	15,367	61,477	78,108	82,004	97,106	108,842
huawei	4,930	30,173	49,163	70,800	85,898	64,958
aliyun	12,484	61,401	90,134	101,548	110,923	121,385
aliyun.trx1	6,909	38,470	57,604	88,163	112,561	105,554
aliyun.trx1.repl	5,832	27,926	36,521	52,252	86,217	95,690
ali.repl.rtt0.7	4,876	26,828	41,624	57,505	76,301	86,433
aws.io2.trx1	3,575	21,479	37,696	59,664	76,279	79,531
aws.io2	8,881	44,059	64,137	79,024	79,754	70,019
aws.io1	1,786	19,047	39,006	68,442	94,216	66,370
aws.gp3	1,689	17,630	34,757	36,656	43,519	52,980

读写混合性能对比 (oltp_read_write)

环境	1线程	8线程	16线程	32线程	64线程	128线程
idc	9,208	49,874	64,265	68,103	69,255	69,969
idc.trx1	7,297	45,183	58,254	63,486	65,714	67,345
huawei	3,728	25,512	40,124	49,743	51,940	52,357
aliyun	7,952	51,194	71,761	81,858	83,569	82,403
aliyun.trx1	6,868	44,801	66,062	78,590	83,049	84,131
aliyun.trx1.repl	8,125	51,348	76,515	98,436	109,191	111,512
ali.repl.rtt0.7	6,225	39,379	62,234	74,702	78,823	0
aws.io2.trx1	5,074	29,077	41,737	47,906	49,160	50,050
aws.io2	6,743	35,997	45,274	50,664	51,002	50,315
aws.io1	1,924	24,967	54,742	68,211	71,816	70,575
aws.gp3	1,741	19,019	42,144	60,885	64,869	63,936

只读性能对比 (oltp_read_only)

环境	1线程	8线程	16线程	32线程	64线程	128线程
idc	11,527	58,919	73,087	74,820	74,631	73,444
idc.trx1	10,803	60,145	71,110	73,527	73,290	72,280
huawei	4,433	27,454	41,995	49,173	51,212	51,027
aliyun	9,389	60,278	76,662	84,123	85,224	85,054
aliyun.trx1	9,311	59,695	76,820	84,023	85,283	85,127
aliyun.trx1.repl	11,207	73,855	103,284	120,653	125,685	122,608
ali.repl.rtt0.7	9,124	55,926	73,447	81,446	83,524	83,351
aws.io2.trx1	7,068	39,993	47,383	50,146	49,763	49,209
aws.io2	7,039	39,720	47,558	49,995	49,821	49,165
aws.io1	1,845	28,879	64,551	73,173	74,400	74,024
aws.gp3	1,692	31,915	59,828	66,972	67,678	67,480

📈 延迟分析

点查询延迟对比 (95%分位, ms)

环境	1线程	8线程	16线程	32线程	64线程	128线程
idc	0.04	0.06	0.10	0.16	0.32	0.61
idc.trx1	0.26	0.23	0.13	0.18	0.31	0.62
huawei	0.17	0.19	0.21	0.31	0.48	0.94
aliyun	0.07	0.08	0.10	0.16	0.29	0.59
aliyun.trx1	0.07	0.08	0.10	0.16	0.29	0.58
aliyun.trx1.repl	0.06	0.09	0.11	0.18	0.30	0.60
ali.repl.rtt0.7	0.07	0.09	0.12	0.19	0.54	1.12
aws.io2.trx1	0.09	0.12	0.18	0.32	0.56	1.06
aws.io2	0.09	0.12	0.18	0.32	0.55	1.08
aws.io1	0.72	0.49	0.13	0.20	0.36	0.72
aws.gp3	0.67	0.46	0.14	0.23	0.39	0.78

读写混合延迟对比 (95%分位, ms)

环境	1线程	8线程	16线程	32线程	64线程	128线程
idc	2.81	4.82	8.74	15.27	36.24	80.03
idc.trx1	3.49	5.28	8.58	15.83	36.24	75.82
huawei	6.79	8.43	11.45	20.00	49.21	106.75
aliyun	3.30	4.10	6.32	11.65	29.72	86.00
aliyun.trx1	3.68	4.65	6.55	11.45	25.28	94.10
aliyun.trx1.repl	2.86	3.89	5.18	8.58	17.95	38.25
ali.repl.rtt0.7	3.96	5.00	6.55	12.08	27.66	0.00
aws.io2.trx1	4.82	6.79	10.09	19.29	50.11	125.52
aws.io2	3.89	5.88	10.65	19.65	47.47	139.85
aws.io1	13.95	9.73	9.06	13.70	29.72	106.75
aws.gp3	15.00	17.32	15.00	15.83	33.72	116.80

只写延迟对比 (95%分位, ms)

环境	1线程	8线程	16线程	32线程	64线程	128线程
idc	0.52	0.94	1.76	4.18	8.74	16.12
idc.trx1	0.63	1.18	2.00	4.10	8.13	14.46
huawei	2.35	2.86	3.49	5.00	8.90	17.95
aliyun	0.99	1.37	1.70	2.86	7.17	23.95
aliyun.trx1	1.37	1.93	2.43	3.13	4.74	9.22
aliyun.trx1.repl	1.44	2.43	3.43	4.82	6.55	12.08
ali.repl.rtt0.7	1.47	2.26	2.91	4.49	7.43	13.22
aws.io2.trx1	2.57	3.07	3.49	4.41	7.30	14.46
aws.io2	1.61	2.00	2.52	4.25	13.70	38.94
aws.io1	5.09	4.82	4.65	5.37	7.70	24.38
aws.gp3	5.99	5.67	5.67	15.00	29.72	44.98

💡 关键发现

性能特点

CPU架构影响
- 不同CPU架构在各场景下表现差异明显
- 单核性能对点查询场景影响显著
事务持久化设置
- innodb_flush_log_at_trx_commit=1 vs 2 对写入性能影响明显
- 建议根据业务对数据安全性要求选择合适配置
并发扩展性
- 各环境在不同并发级别下的扩展性表现不同
- 需要根据实际业务并发选择合适的硬件配置
延迟控制
- 高并发下延迟控制能力体现系统稳定性
- 95%分位延迟是衡量用户体验的重要指标

环境推荐

查询密集型业务: 推荐 aliyun.trx1 环境
写入密集型业务: 推荐 aliyun 环境
混合负载: 需要综合考虑QPS、延迟和成本

📊 64线程性能对比

测试场景	idc	idc.trx1	huawei	aliyun	aliyun.trx1	aliyun.trx1.repl	ali.repl.rtt0.7	aws.io2.trx1	aws.io2	aws.io1	aws.gp3
点查询	299,555	297,696	196,915	328,098	326,549	329,548	271,234	162,516	157,480	249,718	228,321
只读	74,631	73,290	51,212	85,224	85,283	125,685	83,524	49,763	49,821	74,400	67,678
读写混合	69,255	65,714	51,940	83,569	83,049	109,191	78,823	49,160	51,002	71,816	64,869
只写	103,249	97,106	85,898	110,923	112,561	86,217	76,301	76,279	79,754	94,216	43,519

第一章：idc 环境详细报告

测试时间: 2025-11-27 10:28:39
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 51706 条记录

测试配置信息

=== 测试配置信息 ===
MYSQL_HOST: 10.9.10.145
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	2

压测服务器配置

=== CPU 信息 ===
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                48
On-line CPU(s) list:   0-47
Thread(s) per core:    2
Core(s) per socket:    12
座：                 2
NUMA 节点：         2
厂商 ID：           GenuineIntel
CPU 系列：          6
型号：              143
型号名称：        INTEL(R) XEON(R) SILVER 4510
步进：              8
CPU MHz：             2400.000
BogoMIPS：            4800.00
虚拟化：           VT-x
L1d 缓存：          48K
L1i 缓存：          32K
L2 缓存：           2048K
L3 缓存：           30720K
NUMA 节点0 CPU：    0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46
NUMA 节点1 CPU：    1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cat_l2 cdp_l3 invpcid_single intel_pt cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq cldemote movdiri movdir64b md_clear pconfig spec_ctrl intel_stibp flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           376G         47G        257G        1.7G         71G        326G
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

测试场景	并发数	QPS	TPS	平均延迟(ms)	95%延迟(ms)	CPU软中断(%)	CPU用户(%)	CPU系统(%)	CPU等待(%)	IO利用率(%)	测试时间段
oltp_point_select	1	24,725	24,725	0.04	0.04	0.0	0.6	0.6	0.2	11.6	2025-11-24 08:56:53 ~ 2025-11-24 08:57:23
oltp_point_select	8	159,877	159,877	0.05	0.06	0.4	4.8	2.9	1.0	51.9	2025-11-24 08:57:25 ~ 2025-11-24 08:57:55
oltp_point_select	16	252,082	252,082	0.06	0.10	0.6	8.1	4.8	0.6	56.9	2025-11-24 08:57:57 ~ 2025-11-24 08:58:27
oltp_point_select	32	304,631	304,631	0.10	0.16	0.9	10.3	5.8	0.0	42.3	2025-11-24 08:58:29 ~ 2025-11-24 08:58:59
oltp_point_select	64	299,555	299,555	0.21	0.32	1.1	10.4	5.7	0.0	30.0	2025-11-24 08:59:01 ~ 2025-11-24 08:59:31
oltp_point_select	128	287,407	287,407	0.45	0.61	1.0	10.5	5.7	0.0	22.0	2025-11-24 08:59:33 ~ 2025-11-24 09:00:03
oltp_read_only	1	11,527	720	1.39	1.61	0.0	1.3	0.4	0.0	1.0	2025-11-24 09:00:05 ~ 2025-11-24 09:00:35
oltp_read_only	8	58,919	3,682	2.17	3.30	0.3	9.5	1.2	0.1	4.8	2025-11-24 09:00:37 ~ 2025-11-24 09:01:07
oltp_read_only	16	73,087	4,568	3.50	5.28	0.2	13.8	1.6	0.0	5.7	2025-11-24 09:01:09 ~ 2025-11-24 09:01:39
oltp_read_only	32	74,820	4,676	6.84	9.73	0.3	14.7	1.6	0.0	5.5	2025-11-24 09:01:41 ~ 2025-11-24 09:02:11
oltp_read_only	64	74,631	4,664	13.72	17.01	0.3	14.7	1.6	0.0	4.9	2025-11-24 09:02:13 ~ 2025-11-24 09:02:43
oltp_read_only	128	73,444	4,590	27.88	33.12	0.3	14.6	1.7	0.0	4.8	2025-11-24 09:02:45 ~ 2025-11-24 09:03:15
oltp_read_write	1	9,208	460	2.17	2.81	0.0	1.7	0.8	0.2	29.3	2025-11-24 09:03:17 ~ 2025-11-24 09:03:47
oltp_read_write	8	49,874	2,494	3.21	4.82	0.2	10.0	2.0	0.4	52.4	2025-11-24 09:03:49 ~ 2025-11-24 09:04:19
oltp_read_write	16	64,265	3,213	4.98	8.74	0.3	12.8	2.1	0.2	38.9	2025-11-24 09:04:21 ~ 2025-11-24 09:04:51
oltp_read_write	32	68,103	3,405	9.39	15.27	0.2	13.8	2.1	0.0	36.2	2025-11-24 09:04:53 ~ 2025-11-24 09:05:23
oltp_read_write	64	69,255	3,463	18.48	36.24	0.3	13.9	2.0	0.0	33.9	2025-11-24 09:05:25 ~ 2025-11-24 09:05:55
oltp_read_write	128	69,969	3,498	36.57	80.03	0.3	13.8	2.0	0.0	31.4	2025-11-24 09:05:57 ~ 2025-11-24 09:06:28
oltp_write_only	1	19,282	3,214	0.31	0.52	0.0	2.0	1.0	0.1	8.9	2025-11-24 09:06:30 ~ 2025-11-24 09:07:00
oltp_write_only	8	77,540	12,923	0.62	0.94	0.3	8.6	2.8	0.2	25.3	2025-11-24 09:07:02 ~ 2025-11-24 09:07:32
oltp_write_only	16	94,457	15,743	1.02	1.76	0.4	11.1	3.3	0.1	31.3	2025-11-24 09:07:34 ~ 2025-11-24 09:08:04
oltp_write_only	32	88,015	14,669	2.18	4.18	0.4	10.4	3.2	0.1	41.4	2025-11-24 09:08:06 ~ 2025-11-24 09:08:36
oltp_write_only	64	103,249	17,208	3.72	8.74	0.4	11.7	3.2	0.1	37.7	2025-11-24 09:08:38 ~ 2025-11-24 09:09:08
oltp_write_only	128	115,778	19,296	6.63	16.12	0.5	12.4	3.4	0.1	39.6	2025-11-24 09:09:10 ~ 2025-11-24 09:09:40

第二章：idc.trx1 环境详细报告

测试时间: 2025-11-27 10:29:01
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 50627 条记录

测试配置信息

=== 测试配置信息 ===
MYSQL_HOST: 10.9.10.145
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	1

压测服务器配置

=== CPU 信息 ===
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                48
On-line CPU(s) list:   0-47
Thread(s) per core:    2
Core(s) per socket:    12
座：                 2
NUMA 节点：         2
厂商 ID：           GenuineIntel
CPU 系列：          6
型号：              143
型号名称：        INTEL(R) XEON(R) SILVER 4510
步进：              8
CPU MHz：             2400.000
BogoMIPS：            4800.00
虚拟化：           VT-x
L1d 缓存：          48K
L1i 缓存：          32K
L2 缓存：           2048K
L3 缓存：           30720K
NUMA 节点0 CPU：    0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46
NUMA 节点1 CPU：    1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,45,47
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cat_l2 cdp_l3 invpcid_single intel_pt cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq cldemote movdiri movdir64b md_clear pconfig spec_ctrl intel_stibp flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           376G         47G        257G        1.7G         71G        326G
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

测试场景	并发数	QPS	TPS	平均延迟(ms)	95%延迟(ms)	CPU软中断(%)	CPU用户(%)	CPU系统(%)	CPU等待(%)	IO利用率(%)	测试时间段
oltp_point_select	1	15,153	15,153	0.07	0.26	0.0	0.6	0.6	0.8	42.6	2025-11-24 08:38:54 ~ 2025-11-24 08:39:24
oltp_point_select	8	129,671	129,671	0.06	0.23	0.2	4.1	2.7	2.3	81.3	2025-11-24 08:39:26 ~ 2025-11-24 08:39:56
oltp_point_select	16	231,142	231,142	0.07	0.13	0.9	7.8	4.2	0.8	68.0	2025-11-24 08:39:58 ~ 2025-11-24 08:40:28
oltp_point_select	32	296,421	296,421	0.11	0.18	0.9	10.3	5.7	0.0	47.1	2025-11-24 08:40:30 ~ 2025-11-24 08:41:00
oltp_point_select	64	297,696	297,696	0.21	0.31	0.9	10.4	5.7	0.0	31.4	2025-11-24 08:41:02 ~ 2025-11-24 08:41:32
oltp_point_select	128	285,109	285,109	0.45	0.62	0.8	10.5	5.6	0.0	21.7	2025-11-24 08:41:34 ~ 2025-11-24 08:42:04
oltp_read_only	1	10,803	675	1.48	1.86	0.0	1.3	0.4	0.0	1.0	2025-11-24 08:42:06 ~ 2025-11-24 08:42:36
oltp_read_only	8	60,145	3,759	2.13	3.25	0.1	10.2	1.3	0.1	5.3	2025-11-24 08:42:38 ~ 2025-11-24 08:43:08
oltp_read_only	16	71,110	4,444	3.60	5.88	0.2	13.5	1.6	0.0	5.6	2025-11-24 08:43:10 ~ 2025-11-24 08:43:40
oltp_read_only	32	73,527	4,595	6.96	10.09	0.2	14.6	1.6	0.0	5.6	2025-11-24 08:43:42 ~ 2025-11-24 08:44:12
oltp_read_only	64	73,290	4,581	13.97	18.28	0.3	14.6	1.6	0.0	5.1	2025-11-24 08:44:14 ~ 2025-11-24 08:44:44
oltp_read_only	128	72,280	4,518	28.32	34.95	0.2	14.5	1.6	0.0	4.9	2025-11-24 08:44:46 ~ 2025-11-24 08:45:16
oltp_read_write	1	7,297	365	2.74	3.49	0.0	1.5	0.7	0.2	28.6	2025-11-24 08:45:18 ~ 2025-11-24 08:45:48
oltp_read_write	8	45,183	2,259	3.54	5.28	0.1	9.5	2.0	0.4	44.6	2025-11-24 08:45:50 ~ 2025-11-24 08:46:20
oltp_read_write	16	58,254	2,913	5.49	8.58	0.2	12.2	2.2	0.2	32.3	2025-11-24 08:46:22 ~ 2025-11-24 08:46:53
oltp_read_write	32	63,486	3,174	10.08	15.83	0.2	13.5	2.2	0.1	33.5	2025-11-24 08:46:55 ~ 2025-11-24 08:47:25
oltp_read_write	64	65,714	3,286	19.47	36.24	0.3	13.7	2.0	0.0	33.2	2025-11-24 08:47:27 ~ 2025-11-24 08:47:57
oltp_read_write	128	67,345	3,367	37.99	75.82	0.3	14.0	2.0	0.0	32.0	2025-11-24 08:47:59 ~ 2025-11-24 08:48:29
oltp_write_only	1	15,367	2,561	0.39	0.63	0.0	2.1	1.1	0.2	14.5	2025-11-24 08:48:31 ~ 2025-11-24 08:49:01
oltp_write_only	8	61,477	10,246	0.78	1.18	0.2	8.1	3.1	0.2	33.5	2025-11-24 08:49:03 ~ 2025-11-24 08:49:33
oltp_write_only	16	78,108	13,018	1.23	2.00	0.4	10.2	3.3	0.2	34.6	2025-11-24 08:49:35 ~ 2025-11-24 08:50:05
oltp_write_only	32	82,004	13,667	2.34	4.10	0.4	10.4	3.2	0.2	40.3	2025-11-24 08:50:07 ~ 2025-11-24 08:50:37
oltp_write_only	64	97,106	16,184	3.95	8.13	0.4	11.6	3.1	0.1	36.8	2025-11-24 08:50:39 ~ 2025-11-24 08:51:09
oltp_write_only	128	108,842	18,140	7.05	14.46	0.4	12.2	3.3	0.1	40.1	2025-11-24 08:51:11 ~ 2025-11-24 08:51:41

第三章：huawei 环境详细报告

测试时间: 2025-11-27 10:29:08
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 60059 条记录

测试配置信息

=== 测试配置信息 ===
MYSQL_HOST: 10.16.104.124
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	2

压测服务器配置

=== CPU 信息 ===
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                64
On-line CPU(s) list:   0-63
Thread(s) per core:    2
Core(s) per socket:    16
座：                 2
NUMA 节点：         2
厂商 ID：           GenuineIntel
CPU 系列：          6
型号：              106
型号名称：        Intel(R) Xeon(R) Gold 6348 CPU @ 2.60GHz
步进：              6
CPU MHz：             2600.000
BogoMIPS：            5200.00
超管理器厂商：  KVM
虚拟化类型：     完全
L1d 缓存：          48K
L1i 缓存：          32K
L2 缓存：           1280K
L3 缓存：           43008K
NUMA 节点0 CPU：    0-31
NUMA 节点1 CPU：    32-63
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd rsb_ctxsw ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 arat avx512vbmi umip avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq md_clear spec_ctrl intel_stibp arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           251G         21G        127G        944K        102G        229G
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

测试场景	并发数	QPS	TPS	平均延迟(ms)	95%延迟(ms)	CPU软中断(%)	CPU用户(%)	CPU系统(%)	CPU等待(%)	IO利用率(%)	测试时间段
oltp_point_select	1	6,019	6,019	0.17	0.17	0.0	0.2	0.1	0.1	22.1	2025-11-24 10:03:09 ~ 2025-11-24 10:03:39
oltp_point_select	8	45,989	45,989	0.17	0.19	0.0	1.3	0.6	0.4	77.2	2025-11-24 10:03:41 ~ 2025-11-24 10:04:12
oltp_point_select	16	86,219	86,219	0.19	0.21	0.2	3.5	1.5	0.6	92.5	2025-11-24 10:04:14 ~ 2025-11-24 10:04:44
oltp_point_select	32	155,542	155,542	0.21	0.31	0.5	7.0	2.7	0.4	96.2	2025-11-24 10:04:46 ~ 2025-11-24 10:05:16
oltp_point_select	64	196,915	196,915	0.32	0.48	0.4	8.7	3.2	0.0	95.2	2025-11-24 10:05:18 ~ 2025-11-24 10:05:48
oltp_point_select	128	190,484	190,484	0.67	0.94	0.5	8.6	3.2	0.0	90.4	2025-11-24 10:05:50 ~ 2025-11-24 10:06:20
oltp_read_only	1	4,433	277	3.61	4.10	0.0	0.5	0.1	0.0	5.7	2025-11-24 10:06:22 ~ 2025-11-24 10:06:52
oltp_read_only	8	27,454	1,716	4.66	6.79	0.0	4.1	0.5	0.1	29.2	2025-11-24 10:06:54 ~ 2025-11-24 10:07:24
oltp_read_only	16	41,995	2,625	6.09	9.06	0.1	7.6	0.7	0.1	38.9	2025-11-24 10:07:26 ~ 2025-11-24 10:07:56
oltp_read_only	32	49,173	3,073	10.41	16.71	0.1	10.2	0.8	0.1	41.8	2025-11-24 10:07:58 ~ 2025-11-24 10:08:28
oltp_read_only	64	51,212	3,201	19.99	31.94	0.2	11.1	0.9	0.0	41.0	2025-11-24 10:08:30 ~ 2025-11-24 10:09:00
oltp_read_only	128	51,027	3,189	40.12	53.85	0.2	11.2	0.9	0.0	39.5	2025-11-24 10:09:02 ~ 2025-11-24 10:09:32
oltp_read_write	1	3,728	186	5.36	6.79	0.0	0.6	0.2	0.2	50.4	2025-11-24 10:09:34 ~ 2025-11-24 10:10:04
oltp_read_write	8	25,512	1,276	6.27	8.43	0.1	4.6	0.8	0.8	92.8	2025-11-24 10:10:06 ~ 2025-11-24 10:10:36
oltp_read_write	16	40,124	2,006	7.97	11.45	0.1	7.6	1.0	0.6	91.4	2025-11-24 10:10:38 ~ 2025-11-24 10:11:08
oltp_read_write	32	49,743	2,487	12.86	20.00	0.1	10.1	1.1	0.4	90.3	2025-11-24 10:11:10 ~ 2025-11-24 10:11:40
oltp_read_write	64	51,940	2,597	24.63	49.21	0.2	10.8	1.0	0.2	90.0	2025-11-24 10:11:42 ~ 2025-11-24 10:12:12
oltp_read_write	128	52,357	2,618	48.87	106.75	0.2	10.6	1.0	0.2	86.6	2025-11-24 10:12:14 ~ 2025-11-24 10:12:45
oltp_write_only	1	4,930	822	1.22	2.35	0.0	0.5	0.2	0.2	37.4	2025-11-24 10:12:47 ~ 2025-11-24 10:13:17
oltp_write_only	8	30,173	5,029	1.59	2.86	0.1	2.7	0.7	0.5	78.5	2025-11-24 10:13:19 ~ 2025-11-24 10:13:49
oltp_write_only	16	49,163	8,194	1.95	3.49	0.1	4.8	1.2	0.6	87.7	2025-11-24 10:13:51 ~ 2025-11-24 10:14:21
oltp_write_only	32	70,800	11,800	2.71	5.00	0.2	7.1	1.6	0.5	91.8	2025-11-24 10:14:23 ~ 2025-11-24 10:14:53
oltp_write_only	64	85,898	14,316	4.47	8.90	0.3	8.8	1.9	0.4	93.3	2025-11-24 10:14:55 ~ 2025-11-24 10:15:25
oltp_write_only	128	64,958	10,826	11.82	17.95	0.2	6.3	1.5	0.5	97.7	2025-11-24 10:15:27 ~ 2025-11-24 10:15:57

第四章：aliyun 环境详细报告

测试时间: 2025-11-27 10:28:27
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 811 条记录

测试配置信息

=== 测试配置信息 ===
MYSQL_HOST: 10.127.33.154
MYSQL_PORT: 3316
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	2

压测服务器配置

=== CPU 信息 ===
架构：           x86_64
CPU 运行模式：   32-bit, 64-bit
字节序：         Little Endian
CPU:             8
在线 CPU 列表：  0-7
每个核的线程数： 2
每个座的核数：   4
座：             1
NUMA 节点：      1
厂商 ID：        GenuineIntel
BIOS Vendor ID:  Alibaba Cloud
CPU 系列：       6
型号：           173
型号名称：       Intel(R) Xeon(R) 6982P-C
BIOS Model name: pc-i440fx-2.1
步进：           1
CPU MHz：        3600.000
CPU 最大 MHz：   3900.0000
CPU 最小 MHz：   800.0000
BogoMIPS：       5600.00
超管理器厂商：   KVM
虚拟化类型：     完全
L1d 缓存：       48K
L1i 缓存：       64K
L2 缓存：        2048K
L3 缓存：        516096K
NUMA 节点0 CPU： 0-7
标记：           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx_vnni avx512_bf16 wbnoinvd ida arat hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm uintr md_clear serialize tsxldtrk arch_lbr amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           30Gi        20Gi       1.2Gi       2.0Mi       9.1Gi       9.6Gi
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

测试场景	并发数	QPS	TPS	平均延迟(ms)	95%延迟(ms)	CPU软中断(%)	CPU用户(%)	CPU系统(%)	CPU等待(%)	IO利用率(%)	测试时间段
oltp_point_select	1	15,750	15,750	0.06	0.07	0.5	1.7	1.0	0.8	22.6	2025-11-23 07:59:31 ~ 2025-11-23 08:00:01
oltp_point_select	8	109,914	109,914	0.07	0.08	4.6	14.8	7.5	4.6	77.7	2025-11-23 08:00:03 ~ 2025-11-23 08:00:33
oltp_point_select	16	196,497	196,497	0.08	0.10	9.2	32.1	17.0	3.7	90.2	2025-11-23 08:00:35 ~ 2025-11-23 08:01:05
oltp_point_select	32	301,160	301,160	0.11	0.16	13.4	46.4	30.8	0.8	94.7	2025-11-23 08:01:07 ~ 2025-11-23 08:01:37
oltp_point_select	64	328,098	328,098	0.19	0.29	13.6	48.1	33.6	0.0	90.5	2025-11-23 08:01:39 ~ 2025-11-23 08:02:09
oltp_point_select	128	309,373	309,373	0.41	0.59	13.3	48.2	33.8	0.0	81.9	2025-11-23 08:02:11 ~ 2025-11-23 08:02:41
oltp_read_only	1	9,389	587	1.70	2.03	0.3	6.0	0.7	0.2	5.2	2025-11-23 08:02:43 ~ 2025-11-23 08:03:13
oltp_read_only	8	60,278	3,767	2.12	2.43	2.7	50.3	5.4	1.1	27.4	2025-11-23 08:03:15 ~ 2025-11-23 08:03:45
oltp_read_only	16	76,662	4,791	3.34	4.57	4.0	71.2	8.8	0.4	31.7	2025-11-23 08:03:47 ~ 2025-11-23 08:04:17
oltp_read_only	32	84,123	5,258	6.08	8.58	4.0	80.6	9.8	0.1	33.2	2025-11-23 08:04:19 ~ 2025-11-23 08:04:49
oltp_read_only	64	85,224	5,326	12.01	15.55	3.9	81.8	10.5	0.0	30.8	2025-11-23 08:04:51 ~ 2025-11-23 08:05:21
oltp_read_only	128	85,054	5,316	24.07	26.68	3.8	81.6	10.4	0.0	29.0	2025-11-23 08:05:23 ~ 2025-11-23 08:05:53
oltp_read_write	1	7,952	398	2.51	3.30	0.4	6.9	2.6	2.6	73.0	2025-11-23 08:05:55 ~ 2025-11-23 08:06:25
oltp_read_write	8	51,194	2,560	3.12	4.10	3.0	48.6	10.3	5.2	94.7	2025-11-23 08:06:27 ~ 2025-11-23 08:06:57
oltp_read_write	16	71,761	3,588	4.46	6.32	4.1	67.2	11.6	1.6	85.0	2025-11-23 08:06:59 ~ 2025-11-23 08:07:30
oltp_read_write	32	81,858	4,093	7.82	11.65	4.2	77.9	11.9	0.4	83.9	2025-11-23 08:07:32 ~ 2025-11-23 08:08:02
oltp_read_write	64	83,569	4,178	15.31	29.72	4.2	78.7	12.1	0.2	83.7	2025-11-23 08:08:04 ~ 2025-11-23 08:08:34
oltp_read_write	128	82,403	4,120	31.04	86.00	4.3	77.6	12.8	0.2	81.8	2025-11-23 08:08:36 ~ 2025-11-23 08:09:06
oltp_write_only	1	12,484	2,081	0.48	0.99	0.5	5.7	2.2	1.8	33.3	2025-11-23 08:09:08 ~ 2025-11-23 08:09:38
oltp_write_only	8	61,401	10,233	0.78	1.37	3.3	33.1	11.4	4.6	78.9	2025-11-23 08:09:40 ~ 2025-11-23 08:10:10
oltp_write_only	16	90,134	15,022	1.06	1.70	5.0	47.3	15.9	3.8	83.7	2025-11-23 08:10:12 ~ 2025-11-23 08:10:42
oltp_write_only	32	101,548	16,925	1.89	2.86	5.6	50.4	17.0	3.2	88.5	2025-11-23 08:10:44 ~ 2025-11-23 08:11:14
oltp_write_only	64	110,923	18,487	3.46	7.17	5.8	52.8	17.6	2.4	86.8	2025-11-23 08:11:16 ~ 2025-11-23 08:11:47
oltp_write_only	128	121,385	20,231	6.32	23.95	6.5	58.8	18.9	2.0	85.4	2025-11-23 08:11:49 ~ 2025-11-23 08:12:19

第五章：aliyun.trx1 环境详细报告

测试时间: 2025-11-27 10:27:05
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 791 条记录

测试配置信息

=== 测试配置信息 ===
MYSQL_HOST: 10.127.33.154
MYSQL_PORT: 3316
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	1

压测服务器配置

=== CPU 信息 ===
架构：           x86_64
CPU 运行模式：   32-bit, 64-bit
字节序：         Little Endian
CPU:             8
在线 CPU 列表：  0-7
每个核的线程数： 2
每个座的核数：   4
座：             1
NUMA 节点：      1
厂商 ID：        GenuineIntel
BIOS Vendor ID:  Alibaba Cloud
CPU 系列：       6
型号：           173
型号名称：       Intel(R) Xeon(R) 6982P-C
BIOS Model name: pc-i440fx-2.1
步进：           1
CPU MHz：        3600.000
CPU 最大 MHz：   3900.0000
CPU 最小 MHz：   800.0000
BogoMIPS：       5600.00
超管理器厂商：   KVM
虚拟化类型：     完全
L1d 缓存：       48K
L1i 缓存：       64K
L2 缓存：        2048K
L3 缓存：        516096K
NUMA 节点0 CPU： 0-7
标记：           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx_vnni avx512_bf16 wbnoinvd ida arat hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm uintr md_clear serialize tsxldtrk arch_lbr amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           30Gi        20Gi       1.2Gi       2.0Mi       9.1Gi       9.6Gi
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

测试场景	并发数	QPS	TPS	平均延迟(ms)	95%延迟(ms)	CPU软中断(%)	CPU用户(%)	CPU系统(%)	CPU等待(%)	IO利用率(%)	测试时间段
oltp_point_select	1	15,625	15,625	0.06	0.07	0.5	1.8	0.9	0.8	22.3	2025-11-23 19:27:06 ~ 2025-11-23 19:27:36
oltp_point_select	8	113,189	113,189	0.07	0.08	4.7	15.6	7.6	4.7	78.1	2025-11-23 19:27:38 ~ 2025-11-23 19:28:08
oltp_point_select	16	195,783	195,783	0.08	0.10	9.1	31.9	16.4	3.9	90.4	2025-11-23 19:28:10 ~ 2025-11-23 19:28:40
oltp_point_select	32	302,140	302,140	0.11	0.16	13.1	46.5	30.2	0.8	93.8	2025-11-23 19:28:42 ~ 2025-11-23 19:29:12
oltp_point_select	64	326,549	326,549	0.20	0.29	13.6	47.2	33.4	0.0	90.1	2025-11-23 19:29:14 ~ 2025-11-23 19:29:44
oltp_point_select	128	310,429	310,429	0.41	0.58	13.2	47.4	33.5	0.0	81.1	2025-11-23 19:29:46 ~ 2025-11-23 19:30:16
oltp_read_only	1	9,311	582	1.72	2.03	0.3	5.6	0.6	0.2	5.0	2025-11-23 19:30:18 ~ 2025-11-23 19:30:48
oltp_read_only	8	59,695	3,731	2.14	2.43	2.7	48.4	5.5	1.1	27.2	2025-11-23 19:30:50 ~ 2025-11-23 19:31:20
oltp_read_only	16	76,820	4,801	3.33	4.57	3.9	70.1	8.5	0.4	31.7	2025-11-23 19:31:22 ~ 2025-11-23 19:31:52
oltp_read_only	32	84,023	5,251	6.09	8.58	3.9	79.1	9.6	0.1	31.6	2025-11-23 19:31:54 ~ 2025-11-23 19:32:24
oltp_read_only	64	85,283	5,330	12.00	15.55	3.9	80.2	10.3	0.0	31.0	2025-11-23 19:32:26 ~ 2025-11-23 19:32:56
oltp_read_only	128	85,127	5,320	24.05	27.17	3.7	79.4	10.1	0.0	28.7	2025-11-23 19:32:58 ~ 2025-11-23 19:33:29
oltp_read_write	1	6,868	343	2.91	3.68	0.4	5.8	2.2	3.9	78.4	2025-11-23 19:33:31 ~ 2025-11-23 19:34:01
oltp_read_write	8	44,801	2,240	3.57	4.65	2.7	43.5	9.2	8.5	96.9	2025-11-23 19:34:03 ~ 2025-11-23 19:34:33
oltp_read_write	16	66,062	3,303	4.84	6.55	4.1	62.1	11.4	3.7	96.5	2025-11-23 19:34:35 ~ 2025-11-23 19:35:05
oltp_read_write	32	78,590	3,930	8.14	11.45	4.4	73.3	12.1	1.3	94.8	2025-11-23 19:35:07 ~ 2025-11-23 19:35:37
oltp_read_write	64	83,049	4,152	15.41	25.28	4.3	76.3	12.0	0.5	89.1	2025-11-23 19:35:39 ~ 2025-11-23 19:36:09
oltp_read_write	128	84,131	4,207	30.41	94.10	4.2	75.7	11.9	0.4	83.4	2025-11-23 19:36:11 ~ 2025-11-23 19:36:41
oltp_write_only	1	6,909	1,152	0.87	1.37	0.4	4.0	1.7	5.7	94.9	2025-11-23 19:36:43 ~ 2025-11-23 19:37:14
oltp_write_only	8	38,470	6,412	1.25	1.93	2.0	22.2	7.5	7.8	97.7	2025-11-23 19:37:16 ~ 2025-11-23 19:37:46
oltp_write_only	16	57,604	9,601	1.67	2.43	3.2	28.4	10.1	7.1	97.6	2025-11-23 19:37:48 ~ 2025-11-23 19:38:18
oltp_write_only	32	88,163	14,694	2.18	3.13	5.1	41.1	14.4	4.7	97.6	2025-11-23 19:38:20 ~ 2025-11-23 19:38:50
oltp_write_only	64	112,561	18,760	3.41	4.74	6.1	52.3	17.9	2.5	97.3	2025-11-23 19:38:52 ~ 2025-11-23 19:39:22
oltp_write_only	128	105,554	17,592	7.27	9.22	5.6	49.4	16.8	2.3	94.8	2025-11-23 19:39:24 ~ 2025-11-23 19:39:54

第六章：aliyun.trx1.repl 环境详细报告

测试时间: 2025-12-01 18:26:22
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 517 条记录

测试配置信息

=== 测试配置信息 ===
MYSQL_HOST: 10.127.33.154
MYSQL_PORT: 3316
TABLES: 16
TABLE_SIZE: 100000
TEST_TIME: 10

MySQL配置参数

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	1

压测服务器配置

=== CPU 信息 ===
架构：           x86_64
CPU 运行模式：   32-bit, 64-bit
字节序：         Little Endian
CPU:             8
在线 CPU 列表：  0-7
每个核的线程数： 2
每个座的核数：   4
座：             1
NUMA 节点：      1
厂商 ID：        GenuineIntel
BIOS Vendor ID:  Alibaba Cloud
CPU 系列：       6
型号：           173
型号名称：       Intel(R) Xeon(R) 6982P-C
BIOS Model name: pc-i440fx-2.1
步进：           1
CPU MHz：        3600.000
CPU 最大 MHz：   3900.0000
CPU 最小 MHz：   800.0000
BogoMIPS：       5600.00
超管理器厂商：   KVM
虚拟化类型：     完全
L1d 缓存：       48K
L1i 缓存：       64K
L2 缓存：        2048K
L3 缓存：        516096K
NUMA 节点0 CPU： 0-7
标记：           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx_vnni avx512_bf16 wbnoinvd ida arat hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm uintr md_clear serialize tsxldtrk arch_lbr amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           30Gi        21Gi       6.7Gi       2.0Mi       2.8Gi       8.8Gi
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

测试场景	并发数	QPS	TPS	平均延迟(ms)	95%延迟(ms)	CPU软中断(%)	CPU用户(%)	CPU系统(%)	CPU等待(%)	IO利用率(%)	测试时间段
oltp_point_select	1	17,027	17,027	0.06	0.06	0.5	1.5	0.9	0.2	4.6	2025-12-01 18:21:28 ~ 2025-12-01 18:21:38
oltp_point_select	8	109,505	109,505	0.07	0.09	4.2	14.3	6.8	0.4	12.2	2025-12-01 18:21:40 ~ 2025-12-01 18:21:50
oltp_point_select	16	190,769	190,769	0.08	0.11	8.9	28.6	15.7	0.2	8.5	2025-12-01 18:21:52 ~ 2025-12-01 18:22:02
oltp_point_select	32	287,309	287,309	0.11	0.18	12.7	41.0	28.7	0.0	6.5	2025-12-01 18:22:04 ~ 2025-12-01 18:22:14
oltp_point_select	64	329,548	329,548	0.19	0.30	13.0	43.3	30.9	0.0	3.8	2025-12-01 18:22:16 ~ 2025-12-01 18:22:26
oltp_point_select	128	301,471	301,471	0.42	0.60	12.7	42.3	31.6	0.0	2.5	2025-12-01 18:22:28 ~ 2025-12-01 18:22:38
oltp_read_only	1	11,207	700	1.43	1.50	0.4	4.1	0.6	0.0	0.1	2025-12-01 18:22:40 ~ 2025-12-01 18:22:50
oltp_read_only	8	73,855	4,616	1.73	1.93	3.4	35.6	6.2	0.0	0.6	2025-12-01 18:22:52 ~ 2025-12-01 18:23:02
oltp_read_only	16	103,284	6,455	2.48	3.19	5.3	55.6	11.5	0.0	0.7	2025-12-01 18:23:04 ~ 2025-12-01 18:23:14
oltp_read_only	32	120,653	7,541	4.24	5.88	5.5	65.8	13.0	0.0	0.8	2025-12-01 18:23:16 ~ 2025-12-01 18:23:26
oltp_read_only	64	125,685	7,855	8.14	10.84	5.2	67.2	13.8	0.0	0.8	2025-12-01 18:23:28 ~ 2025-12-01 18:23:38
oltp_read_only	128	122,608	7,663	16.68	19.29	5.3	65.4	13.8	0.0	0.6	2025-12-01 18:23:40 ~ 2025-12-01 18:23:50
oltp_read_write	1	8,125	406	2.46	2.86	0.3	3.6	0.9	2.1	52.2	2025-12-01 18:23:52 ~ 2025-12-01 18:24:02
oltp_read_write	8	51,348	2,567	3.11	3.89	2.7	26.9	6.1	4.4	81.0	2025-12-01 18:24:04 ~ 2025-12-01 18:24:14
oltp_read_write	16	76,515	3,826	4.18	5.18	4.1	42.0	10.0	3.2	83.1	2025-12-01 18:24:16 ~ 2025-12-01 18:24:26
oltp_read_write	32	98,436	4,922	6.50	8.58	5.0	53.8	13.1	1.5	82.1	2025-12-01 18:24:28 ~ 2025-12-01 18:24:38
oltp_read_write	64	109,191	5,460	11.71	17.95	5.3	58.7	14.0	0.7	71.0	2025-12-01 18:24:40 ~ 2025-12-01 18:24:51
oltp_read_write	128	111,512	5,576	22.89	38.25	5.5	62.8	14.7	0.5	51.9	2025-12-01 18:24:53 ~ 2025-12-01 18:25:03
oltp_write_only	1	5,832	972	1.03	1.44	0.4	2.5	1.1	4.8	90.0	2025-12-01 18:25:05 ~ 2025-12-01 18:25:15
oltp_write_only	8	27,926	4,654	1.72	2.43	1.5	10.3	3.8	6.1	89.2	2025-12-01 18:25:17 ~ 2025-12-01 18:25:27
oltp_write_only	16	36,521	6,087	2.63	3.43	2.1	13.7	5.1	4.8	78.9	2025-12-01 18:25:29 ~ 2025-12-01 18:25:39
oltp_write_only	32	52,252	8,709	3.67	4.82	2.8	18.9	7.3	3.8	70.4	2025-12-01 18:25:41 ~ 2025-12-01 18:25:51
oltp_write_only	64	86,217	14,370	4.45	6.55	4.4	31.3	12.3	3.2	80.9	2025-12-01 18:25:53 ~ 2025-12-01 18:26:03
oltp_write_only	128	95,690	15,948	8.00	12.08	4.7	32.8	12.8	2.2	74.1	2025-12-01 18:26:05 ~ 2025-12-01 18:26:16

第七章：ali.repl.rtt0.7 环境详细报告

测试时间: 2025-12-05 15:02:51
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 4414 条记录

测试配置信息

=== 测试配置信息 ===
MYSQL_HOST: 10.127.33.154
MYSQL_PORT: 3316
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	2

压测服务器配置

=== CPU 信息 ===
架构：           x86_64
CPU 运行模式：   32-bit, 64-bit
字节序：         Little Endian
CPU:             8
在线 CPU 列表：  0-7
每个核的线程数： 2
每个座的核数：   4
座：             1
NUMA 节点：      1
厂商 ID：        GenuineIntel
BIOS Vendor ID:  Alibaba Cloud
CPU 系列：       6
型号：           173
型号名称：       Intel(R) Xeon(R) 6982P-C
BIOS Model name: pc-i440fx-2.1
步进：           1
CPU MHz：        3600.289
CPU 最大 MHz：   3900.0000
CPU 最小 MHz：   800.0000
BogoMIPS：       5600.00
超管理器厂商：   KVM
虚拟化类型：     完全
L1d 缓存：       48K
L1i 缓存：       64K
L2 缓存：        2048K
L3 缓存：        516096K
NUMA 节点0 CPU： 0-7
标记：           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx_vnni avx512_bf16 wbnoinvd ida arat hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm uintr md_clear serialize tsxldtrk arch_lbr amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           30Gi        19Gi       546Mi       2.0Mi        11Gi        11Gi
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

测试场景	并发数	QPS	TPS	平均延迟(ms)	95%延迟(ms)	CPU软中断(%)	CPU用户(%)	CPU系统(%)	CPU等待(%)	IO利用率(%)	测试时间段
oltp_point_select	1	14,484	14,484	0.07	0.07	0.7	1.7	1.0	0.8	21.7	2025-12-05 14:50:30 ~ 2025-12-05 14:51:00
oltp_point_select	8	96,810	96,810	0.08	0.09	4.1	13.1	6.3	4.4	74.8	2025-12-05 14:51:02 ~ 2025-12-05 14:51:32
oltp_point_select	16	168,662	168,662	0.09	0.12	8.7	29.3	15.5	3.6	87.4	2025-12-05 14:51:34 ~ 2025-12-05 14:52:04
oltp_point_select	32	254,690	254,690	0.13	0.19	12.4	44.3	27.8	1.2	93.5	2025-12-05 14:52:06 ~ 2025-12-05 14:52:36
oltp_point_select	64	271,234	271,234	0.24	0.54	12.9	46.0	29.4	0.5	90.2	2025-12-05 14:52:38 ~ 2025-12-05 14:53:08
oltp_point_select	128	235,929	235,929	0.54	1.12	12.5	45.0	24.6	0.6	79.5	2025-12-05 14:53:10 ~ 2025-12-05 14:53:40
oltp_read_only	1	9,124	570	1.75	2.07	0.3	5.4	0.5	0.2	5.8	2025-12-05 14:53:42 ~ 2025-12-05 14:54:12
oltp_read_only	8	55,926	3,495	2.29	2.66	2.9	44.9	5.1	1.3	30.4	2025-12-05 14:54:14 ~ 2025-12-05 14:54:44
oltp_read_only	16	73,447	4,590	3.48	4.65	4.3	66.8	9.4	0.5	35.5	2025-12-05 14:54:46 ~ 2025-12-05 14:55:16
oltp_read_only	32	81,446	5,090	6.28	8.90	4.3	77.0	10.9	0.1	36.8	2025-12-05 14:55:18 ~ 2025-12-05 14:55:48
oltp_read_only	64	83,524	5,220	12.25	16.71	3.9	79.2	11.3	0.0	35.3	2025-12-05 14:55:50 ~ 2025-12-05 14:56:20
oltp_read_only	128	83,351	5,209	24.55	28.16	3.9	77.7	11.1	0.0	32.2	2025-12-05 14:56:22 ~ 2025-12-05 14:56:53
oltp_read_write	1	6,225	311	3.21	3.96	0.4	5.6	2.1	1.9	57.9	2025-12-05 14:56:55 ~ 2025-12-05 14:57:25
oltp_read_write	8	39,379	1,969	4.06	5.00	2.6	37.7	8.7	5.3	94.0	2025-12-05 14:57:27 ~ 2025-12-05 14:57:57
oltp_read_write	16	62,234	3,112	5.14	6.55	4.3	59.8	12.1	2.1	86.0	2025-12-05 14:57:59 ~ 2025-12-05 14:58:29
oltp_read_write	32	74,702	3,735	8.56	12.08	4.7	71.9	13.7	0.8	81.7	2025-12-05 14:58:31 ~ 2025-12-05 14:59:01
oltp_read_write	64	78,823	3,941	16.23	27.66	4.6	75.1	13.1	0.4	80.9	2025-12-05 14:59:03 ~ 2025-12-05 14:59:33
oltp_read_write	128	0	0	0.00	0.00	0.6	2.2	0.9	1.7	28.4	2025-12-05 14:59:35 ~ 2025-12-05 14:59:36
oltp_write_only	1	4,876	813	1.23	1.47	0.3	2.9	1.1	1.1	19.0	2025-12-05 14:59:38 ~ 2025-12-05 15:00:08
oltp_write_only	8	26,828	4,471	1.79	2.26	1.7	15.0	5.1	2.7	48.4	2025-12-05 15:00:10 ~ 2025-12-05 15:00:40
oltp_write_only	16	41,624	6,937	2.31	2.91	2.8	23.8	8.2	3.1	57.6	2025-12-05 15:00:42 ~ 2025-12-05 15:01:12
oltp_write_only	32	57,505	9,584	3.34	4.49	3.6	31.1	10.9	2.9	62.5	2025-12-05 15:01:14 ~ 2025-12-05 15:01:44
oltp_write_only	64	76,301	12,717	5.03	7.43	4.8	40.4	14.4	2.8	70.4	2025-12-05 15:01:46 ~ 2025-12-05 15:02:16
oltp_write_only	128	86,433	14,406	8.88	13.22	5.3	44.7	16.4	2.5	75.2	2025-12-05 15:02:18 ~ 2025-12-05 15:02:48

第八章：aws.io2.trx1 环境详细报告

测试时间: 2025-11-30 09:15:26
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 5679 条记录

测试配置信息

=== 测试配置信息 ===
MYSQL_HOST: 10.1.2.89
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	1

压测服务器配置

=== CPU 信息 ===
架构：           x86_64
CPU 运行模式：   32-bit, 64-bit
字节序：         Little Endian
CPU:             8
在线 CPU 列表：  0-7
每个核的线程数： 2
每个座的核数：   4
座：             1
NUMA 节点：      1
厂商 ID：        GenuineIntel
BIOS Vendor ID:  Intel(R) Corporation
CPU 系列：       6
型号：           106
型号名称：       Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz
BIOS Model name: Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz
步进：           6
CPU MHz：        2899.956
BogoMIPS：       5799.91
超管理器厂商：   KVM
虚拟化类型：     完全
L1d 缓存：       48K
L1i 缓存：       32K
L2 缓存：        1280K
L3 缓存：        55296K
NUMA 节点0 CPU： 0-7
标记：           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves wbnoinvd ida arat avx512vbmi pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq rdpid md_clear flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           30Gi        18Gi       243Mi        24Mi        11Gi        11Gi
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

测试场景	并发数	QPS	TPS	平均延迟(ms)	95%延迟(ms)	CPU软中断(%)	CPU用户(%)	CPU系统(%)	CPU等待(%)	IO利用率(%)	测试时间段
oltp_point_select	1	11,888	11,888	0.08	0.09	0.6	2.7	1.1	4.0	50.3	2025-11-30 09:02:35 ~ 2025-11-30 09:03:05
oltp_point_select	8	75,291	75,291	0.11	0.12	5.1	25.9	10.7	6.1	82.0	2025-11-30 09:03:07 ~ 2025-11-30 09:03:37
oltp_point_select	16	127,179	127,179	0.13	0.18	7.8	42.7	22.0	2.6	86.1	2025-11-30 09:03:39 ~ 2025-11-30 09:04:09
oltp_point_select	32	161,447	161,447	0.20	0.32	7.4	54.4	26.7	0.8	86.5	2025-11-30 09:04:11 ~ 2025-11-30 09:04:41
oltp_point_select	64	162,516	162,516	0.39	0.56	7.6	55.8	27.9	0.0	85.5	2025-11-30 09:04:43 ~ 2025-11-30 09:05:13
oltp_point_select	128	155,947	155,947	0.82	1.06	7.7	57.8	28.6	0.0	81.8	2025-11-30 09:05:15 ~ 2025-11-30 09:05:46
oltp_read_only	1	7,068	442	2.26	2.86	0.4	6.0	0.5	0.4	7.9	2025-11-30 09:05:48 ~ 2025-11-30 09:06:18
oltp_read_only	8	39,993	2,500	3.20	3.82	3.1	55.9	6.2	1.9	35.5	2025-11-30 09:06:20 ~ 2025-11-30 09:06:50
oltp_read_only	16	47,383	2,961	5.40	8.74	3.0	73.2	8.3	0.8	39.2	2025-11-30 09:06:52 ~ 2025-11-30 09:07:22
oltp_read_only	32	50,146	3,134	10.21	14.46	2.7	81.9	9.9	0.1	38.8	2025-11-30 09:07:24 ~ 2025-11-30 09:07:54
oltp_read_only	64	49,763	3,110	20.57	23.95	2.8	81.8	9.9	0.0	36.6	2025-11-30 09:07:56 ~ 2025-11-30 09:08:26
oltp_read_only	128	49,209	3,076	41.59	45.79	2.8	80.9	10.1	0.0	35.3	2025-11-30 09:08:28 ~ 2025-11-30 09:08:58
oltp_read_write	1	5,074	254	3.94	4.82	0.3	5.6	1.9	4.6	68.4	2025-11-30 09:09:00 ~ 2025-11-30 09:09:30
oltp_read_write	8	29,077	1,454	5.50	6.79	2.3	40.2	8.5	10.0	96.1	2025-11-30 09:09:32 ~ 2025-11-30 09:10:02
oltp_read_write	16	41,737	2,087	7.66	10.09	3.1	61.4	10.3	4.4	96.0	2025-11-30 09:10:04 ~ 2025-11-30 09:10:34
oltp_read_write	32	47,906	2,395	13.35	19.29	2.8	70.4	10.0	2.0	90.2	2025-11-30 09:10:36 ~ 2025-11-30 09:11:06
oltp_read_write	64	49,160	2,458	26.02	50.11	2.8	72.8	10.7	1.2	81.6	2025-11-30 09:11:08 ~ 2025-11-30 09:11:39
oltp_read_write	128	50,050	2,503	51.10	125.52	3.0	76.5	11.0	0.7	76.1	2025-11-30 09:11:41 ~ 2025-11-30 09:12:11
oltp_write_only	1	3,575	596	1.68	2.57	0.2	2.7	1.2	7.5	96.1	2025-11-30 09:12:13 ~ 2025-11-30 09:12:43
oltp_write_only	8	21,479	3,580	2.23	3.07	1.6	16.4	5.0	9.7	96.2	2025-11-30 09:12:45 ~ 2025-11-30 09:13:15
oltp_write_only	16	37,696	6,283	2.55	3.49	2.8	28.8	8.5	7.4	96.0	2025-11-30 09:13:17 ~ 2025-11-30 09:13:47
oltp_write_only	32	59,664	9,944	3.22	4.41	4.0	44.1	13.1	4.4	95.9	2025-11-30 09:13:49 ~ 2025-11-30 09:14:19
oltp_write_only	64	76,279	12,713	5.03	7.30	4.3	55.4	15.5	2.4	95.0	2025-11-30 09:14:21 ~ 2025-11-30 09:14:51
oltp_write_only	128	79,531	13,255	9.65	14.46	4.4	57.5	16.0	1.9	87.8	2025-11-30 09:14:53 ~ 2025-11-30 09:15:24

第九章：aws.io2 环境详细报告

测试时间: 2025-11-30 08:10:38
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 1879 条记录

测试配置信息

=== 测试配置信息 ===
MYSQL_HOST: 10.1.2.89
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	2

压测服务器配置

=== CPU 信息 ===
架构：           x86_64
CPU 运行模式：   32-bit, 64-bit
字节序：         Little Endian
CPU:             8
在线 CPU 列表：  0-7
每个核的线程数： 2
每个座的核数：   4
座：             1
NUMA 节点：      1
厂商 ID：        GenuineIntel
BIOS Vendor ID:  Intel(R) Corporation
CPU 系列：       6
型号：           106
型号名称：       Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz
BIOS Model name: Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz
步进：           6
CPU MHz：        2899.956
BogoMIPS：       5799.91
超管理器厂商：   KVM
虚拟化类型：     完全
L1d 缓存：       48K
L1i 缓存：       32K
L2 缓存：        1280K
L3 缓存：        55296K
NUMA 节点0 CPU： 0-7
标记：           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves wbnoinvd ida arat avx512vbmi pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq rdpid md_clear flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           30Gi        18Gi       251Mi        24Mi        12Gi        11Gi
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

测试场景	并发数	QPS	TPS	平均延迟(ms)	95%延迟(ms)	CPU软中断(%)	CPU用户(%)	CPU系统(%)	CPU等待(%)	IO利用率(%)	测试时间段
oltp_point_select	1	12,004	12,004	0.08	0.09	0.6	2.8	0.8	0.9	20.1	2025-11-30 07:57:47 ~ 2025-11-30 07:58:17
oltp_point_select	8	75,171	75,171	0.11	0.12	5.2	27.1	8.4	4.6	70.1	2025-11-30 07:58:19 ~ 2025-11-30 07:58:49
oltp_point_select	16	126,712	126,712	0.13	0.18	8.3	44.3	20.8	2.3	83.8	2025-11-30 07:58:51 ~ 2025-11-30 07:59:21
oltp_point_select	32	160,866	160,866	0.20	0.32	7.6	55.6	27.6	0.7	88.5	2025-11-30 07:59:23 ~ 2025-11-30 07:59:53
oltp_point_select	64	157,480	157,480	0.41	0.55	7.6	57.3	28.3	0.0	86.7	2025-11-30 07:59:55 ~ 2025-11-30 08:00:25
oltp_point_select	128	153,448	153,448	0.83	1.08	7.5	55.8	27.9	0.0	78.9	2025-11-30 08:00:27 ~ 2025-11-30 08:00:58
oltp_read_only	1	7,039	440	2.27	2.86	0.4	6.0	0.6	0.4	8.2	2025-11-30 08:01:00 ~ 2025-11-30 08:01:30
oltp_read_only	8	39,720	2,482	3.22	3.82	3.1	56.1	6.5	2.0	36.4	2025-11-30 08:01:32 ~ 2025-11-30 08:02:02
oltp_read_only	16	47,558	2,972	5.38	7.70	2.7	75.0	7.7	0.9	39.3	2025-11-30 08:02:04 ~ 2025-11-30 08:02:34
oltp_read_only	32	49,995	3,125	10.24	14.73	2.8	82.1	10.0	0.1	39.2	2025-11-30 08:02:36 ~ 2025-11-30 08:03:06
oltp_read_only	64	49,821	3,114	20.55	23.95	2.8	82.1	10.3	0.0	38.9	2025-11-30 08:03:08 ~ 2025-11-30 08:03:38
oltp_read_only	128	49,165	3,073	41.63	45.79	2.8	82.0	10.5	0.0	36.4	2025-11-30 08:03:40 ~ 2025-11-30 08:04:10
oltp_read_write	1	6,743	337	2.96	3.89	0.4	7.3	2.5	2.5	50.3	2025-11-30 08:04:12 ~ 2025-11-30 08:04:42
oltp_read_write	8	35,997	1,800	4.44	5.88	2.8	53.1	10.6	4.7	94.0	2025-11-30 08:04:44 ~ 2025-11-30 08:05:14
oltp_read_write	16	45,274	2,264	7.07	10.65	2.9	69.0	11.1	2.4	85.7	2025-11-30 08:05:16 ~ 2025-11-30 08:05:46
oltp_read_write	32	50,664	2,533	12.63	19.65	2.9	78.5	11.3	0.5	76.2	2025-11-30 08:05:48 ~ 2025-11-30 08:06:18
oltp_read_write	64	51,002	2,550	25.08	47.47	2.8	77.0	11.0	0.3	71.6	2025-11-30 08:06:20 ~ 2025-11-30 08:06:51
oltp_read_write	128	50,315	2,516	50.83	139.85	3.0	78.0	11.5	0.4	71.6	2025-11-30 08:06:53 ~ 2025-11-30 08:07:23
oltp_write_only	1	8,881	1,480	0.68	1.61	0.5	5.9	2.3	2.3	31.3	2025-11-30 08:07:25 ~ 2025-11-30 08:07:55
oltp_write_only	8	44,059	7,343	1.09	2.00	3.2	34.6	12.0	4.8	71.6	2025-11-30 08:07:57 ~ 2025-11-30 08:08:27
oltp_write_only	16	64,137	10,690	1.50	2.52	4.4	49.6	16.0	3.7	78.3	2025-11-30 08:08:29 ~ 2025-11-30 08:08:59
oltp_write_only	32	79,024	13,171	2.43	4.25	4.5	58.9	17.1	2.0	81.3	2025-11-30 08:09:01 ~ 2025-11-30 08:09:31
oltp_write_only	64	79,754	13,292	4.81	13.70	4.5	59.5	17.6	1.6	81.6	2025-11-30 08:09:33 ~ 2025-11-30 08:10:03
oltp_write_only	128	70,019	11,670	10.96	38.94	4.1	53.5	16.8	2.3	84.7	2025-11-30 08:10:05 ~ 2025-11-30 08:10:35

第十章：aws.io1 环境详细报告

测试时间: 2025-11-28 11:09:53
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 7925 条记录

测试配置信息

=== 测试配置信息 ===
MYSQL_HOST: 10.1.0.47
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	2

压测服务器配置

=== CPU 信息 ===
架构：           x86_64
CPU 运行模式：   32-bit, 64-bit
字节序：         Little Endian
CPU:             8
在线 CPU 列表：  0-7
每个核的线程数： 2
每个座的核数：   4
座：             1
NUMA 节点：      1
厂商 ID：        GenuineIntel
BIOS Vendor ID:  Intel(R) Corporation
CPU 系列：       6
型号：           143
型号名称：       Intel(R) Xeon(R) Platinum 8488C
BIOS Model name: Intel(R) Xeon(R) Platinum 8488C
步进：           8
CPU MHz：        2400.000
BogoMIPS：       4800.00
超管理器厂商：   KVM
虚拟化类型：     完全
L1d 缓存：       48K
L1i 缓存：       32K
L2 缓存：        2048K
L3 缓存：        107520K
NUMA 节点0 CPU： 0-7
标记：           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq monitor ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx_vnni avx512_bf16 wbnoinvd ida arat avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq rdpid cldemote movdiri movdir64b md_clear serialize amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           30Gi        21Gi       253Mi        16Mi       8.9Gi       8.7Gi
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

测试场景	并发数	QPS	TPS	平均延迟(ms)	95%延迟(ms)	CPU软中断(%)	CPU用户(%)	CPU系统(%)	CPU等待(%)	IO利用率(%)	测试时间段
oltp_point_select	1	1,835	1,835	0.54	0.72	0.3	2.4	1.0	8.6	89.6	2025-11-28 10:57:00 ~ 2025-11-28 10:57:30
oltp_point_select	8	56,871	56,871	0.14	0.49	3.1	14.2	5.2	5.4	64.7	2025-11-28 10:57:32 ~ 2025-11-28 10:58:02
oltp_point_select	16	170,296	170,296	0.09	0.13	7.4	43.1	19.7	3.1	90.8	2025-11-28 10:58:04 ~ 2025-11-28 10:58:34
oltp_point_select	32	251,905	251,905	0.13	0.20	6.2	58.5	25.3	1.3	94.2	2025-11-28 10:58:36 ~ 2025-11-28 10:59:06
oltp_point_select	64	249,718	249,718	0.26	0.36	7.1	59.0	28.1	0.0	90.9	2025-11-28 10:59:08 ~ 2025-11-28 10:59:38
oltp_point_select	128	236,283	236,283	0.54	0.72	6.5	59.9	27.8	0.0	83.4	2025-11-28 10:59:40 ~ 2025-11-28 11:00:10
oltp_read_only	1	1,845	115	8.67	10.46	0.3	2.2	0.3	0.1	1.5	2025-11-28 11:00:12 ~ 2025-11-28 11:00:42
oltp_read_only	8	28,879	1,805	4.43	7.43	2.0	26.8	3.6	1.0	20.0	2025-11-28 11:00:44 ~ 2025-11-28 11:01:14
oltp_read_only	16	64,551	4,034	3.96	5.88	2.7	66.8	7.7	0.7	37.5	2025-11-28 11:01:16 ~ 2025-11-28 11:01:46
oltp_read_only	32	73,173	4,573	6.99	11.24	2.5	79.5	9.2	0.3	39.7	2025-11-28 11:01:48 ~ 2025-11-28 11:02:18
oltp_read_only	64	74,400	4,650	13.76	19.65	2.6	81.9	10.0	0.0	37.2	2025-11-28 11:02:20 ~ 2025-11-28 11:02:50
oltp_read_only	128	74,024	4,626	27.65	31.37	2.5	81.6	10.0	0.0	36.0	2025-11-28 11:02:52 ~ 2025-11-28 11:03:22
oltp_read_write	1	1,924	96	10.39	13.95	0.3	3.0	1.2	2.6	37.3	2025-11-28 11:03:24 ~ 2025-11-28 11:03:54
oltp_read_write	8	24,967	1,248	6.41	9.73	1.6	26.0	6.0	8.2	92.0	2025-11-28 11:03:56 ~ 2025-11-28 11:04:27
oltp_read_write	16	54,742	2,737	5.84	9.06	2.7	59.0	10.1	4.5	95.7	2025-11-28 11:04:29 ~ 2025-11-28 11:04:59
oltp_read_write	32	68,211	3,411	9.38	13.70	2.6	73.2	10.3	2.2	89.3	2025-11-28 11:05:01 ~ 2025-11-28 11:05:31
oltp_read_write	64	71,816	3,591	17.81	29.72	2.7	78.2	11.2	0.7	88.3	2025-11-28 11:05:33 ~ 2025-11-28 11:06:03
oltp_read_write	128	70,575	3,529	36.24	106.75	2.7	76.1	11.0	1.2	88.7	2025-11-28 11:06:05 ~ 2025-11-28 11:06:35
oltp_write_only	1	1,786	298	3.36	5.09	0.3	2.6	1.1	3.4	35.3	2025-11-28 11:06:37 ~ 2025-11-28 11:07:07
oltp_write_only	8	19,047	3,174	2.52	4.82	1.4	13.9	4.7	6.8	65.8	2025-11-28 11:07:09 ~ 2025-11-28 11:07:39
oltp_write_only	16	39,006	6,501	2.46	4.65	2.2	25.9	8.5	7.0	80.9	2025-11-28 11:07:41 ~ 2025-11-28 11:08:11
oltp_write_only	32	68,442	11,407	2.80	5.37	3.0	41.0	12.3	5.7	87.6	2025-11-28 11:08:13 ~ 2025-11-28 11:08:43
oltp_write_only	64	94,216	15,703	4.07	7.70	3.6	53.5	15.8	3.8	91.0	2025-11-28 11:08:45 ~ 2025-11-28 11:09:16
oltp_write_only	128	66,370	11,062	11.37	24.38	2.5	39.9	12.5	5.2	96.3	2025-11-28 11:09:18 ~ 2025-11-28 11:09:51

第十一章：aws.gp3 环境详细报告

测试时间: 2025-11-28 11:28:11
测试工具: sysbench + tsar (按时间段精确匹配)
tsar数据样本: 8979 条记录

测试配置信息

=== 测试配置信息 ===
MYSQL_HOST: 10.1.0.52
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

mysql: [Warning] Using a password on the command line interface can be insecure.
Variable_name	Value
innodb_buffer_pool_size	17179869184
innodb_flush_log_at_trx_commit	2

压测服务器配置

=== CPU 信息 ===
架构：           x86_64
CPU 运行模式：   32-bit, 64-bit
字节序：         Little Endian
CPU:             8
在线 CPU 列表：  0-7
每个核的线程数： 2
每个座的核数：   4
座：             1
NUMA 节点：      1
厂商 ID：        GenuineIntel
BIOS Vendor ID:  (invalid)
CPU 系列：       6
型号：           143
型号名称：       Intel(R) Xeon(R) Platinum 8488C
BIOS Model name: (invalid)
步进：           8
CPU MHz：        3437.734
BogoMIPS：       4800.00
超管理器厂商：   KVM
虚拟化类型：     完全
L1d 缓存：       48K
L1i 缓存：       32K
L2 缓存：        2048K
L3 缓存：        107520K
NUMA 节点0 CPU： 0-7
标记：           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq monitor ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx_vnni avx512_bf16 wbnoinvd ida arat avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq rdpid cldemote movdiri movdir64b md_clear serialize amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities

=== 内存信息 ===
              total        used        free      shared  buff/cache   available
Mem:           30Gi        21Gi       514Mi        16Mi       8.8Gi       8.8Gi
Swap:            0B          0B          0B

性能测试结果汇总 (含CPU/IO监控数据)

测试场景	并发数	QPS	TPS	平均延迟(ms)	95%延迟(ms)	CPU软中断(%)	CPU用户(%)	CPU系统(%)	CPU等待(%)	IO利用率(%)	测试时间段
oltp_point_select	1	2,316	2,316	0.43	0.67	0.3	1.8	0.5	0.3	4.6	2025-11-28 11:15:20 ~ 2025-11-28 11:15:50
oltp_point_select	8	60,437	60,437	0.13	0.46	3.0	16.4	6.1	4.7	59.8	2025-11-28 11:15:52 ~ 2025-11-28 11:16:23
oltp_point_select	16	162,670	162,670	0.10	0.14	7.2	43.6	20.4	3.6	91.5	2025-11-28 11:16:25 ~ 2025-11-28 11:16:55
oltp_point_select	32	232,535	232,535	0.14	0.23	6.6	58.1	26.7	1.4	94.6	2025-11-28 11:16:57 ~ 2025-11-28 11:17:27
oltp_point_select	64	228,321	228,321	0.28	0.39	6.9	59.1	28.1	0.0	92.8	2025-11-28 11:17:29 ~ 2025-11-28 11:17:59
oltp_point_select	128	217,381	217,381	0.59	0.78	6.4	59.6	28.1	0.0	86.7	2025-11-28 11:18:01 ~ 2025-11-28 11:18:31
oltp_read_only	1	1,692	106	9.45	10.65	0.3	2.2	0.4	0.1	2.0	2025-11-28 11:18:33 ~ 2025-11-28 11:19:03
oltp_read_only	8	31,915	1,995	4.01	6.67	1.8	34.3	4.6	1.5	26.1	2025-11-28 11:19:05 ~ 2025-11-28 11:19:35
oltp_read_only	16	59,828	3,739	4.28	6.21	2.7	67.8	8.3	0.9	40.5	2025-11-28 11:19:37 ~ 2025-11-28 11:20:07
oltp_read_only	32	66,972	4,186	7.64	11.24	2.4	79.6	9.5	0.3	42.0	2025-11-28 11:20:09 ~ 2025-11-28 11:20:39
oltp_read_only	64	67,678	4,230	15.13	22.28	2.6	81.4	10.1	0.0	41.4	2025-11-28 11:20:41 ~ 2025-11-28 11:21:11
oltp_read_only	128	67,480	4,217	30.33	34.33	2.4	81.4	10.0	0.0	38.4	2025-11-28 11:21:13 ~ 2025-11-28 11:21:43
oltp_read_write	1	1,741	87	11.48	15.00	0.3	3.2	1.2	3.1	38.8	2025-11-28 11:21:45 ~ 2025-11-28 11:22:15
oltp_read_write	8	19,019	951	8.41	17.32	1.3	25.3	5.9	15.7	94.5	2025-11-28 11:22:17 ~ 2025-11-28 11:22:47
oltp_read_write	16	42,144	2,107	7.59	15.00	2.2	50.3	8.9	10.8	94.7	2025-11-28 11:22:49 ~ 2025-11-28 11:23:19
oltp_read_write	32	60,885	3,044	10.51	15.83	2.4	71.0	10.2	2.7	90.0	2025-11-28 11:23:21 ~ 2025-11-28 11:23:51
oltp_read_write	64	64,869	3,243	19.72	33.72	2.5	75.7	10.7	1.0	87.9	2025-11-28 11:23:53 ~ 2025-11-28 11:24:24
oltp_read_write	128	63,936	3,197	40.01	116.80	2.6	76.2	10.7	1.4	89.4	2025-11-28 11:24:26 ~ 2025-11-28 11:24:56
oltp_write_only	1	1,689	282	3.55	5.99	0.3	2.9	1.1	4.4	42.9	2025-11-28 11:24:58 ~ 2025-11-28 11:25:28
oltp_write_only	8	17,630	2,938	2.72	5.67	1.2	18.0	5.5	7.8	72.3	2025-11-28 11:25:30 ~ 2025-11-28 11:26:00
oltp_write_only	16	34,757	5,793	2.76	5.67	1.9	26.9	8.3	8.0	84.9	2025-11-28 11:26:02 ~ 2025-11-28 11:26:32
oltp_write_only	32	36,656	6,109	5.24	15.00	1.7	25.6	7.7	17.7	95.5	2025-11-28 11:26:34 ~ 2025-11-28 11:27:04
oltp_write_only	64	43,519	7,253	8.82	29.72	2.0	29.3	9.1	20.9	97.5	2025-11-28 11:27:06 ~ 2025-11-28 11:27:36
oltp_write_only	128	52,980	8,830	14.49	44.98	2.3	34.6	11.0	22.3	98.1	2025-11-28 11:27:38 ~ 2025-11-28 11:28:09

附录：监控指标说明

监控数据说明

报告列名	tsar对应列	说明
CPU软中断(%)	sirq	软中断CPU使用率
CPU用户(%)	user	用户态CPU使用率
CPU系统(%)	sys	内核态CPU使用率
CPU等待(%)	wait	IO等待时间占用的CPU
IO利用率(%)	util (IO部分)	磁盘IO使用率

性能指标说明

QPS (Queries Per Second): 每秒查询数，衡量数据库处理查询的能力
TPS (Transactions Per Second): 每秒事务数，与QPS在点查询场景下相等
平均延迟: 所有请求的平均响应时间
95%延迟: 95%的请求响应时间不超过此值，更能反映用户体验

测试场景说明

场景	描述	主要指标
oltp_point_select	主键点查询	QPS, 延迟
oltp_read_only	只读事务(包含多表JOIN)	TPS, QPS
oltp_read_write	读写混合事务	TPS, 延迟
oltp_write_only	只写事务	TPS, IO利用率

数据来源说明

CPU/IO数据来源于tsar监控日志，按测试时间段精确匹配并计算平均值
系统监控数据与性能数据时间精确对应，确保数据准确性
测试使用sysbench工具，针对MySQL数据库进行标准化性能测试

报告生成时间: 2025-12-05 16:03:37

MySQL PreparedStatement 性能问题重现

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

MySQL PreparedStatement 性能问题重现

问题描述

在生产环境中发现，当使用 useServerPrepStmts=true 参数时，包含大量参数的 PreparedStatement 查询性能极差。通过系统测试发现，SQL 格式和长度对性能有巨大影响。

只需要一个空表就能稳定重现这个问题，可以给官方提交 bug 了

环境信息

MySQL版本: 5.7.29
JDBC驱动: mysql-connector-j-8.0.33
测试场景: 5万个大整数参数的 IN 查询
参数格式: 15位大整数（如 176302640511975）
重现代码: https://github.com/plantegg/MySQLPrepared

核心发现

🔥 SQL 格式对性能的巨大影响

我们发现 SQL 字符串的格式和长度 是影响服务器端预编译性能的关键因素：

SQL格式	SQL长度	false平均时间	true平均时间	性能差异
紧凑格式 (?,?,?)	100KB	35ms	645ms	慢18倍 ⭐ 最优
带换行格式	2.1MB	47ms	9,128ms	慢194倍
带换行+空格 (128)	6.5MB	52ms	27,839ms	慢535倍
带换行+大量空格 (128)	8.5MB	62ms	44,521ms	慢712倍 🔥 最差

关键结论:

✅ 最优化的紧凑格式 可以将服务器端性能提升 14倍（9,128ms → 645ms）
⚠️ 即使优化后，客户端预编译（35ms）仍比服务器端（645ms）快 18倍

重现步骤

1. 环境准备

创建测试表：

1	mysql -h your-host -P your-port -u your-user -p your-database < create_table.sql

create_table.sql 内容：

DROP TABLE IF EXISTS `large_table`;

CREATE TABLE `large_table` (
  `id` int(11) NOT NULL,
  `col1` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
  `col2` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
  -- ... col3-col19 ...
  `col20` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

2. 运行测试

使用脚本（推荐）

# 最优配置（紧凑格式）
./run_test.sh --host localhost --port 3306 --database test \
  --user root --password mypass --spaces 0

# 测试不同空格配置的影响
./run_test.sh --host localhost --port 3306 --database test \
  --user root --password mypass --spaces 128

# 查看帮助
./run_test.sh --help

使用 Maven

mvn compile exec:java \
    -Dexec.mainClass="com.test.PreparedStatementPerformanceTest" \
    -Ddb.host=localhost \
    -Ddb.port=3306 \
    -Ddb.name=test \
    -Ddb.user=root \
    -Ddb.password=mypassword \
    -Dparam.spaces=0

3. 参数说明

参数	默认值	说明
`--spaces`	128	参数之间的空格数量，0=最紧凑格式
`--rounds`	2	测试轮次

详细测试结果

测试 1: 紧凑格式 (spaces=0) ⭐ 推荐

SQL 示例: WHERE id IN (?,?,?,?,...)

配置: useServerPrepStmts=false
SQL长度: 100,151 字符 (~100KB)
平均执行时间: 35.0ms
Com_stmt_prepare: 0

配置: useServerPrepStmts=true  
SQL长度: 100,151 字符 (~100KB)
平均执行时间: 645.5ms
Com_stmt_prepare: 1

性能差异: 慢 18 倍

测试 2: 带换行格式 (旧版本)

SQL 示例:

WHERE id IN (?
                  ,
                    ?
                  ,
                    ?

配置: useServerPrepStmts=false
SQL长度: 2,100,111 字符 (~2.1MB)
平均执行时间: 47.0ms
Com_stmt_prepare: 0

配置: useServerPrepStmts=true
SQL长度: 2,100,111 字符 (~2.1MB)
平均执行时间: 9,128.5ms
Com_stmt_prepare: 1

性能差异: 慢 194 倍

测试 3: 带空格格式 (spaces=128)

SQL 示例: WHERE id IN (?,<128 spaces>?,<128 spaces>?,...)

配置: useServerPrepStmts=false
SQL长度: 6,500,023 字符 (~6.5MB)
平均执行时间: 52.0ms
Com_stmt_prepare: 0

配置: useServerPrepStmts=true
SQL长度: 6,500,023 字符 (~6.5MB)
平均执行时间: 27,839.5ms
Com_stmt_prepare: 1

性能差异: 慢 535 倍

测试 4: 带换行+大量空格 (极端情况)

配置: useServerPrepStmts=false
SQL长度: 8,499,983 字符 (~8.5MB)
平均执行时间: 62.5ms
Com_stmt_prepare: 0

配置: useServerPrepStmts=true
SQL长度: 8,499,983 字符 (~8.5MB)
平均执行时间: 44,521.5ms
Com_stmt_prepare: 1

性能差异: 慢 712 倍

性能分析

1. SQL 长度与性能的线性关系

服务器端预编译性能随 SQL 长度线性恶化：

100KB  SQL → 645ms    (基准)
2.1MB  SQL → 9,128ms  (14倍恶化)
6.5MB  SQL → 27,839ms (43倍恶化)
8.5MB  SQL → 44,521ms (69倍恶化)

2. 客户端预编译的稳定性

客户端预编译几乎不受 SQL 长度影响：

1
2
3

100KB  SQL → 35-47ms
8.5MB  SQL → 62ms
变化幅度: 仅 77%

3. 问题根因

根据 pstack 分析，服务器端预编译在处理大 SQL 时：

大量内存重分配:
- 50,000 次参数替换操作
- 每次替换需要在大 SQL 字符串中定位和替换
- my_realloc 和 memmove 频繁调用
字符串操作复杂度:
- O(SQL长度) × 参数数量 = 极高时间复杂度
- 单线程 100% CPU 占用
内存碎片化:
- 频繁的大块内存分配和释放
- 进一步降低性能

Thread 1 (Thread 0x7feeb8043640 (LWP 2508284)):
#0  0x00007ff302bb5515 in __memmove_avx512_unaligned_erms () from /lib64/libc.so.6
#1  0x0000000000efffe6 in my_realloc (key=<optimized out>, ptr=0x7fee5e907380, size=7192160, flags=<optimized out>) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/mysys/my_malloc.c:112
#2  0x0000000000d9a921 in String::mem_realloc (this=0x7feeb80424b0, alloc_length=7192155, force_on_heap=force_on_heap@entry=false) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/sql-common/sql_string.cc:128
#3  0x0000000000d9b9d4 in String::replace (this=this@entry=0x7feeb80424b0, offset=7119079, arg_length=arg_length@entry=1, to=0x7fee5c3f5810 "286381588518215", to_length=15) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/sql-common/sql_string.cc:804
#4  0x0000000000d9ba81 in String::replace (this=this@entry=0x7feeb80424b0, offset=<optimized out>, arg_length=arg_length@entry=1, to=...) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/sql-common/sql_string.cc:783
#5  0x0000000000d026e2 in Prepared_statement::insert_params (this=this@entry=0x7fee5c171fe0, null_array=null_array@entry=0x7fee5c45240a "", read_pos=0x7fee5c4ccc05 "\336\274y\206", <incomplete sequence \303>, read_pos@entry=0x7fee5c46c315 "\016r\342\320\355\242\002", data_end=0x7fee5c4cdd95 "", query=query@entry=0x7feeb80424b0) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/sql/sql_prepare.cc:924
#6  0x0000000000d03db6 in Prepared_statement::set_parameters (this=this@entry=0x7fee5c171fe0, expanded_query=expanded_query@entry=0x7feeb80424b0, packet=0x7fee5c46c315 "\016r\342\320\355\242\002", packet_end=<optimized out>) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/sql/sql_prepare.cc:3496
#7  0x0000000000d0772f in Prepared_statement::execute_loop (this=0x7fee5c171fe0, expanded_query=0x7feeb80424b0, open_cursor=<optimized out>, packet=<optimized out>, packet_end=<optimized out>) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/sql/sql_prepare.cc:3559
#8  0x0000000000d07aa4 in mysqld_stmt_execute (thd=thd@entry=0x7fee5c000b60, stmt_id=<optimized out>, flags=0, params=0x7fee5c45240a "", params_length=506251) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/sql/sql_prepare.cc:2582
#9  0x0000000000cdf6f5 in dispatch_command (thd=thd@entry=0x7fee5c000b60, com_data=com_data@entry=0x7feeb8042d40, command=COM_STMT_EXECUTE) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/sql/sql_parse.cc:1428
#10 0x0000000000ce00c7 in do_command (thd=thd@entry=0x7fee5c000b60) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/sql/sql_parse.cc:1032
#11 0x0000000000d9cc08 in handle_connection (arg=arg@entry=0x1eb0a010) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/sql/conn_handler/connection_handler_per_thread.cc:313
#12 0x00000000013fc4a4 in pfs_spawn_thread (arg=0x1ea71270) at /export/home/pb2/build/sb_0-37309218-1576676711.18/mysql-5.7.29/storage/perfschema/pfs.cc:2197
#13 0x00007ff30305b3fb in start_thread () from /lib64/libpthread.so.0
#14 0x00007ff302b0de83 in clone () from /lib64/libc.so.6

监控数据

# top 监控
PID     USER   %CPU  TIME+     COMMAND
2554029 mysql  99.3  4:40.64   mysqld  // 单线程 100%

# show processlist 观察
Id  User  Command  Time  State     Info
382 test  Execute  8     starting  NULL  // SQL 还在组装中

解决方案

✅ 方案 1: 使用客户端预编译 + 紧凑格式（强烈推荐）

// JDBC 连接串
String url = "jdbc:mysql://host:port/database?useServerPrepStmts=false";

// 运行测试
./run_test.sh --host localhost --port 3306 --database test \
  --user root --password mypass --spaces 0

优点:

✅ 性能最优：仅需 35ms
✅ 不受 SQL 长度影响
✅ 不受参数数量影响
✅ 稳定可靠

缺点:

⚠️ 无法享受服务器端查询计划缓存（但对 IN 查询意义不大）

🔄 方案 2: 优化 SQL 格式（如果必须使用服务器端预编译）

如果由于某些原因必须使用 useServerPrepStmts=true，则务必优化 SQL 格式：

// 使用最紧凑格式: ?,?,?,?
// 避免: ?\n  ,\n  ?

String url = "jdbc:mysql://host:port/database?useServerPrepStmts=true";
// 运行时使用 --spaces 0

性能: 645ms（相比未优化的 9,128ms 提升 14 倍）

🔧 方案 3: 分批查询

// 将 50,000 个参数拆分为 50 批，每批 1,000 个
int batchSize = 1000;
for (int i = 0; i < ids.size(); i += batchSize) {
    List<Long> batch = ids.subList(i, Math.min(i + batchSize, ids.size()));
    // 执行查询
}

🗃️ 方案 4: 临时表方案

CREATE TEMPORARY TABLE temp_ids (id BIGINT);
INSERT INTO temp_ids VALUES (?), (?), ...;
SELECT * FROM large_table WHERE id IN (SELECT id FROM temp_ids);
DROP TEMPORARY TABLE temp_ids;

最佳实践

✅ 推荐配置

场景	useServerPrepStmts	预期性能
生产环境	false	35ms ⭐ 最优
标准测试	false	35-50ms
必须服务器端预编译	true	645ms

❌ 避免配置

场景	useServerPrepStmts	SQL格式	性能
❌ 带格式化	true	带换行/缩进	9,128ms 慢194倍
❌ 大量空格	true	spaces > 0	27,839ms 慢535倍
❌ 极端情况	true	大量换行+空格	44,521ms 慢712倍

🎯 实施建议

开发阶段:
- 设置 useServerPrepStmts=false
- 使用 --spaces 0 测试
测试阶段:
- 对比不同配置的性能
- 使用 SHOW PROCESSLIST 监控
生产环境:
- 强制使用客户端预编译
- 避免大参数量 IN 查询
- 如必须使用，考虑分批或临时表方案

完整对比表

配置	SQL格式	SQL长度	false平均	true平均	性能差异
最优	?,?,?	100KB	35ms	645ms	慢18倍 ⭐
带换行	?\n,\n?	2.1MB	47ms	9,128ms	慢194倍
+空格128	?,<128>?	6.5MB	52ms	27,839ms	慢535倍
带换行+空格128	?\n,\n<128>?	8.5MB	62ms	44,521ms	慢712倍 🔥

性能改善总结

通过 SQL 格式优化：

指标	优化前	优化后	改善幅度
SQL 长度	2.1MB	100KB	缩小 95%
服务器端性能	9,128ms	645ms	提升 14 倍
性能差异倍数	194倍	18倍	改善 10 倍

但最终建议: 使用客户端预编译（35ms）才是最佳方案！

结论

SQL 长度是服务器端预编译的致命弱点
- 长度增加 → 性能线性恶化
- 从 100KB（645ms）到 8.5MB（44,521ms），性能下降 69 倍
SQL 格式优化很重要
- 移除换行和多余空格可提升性能 14 倍
- 使用 --spaces 0 获得最紧凑格式
客户端预编译几乎不受影响
- 100KB SQL: 35ms
- 8.5MB SQL: 62ms
- 性能稳定可靠
生产环境强烈建议
- ✅ 使用 useServerPrepStmts=false
- ✅ 使用最紧凑的 SQL 格式（--spaces 0）
- ✅ 避免大参数量 IN 查询，或使用分批/临时表方案
性能差异
- 最优配置（35ms）vs 最差配置（44,521ms）= 1,272 倍差异！
- 这不是优化问题，而是架构选择问题

测试代码仓库

GitHub: https://github.com/plantegg/MySQLPrepared
包含完整的测试代码、脚本和文档
支持 --spaces 参数灵活测试不同 SQL 格式

AWS RDS MySQL 蓝绿部署升级完整指南

发表于 2025-10-25 更新于 2026-02-06 分类于 MySQL

AWS RDS MySQL 蓝绿部署升级完整指南

概述

本文档基于实际测试记录，详细介绍AWS RDS MySQL从5.7升级到8.0的蓝绿部署全过程。

测试环境:

源版本: MySQL 5.7.44-rds.20251212
目标版本: MySQL 8.0.40
实例类型: db.m5.large (2vCPU, 8GB)
Multi-AZ: 启用
区域: ap-southeast-1

蓝绿部署流程图

┌─────────────────────────────────────────────────────────────────────────────┐
│                         蓝绿部署升级完整流程                                  │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  阶段1              阶段2              阶段3              阶段4              │
│  创建读副本          版本升级            配置备份            执行切换           │
│  ┌─────────┐       ┌─────────┐       ┌─────────┐       ┌─────────┐        │
│  │蓝环境    │       │绿环境    │       │绿环境    │       │绿环境    │        │
│  │MySQL5.7 │──复制─▶│MySQL5.7 │──升级─▶│MySQL8.0 │──切换─▶│MySQL8.0│        │
│  │(生产)    │       │(副本)   │        │(就绪)   │       │(新生产)  │        │
│  └─────────┘       └─────────┘       └─────────┘       └─────────┘        │
│       │                 │                 │                 ▲              │
│       │                 │                 │                 │              │
│       └─────────────────┴─────────────────┴─────────────────┘              │
│                        持续数据同步                                         │
│                                                                             │
│  耗时: 10-20分钟      耗时: 10-20分钟    耗时: 几分钟      耗时: 1-5分钟     	   │
│  业务影响: 零         业务影响: 零       业务影响: 零      业务影响: 短暂     		  │
└─────────────────────────────────────────────────────────────────────────────┘

前置条件

1. 检查当前实例状态

aws rds describe-db-instances \
    --db-instance-identifier mysql-test-57 \
    --query 'DBInstances[0].{Status:DBInstanceStatus,Version:EngineVersion,MultiAZ:MultiAZ}' \
    --profile default --region ap-southeast-1

2. 确认可升级的目标版本

aws rds describe-db-engine-versions \
    --engine mysql \
    --engine-version 5.7 \
    --query 'DBEngineVersions[0].ValidUpgradeTarget[?IsMajorVersionUpgrade==`true`].EngineVersion' \
    --profile default --region ap-southeast-1

3. 确保备份已启用

蓝绿部署要求源实例启用自动备份 (BackupRetentionPeriod > 0)

阶段1: 创建蓝绿部署

命令

aws rds create-blue-green-deployment \
    --blue-green-deployment-name mysql-57-to-80-upgrade \
    --source arn:aws:rds:XXXX:db:mysql-test-57 \
    --target-engine-version 8.0.40 \
    --profile default --region ap-southeast-1

参数说明

参数	说明
`--blue-green-deployment-name`	部署名称，用于标识
`--source`	源实例的ARN
`--target-engine-version`	目标MySQL版本

返回示例

{
    "BlueGreenDeployment": {
        "BlueGreenDeploymentIdentifier": "bgd-xen1mlsjdt6hlt8r",
        "Status": "PROVISIONING",
        "Tasks": [
            {"Name": "CREATING_READ_REPLICA_OF_SOURCE", "Status": "PENDING"},
            {"Name": "DB_ENGINE_VERSION_UPGRADE", "Status": "PENDING"},
            {"Name": "CONFIGURE_BACKUPS", "Status": "PENDING"}
        ]
    }
}

阶段2: 监控部署进度

查看部署状态

1
2
3

aws rds describe-blue-green-deployments \
    --blue-green-deployment-identifier bgd-xen1mlsjdt6hlt8r \
    --profile default --region ap-southeast-1

任务状态说明

任务	说明	预计耗时
CREATING_READ_REPLICA_OF_SOURCE	创建源实例的读副本	10-20分钟
DB_ENGINE_VERSION_UPGRADE	升级绿环境到目标版本	10-20分钟
CONFIGURE_BACKUPS	配置备份策略	几分钟

状态流转

1	PROVISIONING → AVAILABLE → SWITCHOVER_IN_PROGRESS → SWITCHOVER_COMPLETED

查看绿环境实例详情

# 绿环境实例名称格式: {源实例名}-green-{随机字符}
aws rds describe-db-instances \
    --db-instance-identifier mysql-test-57-green-b66gdf \
    --query 'DBInstances[0].{Status:DBInstanceStatus,Version:EngineVersion}' \
    --profile default --region ap-southeast-1

阶段3: 执行切换 (Switchover)

前置检查

确保部署状态为 AVAILABLE:

aws rds describe-blue-green-deployments \
    --blue-green-deployment-identifier bgd-xen1mlsjdt6hlt8r \
    --query 'BlueGreenDeployments[0].Status' \
    --profile default --region ap-southeast-1

执行切换命令

aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier bgd-xen1mlsjdt6hlt8r \
    --switchover-timeout 300 \
    --profile default --region ap-southeast-1

参数说明

参数	说明
`--blue-green-deployment-identifier`	蓝绿部署ID
`--switchover-timeout`	切换超时时间(秒)，默认300

切换过程详解

切换时间线 (实测数据):
────────────────────────────────────────────────────────────────
08:33:35  切换开始，TPS正常 (~263)
08:33:51  TPS开始下降，出现错误 (err/s: 142)
08:33:52  TPS=0，写入完全阻塞
08:36:47  连接完全中断 (QPS=0)
08:37:00  DNS切换完成
08:37:30  切换完成，连接恢复
────────────────────────────────────────────────────────────────
总切换时间: ~4分钟
完全断连时间: ~28秒

切换期间的实例名称变化

切换前:
  mysql-test-57          → MySQL 5.7 (生产)
  mysql-test-57-green-xxx → MySQL 8.0 (绿环境)

切换后:
  mysql-test-57          → MySQL 8.0 (新生产，原绿环境)
  mysql-test-57-old1     → MySQL 5.7 (原生产，可用于回滚)

阶段4: 验证升级结果

检查切换状态

aws rds describe-blue-green-deployments \
    --blue-green-deployment-identifier bgd-xen1mlsjdt6hlt8r \
    --query 'BlueGreenDeployments[0].{Status:Status,StatusDetails:StatusDetails}' \
    --profile default --region ap-southeast-1

验证新版本

aws rds describe-db-instances \
    --db-instance-identifier mysql-test-57 \
    --query 'DBInstances[0].EngineVersion' \
    --profile default --region ap-southeast-1

连接验证

1 2	mysql -h mysql-test-57.XXX.rds.amazonaws.com \ -P 3306 -u admin -p -e "SELECT VERSION();"

阶段5: 清理资源

删除蓝绿部署 (保留旧实例)

1
2
3

aws rds delete-blue-green-deployment \
    --blue-green-deployment-identifier bgd-xen1mlsjdt6hlt8r \
    --profile default --region ap-southeast-1

删除蓝绿部署 (同时删除旧实例)

aws rds delete-blue-green-deployment \
    --blue-green-deployment-identifier bgd-xen1mlsjdt6hlt8r \
    --delete-target \
    --profile default --region ap-southeast-1

手动删除旧实例 (如需要)

aws rds delete-db-instance \
    --db-instance-identifier mysql-test-57-old1 \
    --skip-final-snapshot \
    --profile default --region ap-southeast-1

回滚方案

如果升级后发现问题，可以快速回滚:

方法1: 切换回旧实例 (推荐)

在删除蓝绿部署前，旧实例 (mysql-test-57-old1) 仍然可用:

1 2	# 修改应用连接字符串指向旧实例 # mysql-test-57-old1.XXXX.amazonaws.com

方法2: 从快照恢复

aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier mysql-test-57-restored \
    --db-snapshot-identifier <snapshot-id> \
    --profile default --region ap-southeast-1

实测性能数据

测试配置

sysbench oltp_read_write
16表 × 100,000行
8并发线程

性能对比

指标	MySQL 5.7	MySQL 8.0	变化
TPS	263	288	+9.5%
QPS	5,284	5,760	+9.0%
95%延迟	35ms	35ms	持平

切换影响

指标	数值
蓝绿部署总耗时	42分钟
切换总耗时	4分钟
完全断连时间	28秒
数据丢失	0

最佳实践

1. 时间选择

选择业务低峰期执行切换
预留足够的监控和回滚时间

2. 监控准备

提前配置CloudWatch告警
准备实时监控脚本

3. 应用适配

确保应用支持MySQL 8.0语法
测试连接池的重连机制
配置合理的连接超时

4. 回滚准备

保留旧实例至少24小时
准备回滚脚本和流程

5. 通知机制

提前通知相关团队
准备故障升级流程

常见问题

Q1: 蓝绿部署创建失败

原因: 源实例未启用自动备份
解决:

aws rds modify-db-instance \
    --db-instance-identifier mysql-test-57 \
    --backup-retention-period 7 \
    --apply-immediately

Q2: 切换超时

原因: 数据同步延迟过大
解决: 增加 --switchover-timeout 值，或等待复制追平

Q3: 切换后应用连接失败

原因: DNS缓存或连接池未刷新
解决: 重启应用或刷新连接池

参考命令汇总

# 1. 创建蓝绿部署
aws rds create-blue-green-deployment \
    --blue-green-deployment-name <name> \
    --source <source-arn> \
    --target-engine-version <version>

# 2. 查看部署状态
aws rds describe-blue-green-deployments \
    --blue-green-deployment-identifier <bgd-id>

# 3. 执行切换
aws rds switchover-blue-green-deployment \
    --blue-green-deployment-identifier <bgd-id> \
    --switchover-timeout 300

# 4. 删除部署
aws rds delete-blue-green-deployment \
    --blue-green-deployment-identifier <bgd-id>

基于实际测试环境: AWS ap-southeast-1, Account XXXX

跨 Die 热迁移迁移导致的性能问题

发表于 2025-01-29 更新于 2025-11-29 分类于 CPU

跨 Die 热迁移迁移导致的性能问题

场景

在 ARM 上，本来业务跑在 Die0 上，如果通过taskset 将 CPU 绑到 Die1，经过一段时间运行，内存也会慢慢随着释放/新分配慢慢都迁移到 Die1，但是这之后仍然发现性能比在 Die0 上要差很多。而在 Intel X86 上没碰到过这个问题

分析

下图是内存带宽使用率监控数据，可以看到跨 Die 绑定后原来的 Die0 带宽急剧增加（7.5% -> 13%）这是因为内存都需要跨 Die 访问了，随着跨 Die 访问并慢慢将内存迁移到 Die1 后内存带宽使用率回落到 5%：

同时可以看到 CPU 使用率也从 35% 飙升到 76%，随着内存的迁移完毕，CPU 使用率回落到 48%，但仍然比最开始的 35% 高不少：

Intel X86 下跨 Die 迁移

Intel 基本都是一路就是一个 Die，所以你可以理解这里的跨 Die 就是跨路/Socket 迁移：

结论

ARM 比 X86 差这么多的原因是内存页表跨 Die 访问导致的，业务同学测试了开启 THP 负载的影响，从结果看，THP on 可有效降低cpu水位，但是依然存在跨die迁移cpu水位上升的问题。

alios 对应的 patch：https://gitee.com/anolis/cloud-kernel/pulls/2254/commits 不区分 x86 和 arm

页表是进程创建时在内核空间分配好的，所以迁移内存时并不会迁移页表。通过测试页表跨die迁移的poc，验证了跨die页表访问是导致本文所述问题的根本原因

课后作业：

去了解下内存页表/THP(透明大页)

学习 CPU 访问内存延时是怎么回事，然后学习 CPU 和内存速度的差异，最后再去看看大学的计算机组成原理

学习下 taskset/perf 等命令

CPU 使用率高就一定有效率吗？

发表于 2025-01-09 更新于 2025-11-29 分类于 CPU

CPU 使用率高就一定有效率吗？

背景

最近碰到一个客户业务跑在8C ECS 上，随着业务压力增加 CPU使用率也即将跑满，于是考虑将 8C 升级到16C，事实是升级后业务 RT 反而略有增加，这个事情也超出了所有程序员们的预料，所以我们接下来分析下这个场景

分析

通过采集升配前后、以前和正常时段的火焰图对比发现CPU 增加主要是消耗在自旋锁上了：

用一个案例来解释下自旋锁和锁，如果我们要用多线程对一个整数进行计数，要保证线程安全的话，可以加锁(synchronized), 这个加锁操作也有人叫悲观锁，抢不到锁就让出这个线程的CPU 调度(代价上下文切换一次，几千个时钟周期)

另外一种是用自旋锁(CAS、spin_lock) 来实现，抢不到锁就耍赖占住CPU 死磕不停滴抢(CPU 使用率一直100%)，自旋锁的设计主要是针对抢锁概率小、并发低的场景。这两种方案针对场景不一样各有优缺点

假如你的机器是8C，你有100个线程来对这个整数进行计数的话，你用synchronized 方式来实现会发现CPU 使用率永远达不到50%

#taskset -a -c 56-63 java LockAccumulator 100 1000000000
累加结果: 1000000000 and time:84267

Performance counter stats for 'taskset -a -c 56-63 java -Djava.library.path=. LockAccumulator 100 100000000':

      17785.271791      task-clock (msec)         #    2.662 CPUs utilized
           110,351      context-switches          #    0.006 M/sec
            10,094      cpu-migrations            #    0.568 K/sec
            11,724      page-faults               #    0.659 K/sec
    44,187,609,686      cycles                    #    2.485 GHz
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
    22,588,807,670      instructions              #    0.51  insns per cycle
     6,919,355,610      branches                  #  389.050 M/sec
        28,707,025      branch-misses             #    0.41% of all branches

如果我们改成自旋锁版本的实现，8个核CPU 都是100%

以下代码累加次数只有加锁版本的10%，时间还长了很多，也就是效率产出实在是低

#taskset -a -c 56-63 java -Djava.library.path=. SpinLockAccumulator 100 100000000
累加结果: 100000000
操作耗时: 106593 毫秒

 Performance counter stats for 'taskset -a -c 56-63 java -Djava.library.path=. SpinLockAccumulator 100 100000000':

      85363.429249      task-clock (msec)         #    7.909 CPUs utilized
            23,010      context-switches          #    0.270 K/sec
             1,262      cpu-migrations            #    0.015 K/sec
            13,403      page-faults               #    0.157 K/sec
   213,191,037,155      cycles                    #    2.497 GHz
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
    43,523,454,723      instructions              #    0.20  insns per cycle
    10,306,663,291      branches                  #  120.739 M/sec
        14,704,466      branch-misses             #    0.14% of all branches

代码

我放在了github 上，有个带调X86 平台 pause 指令的汇编，Java 中要用JNI 来调用，ChatGPT4帮我写的，并给了编译、运行方案：

javac SpinLockAccumulator.java
javah -jni SpinLockAccumulator

# Assuming GCC is installed and the above C code is in SpinLockAccumulator.c
gcc -shared -o libpause.so -fPIC SpinLockAccumulator.c

java -Djava.library.path=. SpinLockAccumulator

实际gcc编译要带上jdk的头文件：
gcc -I/opt/openjdk/include/ -I/opt/openjdk/include/linux/ -shared -o libpause.so  -fPIC SpinLockAccumulator.c

在MySQL INNODB 里怎么优化这个自旋锁

MySQL 在自旋锁抢锁的时候每次会调 ut_delay（底层会掉CPU指令，让CPU暂停一下但是不让出——避免上下文切换），发现性能好了几倍。这是MySQL 的官方文档：https://dev.mysql.com/doc/refman/5.7/en/innodb-performance-spin_lock_polling.html

所以我们继续在以上代码的基础上在自旋的时候故意让CPU pause(50个), 这个优化详细案例：https://plantegg.github.io/2019/12/16/Intel%20PAUSE%E6%8C%87%E4%BB%A4%E5%8F%98%E5%8C%96%E6%98%AF%E5%A6%82%E4%BD%95%E5%BD%B1%E5%93%8D%E8%87%AA%E6%97%8B%E9%94%81%E4%BB%A5%E5%8F%8AMySQL%E7%9A%84%E6%80%A7%E8%83%BD%E7%9A%84/

该你动手了

随便找一台x86 机器，笔记本也可以，macOS 也行，核数多一些效果更明显。只要有Java环境，就用我编译好的class、libpause.so 理论上也行，不兼容的话按代码那一节再重新编译一下

可以做的实验：

重复我前面两个运行，看CPU 使用率以及最终耗时
尝试优化待pause版本的自旋锁实现，是不是要比没有pause性能反而要好
尝试让线程sleep 一下，效果是不是要好？
尝试减少线程数量，慢慢是不是发现自旋锁版本的性能越来越好了

改变线程数量运行对比：

//自旋锁版本线程数对总时间影响很明显，且线程少的话性能要比加锁版本好，这符合自旋锁的设定:大概率不需要抢就用自旋锁
#taskset -a -c 56-63 java -Djava.library.path=. SpinLockAccumulator 1 100000000
累加结果: 100000000
操作耗时: 2542 毫秒

#taskset -a -c 56-63 java -Djava.library.path=. SpinLockAccumulator 2 100000000
累加结果: 100000000
操作耗时: 2773 毫秒

#taskset -a -c 56-63 java -Djava.library.path=. SpinLockAccumulator 4 100000000
累加结果: 100000000
操作耗时: 4109 毫秒

#taskset -a -c 56-63 java -Djava.library.path=. SpinLockAccumulator 8 100000000
累加结果: 100000000
操作耗时: 11931 毫秒

#taskset -a -c 56-63 java -Djava.library.path=. SpinLockAccumulator 16 100000000
累加结果: 100000000
操作耗时: 13476 毫秒


//加锁版本线程数变化对总时间影响不那么大
#taskset -a -c 56-63 java -Djava.library.path=. LockAccumulator 16 100000000
累加结果: 100000000 and time:9074

#taskset -a -c 56-63 java -Djava.library.path=. LockAccumulator 8 100000000
累加结果: 100000000 and time:8832

#taskset -a -c 56-63 java -Djava.library.path=. LockAccumulator 4 100000000
累加结果: 100000000 and time:7330

#taskset -a -c 56-63 java -Djava.library.path=. LockAccumulator 2 100000000
累加结果: 100000000 and time:6298

#taskset -a -c 56-63 java -Djava.library.path=. LockAccumulator 1 100000000
累加结果: 100000000 and time:3143

设定100并发下，改变机器核数对比：

//16核机器跑3次 耗时稳定在12秒以上，CPU使用率 1600%
#taskset -a -c 48-63 java -Djava.library.path=. SpinLockAccumulator 100 10000000
累加结果: 10000000
操作耗时: 12860 毫秒

#taskset -a -c 48-63 java -Djava.library.path=. SpinLockAccumulator 100 10000000
累加结果: 10000000
操作耗时: 12949 毫秒

#taskset -a -c 48-63 java -Djava.library.path=. SpinLockAccumulator 100 10000000
累加结果: 10000000
操作耗时: 13692 毫秒

//8核机器跑3次，耗时稳定5秒左右，CPU使用率 800%
#taskset -a -c 56-63 java -Djava.library.path=. SpinLockAccumulator 100 10000000
累加结果: 10000000
操作耗时: 6773 毫秒

#taskset -a -c 56-63 java -Djava.library.path=. SpinLockAccumulator 100 10000000
累加结果: 10000000
操作耗时: 5557 毫秒

#taskset -a -c 56-63 java -Djava.library.path=. SpinLockAccumulator 100 10000000
累加结果: 10000000
操作耗时: 2724 毫秒

总结

以后应该不会再对升配后CPU 使用率也上去了，但是最终效率反而没变展现得很惊诧了

从CPU 使用率、上下文切换上理解自旋锁(乐观锁)和锁(悲观锁)

MySQL 里对自旋锁的优化，增加配置 innodb_spin_wait_delay 来增加不同场景下DBA 的干预手段

这篇文章主要功劳要给 ChatGPT4 ，里面所有演示代码都是它完成的

如果你觉得看完对你很有帮助可以通过如下方式找到我

find me on twitter: @plantegg

知识星球：https://t.zsxq.com/0cSFEUh2J

开了一个星球，在里面讲解一些案例、知识、学习方法，肯定没法让大家称为顶尖程序员(我自己都不是)，只是希望用我的方法、知识、经验、案例作为你的垫脚石，帮助你快速、早日成为一个基本合格的程序员。

争取在星球内：

养成基本动手能力
拥有起码的分析推理能力–按我接触的程序员，大多都是没有逻辑的
知识上教会你几个关键的知识点

tcp会偶尔3秒timeout的分析以及如何用php规避这个问题

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

tcp会偶尔3秒timeout的分析以及如何用php规避这个问题

这是一篇好文章，随着蘑菇街的完蛋，蘑菇街技术博客也没了，所以特意备份一下这篇

作者：蚩尤
时间：May 27, 2014

2年前做一个cache中间件调用的时候，发现很多通过php的curl调用一个的服务会出现偶尔的connect_time超时, 表现为get_curlinfo的connect_time在3秒左右, 本来没怎么注意, 因为客户端的curl_timeout设置的就是3秒, 某天, 我把这个timeout改到了5秒后, 发现了一个奇怪的现象, 很多慢请求依旧表现为connect_time在3秒左右..看来这个3秒并不是因为客户端设置的timeout引起的.于是开始查找这个原因.

首先, 凭借经验调整了linux内核关于tcp的几个参数

1 2	net.core.netdev_max_backlog = 862144 net.core.somaxconn = 262144

经过观察发现依旧会有3秒超时, 而且数量并没有减少.

第二步, 排除是大并发导致的问题, 在一台空闲机器上也部署同样的服务, 仅让线上一台机器跑空闲机器的服务, 结果发现依旧会有报错.排除并发导致的问题.

最后, 通过查了大量的资料才发现并不是我们才遇到过这个问题, 而且这个问题并不是curl的问题, 它影响到所有tcp的调用, 网上各种说法, 但结论都指向linux内核对于tcp的实现.(某些版本会出现这些问题), 有兴趣的可以看下下面这两个资料.
资料1
资料2

一看深入到linux内核..不管怎样修改的成本一定很大..于是乎, 发挥我们手中的php来规避这个问题的时间到了.

原本的代码, 简单实现，常规curl调用:

function curl_call($p1, $p2 ...) {
   $ch = curl_init();
   curl_setopt($ch, CURLOPT_TIMEOUT, 5);
   curl_setopt($ch, CURLOPT_URL, 'http://demon.at');
   $res = curl_exec($ch);
   if (false === $res) {
      //失败..抛异常..
   }
   return $res;
}

可以看出, 如果用上面的代码, 无法避免3秒connect_time的问题..这种实现对curl版本会有要求(CURLOPT_CONNECTTIMEOUT_MS)，主要的思路是，通过对链接时间进行毫秒级的控制(因为超时往往发生在connect的时候)，加上失败重试机制，来最大限度保证调用的正确性。所以,下面的代码就诞生了:

function curl_call($p1, $p2, $times = 1) {
   $ch = curl_init();
   curl_setopt($ch, CURLOPT_TIMEOUT, 5);
   curl_setopt($ch, CURLOPT_URL, 'http://demon.at');
   $curl_version = curl_version();
   if ($curl_version['version_number'] >= 462850) {
      curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 20);
      curl_setopt($ch, CURLOPT_NOSIGNAL, 1);
   } else {
      throw new Exception('this curl version is too low, version_num : ' 
                         . $curl_version['version']);
   }
   $res = curl_exec($ch);
   curl_close($ch);
   if (false === $res) {
      if (curl_errno($ch) == CURLE_OPERATION_TIMEOUTED
             and $times != 最大重试阀值 ) {
         $times += 1;
         return curl_call($p1, $p2, $times);
      }
   }

   return $res;
}

上面这段代码只是一个规避的简单实例, 一些小细节并没有可以完善..比如抛出异常常以后curl资源的手动释放等等..这里不做讨论..当然还漏了一点要说的是，对重试次数最好加上限制 :)

说明一下上面几个数字值的含义:

1
2

462850 //因为php的CURLOPT_CONNECTTIMEOUT_MS需要 curl_version 7.16.2,这个值就是这个版本的数字版本号，还需要注意的是, php版本要大于5.2.3
20 //连接超时的时间, 单位:ms

这样这个问题就这样通过php的代码来规避开了.
如果有对这个问题有更好的解决方法，欢迎指教.

总结

tcp connect 的流程是这样的：
1、tcp发出SYN建链报文后，报文到ip层需要进行路由查询
2、路由查询完成后，报文到arp层查询下一跳mac地址
3、如果本地没有对应网关的arp缓存，就需要缓存住这个报文，发起arp请求
4、arp层收到arp回应报文之后，从缓存中取出SYN报文，完成mac头填写并发送给驱动。

问题在于，arp层缓存队列长度默认为3。如果你运气不好，刚好赶上缓存已满，这个报文就会被丢弃。

TCP层发现SYN报文发出去3s（默认值）还没有回应，就会重发一个SYN。这就是为什么少数连接会3s后才能建链。

幸运的是，arp层缓存队列长度是可配置的，用 sysctl -a | grep unres_qlen 就能看到，默认值为3。

关于本博

精华文章推荐

10倍性能提升全过程 在双11的紧张流程下，将系统tps从500优化到5500，从网络到snat、再到Spring和StackTrace，一次全栈性能优化过程的详细记录和分析。

国产CPU和Intel、AMD性能PK 从Intel、AMD、海光、鲲鹏920、飞腾2500 等CPU在TPCC、sysbench下的性能对比来分析他们的性能差距，同时分析内存延迟对性能的影响

LVS 20倍的负载不均衡，原来是内核的这个Bug，这个内核bug现在还在，可以稳定重现，有兴趣的话去重现一下，然后对照源代码以及抓包分析一下就清楚了。

如何在工作中学习 一篇很土但是很务实可以复制的方法论文章。不要讲举一反三、触类旁通，谁都知道要举一反三、触类旁通，但是为什么我总是不能够举一反三、触类旁通？

举三反一–从理论知识到实际问题的推导 坚决不让思路跑偏，如何从一个理论知识点推断可能的问题

性能相关（2015-2018年）

就是要你懂TCP–半连接队列和全连接队列 偶发性的连接reset异常、重启服务后短时间的连接异常

就是要你懂TCP–TCP性能问题 Nagle算法和delay ack

10倍性能提升全过程 在双11的紧张流程下，将系统tps从500优化到5500，从网络到snat、再到Spring和StackTrace，看看一个性能全栈工程师如何在各种工具加持下发现各种问题的。

CPU系列文章（2021年完成）

[Intel PAUSE指令变化是如何影响自旋锁以及MySQL的性能的](/2019/12/16/Intel PAUSE指令变化是如何影响自旋锁以及MySQL的性能的/)

[Perf IPC以及CPU性能](/2021/05/16/Perf IPC以及CPU利用率/)

[CPU 性能和Cache Line](/2021/05/16/CPU Cache Line 和性能/)

网络相关基础知识（2017年完成）

[kubernetes service 和 kube-proxy详解](/2020/09/22/kubernetes service 和 kube-proxy详解/)

DNS相关

LVS 负载均衡

网络工具

TCP 网络性能排查实战：两个经典案例的深度学习总结

概述

案例一：跨机房 Kafka 消费延迟高达 10 分钟

问题描述

排查过程

阶段一：排除基础设施问题

阶段二：发现拥塞窗口异常（TCP 层面）

阶段三：发现内核虚假重传（深入内核层面）

阶段四：发现 Send Buffer 限制

阶段五：定位根因 — 客户端接收 Buffer

根因与解决方案

案例二：同机房 TCP 订阅客户端异常缓慢

问题描述

排查过程

第一步：抓包发现 TCP Zero Window

第二步：确认 Recv Buffer 堆满

第三步：发现 CPU 异常

第四步：定位代码问题

根因与解决方案

两个案例的关联与对比

TCP 缓冲区与窗口的核心原理

为什么 RTT 大时 Buffer 小的问题会被放大？

关键排查命令速查

TCP 连接状态分析

网络重传监控

抓包分析

Java 应用排查

经验教训

1. 不要信任中间件的默认配置

2. 内核参数可能是隐藏的定时炸弹

3. 学会用 Wireshark 做对比分析

4. 应用层的 Bug 也会表现为网络问题

5. 理解 BDP（带宽延迟积）

6. 排查要有层次感

网络知识学习方法与技巧

一、学习路径：从理论到实战

1. 系统化学习框架

2. 问题驱动的学习方法

二、核心知识领域

1. TCP 连接管理

连接队列监控

Socket 选项优化

2. Buffer 与内存管理

Socket 内存信息解读

内核参数调优

3. TCP 性能指标

关键性能指标

TCP 选项优化

4. 负载均衡与高可用

SO_REUSEPORT 实现负载均衡

三、实战诊断方法论

1. 性能问题排查流程

2. 常见问题模式

模式 1：高延迟

模式 2：高重传率

模式 3：连接失败

3. 分层诊断策略

四、工具链与技能树

1. 必备工具

2. 技能进阶路径

10倍性能提升全过程在双11的紧张流程下，将系统tps从500优化到5500，从网络到snat、再到Spring和StackTrace，一次全栈性能优化过程的详细记录和分析。

如何在工作中学习一篇很土但是很务实可以复制的方法论文章。不要讲举一反三、触类旁通，谁都知道要举一反三、触类旁通，但是为什么我总是不能够举一反三、触类旁通？

举三反一–从理论知识到实际问题的推导坚决不让思路跑偏，如何从一个理论知识点推断可能的问题

就是要你懂TCP–半连接队列和全连接队列偶发性的连接reset异常、重启服务后短时间的连接异常

10倍性能提升全过程在双11的紧张流程下，将系统tps从500优化到5500，从网络到snat、再到Spring和StackTrace，看看一个性能全栈工程师如何在各种工具加持下发现各种问题的。