拓冰网站定制 
存储分布式文件系统缓存大数据【免费下载链接】alluxioAlluxio, data orchestration for analytics and machine learning in the cloud项目地址https://gitcode.com/gh_mirrors/al/alluxio点击查看免费下载Alluxio 仓库的microbench模块提供了一套基于 OpenJDK JMHJava Microbenchmark Harness编写的微基准测试覆盖文件系统元数据操作、inode 元数据存储RocksDB、块存储读写、RPC 开销与快照生成等核心组件。本文以 microbench/readme.md 为主线结合模块源码与 microbench/pom.xml 构建配置完整讲解如何构建可执行的benchmarks.jar、如何用 JMH 选项精细控制基准的执行与结果导出并逐一剖析仓库中各类基准测试的实现思路与适用场景帮助你准确评估 Alluxio 各组件在真实负载下的性能特征。模块概览为哪些组件做微基准测试microbench是一个独立的 Maven 模块artifactId 为alluxio-microbench与 Alluxio 主构建一起参与完整构建。它的定位与 stress 模块的端到端压测不同微基准测试聚焦于单个组件、单次操作的开销例如一次getStatusRPC、一次 inode 写入、一次随机块读取从而在可控环境中量化最内层的性能成本。从源码结构看microbench/src/main/java/alluxio本模块的基准测试按包组织成五类包被测组件代表基准类alluxio.fsmaster文件系统元数据管理FileSystemMaster与 gRPC 客户端FileSystemMasterBench.java、FileSystemBench.javaalluxio.inodeInode 元数据存储堆内、RocksDB、RocksDBCacheInodeBenchRead.java、InodeBenchWrite.java、RocksBenchReadWrite.javaalluxio.worker块存储MonoBlockStore / PagedBlockStore的读写与加载BlockStoreRandomReadBench.java、BlockStoreSequentialReadBench.java、WorkerBenchLoad.javaalluxio.snapshotMaster 内嵌日志的快照snapshot生成SnapshotBench.javaalluxio根包RPC 工具类开销RpcUtilsBench.java每个基准类都以Benchmark注解标记被测方法并通过 JMH 的Param、State、Setup等注解声明参数与生命周期。构建产物是一个包含全部基准的 uber JAR方便统一分发执行。构建基准测试生成 benchmarks.jarmicrobench模块会随正常的全量项目构建一起被编译打包。如果只想单独构建本模块在仓库根目录执行$ mvn -DskipTests -Dcheckstyle.skip -Dlicense.skip -Dfindbugs.skip package -pl microbench命令说明-pl microbench只构建microbench模块配合 Maven 多模块项目的 reactor 选择-DskipTests跳过测试执行-Dcheckstyle.skip、-Dlicense.skip、-Dfindbugs.skip跳过代码风格、License 头与 FindBugs 静态检查加速构建。构建完成后会在microbench/target下生成一个名为benchmarks.jar的可执行 uber JAR里面包含本模块的全部基准测试类及其依赖。构建产物是如何生成的benchmarks.jar的命名与可执行性来自 microbench/pom.xml 中的两处配置属性uberjar.namebenchmarks/uberjar.name指定了 shade 插件产物的最终名称maven-shade-plugin的ManifestResourceTransformer将主类设置为org.openjdk.jmh.Main使 JAR 可以直接用java -jar启动 JMH runner。在依赖层面模块直接依赖了alluxio-core-server-common、alluxio-core-server-master、alluxio-core-server-worker、alluxio-core-client-fs、alluxio-tests等内部模块用于在基准中实例化真实的 Master/Worker 组件以及org.openjdk.jmh:jmh-core、jmh-generator-annprocess版本由jmh.version属性控制当前为 1.35、site.ycsb:core用于生成 Zipfian/Uniform 随机分布、mockito-core与junit用于 mock 外部依赖和commons-cli。shade 打包时还排除了签名文件META-INF/*.SF、*.DSA、*.RSA避免带签名 JAR 被合并后启动失败。运行基准测试按名称或正则选择benchmarks.jar是可直接执行的 JAR因此运行某个或某一组基准只需$ java -jar microbench/target/benchmarks.jar benchmark name这里的benchmark name可以是一个基准名称也可以是一个正则表达式——JMH 会运行所有完全限定类名与该正则匹配的基准。例如运行全部 inode 相关基准$ java -jar microbench/target/benchmarks.jar alluxio\.inode\..*如果不带任何参数直接执行 JARJMH 默认会对扫描到的全部基准逐一运行为了控制总时长通常建议显式给出名称或正则来圈定范围。JMH 常用选项详解精细控制基准执行与报告JMH 本身支持数十个选项用于微调基准的执行方式与报告生成。在运行命令后追加-h即可查看完整的用法说明与选项列表$ java -jar microbench/target/benchmarks.jar -h以下按功能分组介绍本模块中最常用的选项即 microbench/readme.md 明确列出的选项并给出可复制的实战示例。选择与排除基准使用-l [pattern]可以列出所有可用的基准如果附带一个正则表达式则只列出完全限定类名匹配该模式的基准。例如查看所有名称中包含rpc的基准$ java -jar microbench/target/benchmarks.jar -l rpc执行结果会显示类似alluxio.RpcUtilsBench.testCallAndReturn、alluxio.RpcUtilsBench.delayBaseline的条目——RpcUtilsBench中恰好就有两个这样的基准方法详见后文源码分析。使用-e pattern可以从运行集合中排除匹配的基准例如在运行全部基准时排除掉RocksBench*$ java -jar microbench/target/benchmarks.jar alluxio\.inode\.RocksBench.* -e .*ReadWrite控制基准的执行针对如何跑这类需求JMH 提供了迭代、时长与 fork 相关的选项选项含义本模块中可参考的默认值-i N测量迭代measurement iteration次数多数基准为 5~6 次-wi N预热迭代warmup iteration次数多数基准为 0~2 次-r time每次测量迭代的运行时长如-r 5s、-r 1000ms常见为 3 秒-w time每次预热迭代的运行时长常见为 3 秒-f N每个基准的 fork 次数1见下文注意事项示例——对RpcUtilsBench运行 2 次预热迭代每次 2 秒与 5 次测量迭代每次 5 秒并 fork 3 次$ java -jar microbench/target/benchmarks.jar alluxio.RpcUtilsBench -wi 2 -w 2s -i 5 -r 5s -f 3关于 fork 的实践要点原文档强调fork 是在同一组参数下重复执行预热阶段 测量阶段用于消除 JIT 编译、类加载等一次性开销带来的偏差。除非是在 IDE 里调试基准本身否则至少应 fork 一次否则测量结果可能包含 JVM 启动与 JIT 预热噪音不够准确。可以看到本模块的基准类普遍在类级别标注了Fork(value 1, jvmArgsPrepend -server)如 RpcUtilsBench.java并在-server模式下运行。参数化基准-lp 与 -p部分基准是参数化的它们在Param上声明了多个取值JMH 会对每个参数组合分别执行。使用-lp可以查看当前选定基准支持的所有参数及其取值$ java -jar microbench/target/benchmarks.jar alluxio.inode.InodeBenchRead -lp例如InodeBenchRead声明了mDepth默认10、mWidth默认0、mFileCount默认1000、mDistribution默认ZIPF、mSingleFiletrue/false、mType默认rocksCache、mRocksConfig默认javaConfig等参数见 InodeBenchRead.java。使用-p paramvalue可以覆盖某个参数。例如把文件数改为 5000、只测单文件查找路径$ java -jar microbench/target/benchmarks.jar alluxio.inode.InodeBenchRead -p mFileCount5000 -p mSingleFiletrue结果与输出-rff、-rf 与 -v用-rff file指定结果输出文件结果将被保存下来供后续数据处理用-rf format指定输出格式例如-rf csv或-rf json用-v启用 verbose 输出便于观察每个迭代的详细运行日志。一个完整的运行 存档示例$ java -jar microbench/target/benchmarks.jar alluxio\.worker\..* -rf json -rff results.json -v值得注意的是本模块的部分基准类在main方法中已经内建了结果导出逻辑。例如 FileSystemMasterBench.java 与 FileSystemBench.java 的main都通过OptionsBuilder.parent(argsCli).result(results.json).resultFormat(ResultFormatType.JSON)构造 runner并在默认输出文件名results.json上叠加命令行传入的 JMH 选项。因此既可以直接执行这些类的main也可以统一走java -jar benchmarks.jar的入口。仓库中的基准测试家族源码级速览为了帮助你快速找到与待测组件对应的基准下面按包逐一说明各基准的测的是什么、关键参数有哪些。fsmaster元数据 RPC 与客户端栈对比FileSystemMasterBench.java 直接实例化真实的FileSystemMaster及其 gRPC 服务端FileSystemMasterClientServiceHandler在内存中构建一棵指定深度mDepth默认 10、宽度mWidth默认 0、每层文件数mFileCount默认 1000的目录树然后反复执行getStatus请求对应./bin/alluxio fs stat类操作测量吞吐量BenchmarkMode(Mode.Throughput)。底层封装位于 FileSystemMasterBase.java它启动 UFS 类型日志系统、DefaultFileSystemMaster与 4 线程的 RPC 执行器预创建目录层级与文件基准方法则通过mFsMasterServer.getStatus(...)走完整的服务端处理链路。FileSystemBench.java 则从客户端视角对比四种读取路径的性能差异全部围绕根目录/的getStatus/getFileStatusalluxioGetStatusBench走 Alluxio 原生alluxio.client.file.FileSystem客户端hadoopGetFileStatusBench走 Hadooporg.apache.hadoop.fs兼容层alluxio.hadoop.FileSystemblockingGetStatusBench直接用 gRPC blocking stub 调用FileSystemMasterClientServiceasyncGetStatusBench用 gRPC future stub 发起异步调用并通过Semaphore默认 100 个并发槽位控制并发度。它的服务端有两种选择FileSystemBase.ServerType见 FileSystemBase.javaALLUXIO_GRPC_SERVER使用 Alluxio 自带的 gRPC 服务端含流控窗口、keepalive、鉴权等完整配置见 BenchStandaloneGrpcServer.javaBASIC_GRPC_SERVER使用裸 gRPC 服务端此外还支持STANDALONE模式——先通过BenchStandaloneGrpcServer.main启动独立服务端进程参数-s/--server、-p/--port、-cs/--client-socket再让基准连上去以便把服务端部署到特定机器上测网络栈。inode元数据存储引擎的读写微基准inode 基准的公共基础设施是 InodeBenchBase.java它把三种元数据存储实现统一封装heapHeapInodeStore纯堆内存实现rocksRocksInodeStore直接使用 RocksDBrocksCacheCachingInodeStore(RocksInodeStore)RocksDB 之上叠加缓存层也是默认值。它通过MasterTestUtils.testMasterContext()构建真实的InodeTree、InodeLockManager、MountTable等 Master 组件因此测出的写路径包含 inode 树的加锁与路径遍历开销见 InodeBenchWrite.java 的类注释。InodeBenchRead支持两种读操作mSingleFiletrue时返回树中单个 inode走lockFullInodePathgetFilemSingleFilefalse时遍历目录并列出子项走lockInodePathgetChildren。针对纯 RocksDB 键值层还有三个直接操作RocksInodeStore的基准RocksBenchBase.javaRocksBenchWrite.java以inodeId - inode 字节为键值对测量连续写入的性能mIsDirectory控制 inode 类型mUseSerialization控制是否把 ProtoBuf 序列化计入被测时间RocksBenchRead.java测量单键读取通过mReadType区分四种读取方式——serRead读回并反序列化、noSerRead只读字节、serNoAllocRead复用预分配 byte[] 反序列化、noSerNoAllocRead复用 byte[] 只读字节用于量化 ProtoBuf 序列化与内存分配在读取路径上的开销RocksBenchReadWrite.java按比例混合读写mWritePercentage默认 20控制写操作占比写操作中增删各半以保持文件总数稳定读 key 采用 Zipfian 分布偏向最近写入更可能命中 memtable的数据模拟热数据在最新写入的工作负载。值得一提的实现细节是 RocksBenchBase.java 中显式创建了WriteOptions().setDisableWAL(true)来关闭 WAL——因为基准要测的是存储引擎本身的读写成本而非日志持久化这一设计也体现了微基准精确隔离被测因素的思路。RocksDB 配置的可比性四种 mRocksConfiginode/Rocks 系列基准通过mRocksConfig参数在四种 RocksDB 配置间切换全部定义在 RocksBenchConfig.java配置名含义javaConfig使用RocksInodeStore中 Java 代码定义的默认配置不加载配置文件是各基准的默认值emptyConfig使用一个内容为空仅含版本头、无实际配置项的 RocksDB options 文件即全部采用 RocksDB 默认值baseConfig以配置文件字符串形式表达的一套基础配置与javaConfig等价但可编辑inodes/edges两个列族均compressionkNoCompression、prefix_extractorrocksdb.FixedPrefix.8并启用HashLinkListRepFactorymemtablebloomConfig在baseConfig基础上开启 Bloom Filter 优化memtable 层memtable_whole_key_filteringtrue、memtable_prefix_bloom_size_ratio0.02块层filter_policybloomfilter:10:false、index_typekHashSearch、data_block_index_typekDataBlockBinaryAndHash同时把块缓存与 memtable 写缓冲区放大write_buffer_size134217728缓存64MB从代码可以看到切换配置时还会同步设置PropertyKey.MASTER_METASTORE_ROCKS_*系列属性如MASTER_METASTORE_ROCKS_INODE_BLOOM_FILTER、MASTER_METASTORE_ROCKS_INODE_CACHE_SIZE等确保 Java 层配置与 RocksDB options 文件保持一致见 RocksBenchConfig.java。这意味着你可以把-p mRocksConfigbloomConfig与-p mRocksConfigemptyConfig的结果对比量化 Bloom Filter、哈希索引与更大缓存对元数据读写吞吐的影响——这也是本套基准最有价值的对比维度之一。worker块存储的随机读、顺序读与加载worker 包下的基准用于评估块存储层的 I/O 能力公共基类 BlockStoreBase.java 同时初始化两种块存储实现并共享同一个 UFSMonoBlockStore以TieredBlockStore为本地存储的传统分块实现PagedBlockStore以页缓存为本地存储的新实现。BlockStoreSequentialReadBench.java 对比两种存储的整块顺序读分别用BlockReader.read模拟未启用 pooling 的BlockReadHandler路径与reader.transferTo模拟启用 pooling 的路径块大小参数mBlockSizeMB可取 16/64 MB针对PagedBlockStore还可通过mPageSize1MB/4MB/8MB改变页大小。UFS 读取路径则通过OpenUfsBlockOptions的noCachetrue关闭缓存直接测远端读。BlockStoreRandomReadBench.java 则用固定随机种子SEED30生成一组随机偏移按 1MB 粒度随机读块覆盖本地缓存命中与 UFS 直读两种场景六个基准方法如monoBlockStoreRandReadLocal、pagedBlockStoreRandTransferUfs等用于评估随机访问模式下的寻址与零拷贝开销。WorkerBenchLoad.java 测量BlockStore.load批量加载 UFS 数据到本地缓存的能力mBatchSize取 1/10/100mBlockSize取 1MB 与 64MB其底层 BlockWorkerBase.java 以 mock 的 BlockMasterClient 与真实的TieredBlockStore/DefaultBlockWorker搭建 worker 环境。snapshot 与 rpc日志快照与 RPC 工具开销SnapshotBench.java 启动完整的AlluxioMasterProcess内嵌 Raft 日志JournalType.EMBEDDED预创建 100 万个已完成写入的文件然后测量JournalStateMachine.takeLocalSnapshot(true)生成一次快照的耗时每次 invocation 结束会清空快照目录避免累积。注意该基准特意设置了Warmup(iterations 0)与Measurement(iterations 1)并在main中使用forks(0)——因为快照是重量级操作完整预热与多次 fork 的成本过高。RpcUtilsBench.java 测量通用 RPC 工具方法RpcUtils.callAndReturn的固定开销以Blackhole.consumeCPU模拟 500 到 16000 纳秒不等的业务延迟同时提供一个不经过callAndReturn的delayBaseline基准作为对照从而分离出工具层的额外成本。基准数据的模拟模型文件结构与访问分布fsmaster/inode 两类基准共享两个工具类用于模拟真实目录树与访问模式BaseFileStructure.java以State(Scope.Benchmark)维护目录树的形状参数——深度depth、宽度width、每层文件数fileCount以及访问分布DistributionUNIFORM或ZIPF。分布生成器来自 YCSB 库UniformLongGenerator/ZipfianGeneratorZIPF 分布下浅层目录与较大的文件 id 被选中的概率更高对应较新的文件/浅路径更热的现实负载。BaseThreadState.java以State(Scope.Thread)记录每个 JMH 工作线程的索引ThreadParams.getThreadIndex()并提供nextDepth/nextWidth/nextFileId帮助方法让每个线程在各自的随机序列上独立取样。这种共享文件结构 线程私有状态的设计既保证了基准间数据的确定性便于复现又模拟了多线程并发访问同一棵目录树时锁竞争的真实场景。实战建议跑出可信的基准数据综合原文档要点与源码实现在实际运行本模块基准时建议遵循以下做法至少 fork 一次-f 1或以上。除 IDE 内调试外不要使用-f 0否则 JVM 启动、类加载与 JIT 预热会污染测量值本模块基准类默认即Fork(1)并加-server参数。先用-l与-lp侦察。通过-l确认基准名称通过-lp确认参数取值再决定是用默认参数还是-p覆盖多数参数基准的默认组合如mFileCount1000、mDistributionZIPF已经能给出有意义的基线。区分预热与测量。默认的-wi 2 -w 3s、-i 5/6 -r 3s是合理的起点如果被测路径包含大量预创建数据如 100 万文件的 SnapshotBench预热迭代数宜调小甚至为 0避免总时长失控。善用输出与对比。用-rf json/csv -rff file保存结构化结果对同一个基准分别跑不同参数如 inode 存储类型heapvsrocksvsrocksCache、RocksDB 配置javaConfigvsbloomConfig、块存储MonovsPaged在相同机器与 JVM 参数下对比结论才具有可比性。长任务注意时长。参数化基准会对每个参数组合逐一执行完整的预热测量循环参数多时总时长呈组合增长建议先用-l圈定范围必要时用-e排除不关心的基准。关于运行环境的前提说明本模块基于 JMH 1.35见 microbench/pom.xml 的jmh.version属性基准通过真实组件Master/Worker/RocksDB在本地进程内运行属于单机微基准若要评估跨节点或集群级吞吐应配合 stress 模块的压测工具使用。总结microbench模块把 JMH 的能力与 Alluxio 的真实组件结合为文件系统元数据 RPC、inode 元数据存储、块存储 I/O、日志快照与 RPC 工具层提供了可直接复现的微基准工具链一条mvn ... package -pl microbench命令产出benchmarks.jar再用java -jar配合-l/-lp/-p/-i/-wi/-r/-w/-f/-rff/-rf/-v即可完成从选择、参数化到结果导出的完整流程。阅读对应基准类如 FileSystemMasterBench.java、InodeBenchRead.java、BlockStoreRandomReadBench.java的类注释与参数定义还能进一步定制出贴合自身工作负载的测试矩阵为性能调优与架构选型提供数据支撑。赞分享存储分布式文件系统缓存大数据【免费下载链接】alluxioAlluxio, data orchestration for analytics and machine learning in the cloud项目地址https://gitcode.com/gh_mirrors/al/alluxio点击查看免费下载相关推荐Apache Pulsar 微基准测试Microbenchmarks模块实战指南基于 JMH 构建与运行Apache Pulsar 微基准测试Microbenchmarks模块实战指南基于 JMH 构建与运行 本文档系统讲解 Apache Pulsar 仓库消息队列后端Apache Kafka JMH 基准测试模块jmh-benchmarks实战指南运行、调参与编写微基准Apache Kafka JMH 基准测试模块jmh benchmarks实战指南运行、调参与编写微基准 本文以 Apache Kafka 仓库中的 jm消息队列流处理数据集成存储Apache Pulsar JMH 微基准测试指南构建、运行、剖析与 Agent 协作实践Apache Pulsar JMH 微基准测试指南构建、运行、剖析与 Agent 协作实践 Apache Pulsar 仓库中的 microbench 模块是消息队列流处理后端微服务消息路由上一篇解决AutoGluon多模态目标检测中的MMCV安装难题从报错到成功运行的完整指南下一篇使用 iTerm2 Python API 自动同步会话尺寸stty 脚本中的 EachSessionOnceMonitor 与 VariableMonitor 实战解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Alluxio 微基准测试指南：基于 JMH 构建、运行与调优 benchmarks.jar
存储分布式文件系统缓存大数据【免费下载链接】alluxioAlluxio, data orchestration for analytics and machine learning in the cloud项目地址https://gitcode.com/gh_mirrors/al/alluxio点击查看免费下载Alluxio 仓库的microbench模块提供了一套基于 OpenJDK JMHJava Microbenchmark Harness编写的微基准测试覆盖文件系统元数据操作、inode 元数据存储RocksDB、块存储读写、RPC 开销与快照生成等核心组件。本文以 microbench/readme.md 为主线结合模块源码与 microbench/pom.xml 构建配置完整讲解如何构建可执行的benchmarks.jar、如何用 JMH 选项精细控制基准的执行与结果导出并逐一剖析仓库中各类基准测试的实现思路与适用场景帮助你准确评估 Alluxio 各组件在真实负载下的性能特征。模块概览为哪些组件做微基准测试microbench是一个独立的 Maven 模块artifactId 为alluxio-microbench与 Alluxio 主构建一起参与完整构建。它的定位与 stress 模块的端到端压测不同微基准测试聚焦于单个组件、单次操作的开销例如一次getStatusRPC、一次 inode 写入、一次随机块读取从而在可控环境中量化最内层的性能成本。从源码结构看microbench/src/main/java/alluxio本模块的基准测试按包组织成五类包被测组件代表基准类alluxio.fsmaster文件系统元数据管理FileSystemMaster与 gRPC 客户端FileSystemMasterBench.java、FileSystemBench.javaalluxio.inodeInode 元数据存储堆内、RocksDB、RocksDBCacheInodeBenchRead.java、InodeBenchWrite.java、RocksBenchReadWrite.javaalluxio.worker块存储MonoBlockStore / PagedBlockStore的读写与加载BlockStoreRandomReadBench.java、BlockStoreSequentialReadBench.java、WorkerBenchLoad.javaalluxio.snapshotMaster 内嵌日志的快照snapshot生成SnapshotBench.javaalluxio根包RPC 工具类开销RpcUtilsBench.java每个基准类都以Benchmark注解标记被测方法并通过 JMH 的Param、State、Setup等注解声明参数与生命周期。构建产物是一个包含全部基准的 uber JAR方便统一分发执行。构建基准测试生成 benchmarks.jarmicrobench模块会随正常的全量项目构建一起被编译打包。如果只想单独构建本模块在仓库根目录执行$ mvn -DskipTests -Dcheckstyle.skip -Dlicense.skip -Dfindbugs.skip package -pl microbench命令说明-pl microbench只构建microbench模块配合 Maven 多模块项目的 reactor 选择-DskipTests跳过测试执行-Dcheckstyle.skip、-Dlicense.skip、-Dfindbugs.skip跳过代码风格、License 头与 FindBugs 静态检查加速构建。构建完成后会在microbench/target下生成一个名为benchmarks.jar的可执行 uber JAR里面包含本模块的全部基准测试类及其依赖。构建产物是如何生成的benchmarks.jar的命名与可执行性来自 microbench/pom.xml 中的两处配置属性uberjar.namebenchmarks/uberjar.name指定了 shade 插件产物的最终名称maven-shade-plugin的ManifestResourceTransformer将主类设置为org.openjdk.jmh.Main使 JAR 可以直接用java -jar启动 JMH runner。在依赖层面模块直接依赖了alluxio-core-server-common、alluxio-core-server-master、alluxio-core-server-worker、alluxio-core-client-fs、alluxio-tests等内部模块用于在基准中实例化真实的 Master/Worker 组件以及org.openjdk.jmh:jmh-core、jmh-generator-annprocess版本由jmh.version属性控制当前为 1.35、site.ycsb:core用于生成 Zipfian/Uniform 随机分布、mockito-core与junit用于 mock 外部依赖和commons-cli。shade 打包时还排除了签名文件META-INF/*.SF、*.DSA、*.RSA避免带签名 JAR 被合并后启动失败。运行基准测试按名称或正则选择benchmarks.jar是可直接执行的 JAR因此运行某个或某一组基准只需$ java -jar microbench/target/benchmarks.jar benchmark name这里的benchmark name可以是一个基准名称也可以是一个正则表达式——JMH 会运行所有完全限定类名与该正则匹配的基准。例如运行全部 inode 相关基准$ java -jar microbench/target/benchmarks.jar alluxio\.inode\..*如果不带任何参数直接执行 JARJMH 默认会对扫描到的全部基准逐一运行为了控制总时长通常建议显式给出名称或正则来圈定范围。JMH 常用选项详解精细控制基准执行与报告JMH 本身支持数十个选项用于微调基准的执行方式与报告生成。在运行命令后追加-h即可查看完整的用法说明与选项列表$ java -jar microbench/target/benchmarks.jar -h以下按功能分组介绍本模块中最常用的选项即 microbench/readme.md 明确列出的选项并给出可复制的实战示例。选择与排除基准使用-l [pattern]可以列出所有可用的基准如果附带一个正则表达式则只列出完全限定类名匹配该模式的基准。例如查看所有名称中包含rpc的基准$ java -jar microbench/target/benchmarks.jar -l rpc执行结果会显示类似alluxio.RpcUtilsBench.testCallAndReturn、alluxio.RpcUtilsBench.delayBaseline的条目——RpcUtilsBench中恰好就有两个这样的基准方法详见后文源码分析。使用-e pattern可以从运行集合中排除匹配的基准例如在运行全部基准时排除掉RocksBench*$ java -jar microbench/target/benchmarks.jar alluxio\.inode\.RocksBench.* -e .*ReadWrite控制基准的执行针对如何跑这类需求JMH 提供了迭代、时长与 fork 相关的选项选项含义本模块中可参考的默认值-i N测量迭代measurement iteration次数多数基准为 5~6 次-wi N预热迭代warmup iteration次数多数基准为 0~2 次-r time每次测量迭代的运行时长如-r 5s、-r 1000ms常见为 3 秒-w time每次预热迭代的运行时长常见为 3 秒-f N每个基准的 fork 次数1见下文注意事项示例——对RpcUtilsBench运行 2 次预热迭代每次 2 秒与 5 次测量迭代每次 5 秒并 fork 3 次$ java -jar microbench/target/benchmarks.jar alluxio.RpcUtilsBench -wi 2 -w 2s -i 5 -r 5s -f 3关于 fork 的实践要点原文档强调fork 是在同一组参数下重复执行预热阶段 测量阶段用于消除 JIT 编译、类加载等一次性开销带来的偏差。除非是在 IDE 里调试基准本身否则至少应 fork 一次否则测量结果可能包含 JVM 启动与 JIT 预热噪音不够准确。可以看到本模块的基准类普遍在类级别标注了Fork(value 1, jvmArgsPrepend -server)如 RpcUtilsBench.java并在-server模式下运行。参数化基准-lp 与 -p部分基准是参数化的它们在Param上声明了多个取值JMH 会对每个参数组合分别执行。使用-lp可以查看当前选定基准支持的所有参数及其取值$ java -jar microbench/target/benchmarks.jar alluxio.inode.InodeBenchRead -lp例如InodeBenchRead声明了mDepth默认10、mWidth默认0、mFileCount默认1000、mDistribution默认ZIPF、mSingleFiletrue/false、mType默认rocksCache、mRocksConfig默认javaConfig等参数见 InodeBenchRead.java。使用-p paramvalue可以覆盖某个参数。例如把文件数改为 5000、只测单文件查找路径$ java -jar microbench/target/benchmarks.jar alluxio.inode.InodeBenchRead -p mFileCount5000 -p mSingleFiletrue结果与输出-rff、-rf 与 -v用-rff file指定结果输出文件结果将被保存下来供后续数据处理用-rf format指定输出格式例如-rf csv或-rf json用-v启用 verbose 输出便于观察每个迭代的详细运行日志。一个完整的运行 存档示例$ java -jar microbench/target/benchmarks.jar alluxio\.worker\..* -rf json -rff results.json -v值得注意的是本模块的部分基准类在main方法中已经内建了结果导出逻辑。例如 FileSystemMasterBench.java 与 FileSystemBench.java 的main都通过OptionsBuilder.parent(argsCli).result(results.json).resultFormat(ResultFormatType.JSON)构造 runner并在默认输出文件名results.json上叠加命令行传入的 JMH 选项。因此既可以直接执行这些类的main也可以统一走java -jar benchmarks.jar的入口。仓库中的基准测试家族源码级速览为了帮助你快速找到与待测组件对应的基准下面按包逐一说明各基准的测的是什么、关键参数有哪些。fsmaster元数据 RPC 与客户端栈对比FileSystemMasterBench.java 直接实例化真实的FileSystemMaster及其 gRPC 服务端FileSystemMasterClientServiceHandler在内存中构建一棵指定深度mDepth默认 10、宽度mWidth默认 0、每层文件数mFileCount默认 1000的目录树然后反复执行getStatus请求对应./bin/alluxio fs stat类操作测量吞吐量BenchmarkMode(Mode.Throughput)。底层封装位于 FileSystemMasterBase.java它启动 UFS 类型日志系统、DefaultFileSystemMaster与 4 线程的 RPC 执行器预创建目录层级与文件基准方法则通过mFsMasterServer.getStatus(...)走完整的服务端处理链路。FileSystemBench.java 则从客户端视角对比四种读取路径的性能差异全部围绕根目录/的getStatus/getFileStatusalluxioGetStatusBench走 Alluxio 原生alluxio.client.file.FileSystem客户端hadoopGetFileStatusBench走 Hadooporg.apache.hadoop.fs兼容层alluxio.hadoop.FileSystemblockingGetStatusBench直接用 gRPC blocking stub 调用FileSystemMasterClientServiceasyncGetStatusBench用 gRPC future stub 发起异步调用并通过Semaphore默认 100 个并发槽位控制并发度。它的服务端有两种选择FileSystemBase.ServerType见 FileSystemBase.javaALLUXIO_GRPC_SERVER使用 Alluxio 自带的 gRPC 服务端含流控窗口、keepalive、鉴权等完整配置见 BenchStandaloneGrpcServer.javaBASIC_GRPC_SERVER使用裸 gRPC 服务端此外还支持STANDALONE模式——先通过BenchStandaloneGrpcServer.main启动独立服务端进程参数-s/--server、-p/--port、-cs/--client-socket再让基准连上去以便把服务端部署到特定机器上测网络栈。inode元数据存储引擎的读写微基准inode 基准的公共基础设施是 InodeBenchBase.java它把三种元数据存储实现统一封装heapHeapInodeStore纯堆内存实现rocksRocksInodeStore直接使用 RocksDBrocksCacheCachingInodeStore(RocksInodeStore)RocksDB 之上叠加缓存层也是默认值。它通过MasterTestUtils.testMasterContext()构建真实的InodeTree、InodeLockManager、MountTable等 Master 组件因此测出的写路径包含 inode 树的加锁与路径遍历开销见 InodeBenchWrite.java 的类注释。InodeBenchRead支持两种读操作mSingleFiletrue时返回树中单个 inode走lockFullInodePathgetFilemSingleFilefalse时遍历目录并列出子项走lockInodePathgetChildren。针对纯 RocksDB 键值层还有三个直接操作RocksInodeStore的基准RocksBenchBase.javaRocksBenchWrite.java以inodeId - inode 字节为键值对测量连续写入的性能mIsDirectory控制 inode 类型mUseSerialization控制是否把 ProtoBuf 序列化计入被测时间RocksBenchRead.java测量单键读取通过mReadType区分四种读取方式——serRead读回并反序列化、noSerRead只读字节、serNoAllocRead复用预分配 byte[] 反序列化、noSerNoAllocRead复用 byte[] 只读字节用于量化 ProtoBuf 序列化与内存分配在读取路径上的开销RocksBenchReadWrite.java按比例混合读写mWritePercentage默认 20控制写操作占比写操作中增删各半以保持文件总数稳定读 key 采用 Zipfian 分布偏向最近写入更可能命中 memtable的数据模拟热数据在最新写入的工作负载。值得一提的实现细节是 RocksBenchBase.java 中显式创建了WriteOptions().setDisableWAL(true)来关闭 WAL——因为基准要测的是存储引擎本身的读写成本而非日志持久化这一设计也体现了微基准精确隔离被测因素的思路。RocksDB 配置的可比性四种 mRocksConfiginode/Rocks 系列基准通过mRocksConfig参数在四种 RocksDB 配置间切换全部定义在 RocksBenchConfig.java配置名含义javaConfig使用RocksInodeStore中 Java 代码定义的默认配置不加载配置文件是各基准的默认值emptyConfig使用一个内容为空仅含版本头、无实际配置项的 RocksDB options 文件即全部采用 RocksDB 默认值baseConfig以配置文件字符串形式表达的一套基础配置与javaConfig等价但可编辑inodes/edges两个列族均compressionkNoCompression、prefix_extractorrocksdb.FixedPrefix.8并启用HashLinkListRepFactorymemtablebloomConfig在baseConfig基础上开启 Bloom Filter 优化memtable 层memtable_whole_key_filteringtrue、memtable_prefix_bloom_size_ratio0.02块层filter_policybloomfilter:10:false、index_typekHashSearch、data_block_index_typekDataBlockBinaryAndHash同时把块缓存与 memtable 写缓冲区放大write_buffer_size134217728缓存64MB从代码可以看到切换配置时还会同步设置PropertyKey.MASTER_METASTORE_ROCKS_*系列属性如MASTER_METASTORE_ROCKS_INODE_BLOOM_FILTER、MASTER_METASTORE_ROCKS_INODE_CACHE_SIZE等确保 Java 层配置与 RocksDB options 文件保持一致见 RocksBenchConfig.java。这意味着你可以把-p mRocksConfigbloomConfig与-p mRocksConfigemptyConfig的结果对比量化 Bloom Filter、哈希索引与更大缓存对元数据读写吞吐的影响——这也是本套基准最有价值的对比维度之一。worker块存储的随机读、顺序读与加载worker 包下的基准用于评估块存储层的 I/O 能力公共基类 BlockStoreBase.java 同时初始化两种块存储实现并共享同一个 UFSMonoBlockStore以TieredBlockStore为本地存储的传统分块实现PagedBlockStore以页缓存为本地存储的新实现。BlockStoreSequentialReadBench.java 对比两种存储的整块顺序读分别用BlockReader.read模拟未启用 pooling 的BlockReadHandler路径与reader.transferTo模拟启用 pooling 的路径块大小参数mBlockSizeMB可取 16/64 MB针对PagedBlockStore还可通过mPageSize1MB/4MB/8MB改变页大小。UFS 读取路径则通过OpenUfsBlockOptions的noCachetrue关闭缓存直接测远端读。BlockStoreRandomReadBench.java 则用固定随机种子SEED30生成一组随机偏移按 1MB 粒度随机读块覆盖本地缓存命中与 UFS 直读两种场景六个基准方法如monoBlockStoreRandReadLocal、pagedBlockStoreRandTransferUfs等用于评估随机访问模式下的寻址与零拷贝开销。WorkerBenchLoad.java 测量BlockStore.load批量加载 UFS 数据到本地缓存的能力mBatchSize取 1/10/100mBlockSize取 1MB 与 64MB其底层 BlockWorkerBase.java 以 mock 的 BlockMasterClient 与真实的TieredBlockStore/DefaultBlockWorker搭建 worker 环境。snapshot 与 rpc日志快照与 RPC 工具开销SnapshotBench.java 启动完整的AlluxioMasterProcess内嵌 Raft 日志JournalType.EMBEDDED预创建 100 万个已完成写入的文件然后测量JournalStateMachine.takeLocalSnapshot(true)生成一次快照的耗时每次 invocation 结束会清空快照目录避免累积。注意该基准特意设置了Warmup(iterations 0)与Measurement(iterations 1)并在main中使用forks(0)——因为快照是重量级操作完整预热与多次 fork 的成本过高。RpcUtilsBench.java 测量通用 RPC 工具方法RpcUtils.callAndReturn的固定开销以Blackhole.consumeCPU模拟 500 到 16000 纳秒不等的业务延迟同时提供一个不经过callAndReturn的delayBaseline基准作为对照从而分离出工具层的额外成本。基准数据的模拟模型文件结构与访问分布fsmaster/inode 两类基准共享两个工具类用于模拟真实目录树与访问模式BaseFileStructure.java以State(Scope.Benchmark)维护目录树的形状参数——深度depth、宽度width、每层文件数fileCount以及访问分布DistributionUNIFORM或ZIPF。分布生成器来自 YCSB 库UniformLongGenerator/ZipfianGeneratorZIPF 分布下浅层目录与较大的文件 id 被选中的概率更高对应较新的文件/浅路径更热的现实负载。BaseThreadState.java以State(Scope.Thread)记录每个 JMH 工作线程的索引ThreadParams.getThreadIndex()并提供nextDepth/nextWidth/nextFileId帮助方法让每个线程在各自的随机序列上独立取样。这种共享文件结构 线程私有状态的设计既保证了基准间数据的确定性便于复现又模拟了多线程并发访问同一棵目录树时锁竞争的真实场景。实战建议跑出可信的基准数据综合原文档要点与源码实现在实际运行本模块基准时建议遵循以下做法至少 fork 一次-f 1或以上。除 IDE 内调试外不要使用-f 0否则 JVM 启动、类加载与 JIT 预热会污染测量值本模块基准类默认即Fork(1)并加-server参数。先用-l与-lp侦察。通过-l确认基准名称通过-lp确认参数取值再决定是用默认参数还是-p覆盖多数参数基准的默认组合如mFileCount1000、mDistributionZIPF已经能给出有意义的基线。区分预热与测量。默认的-wi 2 -w 3s、-i 5/6 -r 3s是合理的起点如果被测路径包含大量预创建数据如 100 万文件的 SnapshotBench预热迭代数宜调小甚至为 0避免总时长失控。善用输出与对比。用-rf json/csv -rff file保存结构化结果对同一个基准分别跑不同参数如 inode 存储类型heapvsrocksvsrocksCache、RocksDB 配置javaConfigvsbloomConfig、块存储MonovsPaged在相同机器与 JVM 参数下对比结论才具有可比性。长任务注意时长。参数化基准会对每个参数组合逐一执行完整的预热测量循环参数多时总时长呈组合增长建议先用-l圈定范围必要时用-e排除不关心的基准。关于运行环境的前提说明本模块基于 JMH 1.35见 microbench/pom.xml 的jmh.version属性基准通过真实组件Master/Worker/RocksDB在本地进程内运行属于单机微基准若要评估跨节点或集群级吞吐应配合 stress 模块的压测工具使用。总结microbench模块把 JMH 的能力与 Alluxio 的真实组件结合为文件系统元数据 RPC、inode 元数据存储、块存储 I/O、日志快照与 RPC 工具层提供了可直接复现的微基准工具链一条mvn ... package -pl microbench命令产出benchmarks.jar再用java -jar配合-l/-lp/-p/-i/-wi/-r/-w/-f/-rff/-rf/-v即可完成从选择、参数化到结果导出的完整流程。阅读对应基准类如 FileSystemMasterBench.java、InodeBenchRead.java、BlockStoreRandomReadBench.java的类注释与参数定义还能进一步定制出贴合自身工作负载的测试矩阵为性能调优与架构选型提供数据支撑。赞分享存储分布式文件系统缓存大数据【免费下载链接】alluxioAlluxio, data orchestration for analytics and machine learning in the cloud项目地址https://gitcode.com/gh_mirrors/al/alluxio点击查看免费下载相关推荐Apache Pulsar 微基准测试Microbenchmarks模块实战指南基于 JMH 构建与运行Apache Pulsar 微基准测试Microbenchmarks模块实战指南基于 JMH 构建与运行 本文档系统讲解 Apache Pulsar 仓库消息队列后端Apache Kafka JMH 基准测试模块jmh-benchmarks实战指南运行、调参与编写微基准Apache Kafka JMH 基准测试模块jmh benchmarks实战指南运行、调参与编写微基准 本文以 Apache Kafka 仓库中的 jm消息队列流处理数据集成存储Apache Pulsar JMH 微基准测试指南构建、运行、剖析与 Agent 协作实践Apache Pulsar JMH 微基准测试指南构建、运行、剖析与 Agent 协作实践 Apache Pulsar 仓库中的 microbench 模块是消息队列流处理后端微服务消息路由上一篇解决AutoGluon多模态目标检测中的MMCV安装难题从报错到成功运行的完整指南下一篇使用 iTerm2 Python API 自动同步会话尺寸stty 脚本中的 EachSessionOnceMonitor 与 VariableMonitor 实战解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考