导读：本文内容源自Alluxio开源团队工程师丁博文在6月26日线上 Alluxio Meetup 分享的《Alluxio 压力测试方法与实践》，主要讲述了以下三方面内容：

• Alluxio压测原理，包括基于Job Service端到端测量组件性能数据与错误汇报。
• Alluxio压测工具分类，包括Master、Worker、Job Service等7大类压测工具。
• Alluxio压测工具使用，包括介绍如何通过命令行使用工具，压测中的常见问题，相关的排错方式。

通过以上几点，希望Alluxio用户、开发者能更便捷地进行压力测试。

欢迎继续关注Alluxio Meetup的一些技术分享。

全文目录：

• 压力测试目的
• Alluxio内置的压测框架
• 使用Alluxio内置压测工具

---

01

压力测试目的

1. 压力测试的目的

（1）确定配置和参数对性能的影响

• 检查影响性能的关键配置是否正确。如：Alluxio 计算内存JVM大小；Worker缓存容量等。
• 检查可调参数的值是否最优。如：根据用户使用场景，确定最佳读写方式。

若对数据持久性比较敏感的场景，建议使用CACHE_THROUGH方式同步写入UFS，避免数据丢失；若对临时文件、中间文件等使用场景，建议使用MUST_CACHE或ASYNC_THROUGH方式异步写入UFS，获取最佳写入速度。

若对于热数据读取的场景，建议使用CACHE或CACHE_PROMOTE方式，将数据读取至缓存中；若对于冷数据读取的场景，建议使用NO_CACHE，减少对缓存影响。

（2）确定系统性能的安全边界

确定系统能够稳定运行的最大外部压力。如：随着请求数量增加，系统吞吐量会逐渐稳定，但延时会增加，说明系统接近饱和状态。当进一步增加请求数量，出现吞吐量减少，延时继续增加的情况，说明系统已经超出安全边界。当明确安全边界后，在运维中，可通过监控及时发现系统达到安全边界的情况，此时可进行队列缓存、抛弃请求操作，保证系统稳定性。

（3）模拟压力过大情况下的失控状态

• 预演系统崩溃的情形，制定应急方案。
• 确定异常状态的恢复机制是否正常工作。如：Alluxio多Worker机制，当Client发现当前Worker Crash后，会向其他Worker发送请求。Master Crash时可通过HA机制，切换至Standby Master，防止集群失去响应能力。

非压力测试的目的：

• 系统的行为是否符合预期。
• 功能是否满足需求。
• 与外部组件是否能够协同工作。

2. Alluxio中压力的来源

（1）客户端的请求

• 对于Master，是元数据相关操作，如：创建、删除文件。
• 对于Worker，是Alluxio缓存的数据读写操作。
• 对于UFS，是底层数据的读写操作。

（2）Alluxio内部的异步和周期性任务

• 异步持久化，启动异步任务将数据写入UFS中。
• 副本数检查，周期性检查副本数是否满足用户设定范围。
• Worker状态报告，周期性向Master上报Worker上文件块的增减，存储容量的增减。
• 存储健康检查，存储设备失效时，需要向Master汇报。

（3）规模

• Alluxio集群管理的文件数量。当集群文件数量较大时，对Master的元数据管理会造成较大压力。
• Alluxio集群的Worker数量。在大集群中，大量Worker向Master汇报状态时，会对Master造成比较大的压力。

3. Alluxio中压力的具体表现形式

• 并发量。如：客户端同时发送大量请求、在Alluxio内部同时发起的异步任务、Worker同时对Master进行注册操作。该场景下瓶颈在于CPU或内存。
• 数据量。如：大流量的读或写。该场景下瓶颈在于存储介质和网络。
• 复杂度。复杂文件系统操作，如递归删除目录等。该场景下瓶颈在于CPU或内存。

Alluxio作为计算应用和底层存储之间的中间件，Alluxio的性能通过计算应用的性能而体现。这导致不同类型的计算应用在Alluxio上部署时，需要有不同的性能衡量方式。

如使用Presto+Alluxio时，使用TPC-DS等性能评估框架，获取QPS、查询复杂度、Presto I/O等性能指标。

再比如AI等工作负载场景，使用fio等评估工具，获得IOPS、数据吞吐量等性能指标。

因为不同类型的计算应用使用Alluxio方式不同，导致获得的性能指标不能直接进行比较。而且Alluxio和计算应用各自都是十分复杂的系统，各自有一系列的调优选项，如果将计算应用也作为压测对象一部分，则可能由于计算应用本身达到瓶颈，无法真正测试Alluxio的性能边界。

因此，Alluxio提供一套内置的压测框架。

--

02

Alluxio内置的压测框架

1. 基本概念

（1）压测操作

Alluxio支持的某一文件系统操作，其性能表现具有代表性。如创建文件，读取数据块时，内置压测框架会收集单次操作耗时作为原始数据。

（2）压测任务

指在一定的压测参数下重复执行单个或一组预定义的压测操作。如：向Master请求创建100万个文件，向Worker请求读取1GB的文件块。压测任务将会被封装为Job Service的执行单元，可以通过Job Worker执行。

压测任务结果即是本次任务计算汇总的统计数据，如：吞吐量、延迟平均值、中位数等。

