plantegg

java tcp mysql performance network docker Linux

发表于 更新于 分类于

网络知识学习方法与技巧

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

1. 系统化学习框架

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

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

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

2. 问题驱动的学习方法

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

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

实践路径：

  1. 遇到问题 → 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 - 多进程负载均衡：

1
2
3
4
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 内存状态：

1
ss -m

输出字段含义：

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

内核实现（参考）：

1
2
3
4
5
6
7
8
9
10
11
12
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() 速度慢

内核参数调优

关键参数：

1
2
3
4
5
# 查看网络软中断预算
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 配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
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 博客的核心价值在于：

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

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

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

持续提升的关键：

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

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

发表于 更新于 分类于

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

1.3 Root Cause (Original Report)

When MySQL server processes PreparedStatement with large number of parameters:

  1. Excessive memory reallocation: 50,000 parameter replacement operations
  2. String operation complexity: O(SQL length) × number of parameters
  3. 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

1
2
3
4
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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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

1
2
3
4
5
6
7
8
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

  1. 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

  2. AWS RDS Optimizations

    • AWS RDS may include specific performance optimizations
    • Behavior may differ from native MySQL installations

  3. JDBC Driver Version

    • Test used mysql-connector-j-8.0.33
    • Driver may have optimized parameter handling logic

5.3 Recommendations

  1. To Reproduce the Original Issue

    • Use MySQL 5.7.29 or earlier versions
    • Use native MySQL instead of AWS RDS

  2. 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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
=== 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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
=== 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:

1
2
3
4
5
6
7
8
9
10
11
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

发表于 更新于 分类于

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 买的是今年最新一代，占点优势

测试环境概览

说明：

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

💡 关键发现

性能特点

  1. CPU架构影响

    • 不同CPU架构在各场景下表现差异明显
    • 单核性能对点查询场景影响显著

  2. 事务持久化设置

    • innodb_flush_log_at_trx_commit=1 vs 2 对写入性能影响明显
    • 建议根据业务对数据安全性要求选择合适配置

  3. 并发扩展性

    • 各环境在不同并发级别下的扩展性表现不同
    • 需要根据实际业务并发选择合适的硬件配置

  4. 延迟控制

    • 高并发下延迟控制能力体现系统稳定性
    • 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 条记录

测试配置信息

1
2
3
4
5
6
7
=== 测试配置信息 ===
MYSQL_HOST: 10.9.10.145
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5
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

压测服务器配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
=== 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 条记录

测试配置信息

1
2
3
4
5
6
7
=== 测试配置信息 ===
MYSQL_HOST: 10.9.10.145
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5
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

压测服务器配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
=== 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 条记录

测试配置信息

1
2
3
4
5
6
7
=== 测试配置信息 ===
MYSQL_HOST: 10.16.104.124
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5
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

压测服务器配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
=== 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 条记录

测试配置信息

1
2
3
4
5
6
7
=== 测试配置信息 ===
MYSQL_HOST: 10.127.33.154
MYSQL_PORT: 3316
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5
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

压测服务器配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
=== 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 条记录

测试配置信息

1
2
3
4
5
6
7
=== 测试配置信息 ===
MYSQL_HOST: 10.127.33.154
MYSQL_PORT: 3316
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5
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

压测服务器配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
=== 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 条记录

测试配置信息

1
2
3
4
5
6
7
=== 测试配置信息 ===
MYSQL_HOST: 10.127.33.154
MYSQL_PORT: 3316
TABLES: 16
TABLE_SIZE: 100000
TEST_TIME: 10

MySQL配置参数

1
2
3
4
5
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

压测服务器配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
=== 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 条记录

测试配置信息

1
2
3
4
5
6
7
=== 测试配置信息 ===
MYSQL_HOST: 10.127.33.154
MYSQL_PORT: 3316
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5
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

压测服务器配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
=== 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 条记录

测试配置信息

1
2
3
4
5
6
7
=== 测试配置信息 ===
MYSQL_HOST: 10.1.2.89
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5
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

压测服务器配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
=== 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 条记录

测试配置信息

1
2
3
4
5
6
7
=== 测试配置信息 ===
MYSQL_HOST: 10.1.2.89
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5
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

压测服务器配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
=== 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 条记录

测试配置信息

1
2
3
4
5
6
7
=== 测试配置信息 ===
MYSQL_HOST: 10.1.0.47
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5
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

