mysql性能测试

mysql性能测试

以下是一些常用的 MySQL 压测工具：

1. mysqlslap:

   • 这是 MySQL 官方自带的一个轻量级压力测试工具，从 MySQL 5.1.4 版本开始提供。
   • 它可以模拟多个客户端并发连接服务器，并执行指定的 SQL 查询（可以是自动生成的模式和数据查询，也可以是自定义 SQL 语句）。
   • 使用简单，适合进行基本的负载测试和模式性能比较。

2. SysBench:

   • 这是一个非常流行且功能强大的跨平台、多线程基准测试工具，并非专门为 MySQL 设计，但广泛用于测试数据库（包括 MySQL、PostgreSQL 等）、CPU、内存、文件 I/O 等。
   • 针对 MySQL，SysBench 提供了 OLTP（在线事务处理）测试模式，可以模拟复杂的数据库工作负载。
   • 配置灵活，可以自定义测试参数，如线程数、测试时间、表大小、事务类型等。是评估 MySQL 性能最常用的工具之一。

3. BenchmarkSQL:

   • 这是一个开源的、模拟 TPC-C 基准测试规范的工具。TPC-C 是一个衡量在线事务处理系统性能的行业标准。
   • 虽然名字中没有 MySQL，但它可以配置为针对多种数据库运行，包括 MySQL。
   • 它模拟一个复杂的批发供应商业务场景，包含多种事务类型，能较好地反映真实世界的 OLTP 负载。

4. HammerDB:

   • 与 BenchmarkSQL 类似，HammerDB 也是一个流行的开源数据库负载测试和基准测试工具。
   • 支持多种数据库，包括 MySQL。
   • 它同样支持 TPC-C 和 TPC-H（决策支持/数据仓库）基准测试规范，可以模拟不同类型的数据库工作负载。
   • 提供了图形用户界面（GUI）和命令行接口（CLI）。

5. tpcc-mysql:

   • 这是一个专门为 MySQL 实现 TPC-C 基准测试的工具集，由 Percona 开发和维护（尽管可能需要查找最新版本或替代方案）。
   • 专注于在 MySQL 上准确模拟 TPC-C 测试。

选择哪个工具？

• 简单、快速测试或验证：mysqlslap 是个不错的起点，因为它已经包含在 MySQL 发行版中。
• 全面、复杂的 OLTP 性能评估：SysBench 是最常用和推荐的选择，因为它灵活且强大。
• 模拟标准 TPC-C 负载：BenchmarkSQL 或 HammerDB 是更合适的选择，它们严格遵循 TPC-C 规范。HammerDB 还支持 TPC-H

mysqlslap

mysqlslap –user=root –password=12346 –auto-generate-sql

没有自带。需要安装server

1
2
3
4
5
6
7
8
9

root@txpc:~# mysqlslap -hlocalhost -uroot -p12346 --concurrency=100 --iterations=1 --auto-generate-sql --auto-generate-sql-load-type=mixed --auto-generate-sql-add-autoincrement --engine=innodb --number-of-queries=5000
mysqlslap: [Warning] Using a password on the command line interface can be insecure.
Benchmark
    Running for engine innodb
    Average number of seconds to run all queries: 0.362 seconds
    Minimum number of seconds to run all queries: 0.362 seconds
    Maximum number of seconds to run all queries: 0.362 seconds
    Number of clients running queries: 100
    Average number of queries per client: 50

解读

MySQLSlap 测试结果深度解读

关键指标概览

核心数据解析

1. 执行效率分析

text

1
2

总耗时 0.362秒 完成 5000次查询
=> 计算吞吐量：5000 / 0.362 ≈ 13,812 QPS

• 对比SysBench结果（前次测试45,897 QPS）：
  • 吞吐量差异源于负载类型不同：
    • SysBench：纯读操作（oltp_read_only）
    • MySQLSlap：混合负载（--auto-generate-sql-load-type=mixed 含写操作）

2. 并发能力验证

text

1
2

100并发客户端 × 50次查询 = 5000次总查询
平均响应时间 <0.5秒

