生产调优2 HDFS-集群压测

本文详细介绍了如何进行HDFS集群的读写性能测试,包括限制和不限制网络条件下的写入测试,以及读取性能测试。通过测试10个128MB文件的写入和读取,分析了网络带宽、磁盘性能对HDFS性能的影响,探讨了实测速度与网络资源的关系,并提供了性能优化建议。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

2 HDFS-集群压测

在企业中非常关心每天从 Java 后台拉取过来的数据,需要多久能上传到集群?消费者关心多久能从 HDFS 上拉取需要的数据?

为了搞清楚 HDFS 的读写性能,生产环境上非常需要对集群进行压测。

image

HDFS的读写性能主要受网络和磁盘影响比较大。为了方便测试,将hadoop102、Hadoop103、hadoop104虚拟机网络都设置为100mbps

image

100Mbps 单位是 bit; 10M/s 单位是 byte ; 1byte=8bit, 100Mbps/8=12.5M/s

测试网速

在hadoop102上开启一个服务器,用于提供对外下载接口

在 hadoop102 的/opt/software 目录下开启服务器。

[ranan@hadoop102 software]$ python3 -m http.server

image

image

下载速度在12.5M/s以内,说明网速设置完成

image

2.1 测试HDFS写性能

image

测试1 限制网络

1 向HDFS集群写10个128M的文件
hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 10 -fileSize 128MB

hadoop-mapreduce-clientjobclient-3.1.3-tests.jar 该jar包专门用于压力测试的
TestDFSIO HDFS的读写性能
-write 写性能
-nrFiles n 为生成 mapTask 的数量,生产环境一般可通过 hadoop103:8088 查看 CPU,一般是测试文件个数=集群CPU总核数 - 1(保证三台服务器都有MapTask运行
核数,设置为(CPU 核数 - 1)
-fileSize 128MB 每个文件的大小为128MB

如果测试过程中,出现异常
image

原因分析:实际4个G,虚拟内存是4*2.1=8.4G,因为centos7和Java8内存处理兼容性差,linux会预留大量内存不能使用,导致虚拟内存经常会溢出。

可以在 yarn-site.xml 中设置虚拟内存检测为 false

<!--是否启动一个线程检查每个任务正使用的虚拟内存量,如果任务超出分配值,则
直接将其杀掉,默认是 true -->
<property>
<name>yarn.nodemanager.vmem-check-enabled</name>
<value>false</value>
</property>

分发配置并重启 Yarn 集群

测试结果分析

image

Number of files: 生成 mapTask 数量, 一般是集群中(CPU 核数-1)
Total MBytes processed:所有数据总总大小
Throughput mb/sec:,单个 mapTask 的吞吐量
计算方式: 处理的总文件大小/(每一个 mapTask写数据的时间累加)
Average IO rate mb/sec::平均 mapTak 的吞吐量
计算方式:(每个 mapTask 处理文件大小/每一个 mapTask 写数据的时间)全部相加除以 task 数量
IO rate std deviation:方差、反映各个 mapTask 处理的差值,越小越均衡

image

1)一个三个副本,进行压测的时候,假设该客户端在集群中那么本地是准备了一份副本(不参与测试),对HFDS进行写的时候只需要写副本2、副本3

一共参与测试的文件: 10 个文件 * 2 个副本 = 20 个
压测后的速度:6.61M/s
实测速度:6.61M/s * 20 个文件 ≈ 132M/s
三台服务器的带宽: 12.5M/S(100mbps) + 12.5 + 12.5 ≈ 30M/s
所有网络资源已经用满。

如果实测速度远远小于网络,并且实测速度不能满足工作需求,可以考虑采用固态硬盘或者增加磁盘个数。

2)如果客户端不在集群节点,那就三个副本都参与计算

image

测试2 不限制网络

1 向HDFS集群写10个128M的文件

修改网络配置

image

hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -write -nrFiles 10 -fileSize 128MB
2 测试结果分析

image
集群中那么本地是准备了一份副本(不参与测试),对HFDS进行写的时候只需要写副本2、副本3

一共参与测试的文件: 10 个文件 * 2 个副本 = 20 个
压测后的速度:60.25M/s
实测速度:60.25M/s * 20 个文件 ≈ 1205M/s
不受网络限制,写速度受磁盘的读写速度限制

2.2 测试HDFS读性能

1 读取HDFS集群10个128M的文件

hadoop jar /opt/module/hadoop-3.1.3/share/hadoop/mapreduce/hadoop-mapreduce-client-jobclient-3.1.3-tests.jar TestDFSIO -read -nrFiles 10 -fileSize 128MB

image

实际的网速(网络的带宽):12.5M/s + 12.5M/s +12.5M/s= 37M/s

为什么读取文件速度大于网络带宽? 由于目前只有三台服务器,且有三个副本,数据读取就近原则,相当于都是读取的本地磁盘数据,没有走网络。