压测服务器配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
=== 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 条记录

测试配置信息

1
2
3
4
5
6
7
=== 测试配置信息 ===
MYSQL_HOST: 10.1.0.52
MYSQL_PORT: 3306
TABLES: 16
TABLE_SIZE: 10000000
TEST_TIME: 30

MySQL配置参数

1
2
3
4
5
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

压测服务器配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
=== 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 性能问题重现

问题描述

在生产环境中发现，当使用 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 内容：

1
2
3
4
5
6
7
8
9
10
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. 运行测试

使用脚本（推荐）

1
2
3
4
5
6
7
8
9
10
# 最优配置（紧凑格式）
./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

1
2
3
4
5
6
7
8
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 (?,?,?,?,...)

1
2
3
4
5
6
7
8
9
10
11
配置: 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 示例: 

1
2
3
4
5
WHERE id IN (?
                  ,
                    ?
                  ,
                    ?
1
2
3
4
5
6
7
8
9
10
11
配置: 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>?,...)

1
2
3
4
5
6
7
8
9
10
11
配置: 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: 带换行+大量空格 (极端情况)

1
2
3
4
5
6
7
8
9
10
11
配置: 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 长度线性恶化：

1
2
3
4
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 时：

  1. 大量内存重分配:

    • 50,000 次参数替换操作
    • 每次替换需要在大 SQL 字符串中定位和替换
    • my_realloc 和 memmove 频繁调用

  2. 字符串操作复杂度:

    • O(SQL长度) × 参数数量 = 极高时间复杂度
    • 单线程 100% CPU 占用

  3. 内存碎片化:

    • 频繁的大块内存分配和释放
    • 进一步降低性能
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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

监控数据

1
2
3
4
5
6
7
# 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: 使用客户端预编译 + 紧凑格式（强烈推荐）

1
2
3
4
5
6
// 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 格式：

1
2
3
4
5
// 使用最紧凑格式: ?,?,?,?
// 避免: ?\n  ,\n  ?

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

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

🔧 方案 3: 分批查询

1
2
3
4
5
6
// 将 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: 临时表方案

1
2
3
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 spaces 预期性能
生产环境 false 0 35ms ⭐ 最优
标准测试 false 0 35-50ms
必须服务器端预编译 true 0 645ms

❌ 避免配置

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

🎯 实施建议

  1. 开发阶段:

    • 设置 useServerPrepStmts=false
    • 使用 --spaces 0 测试

  2. 测试阶段:

    • 对比不同配置的性能
    • 使用 SHOW PROCESSLIST 监控

  3. 生产环境:

    • 强制使用客户端预编译
    • 避免大参数量 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）才是最佳方案！

结论

  1. SQL 长度是服务器端预编译的致命弱点

    • 长度增加 → 性能线性恶化
    • 从 100KB（645ms）到 8.5MB（44,521ms），性能下降 69 倍

  2. SQL 格式优化很重要

    • 移除换行和多余空格可提升性能 14 倍
    • 使用 --spaces 0 获得最紧凑格式

  3. 客户端预编译几乎不受影响

    • 100KB SQL: 35ms
    • 8.5MB SQL: 62ms
    • 性能稳定可靠

  4. 生产环境强烈建议

    • ✅ 使用 useServerPrepStmts=false
    • ✅ 使用最紧凑的 SQL 格式（--spaces 0）
    • ✅ 避免大参数量 IN 查询，或使用分批/临时表方案

  5. 性能差异

    • 最优配置（35ms）vs 最差配置（44,521ms）= 1,272 倍差异！
    • 这不是优化问题，而是架构选择问题

测试代码仓库

发表于 更新于 分类于

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

前置条件

1. 检查当前实例状态

1
2
3
4
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. 确认可升级的目标版本

1
2
3
4
5
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: 创建蓝绿部署

命令

1
2
3
4
5
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版本

返回示例