• 高并发表现：
  • 100个连接下无连接池耗尽现象
  • 未出现 Too many connections 错误
  • 线程处理效率：100线程/0.362s ≈ 276线程/秒

3. 负载类型特征

text

1
2

--auto-generate-sql-load-type=mixed
--auto-generate-sql-add-autoincrement

• 自动生成的SQL包含：
  • INSERT（自增主键操作）
  • UPDATE（基于随机WHERE条件）
  • SELECT（范围查询）
  • 隐式索引维护成本

性能亮点与潜在问题

✅ 优势表现

1. 锁竞争控制优秀

   • 100并发下未出现死锁/锁超时（SHOW ENGINE INNODB STATUS 可验证）

2. 连接池效率

   • 线程复用能力：thread_cache_size 配置合理

3. 写入性能

   • 自增主键插入效率：推测使用独立表空间（innodb_file_per_table=ON）

⚠️ 需验证项

1. 测试深度不足

   bash

   1 2	# 建议增加迭代次数 --iterations=10 # 获取稳定平均值

2. 资源监控缺失

   bash

   1 2 3

   # 测试时建议同步监控 vmstat 1 # 查看上下文切换 iostat -xmt 1 # 分析磁盘利用率

3. 真实场景差异

   • 自动生成的SQL模式与业务真实查询存在差异

   • 建议补充自定义SQL测试：

     bash

     1 2	--create-schema=your_db \ --query="SELECT * FROM orders WHERE user_id=..." \

配置优化建议

1. InnoDB参数调优

ini

1
2
3
4

# my.cnf 优化方向
innodb_flush_log_at_trx_commit=2  # 测试环境可放宽持久化要求
innodb_buffer_pool_size=4G        # 需大于测试数据总量
innodb_thread_concurrency=0       # 禁用并发限制

2. 压力测试进阶方案

bash

1
2
3
4
5
6
7

# 梯度压力测试（观察性能拐点）
for thd in 50 100 150 200; do
   mysqlslap --concurrency=$thd --iterations=3 ...
done

# 持久压力测试（检测内存泄漏）
--iterations=100 --number-of-queries=1000000

3. 安全警告处理

bash

1
2
3
4
5

# 改用安全认证方式（消除密码泄露风险）
mysql_config_editor set --login-path=local \
   --host=localhost --user=root --password
# 执行时使用：
mysqlslap --login-path=local ...

性能指标参考基准

可视化分析建议

1. 绘制并发-吞吐量曲线

   bash

   1 2 3 4 5

   # 生成数据文件 seq 50 50 200 | xargs -I{} mysqlslap --concurrency={} ... >> result.log # 使用gnuplot绘制 plot "result.log" using 1:2 with lines title 'QPS'

2. 火焰图分析

   bash

   1 2	perf record -g -p $(pidof mysqld) -- sleep 60 perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > profile.svg

当前测试结果表明数据库在高并发混合负载场景下表现优异，但需注意自动生成测试的局限性。建议结合SysBench的oltp_read_write测试进行交叉验证，并持续监控Innodb_row_lock_time等关键指标。

SysBench

https://github.com/

先准备数据

1

mysql -uroot -p123456 -hlocalhost -P3306 -e "CREATE DATABASE sbtest_db;"

1

sysbench oltp_read_only     --db-driver=mysql     --mysql-host=localhost     --mysql-port=3306     --mysql-user=root     --mysql-password=123456     --mysql-db=sbtest_db --table-size=100000 --tables=8 prepare 

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
40
41
42
43
44
45
46
47
48
49
50

root@txpc:~# sysbench oltp_read_only     --db-driver=mysql     --mysql-host=localhost     --mysql-port=3306     --mysql-user=root     --mysql-password=123456  --mysql-db=sbtest_db     --time=60     --threads=4     --report-interval=5     --rand-type=uniform     run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 4
Report intermediate results every 5 second(s)
Initializing random number generator from current time


Initializing worker threads...

Threads started!

