简介SwingBench 2.6.1124 是一款简单易用的 Oracle 数据库负载生成工具面向 DBA、开发人员与架构师可用于压力测试、功能验证如分区、压缩特性及新硬件性能评估是数据库性能调优与容量规划的有力助手。整包共含 325 个文件大小约 27.92MB其中 SQL 脚本多达 129 个用于基准测试数据集生成与查询78 个 Java 文件便于二次开发与源码学习另有 bat 启动脚本、jar 依赖库、XML 配置等可快速运行各向导。2.6 版本亮点包括新增 JSON 和 TPC-DS 基准测试、用户自定义基准的声明式配置、SQL 查询编辑器、新图表渲染引擎并附带结果转 PDF 工具与集群监控等功能。目前已有 1258 人学习下载适合需要模拟真实负载、评估数据库特性或验证硬件性能的 Oracle 技术人员可帮助读者快速搭建测试环境并产出规范的压力测试报告。 干数据库压测这行的人迟早会碰上一个叫 SwingBench 的工具。我最近在给一套 Oracle 19c 环境做上线前的容量评估翻出 swingbench2.6.1124.zip 这个压缩包时发现很多朋友对它还是停留在“听说过、没跑过”的阶段甚至有人下载完解压就卡住了。今天把这套工具的安装、配置、跑压测、看结果完整梳理一遍希望能帮到正准备做数据库基准测试的 DBA 和性能测试工程师。SwingBench 是一个专门针对 Oracle 数据库的开源负载生成工具可以用来模拟 OLTP、OLAP、Data Warehouse 等不同类型的工作负载最典型的场景就是数据库迁移前的评估、POC 验证、版本升级后的回归对比以及上线前的容量规划。它提供图形界面、命令行和无头三种模式2.6.1 是目前比较稳定的版本整个工具通过 ZIP 包分发跨平台、免安装解压就能用。1. SwingBench 2.6.1 是个什么工具为什么用 ZIP 分发1.1 项目背景与定位一个“免费但专业”的 Oracle 压测工具SwingBench 最初由 Oracle 性能工程团队的高级架构师 Dominic Giles 开发后来开源在 SourceForge 上持续维护。它的定位非常精准只做 Oracle 数据库的负载模拟不贪多不图全。所以跟 JMeter、Sysbench 这类通用压测工具相比它在本土化场景上做得极其细致比如对 RAC 多节点服务分发、绑定变量、事务权重、连接数控制这些 Oracle 特有机制都有原生支持。2.6.1 版本里内置了多个标准场景最常见的是 OrderEntry订单录入模拟 OLTP 交易、SalesHistory销售历史分析偏 OLAP、CallCenter呼叫中心混合负载以及数据库内部基准测试用的 TPC-C like 和 TPC-DS like 场景。压测时它会按配置生成大量虚拟用户每个用户独立发起 SQL 事务然后统一收集响应时间和吞吐数据。在实际项目中我通常拿它做两类事情一类是在新硬件上给 Oracle 做基准摸底看这台服务器能扛住多少并发和 TPS另一类是在 Oracle 迁移比如从旧版升到 19c、或者换存储前后各跑一轮同样的负载通过对比曲线判断改动是否带来性能回退。1.2 为什么下载下来是一个 ZIP 而不是安装包这个问题很多人没细想过。SwingBench 是纯 Java 编写的不需要往系统目录里写驱动、不需要注册 Windows 服务、不需要在 Linux 下建立 systemd unit所以作者选择了最朴素的 ZIP 打包方式。这么做有几个很实际的好处跨平台一致Linux 解压出来的目录结构和 Windows 完全一样换机器、换系统没有任何差异脚本路径也不会出现兼容问题。免 root 权限在服务器上放进任意用户目录就能跑不需要 sudo这在很多安全管控严格的生产环境里非常有用。离线部署友好整个包自带所有运行库和第三方依赖只要目标机器有 JDK就能离线运行适合内网隔离环境。透明可审查解压后所有 jar、脚本、配置都摆在明面上安全团队检查起来方便不像安装包那样有“黑盒”嫌疑。不过 ZIP 分发也带来一个问题下载不完整时根本没有提示。你拿到 swingbench2.6.1124.zip双击解压到一半报错或者解压完了启动脚本直接提示找不到类十有八九是包坏了。这里先给一个通用检查命令后面第 5 章还会详细展开。unzip -t swingbench2.6.1124.zip出现 OK 字样才说明压缩包完整可用。如果系统没有 unzip用jar tf swingbench2.6.1124.zip也能起到同样的校验作用。2. 安装前准备JDK、数据库账号与目录规划2.1 版本号里的信息2.6.1 和 1124 分别代表什么文件名叫 swingbench2.6.1124.zip拆开看2.6.1 是主版本号1124 更接近构建号或日期编号类似于“2024 年第 11 周第 24 次构建”这类标记不是功能上的特别含义。重点还是关注主版本因为 SwingBench 2.x 是基于 Java 11 重写的架构跟老版本 1.x 在场景文件格式、命令行参数上有不少差异。很多网络教程还在写 1.x 时代的操作方式比如用swingbench脚本直接加-u参数其实 2.6.1 的参数体系已经重构过一次。看官方文档时一定要确认对应的版本区间否则照着旧教程配置 2.6.1 很容易踩坑。我建议下载后先在本地虚拟机里把压缩包解压验证一下确认能启动 GUI 或命令行再拿到生产服务器上去避免白跑一趟机房。2.2 运行环境准备JDK 版本和数据库端权限SwingBench 2.6.1 需要 JDK 11 或更高版本用 JDK 17 实测也没有问题。安装 JDK 这里不赘述但要确认一点如果机器的默认 Java 版本低于 11光解压 ZIP 是不够的还必须设置好 JAVA_HOME 环境变量让 SwingBench 启动脚本能指向正确的 JDK。数据库端需要准备一个有足够权限的账号。如果压测目标是单实例用 SYSTEM 账号最省事如果是 Oracle 19c 的多租户架构建议直接在 PDB 里创建专用账号并授予DBA角色或至少CONNECT, RESOURCE权限因为 OrderEntry 场景需要建表、建索引、写入大量数据。SwingBench 使用 JDBC Thin 驱动连接数据库不需要在数据库服务器上安装 Oracle Client这在异构环境里尤其方便。还有个容易被忽略的点压测机和数据库最好不要放在同一台物理机上。如果数据库和应用各占一半 CPU压测曲线会出现“资源互抢”的假瓶颈你很难判断到底是数据库慢还是压测机拖后腿。真实项目中至少保证数据库服务器独占 CPU 核心。2.3 解压后的目录结构解压 swingbench2.6.1124.zip 后关键目录如下目录/文件作用bin/可执行脚本目录包含 swingbench、charbench、minibench、runbench 等lib/Java 依赖库包括 SwingBench 核心 jar 和第三方类库config/场景配置文件OrderEntry.xml、SalesHistory.xml 等workdir/压测过程中的临时文件、日志、结果输出目录samples/示例脚本和辅助配置初学者值得仔细看docs/官方文档包含参数说明和 FAQbin 目录下需要重点记住三个脚本swingbench图形界面启动器适合交互式操作和参数调优。charbench命令行模式负载生成器无头环境下最常用可以独立于 GUI 运行。minibench嵌入式运行引擎主要面向通过 Java 代码调用压测的场景做自动化框架合适。实际压测时我在服务器上几乎只用 charbench因为它不依赖图形环境方便通过 SSH 远端执行也方便写进 shell 脚本做循环压测。3. 第一个压测场景OrderEntry 从 GUI 到命令行3.1 GUI 启动与连接配置把 JDK 确认好后进入解压目录执行cd /opt/swingbench/bin ./swingbench如果机器没有图形环境这一步会报 DISPLAY 相关错误别慌这是正常的后面直接跳去用 charbench。有图形环境的机器上会弹出 SwingBench 主界面左侧是“配置连接”面板右侧是场景选择、参数配置和结果图表区。首次使用建议先点开 Configuration 填好连接信息主机名或 IP、端口默认 1521、服务名。不少新手在这里填 SID结果连接失败记住 19c 里绝大多数场景应该填服务名比如 Oracle 19c 的 PDB 默认服务名通常是pdb1这种样式连接时用jdbc:oracle:thin://host:1521/pdb1的格式才能正确命中 PDB。连接测试通过后从左侧场景下拉框选择 OrderEntry就能进入压测参数界面。3.2 关键参数释义用户数、迭代次数、Think Time 和权重OrderEntry 场景参数不少但核心就几个理解透了基本就掌握了大半参数作用我的建议用户数并发连接数决定负载强度不要一开始就上 200先用 50 摸底迭代次数每个虚拟用户执行的事务次数0 表示无限循环压测时长由时长参数控制Think Time模拟真实用户思考/操作间隔毫秒常用 3000ms 左右太短会产生过载假象权重Weight各事务类型占比默认值即可不要随意改动统计间隔结果聚合的粒度建议 10s便于观察曲线变化连接超时数据库连接建立的超时时间默认通常够用网络差时适当调大其中最容易影响压测结果的就是 Think Time。把它设成 0 意味着所有虚拟用户拼了命地发请求压出来的是极限吞吐真实业务系统里用户不可能没有停顿所以做容量评估时我一般会设到 2000-3000ms这样出的结果更贴近生产实际。OrderEntry 默认场景自带的是一个大约 10GB 左右的数据量如果你只是想在几台小机器上做个快速验证可以先用 SwingBench 的配置生成器生成一个较小规模的数据集比如 100 个仓库Warehouse大概 1GB 出头先跑通流程再放大。3.3 命令行无头压测一键跑完一轮到了服务器上图形界面往往用不了这时候用 charbench 做无头压测才是正路。一个最基础的用法是./charbench -c ../config/OrderEntry.xml \ -u 50 \ -i 1000 \ -t 300 \ -o ./results/oe_50users \ -uc 0参数含义-c指定场景配置文件-u指定并发用户数-i每个用户的事务迭代次数-t压测持续时间秒-o结果文件前缀-uc是我自己常用的一个组合参数含义是“unlimited connection”即允许连接数不被 JVM 默认值限制。跑完后按 Enter 键会退出但结果已经写入了 CSV 文件。实际在自动化脚本里我常常用 nohup 挂在后台执行并把输出重定向到日志文件这样的好处是压测过程不会被 SSH 断开影响第二天早上直接看报告。4. 把压测跑起来之后结果读法与监控配合4.1 看懂输出指标TPS、响应时间和最大事务延迟SwingBench 的结果面板每一行都是一次统计快照最核心的指标是 TPS每秒事务数和平均响应时间这两项直接反映数据库的处理能力。除了平均值还要关注“最大事务延迟”这个指标很敏感一旦数据库出现排队或锁等待它往往会突然飙升到几十秒。举个例子我做过一轮 128 用户压测TPS 曲线从 4000 一路涨到 4600看着挺好的但最大事务延迟在某个时间点突然跳到 30 秒。单独看平均响应时间根本没有异常只有拆开看明细才定位到是审计表空间满了导致小部分事务被阻塞。所以读结果时先看整体趋势再逐个指标排查如果 TPS 平稳上升后维持水平说明系统还有余量如果 TPS 掉头向下往往是某个资源被打满。此时需要结合数据库监控来确认瓶颈在哪。4.2 与数据库监控结合AWR、OS 指标缺一不可SwingBench 是客户端视角它看不到数据库内部到底发生了什么。所以压测的同时手头要有数据库侧和操作系统侧的监控数据。我在跑压测时会同时盯着三块操作系统层top看 CPU 负载、iostat看磁盘 IO、free看内存。如果用户数提升但 TPS 不涨先看 CPU 是不是已经 100% 了。数据库层Oracle 的 AWR 报告里重点看 Top 5 Timed Events如果是db file sequential read居前多半是 IO 瓶颈如果是library cache lock之类可能是 SQL 解析和并发冲突。连接层压测端到数据库端口的连接数也要留意TCP 连接建立速率过高时会出现 TIME_WAIT 堆积表现为连接失败率上升。把这三层数据按时间对齐就很容易看出负载压在哪一层。有一个经验TPS 不再上升、CPU 也没有打满、IO 也不繁忙但响应时间在增加这时八成是数据库内部有锁等待或并发串行化的问题。4.3 压测数据保存与多次对比2.6.1 可以把结果输出到 CSV、JSON 或者数据库表里。CSV 是最常用的因为我可以用 Python 或 Excel 快速处理把多轮压测数据画在一起对比。多次压测对比时注意保持参数一致同样的用户数、同样的 Think Time、同样的场景配置否则对比出来的差异没有意义。在自动化脚本里我会让每轮压测输出带时间戳的文件名比如oe_128user_20250120.csv这样后续整理历史数据时一目了然。5. 常见问题与避坑记录5.1 解压阶段目标 zip 损坏、目录不干净先解决最让人头疼的下载包问题。网上有相当多求助帖比如“导入资源包失败 caused by: invalid zip archive: could not find eocd”这类错误几乎都是因为下载过程中文件被截断或者用了某些不稳定的下载工具导致 ZIP 尾部数据损坏EOCDEnd of Central Directory记录丢失解压工具就找不到文件表的结束位置。解决办法分两步# 1. 先校验 unzip -t swingbench2.6.1124.zip # 2. 确认损坏后用 curl 重新下载并开启断点续传 curl -L -C - -o swingbench2.6.1124.zip https://xxxx这里我强烈建议用curl或wget -c而不是浏览器默认下载器前者即使中途断了也能续传后者在弱网环境下很容易下载出不完整的包。如果源码包是从 SourceForge 下载的优先选择就近的镜像地址。解压目录也要留心路径中不要包含中文、空格和特殊符号。Java 对带空格的路径处理偶尔会出诡异问题我曾经把工具放在 Windows 的C:\Program Files下结果脚本启动时报找不到类换到D:\tools\swingbench就好了。这不是 SwingBench 的 bug而是很多 Java 命令行工具在引号处理上的通病。5.2 连接阶段驱动缺失、账号权限、PDB 服务名最常遇到的运行时报错是驱动找不到提示java.lang.ClassNotFoundException: oracle.jdbc.OracleDriver。原因是 SwingBench 默认 lib 目录里不带 Oracle JDBC 驱动包需要从 Oracle 官方下载ojdbc11.jar对应 JDK 11放到 lib 目录下。注意 2.6.1 和ojdbc8.jar、ojdbc11.jar的兼容性有讲究JDK 17 环境下我用ojdbc11.jar实测稳定JDK 11 环境下两者都行。连接数据库遇到ORA-01017: invalid username/password时先检查账号再检查服务名。前面提到过19c 多租户模式下很可能需要连接 PDB 而不是 CDB。CDB 的根容器通常没有业务数据压测时如果连接 SID 为ORCL这类 CDB 服务名会发现找不到业务表或者权限不足。另外提醒一下SwingBench 的场景文件在创建表之前需要账号有建表权限很多小号为了安全限制得很严压测前先手动跑一下场景里的建表脚本或者直接授权 DBA 角色能省下不少排查时间。5.3 运行阶段内存不足、连接风暴和 GUI 起不来运行中如果出现OutOfMemoryError: Java heap space可以调整 SwingBench 启动脚本里的 JVM 参数默认堆内存可能只有 256MB高并发场景下明显不够。我的习惯是改成JAVA_OPTS-Xms512m -Xmx2048m。用户数不是越大越好。我见过有人直接把用户数拉到 1000结果压测机自己先撑不住大量 TIME_WAIT 连接占满端口数据库侧还没打满压测端先崩了。合理做法是分批加用户50 用户跑一轮看曲线100 用户再跑一轮逐步往上加直到 TPS 不再增长那个点就是系统的性能天花板。至于 GUI 起不来的问题在 Linux 服务器上没有 DISPLAY 是正常现象建议直接习惯用 charbench。如果你想在自己电脑上跑 GUI 又怕影响办公网络可以先用本机的数据库虚拟机试或者干脆把所有压测委托到一台专门的压力机上跑命令行。5.4 常见错误速查表错误现象可能原因处理办法invalid zip archive: could not find eocd下载不完整用 unzip -t 校验curl 断点续传重下ClassNotFoundException: OracleDriver缺少 JDBC 驱动下载 ojdbc11.jar 放入 lib 目录ORA-01017账号密码错误检查账号和服务名PDB 环境填 PDB 服务名Listener refused the connection网络不通或监听器未起telnet 测试 1521 端口检查监听状态OutOfMemoryErrorJVM 堆内存不足调大启动脚本 JAVA_OPTS无法打开 GUI没有图形环境改用 charbench 无头模式6. 一套可复制的压测流程参考最后给一个可以直接抄作业的标准化流程我在 CentOS 7.6 Oracle 19c 的环境里跑过很多次改动很少就能适配其他场景。首先确认四件事目标数据库能连通、拥有 DBA 权限的压测账号存在、JDK 11 已安装、swingbench2.6.1124.zip 已解压且校验完整。然后按下面步骤走把ojdbc11.jar复制到 SwingBench 的 lib 目录。用charbench生成指定规模的数据集./charbench -c ../config/OrderEntry.xml -cf ../config/Oracle19c.xml -s -n 100这里的-cf是指定数据库配置文件的路径-s是执行 schema 构建-n 100代表创建 100 个仓库约为 1GB 数据量。初次跑通可以用这个规模正式评估再放大到 500 或 1000 仓库。数据灌好后跑一轮 50 用户 5 分钟的快速验证确认场景没问题./charbench -c ../config/OrderEntry.xml -u 50 -t 300 -o ./results/oe_50u_json.log依次增加用户数到 100、150、200每轮完成后记录 TPS 和响应时间保存 CSV 结果。压测结束后同时生成数据库侧的 AWR 报告和 SwingBench 结果按时间段对齐分析。这个流程跑完后你会得到一张“并发用户数 vs TPS”的曲线这条曲线就是这套环境当前能力的最直观表达后续无论是做 SQL 优化还是硬件扩容都可以用它做前后对比。我个人的经验是在大多数业务场景下50 到 100 个并发用户足够暴露大部分性能问题200 个以上往往连测试机自己的连接管理都吃力了。真正要关注的不是“能跑到多少并发”而是“系统在什么压力下开始劣化”以及“劣化时瓶颈在哪”。SwingBench 的价值不是帮你把数据库打到崩溃而是给你一把能量化的尺子让你知道边界在哪里。如果后续想做得更深入可以研究一下 SwingBench 的结果导出到 JSON 后配合 Prometheus 和 Grafana 做大屏监控或者把多轮压测结果做成自动回归脚本。这些方向都是在现有工具链上叠加并不需要替换压测引擎本身。本文还有配套的精品资源点击获取 SwingBench 2.6.1 Oracle压测实战：安装配置与结果解读
简介SwingBench 2.6.1124 是一款简单易用的 Oracle 数据库负载生成工具面向 DBA、开发人员与架构师可用于压力测试、功能验证如分区、压缩特性及新硬件性能评估是数据库性能调优与容量规划的有力助手。整包共含 325 个文件大小约 27.92MB其中 SQL 脚本多达 129 个用于基准测试数据集生成与查询78 个 Java 文件便于二次开发与源码学习另有 bat 启动脚本、jar 依赖库、XML 配置等可快速运行各向导。2.6 版本亮点包括新增 JSON 和 TPC-DS 基准测试、用户自定义基准的声明式配置、SQL 查询编辑器、新图表渲染引擎并附带结果转 PDF 工具与集群监控等功能。目前已有 1258 人学习下载适合需要模拟真实负载、评估数据库特性或验证硬件性能的 Oracle 技术人员可帮助读者快速搭建测试环境并产出规范的压力测试报告。 干数据库压测这行的人迟早会碰上一个叫 SwingBench 的工具。我最近在给一套 Oracle 19c 环境做上线前的容量评估翻出 swingbench2.6.1124.zip 这个压缩包时发现很多朋友对它还是停留在“听说过、没跑过”的阶段甚至有人下载完解压就卡住了。今天把这套工具的安装、配置、跑压测、看结果完整梳理一遍希望能帮到正准备做数据库基准测试的 DBA 和性能测试工程师。SwingBench 是一个专门针对 Oracle 数据库的开源负载生成工具可以用来模拟 OLTP、OLAP、Data Warehouse 等不同类型的工作负载最典型的场景就是数据库迁移前的评估、POC 验证、版本升级后的回归对比以及上线前的容量规划。它提供图形界面、命令行和无头三种模式2.6.1 是目前比较稳定的版本整个工具通过 ZIP 包分发跨平台、免安装解压就能用。1. SwingBench 2.6.1 是个什么工具为什么用 ZIP 分发1.1 项目背景与定位一个“免费但专业”的 Oracle 压测工具SwingBench 最初由 Oracle 性能工程团队的高级架构师 Dominic Giles 开发后来开源在 SourceForge 上持续维护。它的定位非常精准只做 Oracle 数据库的负载模拟不贪多不图全。所以跟 JMeter、Sysbench 这类通用压测工具相比它在本土化场景上做得极其细致比如对 RAC 多节点服务分发、绑定变量、事务权重、连接数控制这些 Oracle 特有机制都有原生支持。2.6.1 版本里内置了多个标准场景最常见的是 OrderEntry订单录入模拟 OLTP 交易、SalesHistory销售历史分析偏 OLAP、CallCenter呼叫中心混合负载以及数据库内部基准测试用的 TPC-C like 和 TPC-DS like 场景。压测时它会按配置生成大量虚拟用户每个用户独立发起 SQL 事务然后统一收集响应时间和吞吐数据。在实际项目中我通常拿它做两类事情一类是在新硬件上给 Oracle 做基准摸底看这台服务器能扛住多少并发和 TPS另一类是在 Oracle 迁移比如从旧版升到 19c、或者换存储前后各跑一轮同样的负载通过对比曲线判断改动是否带来性能回退。1.2 为什么下载下来是一个 ZIP 而不是安装包这个问题很多人没细想过。SwingBench 是纯 Java 编写的不需要往系统目录里写驱动、不需要注册 Windows 服务、不需要在 Linux 下建立 systemd unit所以作者选择了最朴素的 ZIP 打包方式。这么做有几个很实际的好处跨平台一致Linux 解压出来的目录结构和 Windows 完全一样换机器、换系统没有任何差异脚本路径也不会出现兼容问题。免 root 权限在服务器上放进任意用户目录就能跑不需要 sudo这在很多安全管控严格的生产环境里非常有用。离线部署友好整个包自带所有运行库和第三方依赖只要目标机器有 JDK就能离线运行适合内网隔离环境。透明可审查解压后所有 jar、脚本、配置都摆在明面上安全团队检查起来方便不像安装包那样有“黑盒”嫌疑。不过 ZIP 分发也带来一个问题下载不完整时根本没有提示。你拿到 swingbench2.6.1124.zip双击解压到一半报错或者解压完了启动脚本直接提示找不到类十有八九是包坏了。这里先给一个通用检查命令后面第 5 章还会详细展开。unzip -t swingbench2.6.1124.zip出现 OK 字样才说明压缩包完整可用。如果系统没有 unzip用jar tf swingbench2.6.1124.zip也能起到同样的校验作用。2. 安装前准备JDK、数据库账号与目录规划2.1 版本号里的信息2.6.1 和 1124 分别代表什么文件名叫 swingbench2.6.1124.zip拆开看2.6.1 是主版本号1124 更接近构建号或日期编号类似于“2024 年第 11 周第 24 次构建”这类标记不是功能上的特别含义。重点还是关注主版本因为 SwingBench 2.x 是基于 Java 11 重写的架构跟老版本 1.x 在场景文件格式、命令行参数上有不少差异。很多网络教程还在写 1.x 时代的操作方式比如用swingbench脚本直接加-u参数其实 2.6.1 的参数体系已经重构过一次。看官方文档时一定要确认对应的版本区间否则照着旧教程配置 2.6.1 很容易踩坑。我建议下载后先在本地虚拟机里把压缩包解压验证一下确认能启动 GUI 或命令行再拿到生产服务器上去避免白跑一趟机房。2.2 运行环境准备JDK 版本和数据库端权限SwingBench 2.6.1 需要 JDK 11 或更高版本用 JDK 17 实测也没有问题。安装 JDK 这里不赘述但要确认一点如果机器的默认 Java 版本低于 11光解压 ZIP 是不够的还必须设置好 JAVA_HOME 环境变量让 SwingBench 启动脚本能指向正确的 JDK。数据库端需要准备一个有足够权限的账号。如果压测目标是单实例用 SYSTEM 账号最省事如果是 Oracle 19c 的多租户架构建议直接在 PDB 里创建专用账号并授予DBA角色或至少CONNECT, RESOURCE权限因为 OrderEntry 场景需要建表、建索引、写入大量数据。SwingBench 使用 JDBC Thin 驱动连接数据库不需要在数据库服务器上安装 Oracle Client这在异构环境里尤其方便。还有个容易被忽略的点压测机和数据库最好不要放在同一台物理机上。如果数据库和应用各占一半 CPU压测曲线会出现“资源互抢”的假瓶颈你很难判断到底是数据库慢还是压测机拖后腿。真实项目中至少保证数据库服务器独占 CPU 核心。2.3 解压后的目录结构解压 swingbench2.6.1124.zip 后关键目录如下目录/文件作用bin/可执行脚本目录包含 swingbench、charbench、minibench、runbench 等lib/Java 依赖库包括 SwingBench 核心 jar 和第三方类库config/场景配置文件OrderEntry.xml、SalesHistory.xml 等workdir/压测过程中的临时文件、日志、结果输出目录samples/示例脚本和辅助配置初学者值得仔细看docs/官方文档包含参数说明和 FAQbin 目录下需要重点记住三个脚本swingbench图形界面启动器适合交互式操作和参数调优。charbench命令行模式负载生成器无头环境下最常用可以独立于 GUI 运行。minibench嵌入式运行引擎主要面向通过 Java 代码调用压测的场景做自动化框架合适。实际压测时我在服务器上几乎只用 charbench因为它不依赖图形环境方便通过 SSH 远端执行也方便写进 shell 脚本做循环压测。3. 第一个压测场景OrderEntry 从 GUI 到命令行3.1 GUI 启动与连接配置把 JDK 确认好后进入解压目录执行cd /opt/swingbench/bin ./swingbench如果机器没有图形环境这一步会报 DISPLAY 相关错误别慌这是正常的后面直接跳去用 charbench。有图形环境的机器上会弹出 SwingBench 主界面左侧是“配置连接”面板右侧是场景选择、参数配置和结果图表区。首次使用建议先点开 Configuration 填好连接信息主机名或 IP、端口默认 1521、服务名。不少新手在这里填 SID结果连接失败记住 19c 里绝大多数场景应该填服务名比如 Oracle 19c 的 PDB 默认服务名通常是pdb1这种样式连接时用jdbc:oracle:thin://host:1521/pdb1的格式才能正确命中 PDB。连接测试通过后从左侧场景下拉框选择 OrderEntry就能进入压测参数界面。3.2 关键参数释义用户数、迭代次数、Think Time 和权重OrderEntry 场景参数不少但核心就几个理解透了基本就掌握了大半参数作用我的建议用户数并发连接数决定负载强度不要一开始就上 200先用 50 摸底迭代次数每个虚拟用户执行的事务次数0 表示无限循环压测时长由时长参数控制Think Time模拟真实用户思考/操作间隔毫秒常用 3000ms 左右太短会产生过载假象权重Weight各事务类型占比默认值即可不要随意改动统计间隔结果聚合的粒度建议 10s便于观察曲线变化连接超时数据库连接建立的超时时间默认通常够用网络差时适当调大其中最容易影响压测结果的就是 Think Time。把它设成 0 意味着所有虚拟用户拼了命地发请求压出来的是极限吞吐真实业务系统里用户不可能没有停顿所以做容量评估时我一般会设到 2000-3000ms这样出的结果更贴近生产实际。OrderEntry 默认场景自带的是一个大约 10GB 左右的数据量如果你只是想在几台小机器上做个快速验证可以先用 SwingBench 的配置生成器生成一个较小规模的数据集比如 100 个仓库Warehouse大概 1GB 出头先跑通流程再放大。3.3 命令行无头压测一键跑完一轮到了服务器上图形界面往往用不了这时候用 charbench 做无头压测才是正路。一个最基础的用法是./charbench -c ../config/OrderEntry.xml \ -u 50 \ -i 1000 \ -t 300 \ -o ./results/oe_50users \ -uc 0参数含义-c指定场景配置文件-u指定并发用户数-i每个用户的事务迭代次数-t压测持续时间秒-o结果文件前缀-uc是我自己常用的一个组合参数含义是“unlimited connection”即允许连接数不被 JVM 默认值限制。跑完后按 Enter 键会退出但结果已经写入了 CSV 文件。实际在自动化脚本里我常常用 nohup 挂在后台执行并把输出重定向到日志文件这样的好处是压测过程不会被 SSH 断开影响第二天早上直接看报告。4. 把压测跑起来之后结果读法与监控配合4.1 看懂输出指标TPS、响应时间和最大事务延迟SwingBench 的结果面板每一行都是一次统计快照最核心的指标是 TPS每秒事务数和平均响应时间这两项直接反映数据库的处理能力。除了平均值还要关注“最大事务延迟”这个指标很敏感一旦数据库出现排队或锁等待它往往会突然飙升到几十秒。举个例子我做过一轮 128 用户压测TPS 曲线从 4000 一路涨到 4600看着挺好的但最大事务延迟在某个时间点突然跳到 30 秒。单独看平均响应时间根本没有异常只有拆开看明细才定位到是审计表空间满了导致小部分事务被阻塞。所以读结果时先看整体趋势再逐个指标排查如果 TPS 平稳上升后维持水平说明系统还有余量如果 TPS 掉头向下往往是某个资源被打满。此时需要结合数据库监控来确认瓶颈在哪。4.2 与数据库监控结合AWR、OS 指标缺一不可SwingBench 是客户端视角它看不到数据库内部到底发生了什么。所以压测的同时手头要有数据库侧和操作系统侧的监控数据。我在跑压测时会同时盯着三块操作系统层top看 CPU 负载、iostat看磁盘 IO、free看内存。如果用户数提升但 TPS 不涨先看 CPU 是不是已经 100% 了。数据库层Oracle 的 AWR 报告里重点看 Top 5 Timed Events如果是db file sequential read居前多半是 IO 瓶颈如果是library cache lock之类可能是 SQL 解析和并发冲突。连接层压测端到数据库端口的连接数也要留意TCP 连接建立速率过高时会出现 TIME_WAIT 堆积表现为连接失败率上升。把这三层数据按时间对齐就很容易看出负载压在哪一层。有一个经验TPS 不再上升、CPU 也没有打满、IO 也不繁忙但响应时间在增加这时八成是数据库内部有锁等待或并发串行化的问题。4.3 压测数据保存与多次对比2.6.1 可以把结果输出到 CSV、JSON 或者数据库表里。CSV 是最常用的因为我可以用 Python 或 Excel 快速处理把多轮压测数据画在一起对比。多次压测对比时注意保持参数一致同样的用户数、同样的 Think Time、同样的场景配置否则对比出来的差异没有意义。在自动化脚本里我会让每轮压测输出带时间戳的文件名比如oe_128user_20250120.csv这样后续整理历史数据时一目了然。5. 常见问题与避坑记录5.1 解压阶段目标 zip 损坏、目录不干净先解决最让人头疼的下载包问题。网上有相当多求助帖比如“导入资源包失败 caused by: invalid zip archive: could not find eocd”这类错误几乎都是因为下载过程中文件被截断或者用了某些不稳定的下载工具导致 ZIP 尾部数据损坏EOCDEnd of Central Directory记录丢失解压工具就找不到文件表的结束位置。解决办法分两步# 1. 先校验 unzip -t swingbench2.6.1124.zip # 2. 确认损坏后用 curl 重新下载并开启断点续传 curl -L -C - -o swingbench2.6.1124.zip https://xxxx这里我强烈建议用curl或wget -c而不是浏览器默认下载器前者即使中途断了也能续传后者在弱网环境下很容易下载出不完整的包。如果源码包是从 SourceForge 下载的优先选择就近的镜像地址。解压目录也要留心路径中不要包含中文、空格和特殊符号。Java 对带空格的路径处理偶尔会出诡异问题我曾经把工具放在 Windows 的C:\Program Files下结果脚本启动时报找不到类换到D:\tools\swingbench就好了。这不是 SwingBench 的 bug而是很多 Java 命令行工具在引号处理上的通病。5.2 连接阶段驱动缺失、账号权限、PDB 服务名最常遇到的运行时报错是驱动找不到提示java.lang.ClassNotFoundException: oracle.jdbc.OracleDriver。原因是 SwingBench 默认 lib 目录里不带 Oracle JDBC 驱动包需要从 Oracle 官方下载ojdbc11.jar对应 JDK 11放到 lib 目录下。注意 2.6.1 和ojdbc8.jar、ojdbc11.jar的兼容性有讲究JDK 17 环境下我用ojdbc11.jar实测稳定JDK 11 环境下两者都行。连接数据库遇到ORA-01017: invalid username/password时先检查账号再检查服务名。前面提到过19c 多租户模式下很可能需要连接 PDB 而不是 CDB。CDB 的根容器通常没有业务数据压测时如果连接 SID 为ORCL这类 CDB 服务名会发现找不到业务表或者权限不足。另外提醒一下SwingBench 的场景文件在创建表之前需要账号有建表权限很多小号为了安全限制得很严压测前先手动跑一下场景里的建表脚本或者直接授权 DBA 角色能省下不少排查时间。5.3 运行阶段内存不足、连接风暴和 GUI 起不来运行中如果出现OutOfMemoryError: Java heap space可以调整 SwingBench 启动脚本里的 JVM 参数默认堆内存可能只有 256MB高并发场景下明显不够。我的习惯是改成JAVA_OPTS-Xms512m -Xmx2048m。用户数不是越大越好。我见过有人直接把用户数拉到 1000结果压测机自己先撑不住大量 TIME_WAIT 连接占满端口数据库侧还没打满压测端先崩了。合理做法是分批加用户50 用户跑一轮看曲线100 用户再跑一轮逐步往上加直到 TPS 不再增长那个点就是系统的性能天花板。至于 GUI 起不来的问题在 Linux 服务器上没有 DISPLAY 是正常现象建议直接习惯用 charbench。如果你想在自己电脑上跑 GUI 又怕影响办公网络可以先用本机的数据库虚拟机试或者干脆把所有压测委托到一台专门的压力机上跑命令行。5.4 常见错误速查表错误现象可能原因处理办法invalid zip archive: could not find eocd下载不完整用 unzip -t 校验curl 断点续传重下ClassNotFoundException: OracleDriver缺少 JDBC 驱动下载 ojdbc11.jar 放入 lib 目录ORA-01017账号密码错误检查账号和服务名PDB 环境填 PDB 服务名Listener refused the connection网络不通或监听器未起telnet 测试 1521 端口检查监听状态OutOfMemoryErrorJVM 堆内存不足调大启动脚本 JAVA_OPTS无法打开 GUI没有图形环境改用 charbench 无头模式6. 一套可复制的压测流程参考最后给一个可以直接抄作业的标准化流程我在 CentOS 7.6 Oracle 19c 的环境里跑过很多次改动很少就能适配其他场景。首先确认四件事目标数据库能连通、拥有 DBA 权限的压测账号存在、JDK 11 已安装、swingbench2.6.1124.zip 已解压且校验完整。然后按下面步骤走把ojdbc11.jar复制到 SwingBench 的 lib 目录。用charbench生成指定规模的数据集./charbench -c ../config/OrderEntry.xml -cf ../config/Oracle19c.xml -s -n 100这里的-cf是指定数据库配置文件的路径-s是执行 schema 构建-n 100代表创建 100 个仓库约为 1GB 数据量。初次跑通可以用这个规模正式评估再放大到 500 或 1000 仓库。数据灌好后跑一轮 50 用户 5 分钟的快速验证确认场景没问题./charbench -c ../config/OrderEntry.xml -u 50 -t 300 -o ./results/oe_50u_json.log依次增加用户数到 100、150、200每轮完成后记录 TPS 和响应时间保存 CSV 结果。压测结束后同时生成数据库侧的 AWR 报告和 SwingBench 结果按时间段对齐分析。这个流程跑完后你会得到一张“并发用户数 vs TPS”的曲线这条曲线就是这套环境当前能力的最直观表达后续无论是做 SQL 优化还是硬件扩容都可以用它做前后对比。我个人的经验是在大多数业务场景下50 到 100 个并发用户足够暴露大部分性能问题200 个以上往往连测试机自己的连接管理都吃力了。真正要关注的不是“能跑到多少并发”而是“系统在什么压力下开始劣化”以及“劣化时瓶颈在哪”。SwingBench 的价值不是帮你把数据库打到崩溃而是给你一把能量化的尺子让你知道边界在哪里。如果后续想做得更深入可以研究一下 SwingBench 的结果导出到 JSON 后配合 Prometheus 和 Grafana 做大屏监控或者把多轮压测结果做成自动回归脚本。这些方向都是在现有工具链上叠加并不需要替换压测引擎本身。本文还有配套的精品资源点击获取