第一章：Sysbench 简介

第一章：Sysbench 简介

1.1 什么是 Sysbench

Sysbench（System Benchmark）是一个模块化的、跨平台的多线程基准测试工具。它允许你快速评估系统在不同负载下的性能表现，尤其擅长数据库（OLTP）场景的压力测试。

1.1.1 历史沿革

注意：本教程基于 1.0.20+ 版本。如果你使用的是 0.4.x 旧版，命令参数有较大差异，请参考第二章升级指南。

1.1.2 核心特性

• 多线程：原生支持多线程并发，可模拟高并发负载
• 模块化：内置 CPU、内存、文件 I/O、数据库等多种测试模块
• 可扩展：通过 Lua 脚本自定义测试逻辑，灵活度极高
• 跨平台：支持 Linux、macOS、Windows（WSL）
• 标准化：测试结果可重复，适合对比不同环境

1.2 Sysbench 能做什么

Sysbench 的测试能力覆盖以下四大领域：

1.2.1 CPU 性能测试

sysbench cpu --threads=8 --time=60 run

• 素数计算基准
• 多核扩展性评估
• CPU 调度器影响分析

1.2.2 内存性能测试

sysbench memory --memory-block-size=1M --memory-total-size=100G --threads=4 run

• 内存带宽（Bandwidth）测量
• 读/写延迟（Latency）测试
• NUMA（Non-Uniform Memory Access）架构影响

1.2.3 文件 I/O 测试

sysbench fileio --file-test-mode=rndrw --file-total-size=10G --threads=8 prepare
sysbench fileio --file-test-mode=rndrw --file-total-size=10G --threads=8 run
sysbench fileio --file-test-mode=rndrw cleanup

• 顺序读/写（Sequential Read/Write）
• 随机读/写（Random Read/Write）
• 混合负载模拟
• 不同文件系统（ext4、xfs、btrfs）对比

1.2.4 数据库 OLTP 测试

sysbench oltp_read_write --mysql-host=127.0.0.1 --mysql-user=root \
  --tables=16 --table-size=1000000 --threads=32 --time=300 prepare

sysbench oltp_read_write --mysql-host=127.0.0.1 --mysql-user=root \
  --tables=16 --table-size=1000000 --threads=32 --time=300 run

• OLTP 读写混合（oltp_read_write）
• 只读 OLTP（oltp_read_only）
• 写入密集型（oltp_write_only）
• 点查询（oltp_point_select）
• 范围查询（oltp_range_select）
• 索引更新（oltp_update_index）
• 非索引更新（oltp_update_non_index）
• 插入测试（oltp_insert）
• 删除测试（oltp_delete）

1.3 适用场景

1.3.1 服务器选型与采购

当你需要对比不同硬件配置时，Sysbench 提供了标准化的测试方法：

1.3.2 数据库调优验证

# 测试前记录基线
sysbench oltp_read_write --mysql-host=127.0.0.1 --mysql-user=root \
  --tables=16 --table-size=1000000 --threads=16 --time=300 run \
  | tee /tmp/before_tuning.txt

# 修改 my.cnf 参数（如 innodb_buffer_pool_size）
# 重启 MySQL ...

# 测试后对比
sysbench oltp_read_write --mysql-host=127.0.0.1 --mysql-user=root \
  --tables=16 --table-size=1000000 --threads=16 --time=300 run \
  | tee /tmp/after_tuning.txt

diff /tmp/before_tuning.txt /tmp/after_tuning.txt

1.3.3 持续集成中的性能回归检测

在 CI/CD 流水线中集成 Sysbench 测试，可及早发现性能回归：

# GitLab CI 示例
performance-test:
  stage: test
  script:
    - sysbench cpu --threads=4 --time=30 run > cpu_result.txt
    - grep "events per second" cpu_result.txt
    - # 设定阈值，低于则失败

1.3.4 云服务商评估

对比 AWS、GCP、Azure、阿里云等不同实例类型的性能价格比。

1.3.5 内核 / 调度器影响研究

# 对比不同 I/O 调度器的影响
echo "mq-deadline" | sudo tee /sys/block/sda/queue/scheduler
sysbench fileio --file-test-mode=rndrw --time=60 run > sched_mq_deadline.txt

echo "bfq" | sudo tee /sys/block/sda/queue/scheduler
sysbench fileio --file-test-mode=rndrw --time=60 run > sched_bfq.txt

1.4 Sysbench 与其他工具对比

何时选择 Sysbench

• ✅ 需要跨平台、跨数据库的统一测试方案
• ✅ 需要自定义测试逻辑（Lua 脚本灵活性强）
• ✅ 需要测试 CPU / 内存 / I/O 等多种组件
• ✅ 团队已熟悉 Sysbench 的输出格式和解读方法

何时选择其他工具