2. 压测运行模式

Alluxio压测框架，支持两种基本的运行模式：集群模式、单机模式。

（1）集群模式（--cluster）

• 通过Job Service分发压测任务到Job Worker。
• Job Worker模拟客户端，向被测组件发起请求。
• Job Worker收到被测组件响应后，向Job Master报告压测结果。
• 可根据设置的压力参数，控制并发量和数据量。

集群模式优点在于可以极大地提高可模拟的并发量，但缺点在于出错时不易debug。

（2）单机模式

• 用户在当前节点提交压测任务，运行压测任务的节点直接向被测组件发起请求。
• 可根据设置的压力参数，控制并发量和数据量。

单机模式优点在于不依赖Job Service，使用简单，易于debug。但缺点在于并发量受限于单节点的计算能力。

3. 压测结果结算方式

（1）基于时间（--duration）

指设置压测运行的目标时长，在运行过程中反复执行压测操作，直到时间达到目标时间。根据该时间段内记录的操作次数，计算吞吐量。

基于时间是比较常见的压测结果计算方式。

（2）基于次数（--stop-count）

指设置压测操作的次数，反复执行压测操作，直到到达目标次数。根据确定的次数和记录完成这些操作所需时间，计算吞吐量。

基于次数的压测结果计算方式更适用于以数据量为变量的压测方案，如测量文件数量对性能的影响。也可用作某些测试中生成测试文件的步骤。

4. 压力测试结果报告

当压测操作完成时，压测工具会记录每次操作的耗时。

当压测操作发生错误时，会记录错误原因。

会基于耗时数据计算吞吐量、延迟的平均值、中位数、最大值等统计信息。

每个Job Worker会向Job Master汇报结果。Job Master汇总数据后发送报告给用户，压测报告会附带并压测相关配置参数，方便用户进行数据对比。

5. 压测工具分类

目前压测工具分为7类：

• Master：StressMasterBench, MaxFileBench, MasterMaxThroughput
• Worker：StressWorkerBench
• Job Service：StressJobServiceBench
• UFS：UfsIOBench
• FUSE：FuseIOBench
• Client：StressClientBench, CompactionBench
• RPC：WorkerHeartbeatBench, RegisterWorkerBench, GetPinnedFileIdsBench

压测工具举例：

（1）StressMasterBench

测量Master处理元数据操作在压力下的性能。支持以下操作：

• 支持指定操作类型，如创建文件、获取文件信息、删除文件等
• 支持指定读写类型(MUST_CACHE、CACHE_PROMOTE等)
• 支持指定客户端线程数量
• 支持指定文件或目录数量
• 支持覆盖默认客户端配置

（2）CompactionBench

模拟一个实现文件合并功能的简单应用的IO操作，并从客户端的角度测量性能，即测量的耗时中同时包含与Master和Worker交互的耗时。具体包括以下步骤：

• 创建一个临时文件
• 依次读取输入文件，将数据写入到临时文件
• 重命名临时文件为输出文件
• 删除所有输入文件

支持以下操作：

• 支持指定合并比例
• 支持指定文件大小和数量
• 支持指定线程数量
• 支持指定读写类型

--

03

使用Alluxio压测工具

1. 压测工具运行方式

Alluxio压测工具位于alluxio.stress.cli包内，部分位于对应的子包内。

用户可以通过alluxio命令行运行所需的压测类，步骤如下：

第一步，进入Alluxio的安装目录；

第二步，运行bin/alluxio runClass alluxio.stress.cli.StressMasterBench等。

用户也可通过执行--help查看可用选项和帮助。

2. 常见问题

（1）压测运行超时。常见原因有压测规模过大，在默认的压测超时时间（20分钟）内无法获取结果导致超时。针对这种情况，建议设置更长的超时时间，或缩小压测规模。

（2）所有压测操作均出错（没有有效的吞吐量数值）。需要根据错误信息判断错误原因并修复。常见原因有配置错误、网络连接错误导致客户端无法连接Master等。

（3）部分压测操作出错。在部分压测途中出现异常，前面操作成功但后续操作失败。常见原因有Master等组件遇到内存资源紧张，进入长时间GC，导致客户端等待结果超时。

3. Debugging

针对上述压测问题，用户可以开启debug log，从而查看详细的debug日志。

单机模式下，debug log位于运行压测工具的节点的logs/user/.log文件中，通过该文件可查看压测工具日志。

集群模式下，debug log位于各Job Worker节点的logs/user/.log文件中，通过该文件可查看Job Worker上执行压测操作的日志。或在job_master.log和job_worker.log中查看Job Service分配压测任务产生的日志。

今天的分享就到这里，谢谢大家。

---

分享嘉宾：丁博文 Alluxio 工程师

编辑整理：区启晟

出品平台：DataFunTalk

---

01/分享嘉宾

丁博文

Alluxio 开源团队工程师

---

主要负责Alluxio性能测试和计算应用集成等工作，工作期间成功解锁复旦大学电子工程专业硕士学位。

---

02/报名看直播 免费领PPT

---

03/关于我们

DataFun：专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100+线下和100+线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号 DataFunTalk 累计生产原创文章700+，百万+阅读，14万+精准粉丝。