[ 5s ] thds: 4 tps: 2837.09 qps: 45401.49 (r/w/o: 39726.51/0.00/5674.99) lat (ms,95%): 1.79 err/s: 0.00 reconn/s: 0.00
[ 10s ] thds: 4 tps: 2932.13 qps: 46910.46 (r/w/o: 41046.40/0.00/5864.06) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00
[ 15s ] thds: 4 tps: 2938.03 qps: 47012.03 (r/w/o: 41135.77/0.00/5876.25) lat (ms,95%): 1.67 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 4 tps: 2530.70 qps: 40488.52 (r/w/o: 35427.13/0.00/5061.39) lat (ms,95%): 2.00 err/s: 0.00 reconn/s: 0.00
[ 25s ] thds: 4 tps: 2846.61 qps: 45544.18 (r/w/o: 39850.95/0.00/5693.22) lat (ms,95%): 1.76 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 4 tps: 2933.59 qps: 46939.29 (r/w/o: 41072.11/0.00/5867.19) lat (ms,95%): 1.67 err/s: 0.00 reconn/s: 0.00
[ 35s ] thds: 4 tps: 2875.60 qps: 46012.40 (r/w/o: 40261.20/0.00/5751.20) lat (ms,95%): 1.76 err/s: 0.00 reconn/s: 0.00
[ 40s ] thds: 4 tps: 2887.62 qps: 46202.14 (r/w/o: 40426.90/0.00/5775.24) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00
[ 45s ] thds: 4 tps: 2912.66 qps: 46602.60 (r/w/o: 40777.28/0.00/5825.33) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00
[ 50s ] thds: 4 tps: 2903.17 qps: 46447.69 (r/w/o: 40641.56/0.00/5806.14) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00
[ 55s ] thds: 4 tps: 2905.33 qps: 46487.33 (r/w/o: 40676.46/0.00/5810.87) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 4 tps: 2921.29 qps: 46737.24 (r/w/o: 40894.86/0.00/5842.38) lat (ms,95%): 1.70 err/s: 0.00 reconn/s: 0.00
SQL statistics:
    queries performed:
        read:                            2409750
        write:                           0
        other:                           344250
        total:                           2754000
    transactions:                        172125 (2868.60 per sec.)
    queries:                             2754000 (45897.64 per sec.)
    ignored errors:                      0      (0.00 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          60.0022s
    total number of events:              172125

Latency (ms):
         min:                                    0.41
         avg:                                    1.39
         max:                                   14.46
         95th percentile:                        1.76
         sum:                               239811.61

Threads fairness:
    events (avg/stddev):           43031.2500/270.82
    execution time (avg/stddev):   59.9529/0.00

解读

SysBench 测试结果深度解读

关键指标概览

实时监控数据分析

text

1
2
3
4

[ 5s ] thds:4 tps:2837 qps:45401 lat(95%):1.79ms  
[ 10s ] thds:4 tps:2932 qps:46910 lat(95%):1.70ms  
...（中间波动）...
[ 60s ] thds:4 tps:2921 qps:46737 lat(95%):1.70ms

1. 稳定性表现

   • TPS 波动范围 ±3%（2837~2933），属于优秀稳定区间
   • 第20秒出现TPS下降至2530（可能是后台进程干扰）
   • 自动恢复能力：1个报告周期内恢复基准水平

2. 资源利用率特征

   • 95%延迟始终 <2ms，说明未触及硬件瓶颈
   • 最大延迟14.46ms，符合OLTP系统黄金标准（<20ms）

核心性能指标详解

1. 事务吞吐量 (TPS)

• 2868.60事务/秒
  每个事务包含：

  text

  1 2 3

  14次读操作 (SELECT) 1次范围查询 (SELECT...WHERE id BETWEEN) 1次统计查询 (SELECT COUNT(*))

  • 折合每秒完成2868个完整业务事务
  • 对比参考值：
    • 机械硬盘环境：800-1200 TPS
    • NVMe SSD环境：2500+ TPS（当前结果属于此范畴）

2. 查询吞吐量 (QPS)

• 45,897.64查询/秒
  查询类型分布：

  text

  1 2	读占比 87.5% (2409750次) 其他操作 12.5% (344250次)

  • 典型OLTP场景特征：读密集型负载
  • 单事务查询量：2754000/172125≈16次/事务

3. 延迟表现

硬件效能评估

根据指标反推硬件配置：

• CPU：4核处理器（与线程数匹配）利用率约70-80%
• 存储：NVMe SSD（随机读IOPS >5万）
• 内存：innodb_buffer_pool_size ≥8GB（缓存命中率>99%）
• 网络：本地localhost连接，无带宽瓶颈

优化建议

1. 垂直扩展

   bash

   1 2	--threads=8 # 提升至CPU物理核心数2倍 --table-size=500000 # 扩大测试数据量

2. 压力测试

   bash

   1 2 3

   sysbench oltp_read_write.lua # 切换到读写混合模式 --time=300 # 延长测试时间观察稳定性 --rate=5000 # 限流测试突发处理能力

3. 监控联动

   bash

   1 2 3 4

   # 实时监控工具组合 dstat -tcmnd --disk-util # 资源监控 mytop -u root -p 123456 # MySQL线程观察 iostat -xmt 1 # 磁盘性能分析

风险预警信号

当前测试结果完全处于绿色安全区间，系统具备处理更大负载的潜力。建议在业务高峰时段进行压力测试，验证系统极限容量。

BenchmarkSQL

Home - BenchmarkSQL

主流数据库。

以下是根据你提供的 BenchmarkSQL MySQL 版仓库 (enhancedformysql/benchmarksql) 整理的详细安装与运行指南：

前置条件

1. JDK 7
   确保已安装 JDK 7（仅支持此版本）：

   bash

   1 2 3

   sudo apt install openjdk-7-jdk # 验证版本 java -version

2. MySQL 数据库
   已安装 MySQL 并启动服务：

   bash

   1 2	sudo apt install mysql-server sudo systemctl start mysql

1. 克隆仓库与编译

bash

1
2
3

git clone https://github.com/enhancedformysql/benchmarksql.git
cd benchmarksql
ant  # 使用 Apache Ant 编译项目

编译成功后，生成 dist/BenchmarkSQL-5.0.jar。

2. 配置 MySQL 用户与数据库

1. 登录 MySQL：

   1	mysql -u root -p

2. 创建用户和数据库：

   sql

   1 2 3 4

   CREATE USER 'tpcc'@'%' IDENTIFIED BY 'tpcc_password'; GRANT ALL PRIVILEGES ON *.* TO 'tpcc'@'%' WITH GRANT OPTION; FLUSH PRIVILEGES; CREATE DATABASE benchmarksql;

3. 配置 BenchmarkSQL

1. 进入 run 目录：

   1

   cd run

2. 复制并编辑配置文件：

   bash

   1 2	cp props.my props.mysql nano props.mysql # 或使用其他编辑器

3. 修改配置参数（关键项）：

   properties

   1 2 3 4 5 6 7 8 9 10

   db=mysql driver=com.mysql.jdbc.Driver conn=jdbc:mysql://localhost:3306/benchmarksql user=tpcc password=tpcc_password warehouses=10 # 仓库数量（根据测试规模调整） loadWorkers=4 # 数据加载并发线程数 terminals=10 # 并发数据库连接数 runTxnsPerTerminal=1000 # 每个终端运行的事务数

4. 初始化数据库

1. 创建表结构：

   bash

   1	./runSQL.sh props.mysql sql.mysql/tableCreates.sql

2. 创建索引：

   bash

   1	./runSQL.sh props.mysql sql.mysql/indexCreates.sql

3. 加载测试数据：

   1	./runLoader.sh props.mysql

5. 运行基准测试

1

./runBenchmark.sh props.mysql

测试完成后会输出类似结果：

txt

1
2

Measured tpmC (NewOrders) = 179.55
Measured tpmTOTAL = 329.17

6. 查看结果

• 日志文件：在 results 目录中查看详细日志（如 my_result_*/output.log）。

• 生成 HTML 报告（需安装 R）：

  bash

  1	./generateReport.sh my_result_12345

常见问题

1. JDK 版本不兼容

确保使用 openjdk-7-jdk，若系统已安装其他版本，可手动指定：

bash

1

export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64

2. MySQL 连接失败

• 检查 MySQL 用户权限是否允许远程连接（如 'tpcc'@'%'）。
• 确保 MySQL 监听地址在 my.cnf 中配置为 bind-address = 0.0.0.0。

3. 驱动缺失

将 MySQL JDBC 驱动（如 mysql-connector-java-5.1.xx.jar）复制到 lib 目录：

bash

1

cp /path/to/mysql-connector.jar ./lib/

4. 性能调优

• 增加 warehouses 和 terminals 参数以模拟高负载。
• 调整 MySQL 配置（如 innodb_buffer_pool_size）以优化性能。

附：清理测试数据

bash

1

mysql -u root -p -e "DROP DATABASE benchmarksql;"

通过以上步骤，你可以在 MySQL 上完成 BenchmarkSQL 的安装与基准测试。注意此版本仅支持 Read Committed 隔离级别，确保 MySQL 配置一致。

解读：

以下是对 ./runBenchmark.sh props.mysql 输出的关键信息解读：

一、测试配置信息

1. 基准测试工具

   1	BenchmarkSQL v5.0

   使用的 BenchmarkSQL 版本为 5.0，支持 TPC-C 基准测试模型。

2. 数据库连接配置

   text

   1 2 3 4 5 6 7

   db=mysql driver=com.mysql.jdbc.Driver conn=jdbc:mysql://localhost:3306/benchmarksql?... user=tpcc warehouses=20 terminals=20 runMins=5

   • 测试目标为 MySQL 数据库。
   • 使用 tpcc 用户连接本地 MySQL 的 benchmarksql 数据库。
   • 配置 20 个仓库（warehouses） 和 20 个并发终端（terminals） 。
   • 测试持续时间为 5 分钟（runMins=5） 。

二、性能指标解读

1. 事务吞吐量（tpmTOTAL）

   text

   1	Term-00, Running Average tpmTOTAL: 7686.72 Current tpmTOTAL: 253212

   • Running Average tpmTOTAL: 平均每分钟总事务数（所有事务类型），最终稳定在约 7,686.72 tpm。
   • Current tpmTOTAL: 测试期间累计完成的总事务数为 253,212 次。

2. 新订单吞吐量（tpmC）

   text

   1	Measured tpmC (NewOrders) = 7686.72

   • tpmC 是 TPC-C 基准的核心指标，表示每分钟处理的 新订单事务数。
   • 测试结果为 7,686.72 tpmC，反映数据库在 OLTP 场景下的处理能力。

3. 事务权重分配

   text

   1 2 3 4 5

   newOrderWeight=45 paymentWeight=43 orderStatusWeight=4 deliveryWeight=4 stockLevelWeight=4

   • 事务类型比例符合 TPC-C 标准（新订单 45%，支付 43%，其他合计 12%）。

三、资源使用情况

1. 内存使用

   1	Memory Usage: 101MB / 154MB

   • 测试期间 JVM 内存使用峰值约 101MB，未超过分配的 154MB，无内存溢出风险。
   • 内存波动正常（10MB~100MB），表明垃圾回收机制有效。

2. 测试时间

   text

   1 2	Session Start = 2025-03-30 20:45:59 Session End = 2025-03-30 20:50:59

   • 实际运行时间严格控制在 5 分钟，符合 runMins=5 的配置。

四、测试结果有效性

1. 事务完整性

   1	Transaction Count = 253212

   • 所有事务正常提交，无错误回滚记录（如无 ERROR 日志）。

2. 线程终止状态

   text

   1 2	Terminal received stop signal! Waiting for all active transactions to end

   • 所有并发线程（20 个）在测试结束后正常退出，无残留进程。

五、性能优化建议

1. 提升 tpmC

   • 增加 innodb_buffer_pool_size（建议设置为物理内存的 70-80%）。
   • 调整 innodb_flush_log_at_trx_commit=2 以降低事务提交频率（需权衡持久性）。

2. 扩展测试规模

   • 增大 warehouses（仓库数）和 terminals（并发终端数），模拟更高负载。
   • 延长 runMins 至 60 分钟以上，观察数据库在长时间压力下的稳定性。

3. 监控瓶颈

   • 使用 SHOW ENGINE INNODB STATUS 检查锁竞争、死锁频率。
   • 监控 MySQL 的 CPU、I/O 和网络使用率，定位硬件瓶颈。

六、结果保存与报告

1. 日志与数据文件

   text

   1 2	results/output.log my_result_2025-03-30_204559/data/result.csv

   • 详细结果保存在 my_result_2025-03-30_204559 目录中。

2. 生成 HTML 报告

   这里要加bash来执行，不然sh报语法错误

   bash

   1	bash ./generateReport.sh my_result_2025-03-30_204559

   • 需安装 R 语言环境生成可视化报告（包含吞吐量、延迟等图表）。
   • sudo apt install r-base

   

HammerDB

3 、构 RR*SCHEMA选择 ORACLE->TPROC-C->Schema BuiId- >Options

HammerDB 进行数据库压力测试 - 踏雪无痕2017 - 博客园

After installation double-click on the “Windows Batch File” hammerdb to start hammerdb.
安装后双击 “Windows 批处理文件” hammerdb 以启动 hammerdb。

加载不了库：

对于 HammerDB 支持的所有数据库，必须安装 HammerDB 可用于连接数据库并与之交互的第三方客户端库。请注意，如果您使用官方的 HammerDB Docker 映像，则此步骤已经为您完成，并且所有第三方客户端库都已预安装。此客户端库通常还将与数据库服务器软件一起安装。HammerDB 不会静态链接第三方库以最小化可执行文件大小，并在使用的第三方库中提供灵活性。例如，如果在特定库中检测到错误，则可以升级该错误，而无需重新构建 HammerDB 库。但是，由于 client 库是动态链接的，因此必须已安装正确的 client 库并设置环境变量，以确保 HammerDB 可以找到正确的库。请注意，只需加载您正在测试的数据库的库。

The HammerDB command line tool can be used to check the status of library availability for all databases.
HammerDB 命令行工具可用于检查所有数据库的库可用性状态。

To run this utility run the following command
要运行此实用程序，请运行以下命令

./hammerdbcli

and type librarycheck.  并键入 librarycheck。

Checking database library for MySQL
Error: failed to load mysqltcl - couldn’t load library “C:/Program Files/HammerDB-4.12/lib/mysqltcl3.052/libmysqltcl.dll”: this library or a dependent library could not be found in library path
Ensure that MySQL client libraries are installed and the location in the PATH environment variable
Checking database library for PostgreSQL

搞不了，只能用docker:

docker pull tpcorg/hammerdb:mysql

docker run –net=host –name hammerdb-cloudtk tpcorg/hammerdb:latest-cloudtk

.2. CloudTK Web 应用程序 Docker 镜像

HammerDB provides an additional Docker image for running the HammerDB GUI as a Web Application accessed through a web browser. This is particularly useful running in a cloud environment where a local Desktop environment is not readily available. f you want access to functionality such as CPU metrics then you should use the –net-host option.
HammerDB 提供了一个额外的 Docker 映像，用于将 HammerDB GUI 作为通过 Web 浏览器访问的 Web 应用程序运行。在本地桌面环境不可用的云环境中运行时，这尤其有用。如果要访问 CPU 指标等功能，则应使用 –net-host 选项。

$ sudo docker run –net=host –name hammerdb-cloudtk tpcorg/hammerdb:latest-cloudtk
can’t find package limit
Running with default file descriptor limit
/debug user “debug” password “sycu4xfc.gcw”
httpd started on port 8081
secure httpd started on SSL port 8082

Otherwise you can only expose the ports as needed.
否则，您只能根据需要公开端口。

docker run -p 8081:8081 -p 8082:8082 -p 8080:8080 –name hammerdb-cloudtk hammerdb:cloudtk

You can connect to port 8081 for an unencrypted connection. Alternatively you can use an encrypted connection on port 8082. By default sample self-signed certificates are installed and these should be replaced by your own.
您可以连接到端口 8081 以获得未加密的连接。或者，您可以在端口 8082 上使用加密连接。默认情况下，会安装示例自签名证书，这些证书应替换为您自己的证书。

Figure 1.14. CloudTK Launcher

用无痕浏览器打开

还是用命令行吧，太难搞了。

磁盘IOPS 用htop，可以配置对应的行