• ❌ 只做 MySQL 简单测试 → 可用 mysqlslap（更简单）
• ❌ 只做 I/O 专项测试 → 推荐 fio（更专业）
• ❌ 需要完整的 TPC-C 标准测试 → 推荐 HammerDB 或 BenchmarkSQL
• ❌ 只做 PostgreSQL 测试 → pgbench 是 PG 内置工具，开箱即用

1.5 Sysbench 的测试原理

1.5.1 线程模型

┌──────────────────────────────┐
│         Sysbench 主进程       │
│    ┌──────┬──────┬──────┐    │
│    │Worker│Worker│Worker│...  │
│    │Thread│Thread│Thread│    │
│    └──┬───┴──┬───┴──┬───┘    │
│       │      │      │        │
│       ▼      ▼      ▼        │
│    ┌──────────────────┐      │
│    │   被测目标系统    │      │
│    │ (DB / IO / CPU)  │      │
│    └──────────────────┘      │
└──────────────────────────────┘

• 主进程：负责统计、计时、结果汇总
• 工作线程（Worker Thread）：每个线程独立执行测试操作
• 统计收集：定期（默认每秒）收集各线程的操作数和延迟

1.5.2 OLTP 测试的事务流程

以 oltp_read_write 为例，每个事务包含：

1. BEGIN（开启事务）
2. 点查询（Point Select）：SELECT c FROM sbtest WHERE id=?
3. 范围查询（Range Select）：SELECT c FROM sbtest WHERE id BETWEEN ? AND ?
4. 范围查询（SUM）：SELECT SUM(k) FROM sbtest WHERE id BETWEEN ? AND ?
5. 范围查询（ORDER BY）：SELECT c FROM sbtest WHERE id BETWEEN ? ORDER BY c
6. 范围查询（DISTINCT）：SELECT DISTINCT c FROM sbtest WHERE id BETWEEN ? ORDER BY c
7. 索引更新（Update Index）：UPDATE sbtest SET k=k+1 WHERE id=?
8. 非索引更新（Update Non-Index）：UPDATE sbtest SET c=? WHERE id=?
9. DELETE：DELETE FROM sbtest WHERE id=?
10. INSERT：INSERT INTO sbtest VALUES(...)
11. COMMIT

1.5.3 统计指标

Sysbench 运行结束后输出的关键指标：

1.6 局限性与注意事项

1.6.1 Sysbench 不是什么

• 不是 压力测试工具（虽然可以产生高负载，但缺乏渐进式加压能力）
• 不是 业务模拟器（OLTP 测试是标准化的，不等于真实业务）
• 不是 诊断工具（告诉你"多快"，不告诉你"为什么慢"）

1.6.2 使用限制

1.6.3 常见误区

1. 误区一：只看 TPS

   • 应同时关注延迟分布（P95/P99），高 TPS 伴随高延迟可能意味着排队

2. 误区一：测试一次就够了

   • 建议多次运行取平均值，至少 3 次

3. 误区三：忽略预热（Warm-up）

   • 数据库缓存（Buffer Pool）未预热时，前几次测试结果偏低

4. 误区四：与生产环境数据量差距过大

   • 测试数据量应尽量接近生产规模，特别是数据库测试

5. 误区五：跨版本对比

   • 不同 Sysbench 版本的测试逻辑可能有变化，结果不完全可比

1.7 典型工作流程

  ┌─────────────┐
  │  1. 确定目标 │  明确要测试什么（数据库? I/O? CPU?）
  └──────┬──────┘
         ▼
  ┌─────────────┐
  │  2. 安装部署 │  安装 Sysbench + 被测系统
  └──────┬──────┘
         ▼
  ┌─────────────┐
  │  3. 准备数据 │  prepare 阶段，创建表/文件
  └──────┬──────┘
         ▼
  ┌─────────────┐
  │  4. 预热运行 │  短时间 run，让缓存预热
  └──────┬──────┘
         ▼
  ┌─────────────┐
  │  5. 正式测试 │  正式 run，收集结果
  └──────┬──────┘
         ▼
  ┌─────────────┐
  │  6. 多次重复 │  至少 3 次，取稳定值
  └──────┬──────┘
         ▼
  ┌─────────────┐
  │  7. 分析结果 │  对比 TPS、延迟分布
  └──────┬──────┘
         ▼
  ┌─────────────┐
  │  8. 清理环境 │  cleanup 阶段，释放资源
  └─────────────┘

1.8 小结

在下一章中，我们将介绍如何在不同平台上安装和编译 Sysbench。

扩展阅读

• Sysbench GitHub Wiki
• Alexey Kopytov: “sysbench 1.0 — a New Era” (博客)
• Percona: MySQL Benchmarking Best Practices
• 官方 Lua 脚本 API 文档