<think>好的,我需要回答用户关于分布式集群试的具体步骤和性能方案。首先,用户提到的引用资料里提到了使用Hadoop试任务如WordCount和Sort进行,还有配置参数整、故障模拟等化措施。我得整理这些信息,确保步骤清晰。 接下来,用户需要具体的步骤和化方案。根据引用[1],试的步骤应该包括准备试任务、执行试、监控指标和分析结果。要详细说明每一步该做什么,比如选择哪些试任务,如何监控资源使用情况。 性能部分,引用[1]提到了整配置参数、增加节点和化数据存储。我需要分点列出这些方面,并给出具体的例子,比如Hadoop的内存参数或者化数据分片策略。另外,引用[5]提到配置文件同步,可能涉及集群配置的一致性,这点也要提到。 用户还希望有示例,可能需要举一个试的实例,比如用Teragen生成数据并用Terrasort试。同时,引用[3]中Dask的例子也可以作为Python分布式集群化案例,比如使用Dask的内置算法计算效率。 还要注意引用文献的正确标注,比如在提到整配置参数时引用[1],在创建分布式表时引用[2],Dask的例子用引用[3],运行任务时引用[4],配置同步用引用[5]。 最后,生成的相关问题需要与分布式集群化相关,比如工具选择、参数、数据存储化等。确保问题覆盖用户可能感兴趣的各个方面。</think>### 分布式集群试步骤与性能方案 #### 一、分布式集群试步骤 1. **试任务准备** - 选择标准试任务(如Hadoop的$WordCount$、$Sort$或$TeraSort$),或根据业务场景定制试数据集[^1]。 - 使用工具生成大规模试数据(例如Hadoop的$Teragen$生成随机数据)。 - 创建分布式表或数据分片,确保数据均匀分布在集群节点上(参考示例:`CREATE TABLE my_distributed_table...`[^2])。 2. **试任务执行** - 通过集群管理界面或命令行提交任务(例如使用Dask的分布式度或Hadoop的`mapreduce`任务)[^3][^4]。 - 示例代码(Hadoop TeraSort试): ```bash hadoop jar hadoop-mapreduce-examples.jar teragen 1000000 /input hadoop jar hadoop-mapreduce-examples.jar terasort /input /output ``` 3. **监控与指标采集** - **资源监控**:观察CPU、内存、磁盘I/O、网络带宽使用率,重点关注瓶颈节点。 - **任务指标**:记录任务执行时间、任务失败率、数据倾斜情况(例如通过Hadoop JobTracker或Dask Dashboard)。 - **日志分析**:检查集群日志(如`pdi.log`),定位错误或警告信息。 4. **结果分析与基线建立** - 对比不同规模数据下的性能表现,建立基准性能曲线。 - 识别异常指标(如某节点磁盘I/O持续饱和),标记潜在化点。 --- #### 二、性能方案 1. **配置参数化** - **资源分配**:Hadoop的`mapreduce.map.memory.mb`或Dask的`worker_memory`,避免内存溢出或资源浪费[^1][^3]。 - **并行度控制**:根据节点数量化`mapreduce.tasktracker.map.tasks.maximum`(Hadoop)或Dask的`n_workers`参数。 - **示例化**:将Hadoop的`io.file.buffer.size`从4KB整为64KB,减少小文件I/O开销[^5]。 2. **数据存储化** - **分片策略**:根据数据访问模式选择分片键(例如按哈希或范围分布),减少跨节点数据传输。 - **缩算法**:启用Snappy或ZStandard缩,降低磁盘占用和网络传输开销。 - **冷热数据分离**:将频繁访问的热数据存储在高性能节点(如SSD存储节点)。 3. **集群扩展与容错** - **水平扩展**:增加计算节点(通过`deploy.sh`同步配置到新节点[^5])。 - **故障模拟试**:主动关闭部分节点,验证任务自动恢复能力(如Hadoop的TaskTracker重试机制)。 - **负载均衡**:使用动态度策略(如Dask的弹性工作队列),避免单节点过载。 4. **计算模型化** - **算法替换**:对特定计算任务使用内置化算法(如Dask的并行化XGBoost或Spark的Tungsten引擎)[^3]。 - **数据本地化**:通过`HDFS Block Placement Policy`确保计算任务先在数据所在节点执行。 --- #### 三、示例:Hadoop集群 1. **场景** - 使用$TeraSort$对1TB数据进行排序,初始执行时间为2小时。 - 发现`Reduce`阶段出现长尾效应,某节点磁盘写入速度显著低于其他节点。 2. **操作** - 将`mapreduce.reduce.shuffle.parallelcopies`从5整为20,提升数据拉取并行度。 - 为高负载节点更换为NVMe SSD,并将该节点标记为专用数据节点。 - 化后执行时间缩短至1.2小时,资源利用率从65%提升至82%。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值