1. 项目概述为什么我们需要SLOB如果你是一名Oracle数据库管理员或者性能架构师那么“压测”这个词对你来说一定不陌生。无论是新系统上线前的容量评估还是硬件升级、参数调整后的效果验证甚至是模拟一个“双十一”级别的业务洪峰我们都需要一个可靠的工具来给数据库“上上强度”。市面上压测工具不少但针对Oracle数据库尤其是专注于模拟真实OLTP联机事务处理负载的SLOBSilly Little Oracle Benchmark绝对是一个绕不开的名字。我第一次接触SLOB是在一次核心系统存储阵列升级的预演中。当时我们团队争论不休新的全闪存阵列理论上IOPS每秒输入输出操作次数提升了十倍但数据库的响应时间真能线性改善吗redo log重做日志的写入会不会成为新的瓶颈光靠理论计算和厂商的基准报告心里实在没底。我们需要一个能精准、可控地“折磨”数据库I/O子系统特别是模拟多用户并发访问同一组数据块即缓存竞争场景的工具。这时一位资深同事扔过来一个GitHub链接说“试试这个SLOB专治各种不服。” 从此SLOB就成了我性能工具箱里的“压舱石”。简单来说SLOB不是一个全能的、花哨的基准测试套件。它目标极其明确专注于评估和测量Oracle数据库在多种I/O模式下的性能尤其是物理I/OPhysical I/O的延迟和吞吐量。它通过创建一张或多张结构简单的表让多个并发会话进程对这些表进行随机的读写操作从而产生可预测的、可重复的I/O压力。它的“Silly”简单体现在其模型纯粹不模拟复杂业务逻辑“Little”小巧指的是它部署轻量几个脚本就能跑起来但其产生的压力和对瓶颈的揭示能力却一点也不“Little”。2. SLOB核心原理与架构拆解要玩转SLOB不能只停留在运行脚本的层面理解其内部工作原理至关重要。这能帮助你在结果异常时快速定位问题也能让你根据测试目标灵活调整策略。2.1 核心工作模型物理I/O的“压力发生器”SLOB的核心思想是通过数据库会话制造出特定模式的、可量化的物理I/O负载。它不关心你的SQL有多复杂只关心这些SQL最终导致了多少数据块从磁盘被读取物理读或写入磁盘物理写主要指DBWR进程写脏块和LGWR写日志但SLOB主要通过更新操作触发前者。它的标准工作流程是这样的准备阶段SetupSLOB会创建一套专属的用户模式Schema并在其中创建1到多张核心测试表。每张表的结构完全相同包含一个主键列和若干个填充数据的列。表的大小、块大小、并行度Parallel Degree等都可以在配置中指定。数据会用随机字符串填充以确保数据块内的内容“饱满”模拟真实数据密度。负载生成阶段Run这是压测的核心。SLOB会启动配置指定数量的并发会话UPDATE_WORKERS。每个会话在一个循环中反复执行以下操作随机选择一个键值在表的主键范围内随机选取一个值。执行一个UPDATE语句例如UPDATE test_table SET col ‘new_value’ WHERE id :random_id。这个操作是关键如果目标数据块不在Buffer Cache缓冲区缓存中则会发生物理读Physical Read将块从磁盘读入内存。更新操作会产生undo回滚信息并修改Buffer Cache中的块使其变“脏”。随着脏块增多数据库的写进程DBWR会将这些块异步写回磁盘产生物理写Physical Write。可选的SELECT操作根据配置可能还会在UPDATE前后执行SELECT以增加逻辑读Logical Read和可能的物理读。清理阶段Teardown测试结束后可以删除创建的用户和表空间清理环境。这个模型巧妙地实现了几个目标缓存竞争Buffer Busy Waits当多个会话随机更新同一张表时它们有很大概率试图修改同一个数据块。这会在内存中引发对缓冲区块的争用模拟了高并发OLTP系统中的典型等待事件。物理I/O压力通过控制测试数据的总大小远大于Buffer Cache可以迫使数据库频繁进行物理I/O。通过调整UPDATE_WORKERS更新用户数和SCALE数据量的比例可以控制I/O的“热度”和随机程度。可重复性由于数据生成和操作模式是确定的基于相同的随机种子在相同硬件和数据库配置下SLOB测试结果具有高度可重复性非常适合做“控制变量”的对比测试。2.2 关键配置参数解析SLOB的强大和灵活很大程度上体现在其丰富的配置参数上。slob.conf文件是它的控制中枢。理解几个核心参数你就掌握了压测的“方向盘”。SCALE 这是最重要的参数之一决定了每个测试用户Schema拥有的数据块数量。注意它不是指数据大小MB/GB而是块的数量。例如SCALE100000且数据库块大小是8KB那么一个用户的数据量大约是781MB。总数据量 SCALE*块大小*用户数。为了让测试产生足够的物理I/O你需要确保总数据量显著大于数据库的Buffer Cache大小。UPDATE_PCT 控制事务中UPDATE操作的比例。例如UPDATE_PCT50意味着50%的事务是UPDATE另外50%是纯SELECT如果RUN_TIME或LOOPS控制事务数。100%的UPDATE会产生最大的写压力redo log和DBWR。UPDATE_WORKERS 并发执行UPDATE的工作进程数。这是控制并发压力的主要阀门。增加此值会直接增加对共享资源Buffer Cache、CPU、磁盘的争用。RUN_TIME 每个工作进程运行的总时间秒。测试会持续这么长时间然后所有进程停止。这是控制测试时长的常用方式。LOOPS 每个工作进程执行的事务循环次数。与RUN_TIME二选一。如果设置了LOOPS每个进程在完成指定次数的事务后停止。SCAN_PCT 控制全表扫描Full Table Scan操作的比例。设置为非零值可以模拟混合负载这对评估CBO基于成本的优化器和直接路径读Direct Path Read等特性有影响。WORK_LOOP 每个事务内部循环的次数用于放大单次数据库调用内的逻辑处理量增加CPU消耗。ADMIN_SQLNET_SERVICE 指向数据库服务名的配置。这是连接数据库的关键必须正确配置。实操心得第一次跑SLOB最容易犯的错误就是SCALE设置太小。如果你的数据总量SCALE * 用户数 * 块大小比Buffer Cache还小那么绝大部分操作都会是逻辑读物理I/O压力根本起不来测试也就失去了意义。一个经验法则是确保测试数据总量至少是Buffer Cache大小的3到5倍。例如Buffer Cache为20GB那么你的SLOB测试数据总量最好在60GB到100GB以上。3. 从零开始部署与运行SLOB理论说再多不如动手跑一遍。下面我将以Linux环境Oracle Database 19c为例展示一个完整的SLOB部署和基础压测流程。3.1 环境准备与依赖安装SLOB本身是纯SQL和Shell脚本对运行环境要求不高。主要依赖是一个正在运行的Oracle数据库11gR2及以上版本均可推荐12c/19c。数据库服务器上的操作系统用户需要安装Oracle Instant Client或完整Oracle客户端以便使用sqlplus。Git工具用于下载SLOB和make工具用于编译SLOB自带的wait_kit工具。具体步骤# 1. 以oracle用户登录数据库服务器 su - oracle # 2. 克隆SLOB仓库到本地如果无法访问GitHub可下载zip包并上传 cd /opt git clone https://github.com/tanelpoder/slob.git cd slob # 3. 编译wait_kit一个用于生成CPU压力的辅助工具 cd wait_kit make # 编译后会生成 wait_kit 可执行文件可以把它放到PATH路径下但非必须。3.2 配置数据库与SLOB参数在运行SLOB前需要确保数据库有合适的表空间来存放测试数据并正确配置slob.conf。数据库端准备-- 使用sysdba账户登录sqlplus sqlplus / as sysdba -- 创建一个专用的、自动扩展的表空间给SLOB使用 CREATE TABLESPACE slob_data DATAFILE ‘/u01/app/oracle/oradata/ORCL/slob_data01.dbf‘ SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO; -- 创建一个SLOB测试用户并授予必要权限 CREATE USER slob_user IDENTIFIED BY your_password DEFAULT TABLESPACE slob_data TEMPORARY TABLESPACE temp QUOTA UNLIMITED ON slob_data; GRANT CONNECT, RESOURCE TO slob_user; GRANT CREATE SESSION, CREATE TABLE TO slob_user; -- 为了更全面的测试有时需要授予更多权限但上述权限已足够基础运行。配置slob.conf这是核心步骤。进入SLOB目录编辑slob.conf文件。cd /opt/slob cp slob.conf slob.conf.bak # 建议先备份 vi slob.conf你需要修改的关键参数示例如下# 数据库连接信息 ADMIN_SQLNET_SERVICEORCL # 你的数据库服务名 SQLNET_SERVICE_BASEORCL DB_USERslob_user DB_PASSyour_password # 负载参数 SCALE100000 # 每个用户的数据块数根据你的Buffer Cache调整 UPDATE_PCT90 # 90%的操作是UPDATE制造写压力 UPDATE_WORKERS32 # 启动32个并发更新进程 RUN_TIME300 # 每个进程运行300秒5分钟 WORK_LOOP100 # 每个事务内循环100次增加CPU消耗 SCAN_PCT0 # 先不做全表扫描纯随机访问 # 模式参数 SCHEMAS4 # 创建4个测试用户模式增加数据总量和分散热点 THREADS_PER_SCHEMA8 # 每个模式分配8个线程更新进程总进程数 SCHEMAS * THREADS_PER_SCHEMA注意UPDATE_WORKERS和SCHEMAS/THREADS_PER_SCHEMA是两种设置并发的方式。在SLOB 2.x版本中更推荐使用SCHEMAS和THREADS_PER_SCHEMA的组合因为它能更好地模拟多应用用户场景。总并发数 SCHEMAS*THREADS_PER_SCHEMA。上例中总并发数为 4 * 8 32。3.3 执行压测并获取结果配置完成后按顺序执行以下脚本# 1. 清理旧环境如果是第一次运行可跳过但建议执行以确保环境干净 ./drop_schema.sh # 2. 创建测试模式用户和表结构并加载数据 # 这一步会根据SCALE和SCHEMAS参数生成大量数据耗时较长。 ./setup.sh # 3. 执行压测 # 这一步会根据slob.conf中的参数UPDATE_WORKERS, RUN_TIME等开始运行并发负载。 ./runit.sh # 4. 压测过程中你可以在另一个终端窗口监控数据库性能 # 例如使用AWR报告、ASH报告或实时查询v$sysstat, v$system_event等视图。 sqlplus / as sysdba SELECT stat_name, value FROM v$sysstat WHERE stat_name IN (‘physical read total bytes‘, ‘physical write total bytes‘, ‘session logical reads‘); SELECT event, total_waits, time_waited_micro FROM v$system_event WHERE wait_class ‘Idle‘ ORDER BY time_waited_micro DESC; # 5. 压测结束后可以清理环境可选 ./drop_schema.shrunit.sh脚本运行后你会看到终端上开始滚动输出各个工作进程的状态。运行结束后它不会直接生成一个漂亮的性能报告。SLOB的设计哲学是“只负责制造压力”性能数据的收集和分析需要你借助Oracle数据库自身的诊断工具如AWR、Statspack或OS工具如iostat,vmstat来完成。4. 解读SLOB压测结果与性能分析SLOB跑完了屏幕上刷过一堆日志然后呢真正的功夫在于对测试期间数据库表现的分析。SLOB本身输出有限通常只记录每个线程完成的事务数TPS。我们需要结合Oracle的监控数据来解读。4.1 关键性能指标KPI收集在SLOB运行期间通常取RUN_TIME中间稳定时段你应该从数据库和操作系统层面收集以下核心指标数据库层面通过AWR报告最全面TPS (Transactions Per Second) 每秒事务数。可以从SLOB输出日志中粗略计算总事务数/运行时间但更准确的是看AWR报告中的“Load Profile - Executes (SQL)”或“Instance Activity Stats - user commits/rollbacks”。平均响应时间Avg Response Time AWR报告“Load Profile”中的“Avg Elapsed Time per Exec (s)”。这个值越低越好直接体现SQL执行效率。物理读/写Physical Reads/Writes AWR报告“Load Profile”中的“Physical reads”和“Physical writes”。SLOB的目标就是让这些值“动起来”。计算物理读IOPS和物理写IOPS分别除以运行时间。逻辑读Logical Reads “Load Profile”中的“Logical reads”。高并发下逻辑读过高可能意味着SQL效率或绑定变量问题但在SLOB的随机访问模型下它主要反映缓存命中率和竞争。主要等待事件Top Foreground Wait Events 这是诊断瓶颈的黄金位置。常见的与SLOB相关的等待事件包括db file sequential read 单块读等待通常指向磁盘读取速度。db file scattered read 多块读等待如果设置了SCAN_PCT。log file sync 提交等待反映redo日志写入速度。UPDATE_PCT高时此事件会突出。buffer busy waits 缓冲区块忙等待证明发生了并发争用这正是SLOB想模拟的。free buffer waits 空闲缓冲区等待说明DBWR写脏块的速度跟不上产生脏块的速度是I/O子系统或DBWR配置不合理的信号。enq: TX - row lock contention 行锁竞争如果大量出现可能需要调整SLOB的WORK_LOOP或检查主键随机算法是否导致冲突过高。操作系统层面CPU利用率 使用top或mpstat查看。SLOB的WORK_LOOP参数会消耗CPU。理想情况下我们希望瓶颈在I/O而不是CPU先达到100%。磁盘I/O利用率与延迟 使用iostat -x 2查看。关注%util利用率和await平均等待时间ms。对于数据库await通常应低于10-20ms。如果%util持续接近100%且await很高说明磁盘是瓶颈。网络与内存 通常SLOB在本地运行网络不是瓶颈。内存主要关注是否发生交换si,so 0使用vmstat 2查看。4.2 常见性能瓶颈模式与调优思路根据SLOB测试结果我们可以识别出几种典型的瓶颈模式I/O子系统瓶颈最常见现象db file sequential read平均等待时间很高如20ms操作系统iostat显示磁盘await高且%util饱和。分析 存储无法满足数据库随机读/写的IOPS或吞吐量要求。调优方向硬件升级 考虑更换为更高性能的SSD或全闪存阵列。存储配置 检查RAID级别RAID 10通常比RAID 5更适合随机I/O、条带大小Stripe Size是否与Oracle块大小匹配。数据库配置 增加db_writer_processesDBWR进程数启用异步I/Ofilesystemio_optionssetall考虑使用Flash Cache如果存储支持。Log File Sync瓶颈现象log file sync等待事件排名靠前且平均等待时间长。分析 redo日志文件的写入速度跟不上事务提交速度。这可能是日志所在磁盘慢或者是LOG_BUFFER太小导致频繁写入。调优方向将redo日志文件放在最快的磁盘上如单独的高性能SSD并与数据文件分离。考虑增大日志文件大小减少日志切换频率。适当增大LOG_BUFFER但通常效果有限主要瓶颈在磁盘。对于极高并发写场景评估使用多路复用redo日志组。Buffer Cache竞争瓶颈现象buffer busy waits和cache buffers chainslatch等待显著。分析 过多会话争抢内存中相同的数据块。这可能是SLOB的SCALE设置相对于UPDATE_WORKERS太小导致热点过于集中。调优方向增加SCALE参数扩大测试数据总量分散热点。考虑增加db_block_size需重建数据库更大的块能容纳更多行减少块争用但会增加块内竞争风险需测试验证。评估应用设计现实中可通过分区Partitioning、反向键索引Reverse Key Index等技术分散热点。CPU瓶颈现象 操作系统CPU利用率持续在90%以上而磁盘I/O等待并不高。数据库等待事件中CPU time占比高。分析 SLOB的WORK_LOOP或SQL解析/执行消耗了大量CPU。调优方向检查SQL执行计划是否高效。SLOB的SQL很简单通常不是问题。如果CPU确实是瓶颈考虑升级更快的CPU或增加核心数。在SLOB测试中可以降低WORK_LOOP来减少CPU消耗将压力更多地导向I/O。注意事项一次SLOB测试的结果是“一个点”。有意义的性能评估往往需要“一条线”或“一个面”。务必进行对比测试。例如在调整了某个数据库参数如db_cache_size或更换了存储硬件后在完全相同的SLOB配置下重新运行测试比较前后AWR报告中关键指标TPS、平均响应时间、主要等待事件时间的变化。只有控制了变量的对比才能得出可靠的结论。5. 高级用法与实战场景掌握了基础用法后SLOB还能玩出更多花样以应对更复杂的性能评估需求。5.1 模拟混合读写与特定访问模式默认的SLOB是随机单点更新。但真实负载可能是读多写少或者包含范围扫描。模拟读密集型负载 将UPDATE_PCT设置为一个较低的值如10或20同时大幅增加SCAN_PCT如30。这样负载将由大量的SELECT包括随机SELECT和全表扫描和少量的UPDATE构成。这对于评估缓存命中率、优化器对混合负载的适应能力非常有用。模拟热点块访问 故意将SCALE设置得非常小比如1000同时使用大量的UPDATE_WORKERS比如64。这会导致所有并发会话疯狂争抢少数几个数据块buffer busy waits事件会急剧上升。这可以用来压力测试Buffer Cache的并发管理能力或者测试“行级锁”或“ITL事务槽”相关参数的合理性如INITRANS。使用wait_kit制造CPU压力 前面编译的wait_kit工具可以在SLOB会话中调用执行一个消耗CPU的循环从而制造出CPU和I/O混合的压力。这有助于观察在CPU饱和的情况下I/O子系统性能是否会受到影响或者数据库的调度机制如何应对资源竞争。5.2 集成与自动化将SLOB纳入CI/CD流程在大型企业或云环境中性能测试需要自动化、常态化。SLOB可以很好地集成到自动化流程中。脚本化执行与结果提取 你可以编写一个Shell脚本自动完成配置修改、执行setup.sh和runit.sh、收集AWR报告通过DBMS_WORKLOAD_REPOSITORY包、解析关键指标如使用awk/sed从AWR的txt报告中提取平均响应时间、TPS等并将结果输出到JSON或CSV文件。与监控平台集成 在SLOB运行期间通过数据库的v$视图或操作系统命令实时将性能指标如物理读IOPS、log file sync等待时间推送到监控系统如Prometheus Grafana实现性能数据的可视化看板。作为变更验证关口 在数据库版本升级、重要参数调整、存储迁移等变更前和变更后自动执行一套标准化的SLOB测试用例并对比关键性能指标。如果指标退化超过阈值如TPS下降5%或平均响应时间增加10%则自动触发告警阻止变更或要求进一步审查。5.3 真实案例评估全闪存阵列性能增益这是我亲身经历的一个案例。公司计划将一套核心OLTP数据库的存储从传统SAS硬盘阵列迁移到全闪存阵列。迁移前我们需要量化性能提升预期。测试方案基准测试 在原有硬盘阵列上部署SLOB。配置SCALE500000约40GB数据SCHEMAS8THREADS_PER_SCHEMA8总并发64UPDATE_PCT70RUN_TIME90015分钟。确保总数据量远超Buffer Cache16GB。数据收集 运行SLOB收集整个15分钟内的AWR报告。重点关注Physical reads/sec,Physical writes/sec,Avg Exec Time,DB Time, 以及等待事件db file sequential read avg wait和log file sync avg wait。执行迁移 将数据库文件数据文件、redo日志、控制文件迁移到新的全闪存阵列。对比测试 在完全相同的SLOB配置、数据库参数和主机环境下再次运行15分钟压测。结果分析TPS 从原来的约1250 TPS提升到约4200 TPS提升236%。平均物理读延迟db file sequential read平均等待时间从8.2ms下降到0.9ms。平均事务响应时间 从51ms下降到15ms。DB Time 大幅减少说明数据库处理相同负载所需的总CPU时间更少因为等待I/O的时间减少了。这个用数据说话的报告有力地支撑了存储升级的投资决策并且为迁移后的系统容量规划提供了精确的基线数据。6. 常见问题与故障排除实录即使按照指南操作在实际运行SLOB时也难免会遇到问题。下面是我和同事们踩过的一些“坑”以及解决办法。6.1 安装与运行问题问题1运行setup.sh时sqlplus报错“ORA-12154: TNS:could not resolve the connect identifier”原因slob.conf中的ADMIN_SQLNET_SERVICE配置错误或者ORACLE_HOME、TNS_ADMIN环境变量未正确设置。解决检查slob.conf中的服务名是否与数据库的tnsnames.ora文件中的条目一致。确保以正确的Oracle用户运行脚本并且.bash_profile或.bashrc中正确设置了ORACLE_HOME和TNS_ADMIN。可以手动测试连接sqlplus slob_user/your_passwordORCL。问题2setup.sh运行极慢或者中途卡住原因SCALE参数设置过大导致需要插入的数据量巨大。默认的INSERT方式是单条提交效率极低。解决 SLOB的setup.sh脚本内部其实有优化。但如果你需要加载海量数据如TB级别可以考虑以下方法使用CREATE TABLE AS SELECT (CTAS)配合PARALLEL提示和NOLOGGING模式来加速初始数据创建需要修改setup.sh脚本。分批次加载即先设置一个较小的SCALE和SCHEMAS跑完测试后用INSERT /* APPEND */的方式增量添加数据需小心undo空间。实操心得对于超大规模压测的数据准备我通常会写一个独立的PL/SQL脚本使用DBMS_PARALLEL_EXECUTE包来并行插入数据效率比原版setup.sh高一个数量级。问题3runit.sh启动后很快所有会话都报错退出原因 最常见的原因是主键冲突。SLOB的随机算法在极高并发下可能生成重复的随机键值导致UPDATE时因唯一约束冲突而失败。解决检查SLOB的wait_kit是否已正确编译并确认slob.conf中相关路径设置正确。wait_kit中的随机数生成器质量更高。增大SCALE值。更大的数据范围能降低随机冲突的概率。减少UPDATE_WORKERS。降低并发度也能减少冲突。可以修改SLOB源码中的随机数生成逻辑但这需要一定的C语言和Oracle编程知识。6.2 性能结果异常分析问题4测试期间TPS非常低但磁盘%util和await都很低原因 “有压力无性能”。可能瓶颈不在I/O。排查检查CPU 用top看是否有一个或多个oracle进程CPU占用率100%。可能是WORK_LOOP设置过大或wait_kit消耗了过多CPU。适当降低WORK_LOOP。检查锁竞争 查询v$lock和v$session看是否有大量会话阻塞在enq: TX - row lock contention。SLOB的随机更新在极端情况下可能导致行锁竞争。这通常需要调整SLOB的随机算法或降低并发。检查日志切换 如果UPDATE_PCT很高redo日志生成会很快。如果日志文件太小频繁的日志切换log file switch completion会带来额外开销。检查v$logfile和v$log增大redo日志文件大小。问题5物理读IOPS远低于存储标称值原因 存储标称值通常是理论峰值或特定条件下的最优值。排查确认测试模式 存储厂商的IOPS通常是在100%随机读、队列深度Queue Depth很高的情况下测得的。SLOB默认的访问模式虽然是随机的但其队列深度受限于UPDATE_WORKERS数。可以尝试大幅增加并发数如128甚至256以增加队列深度压出存储的极限IOPS。检查操作系统和HBA卡队列深度 Linux系统的/sys/block/sdX/queue/nr_requests参数可能限制了单个设备的队列深度。HBA卡驱动也可能有相关设置。检查数据库参数db_file_multiblock_read_count参数影响多块读的大小但对单块读影响不大。确保filesystemio_options设置为SETALL或ASYNCH以启用异步I/O。6.3 环境与配置问题问题6测试数据量太大表空间不够用计算 总数据量 ≈SCALE*SCHEMAS*数据库块大小。例如SCALE1000000,SCHEMAS16,块大小8192字节则总数据量 ≈ 1000000 * 16 * 8KB ≈ 128GB。确保表空间数据文件有足够空间且AUTOEXTEND打开。解决 规划测试时预先计算好所需空间。可以使用大文件表空间Bigfile Tablespace简化管理。问题7如何测试RACReal Application Clusters环境SLOB的配置 SLOB完全支持RAC。你可以在slob.conf中配置多个SQLNET_SERVICE如SQLNET_SERVICE_BASEracdb并设置THREADS_PER_SCHEMA。SLOB的每个进程会随机连接到RAC中的不同实例。这是测试缓存融合Cache Fusion和全局资源竞争的绝佳工具。重点关注 在RAC环境下跑SLOB要特别关注gc cr block receive time和gc buffer busy这类全局缓存等待事件。它们能反映节点间网络互联Private Network的性能。