把Jerasure整合到HDFS-RAID中

时间:2022-12-27 19:54:22

之前把HDFS-RAID迁移到Hadoop-2.2.0中,在公司的集群内测试,用Java语言实现的EC算法超慢,下面是一些测试分析数据:

生成算法性能测试

测试目的:根据生成EC的三个流程,读原始数据,计算EC校验码,写校验数据,我们要测试三个流程各自对总时间的占比,这样方便我们分析性能瓶颈在什么地方。

预制条件:HDFS中存在测试文件。分析HDFS-RAID中的源代码,在编码器类Encoder的具体实现类ReedSolomonEncoder中的encodeStripe()方法中,存在如下逻辑:假定编码策略为RS(K,M),首先从流中读入大小为bufSize的K路数据,然后对这些读入内存中的K路数据按字节进行EC运算,算出结果后,再把bufSize的M路数据写出去HDFS。这三个小步骤计算完后,重新一个循环,直到把一个条带内的块数据计算完。对上面三个步骤的间隙我们分别记下时间戳,d0,d1,d2,d3。相互的差值刚好算出每部分的时长:

 读取原始数据时长 =  t1 = d1 – d0

计算EC校验码时长 =  t2 = d2 – d1

写EC校验数据时长 =  t3 = d3 – d2

            总时间 =   t = d3 – d0

我们在程序中设置bufSize为1M大小,程序运行时把上面的时间戳分别输出,就可扑捉占比信息。

测试结果

 

耗时(毫秒)

bufSize

K

M

t1

%

t2

%

t3

%

t

%

1M

10

4

32

8%

378

91%

6

1%

416

100%

1M

10

4

16

4%

446

95%

6

1%

468

100%

1M

10

4

16

4%

405

93%

12

3%

433

100%

1M

10

4

20

3%

551

96%

7

1%

578

100%

在记录上面数据时,同时用top命令检测机器上CPU的使用情况。当前机器配置了24个CPU核,检测发现,在某个时刻,24核中总有一个核的CPU使用率维持在95%以上,而其他23核基本维持在空置情况。通过进程追踪发现,促使CPU使用在95%以上的那个进程正是执行EC运算的程序。

结果分析

       通过对上表数据进行线性回归,粗略可以估算每个步骤的时间占比:读取原始数据占比5%,计算EC数据占比93%,写EC校验数据占比2%。由此看出,在这个小串行的执行过程中,计算EC数据的整个性能的瓶颈。考虑计算EC数据的CPU使用情况,推知HDFS-RAID上基于Java原生态函数实现的EC算法,性能非常低,并且没有把算法并行或并发化,没有充分利用多核CPU的效力。(通过对源代码的分析,佐证了这个推测。)


于是决定使用Jerasure替换HDFS-RAID中的计算模块,Jerasure采用较为旧的1.2版本,据说最新的2.0拥有更快的速度。

替换后,发现之前计算1M的数据大约在500ms左右,而替换后降为100ms左右。通过执行计算时分析CPU使用情况发现,Jerasure依然没有发挥多核的优势,估计作者Plank依然没有对EC进行并行化计算。


由于公司对这块的计算速度有特殊的要求,打算继续引入另一个可能更快的计算库:ISA-L。到时对三者进行对比。