关闭

Alluxio 压力测试的方法与实践

发表于:2024-4-03 09:42

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:佚名    来源:今日头条

  一、压力测试目的
  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提供一套内置的压测框架。
  二、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交互的耗时。具体包括以下步骤:
  · 创建一个临时文件
  · 依次读取输入文件,将数据写入到临时文件
  · 重命名临时文件为输出文件
  · 删除所有输入文件
  支持以下操作:
  · 支持指定合并比例
  · 支持指定文件大小和数量
  · 支持指定线程数量
  · 支持指定读写类型
  三、使用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/<username>.log文件中,通过该文件可查看压测工具日志。
  集群模式下,debug log位于各Job Worker节点的logs/user/<username>.log文件中,通过该文件可查看Job Worker上执行压测操作的日志。或在job_master.log和job_worker.log中查看Job Service分配压测任务产生的日志。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号