1
2
3
4
5
6
7
8
9
10
11
{
    "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

查看绿环境实例详情

1
2
3
4
5
# 绿环境实例名称格式: {源实例名}-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:

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

执行切换命令

1
2
3
4
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

切换过程详解

1
2
3
4
5
6
7
8
9
10
11
切换时间线 (实测数据):
────────────────────────────────────────────────────────────────
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秒

切换期间的实例名称变化

1
2
3
4
5
6
7
切换前:
  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: 验证升级结果

检查切换状态

1
2
3
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

验证新版本

1
2
3
4
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

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

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

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

1
2
3
4
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: 从快照恢复

1
2
3
4
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: 蓝绿部署创建失败

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

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

Q2: 切换超时

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

Q3: 切换后应用连接失败

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

参考命令汇总

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 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

发表于 更新于 分类于

问题：为什么你的 SYN 包被丢了——求答案

江湖有个传说：一旦设置了 net.ipv4.tcp_tw_recycle 在 NAT 场景下(多个客户端经过一个 LVS 访问一个服务端，NAT 后服务端看到的客户端是同一个 IP) 就会发生丢包

也可以看看这节：https://xiaolincoding.com/network/3_tcp/syn_drop.html#%E5%9D%91%E7%88%B9%E7%9A%84-tcp-tw-recycle

我们来重现和分析一下这个问题，这应该会是个连续剧，我会根据大家实验情况来推进后面的内容

客户端

我们默认 99 的 ECS 就行，默认配置。

1
yum install tcptraceroute //装一下这个工具，可以对端口进行探测

想要持续对端口探测，类似 ping 一样，就装一下下面的 shell 脚本(tcpping , tcpping 里面会调用 tcptraceroute )：

介绍：http://www.vdberg.org/~richard/tcpping.html

脚本我放仓库里了：https://github.com/plantegg/programmer_case/commit/7c59a7d3666db2fe5af9ba598104cd88cad52497

探测端口通不通：

1
tcpping -d 1.2.3.4 22

通的话会收到：

1
seq 0: tcp response from e237  <syn,ack>  0.088 ms

端口不存在肯定不通，且会被 RST

1
seq 3: tcp response from e237  <rst,ack>  0.076 ms

端口在但是偶尔不通，是今天的主角：

1
2
3
4
5
6
Thu Aug  8 16:48:44 CST 2024
traceroute to , 255 hops max, 60 byte packets
seq 13: tcp response from  <syn,ack>  28.850 ms //通
Thu Aug  8 16:48:52 CST 2024
traceroute to , 255 hops max, 60 byte packets
seq 21: no response (timeout)  //不通

服务端

建议找一个 3.10 内核的机器，4.13 开始已经没有 tcp_tw_recycle 这个参数了

1
2
3
4
5
6
#sysctl -a |egrep "recycle|timestamp"
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_tw_recycle = 1 //这个参数默认是 0，必须改成 1

#uname -r
3.10.0-1062.18.1.el7.x86_64  //我在阿里云上买的一个 CentOS7，版本只要是 4.12 之前的都行

实验步骤

  1. 服务端随便起一个 http 服务端口，比如 1234
  2. 在客户端上执行 tcpping -d 服务端 ip 1234 //这一步可以看到 100% 是通的
  3. 在客户端执行下 curl 服务端 ip:1234 //可以很快看到 tcpping 开始报偶尔通/偶尔不通

重现效果，如下图，本来一次都没有 timeout，但我 curl 一下立即就 timeout 了

img

请分析，为什么 curl 一下 tcpping 就不通了？

发表于 更新于 分类于

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

场景

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

分析

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

img

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

img

Intel X86 下跨 Die 迁移

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

img

img

结论

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 使用率高就一定有效率吗？

背景

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

分析

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

image-20240202085410669

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

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

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

image-20240202090428778

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#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%

image-20240202090714845

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#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帮我写的，并给了编译、运行方案：

1
2
3
4
5
6
7
8
9
10
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 一下，效果是不是要好？
  • 尝试减少线程数量，慢慢是不是发现自旋锁版本的性能越来越好了

改变线程数量运行对比：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
//自旋锁版本线程数对总时间影响很明显，且线程少的话性能要比加锁版本好，这符合自旋锁的设定:大概率不需要抢就用自旋锁
#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并发下，改变机器核数对比：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
//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 ，里面所有演示代码都是它完成的

相关阅读

流量一样但为什么CPU使用率差别很大 同样也是跟CPU 要效率，不过这个案例不是因为自旋锁导致CPU 率高，而是内存延时导致的

今日短平快，ECS从16核升配到48核后性能没有任何提升（Netflix） 也是CPU 使用率高没有产出，cacheline伪共享导致的

听风扇声音来定位性能瓶颈

你要是把这个案例以及上面三个案例综合看明白了，相当于把计算机组成原理就学明白了。这里最核心的就是“内存墙”，也就是内存速度没有跟上CPU的发展速度，导致整个计算机内绝大多场景下读写内存缓慢成为主要的瓶颈

发表于 更新于 分类于

为什么你的 SYN 包被丢 net.ipv4.tcp_tw_recycle

本来这是我计划在知识星球里要写的连续剧，我打算好好多写几篇的(每篇都计划重现一个场景/坑点)，后来没看到任何一个同学参与，这样的话写了你们看完也没有体感，所以我直接公布答案吧，还能节省点你们的时间，记住干货就好：不要开 net.ipv4.tcp_tw_recycle

作为全网最权威/最全面的 net.ipv4.tcp_tw_recycle 问题分析还是从知识星球分享出来，希望更多的人避免踩坑

答案

首先不通了是因为服务端开启了 net.ipv4.tcp_tw_recycle，需要判断握手包的时间得保持递增(T2 - T1 >1)

tcpping 一直是通的，因为服务端没有记录到 T1，T1 是每次 FIN 断开时记录，T2 是每个 SYN 包中携带。当 curl 然后断开时走了 FIN 服务端记录下 T1，下次 tcpping 就可以比较了，所以有一半概率不通，直到 1 分钟后 T1 一直没有跟新，超过 60 秒的 T1 失效，后面连接正常

为什么要有 net.ipv4.tcp_tw_recycle？

net.ipv4.tcp_tw_recycle 是一个 Linux 内核参数，用于控制 TCP 连接的 TIME_WAIT 状态的处理方式。这个参数的主要作用是加速 TIME_WAIT 套接字的回收。

参考：Coping with the TCP TIME-WAIT state on busy Linux servers

PAWS(Protection Against Wrapped Sequences)

TCP 包的 seq 是有限的(4字节 32bit)，会在达到最大值后回绕到零，这种情况称为”seq回绕”，seq 回绕后怎么判断这个 seq 是重复的(丢弃) 还是可以接受的？

引入 PAWS 的目的是确保即使seq 回绕发生，也能正确地处理序列号，除了 seq 外额外在 TCP options 里面增加了 timestamp 来作为维护数据包的seq 正确的判断。时间戳随每个数据包发送，并且单调增加，因此即使序列号回绕，接收方也可以使用时间戳来确定数据包的真实顺序，这就是 PAWS

PAWS会检查syn 网络包的 timestamps ，来判断这个syn包的发送时间是否早于上一次同 ip/stream（3.10 是 per ip/4.10 是 per stream） 的 fin包，如果早就扔掉，这也是导致syn 握手失败的一个高发原因，尤其是在NAT场景下。原本 PAWS 是每个连接的维度，但同时开启tcp_timestamp和tcp_tw_recycle之后，PAWS就变成per host粒度了

1
2
3
timestamp为TCP/IP协议栈提供了两个功能：  
    a. 更加准确的RTT测量数据，尤其是有丢包时  -- RTTM  
    b. 保证了在极端情况下，TCP的可靠性        -- PAWS

不同 OS 内核版本因为 timestamp 生成不一样导致 PAWS 行为还不一样，通过参数来控制：net.ipv4.tcp_timestamps

服务端如何通过判断时间戳来丢包？

对同一个 src-ip 记录最后一次 FIN 包的时间戳为 T1，当这个 src-ip 有 SYN 包时取 SYN 包中的时间戳为 T2

如果 T2-T1 小于 1 就扔掉这个 SYN 包

一旦发生这种 SYN 包被丢弃，对应的监控指标(LINUX_MIB_PAWSPASSIVEREJECTED)：

1
2
3
4
5
6
7
8
9
10
11
12
//第二个指标包含第一个，passive connections rejected 了也一定会是 SYN dropped
#netstat -s |egrep "SYNs to LISTEN sockets dropped|passive connections rejected because"
    960055 passive connections rejected because of time stamp
    1049368 SYNs to LISTEN sockets dropped

#netstat -s |egrep "SYNs to LISTEN sockets dropped|passive connections rejected because"
    960535 passive connections rejected because of time stamp
    1049848 SYNs to LISTEN sockets dropped

#netstat -s |egrep "SYNs to LISTEN sockets dropped|passive connections rejected because"
    961015 passive connections rejected because of time stamp
    1050328 SYNs to LISTEN sockets dropped

这个指标也很重要，我喜欢这种

服务端丢包条件更多细节

服务端设置 net.ipv4.tcp_tw_recycle 为 1 是必要条件，然后同时满足了这两个条件：

  1. (u32)get_seconds() - tm->tcpm_ts_stamp < TCP_PAWS_MSL（=60）：容易满足，几乎总是满足。对比的是本地时间。收到syn的本地时间相比上次收包记录的本地时间，小于60s
  2. (s32)(tm->tcpm_ts - req->ts_recent) > TCP_PAWS_WINDOW（=1）：对比的是tcp时间戳，上次更新的tcp时间戳 - 这次syn的tcp时间戳，大于1（并且小于231）。也就是这次syn的tcp时间戳，如果小于上次记录到的时间戳（ms级），就会被丢掉。

这里tm和req对应什么？一个四元组，还是ip地址，还是其他？3.10对应的是ip地址(不同内核版本不一样)

上次记录的时间戳是什么？注意这里对比的都是tm时间，是在连接关闭相关阶段，通过tcp_remember_stamp或tcp_tw_remember_stamp函数记录的，具体情况比较多。

服务端将客户端的时间戳保存在哪里？

6u(2.6.32)代码：

由于inet_timewait_sock在连接进入tw状态会被释放掉，其中记录最近一次接收报文的timestamp信息会丢失；VJ 的思路，把此tcp stamp信息放入路由cache表的rtable中struct inet_peer中，rtable中只保srcIP，dstIP的PATH信息，没有端口号信息，也就是同src-dstIP(即使端口不同)的所有连接受同一个timestamp限制。

7u(3.10.0)代码：

3.5版本以后的内核版本不再使用rtable记录，tcp stamp信息改为存放在目标地址出接口net中存放的tcp_metrics_block，timestamp判断逻辑跟6u比增加了“如果之前有记录timestamp且在一个MSL内，而本次连接无timestamp时，请求被丢弃”的逻辑，这么修改的原因参见：

https://patchwork.ozlabs.org/patch/380021/

https://patchwork.ozlabs.org/patch/379163/

2017 年的这个讨论https://patchwork.ozlabs.org/project/netdev/patch/20170315203046.158791-1-soheil.kdev@gmail.com/ 要去掉这个全局存放，改成可以按客户端 port 来记录

客户端如何生成时间戳？

  • 3.10 内核是按 客户端 ip 来生成 timestamp，也就是不管跟谁通信都是全局单调递增
  • 4.19(4.12)是按 ip 对（per-destination timestamp**）**来生 timestamp ，也就是一对 ip 之间保证单调递增；
  • 4.10之前是 per-client 生成递增 timestamp ，4.10 改成 per-connection 生成递增 timestamp(导致了兼容 net.ipv4.tcp_tw_recycle问题严重)，4.11 改成 per-destination-host 生成递增 timestamp(downgrade to per-host timestamp offsets)；4.12 去掉 net.ipv4.tcp_tw_recycle 参数永远解决问题

有哪些场景会触发 net.ipv4.tcp_tw_recycle 丢包

服务端的内核参数 net.ipv4.tcp_tw_recycle(4.12内核 中删除这个参数了) 和 net.ipv4.tcp_timestamps 的值都为 1时，服务器会检查每一个 SYN报文中的时间戳（Timestamp，跟同一ip下最近一次 FIN包时间对比），若 Timestamp 不是递增的关系，就扔掉这个SYN包（诊断：netstat -s | grep “ passive connections rejected because of time stamp”），常见触发时间戳非递增场景：

  1. 4.10 内核，一直必现大概率性丢包。4.11 改成了 per-destination host的算法 //内核改来改去也是坑点
  2. tcpping 这种时间戳按连接随机的，必现大概率持续丢包
  3. 同一个客户端通过直连或者 NAT 后两条链路到同一个服务端，客户端生成时间戳是 by dst ip，导致大概率持续丢包
  4. 经过NAT/LVS 后多个客户端被当成一个客户端，小概率偶尔出现——通过 tc qdisc 可以来构造丢包重现该场景
  5. 网路链路复杂/链路长容易导致包乱序，进而出发丢包，取决于网络会小概率出现
  6. 客户端修改 net.ipv4.tcp_timestamps
    • 1->0，触发持续60秒大概率必现的丢包，60秒后恢复
    • 0->1 持续大概率一直丢包60秒; 60秒过后如果网络延时略高且客户端并发大一直有上一次 FIN 时间戳大于后续SYN 会一直概率性丢包持续下去；如果停掉所有流量，重启客户端流量，恢复正常
    • 2->1 丢包，情况同2
    • 1->2 不触发丢包

其它 SYN 连不上的场景延伸阅读：程序员如何学习和构建网络知识体系

一些特殊场景

这些特殊场景很可怕，不知不觉会产生 T2 不大于 T1 的情况，导致连接异常

DNAT/ENAT

请求经过 DNAT 后 Server 端看到的 src-ip 是 client 的 IP，客户端同时通过直连(绿色)和走 LVS(黑色)两条链路就会大概率不通：

image-20240822161109563

没有挥手断开场景

有些 HA 探测都是握手/select 1/ RESET 连接，不走 FIN 四次挥手(比如 Jedis，见小作业应用断开连接的时候如何让 OS 走 RST 流程：https://articles.zsxq.com/id_v0mhaadx3cx5.html )，Server 端没有机会记录 T1，也就永远不会触发丢包，看着一切正常，直到某天来了个用户 curl 一下系统就崩了

比如 Jedis 就是直接 RST 断开连接，从不走 FIN 四次挥手

延伸

如果服务端所用端口是 time_wait 状态，这时新连接 SYN 握手包刚好和 time_wait 的5元组重复，这个时候服务端不会回复 SYN+ACK 而是回复 time_wait 前的ack

其它

Server 在握手的第三阶段（TCP_NEW_SYN_RECV），等待对端进行握手的第三步回 ACK时候，如果收到RST 内核会对报文进行PAWS校验，如果 RST 带的 timestamp(TVal) 不递增就会因为通不过 PAWS 校验而被扔掉

https://github.com/torvalds/linux/commit/7faee5c0d514162853a343d93e4a0b6bb8bfec21 这个 commit 去掉了TCP_SKB_CB(skb)->when = tcp_time_stamp，导致 3.18 的内核版本linger close主动发送的 RST 中 ts_val为0，而修复的commit在 675ee231d960af2af3606b4480324e26797eb010，直到 4.10 才合并进内核

参考资料

per-connection random offset：https://lwn.net/Articles/708021/

发表于 更新于 分类于

一次 Sysbench opening tables 卡慢的分析过程

背景

用 Sysbench 随便跑个压力，然后我用如下命令起压力，只达到了我预期的性能的 10%

1
sysbench --mysql-user=root --mysql-password=123 --mysql-db=sbtest --mysql-host=e237 --mysql-port=3306 --tables=64 --threads=256 --table-size=2000000 --range-size=5 --db-ps-mode=disable --skip-trx=on --mysql-ignore-errors=all --time=1200 --report-interval=1 --histogram=off oltp_point_select run

分析

看了下 MySQL 的进程状态，CPU 消耗很低，再看 processlist 都是 Opening tables，这问题我熟啊，table_open_cache 设置太小，直接干大 10 倍，悲催的是性能依然没有任何变化看了下 MySQL 的进程状态，CPU 消耗很低，再看 processlist 都是 Opening tables，这问题我熟啊，table_open_cache 设置太小，直接干大 10 倍，悲催的是性能依然没有任何变化

image-20241022175210162

image-20241023104502834

难道还有别的地方限制了？我去查了下 status 发现 Table_open_cache_overflows 一直是 0，从状态来看 table_open_cache 肯定够了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#mysql -he237 -P3306 -uroot -p123 -e "show global status like '%open%' "
mysql: [Warning] Using a password on the command line interface can be insecure.
+----------------------------+---------+
| Variable_name              | Value   |
+----------------------------+---------+
| Com_ha_open                | 0       |
| Com_show_open_tables       | 0       |
| Innodb_num_open_files      | 48      |
| Open_files                 | 14      |
| Open_streams               | 0       |
| Open_table_definitions     | 159     |
| Open_tables                | 1161    |
| Opened_files               | 173     |
| Opened_table_definitions   | 138     |
| Opened_tables              | 1168    |
| Slave_open_temp_tables     | 0       |
| Table_open_cache_hits      | 8125315 |
| Table_open_cache_misses    | 1168    |
| Table_open_cache_overflows | 0       |
+----------------------------+---------+

#mysql -he237 -P3306 -uroot -p123 -e "show global status like '%Table_open%' "
mysql: [Warning] Using a password on the command line interface can be insecure.
+----------------------------+---------+
| Variable_name              | Value   |
+----------------------------+---------+
| Table_open_cache_hits      | 9039467 |
| Table_open_cache_misses    | 1170    |
| Table_open_cache_overflows | 0       |
+----------------------------+---------+

#mysql -he237 -P3306 -uroot -p123 -e "show global variables like '%Table_open%' "
mysql: [Warning] Using a password on the command line interface can be insecure.
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| table_open_cache           | 8192  |
| table_open_cache_instances | 16    |
+----------------------------+-------+

这些有点难绷，因为我用的别人的 sysbench, 于是自己编译了一个重压性能一下就正常了，于是我开始 dump 别人的 sysbench 完整参数，最后发现是我使用的时候配置错误将：–tables=32 设置成了 –tables=64 也就是我的 database 总共只有 32 张表，而我压测的时候写成了 64 张，还有 32 张表不存在导致。

而别人的 sysbench 默认添加了：–mysql-ignore-errors=all 也就是把报错信息都忽略了，导致控制台看不到异常信息

碰到这种问题怎么办？

我们经常碰到业务代码把报错信息吃掉了(类似设置了 –mysql-ignore-errors=all )，同时 SQL 里面拼错了表明或者写错了 Database 名也导致表不存在

所以这里的必杀技(银弹) 抓包(或者堆栈热点分析)：

image-20241023101835801

上图中只要不是 1146 的都是表明正确的请求，可以看到 RT 是 0.1-0.2 毫秒之间；但是 response Error 1146 报错的 RT 就很大了，同时抓包里 1146 也给出了错误原因

1
2
3
4
5
+-------+------+---------------------------------------+
| Level | Code | Message                               |
+-------+------+---------------------------------------+
| Error | 1146 | Table 'sbtest.sbtest42' doesn't exist |
+-------+------+---------------------------------------+

正常时 50 万 QPS 的 RT：

1
2
3
	 time								port	avg_rt	svc_rt  up_rt    QPS  	drop	rtt
2024-10-23 10:14:57    P3306    227 	 228 	 0 	 532688 	 0 	 34
2024-10-23 10:14:58    P3306    227 	 228 	 0 	 533439 	 0 	 34

异常时 5 万 QPS 的 RT：

1
2
3
4
5
6
7
	 time								port	avg_rt	svc_rt  up_rt    QPS  	drop	rtt
2024-10-23 10:13:56    P3306    2201 	 2201 	 0 	 58910 	 0 	 34
2024-10-23 10:13:57    P3306    2195 	 2195 	 0 	 59141 	 0 	 34
2024-10-23 10:13:58    P3306    2203 	 2203 	 0 	 58923 	 0 	 34
2024-10-23 10:13:59    P3306    2190 	 2191 	 0 	 59266 	 0 	 34
2024-10-23 10:14:00    P3306    2198 	 2198 	 0 	 59018 	 0 	 34
2024-10-23 10:14:01    P3306    2242 	 2242 	 0 	 57926 	 0 	 34

从 RT 确实可以看出来是 3306 端口返回/响应慢了，我在 MySQLD 的日志里也搜索了，应该是没有记录这种 1146 错误

如果多看几次 processlist 的话还会发现 Opening table 的 SQL 对应的表明都是大于 31 的，表名小的 SQL 就不会出现 Opening table

总结

这个问题我第一时间没有想到抓包，显示根据经验 Opening tables 就是打开表慢了，然后调大 cache 参数，还不好用就觉得超出我的理解有点慌！

然后想到去比较参数/版本的差异，运气好发现了参数的差异；如果运气不好我重新编译然后复制白屏的命令参数估计还是发现不了。

所以我在想有什么更好的办法能识别这种问题，最后的结论居然还是抓个包看看，并且真管用，正好和这篇方法论呼应一下：https://articles.zsxq.com/id_mnp5z56gl0wi.html

延伸

很多时候开发很坑人，把业务异常堆栈吃了不输出，就拿这个例子来说也有业务写错表名，然后报错又不输出就会出现和问题一样的问题，导致分析问题的时候发现很奇怪好好的系统就是慢，这个时候除了抓包还可以通过 perf/jstack 去看看堆栈，抓下热点

推上也有一些讨论，可以参考下别人的思路：https://x.com/plantegg/status/1851066206163521712

0%