注册
关闭
区块链大帝

区块链大帝

发布于 2019-12-18 阅读数 3356

Lotus挖矿:“小米+步枪”与“飞机+大炮”的对决,低配置挖矿的践行

编者注:原标题为《Lotus挖矿 – 小米+步枪 vs 飞机+大炮 ~ 低配置挖矿的践行》

 

lotus测试网上线不久后,接二连三的有很多矿工冒出排行榜,很快有的存储算力甚至超过了官方,场面真可谓是壮观,这“繁华”的背后流淌的是白花花的银子,让你不禁感叹这简直是土豪的烧钱游戏。

 

一、老将残兵的尝试:

经过几天时间对lotus存储过程和研究和尝试,技术团队使用1台二手的老将+30台二手的残军机器,综合时间在1.5天内(中途有过停止矿工,更换硬件,增加GPU等操作)获得了561G的算力,力图为证 (矿工Id: t02636):

Lotus挖矿:“小米+步枪”与“飞机+大炮”的对决,低配置挖矿的践行

 

二、本次测试的重点:

我们关注的重点一直在于对lotus存储本身的测试和研究,从而了解lotus的稳定性和lotus不同存储过程状态对硬件资源的消耗情况,最终得到一个数字上最合理的硬件资源模型,挖掘出硬件配置和存储算力产出之间的关系。这需要清晰的知道lotus存储过程的细节,以及实践得到每个状态转换过程中主要耗费的硬件资源和时间,到最后得出怎样的硬件配比可以被充分利用,而不导致过多的资源闲置。

 

三、关于lotus的稳定性测试:

总体评测如下:

1. 整体测试流程还是比较流畅的,硬件和GPU配置正确的情况下,官方描述的挖矿流程都可以顺利的跑通。

2. 测试期间没有无故的lotus和lotus-storage-miner进程退出,不像最早的Filecoin进程跑了一段时间会无故的退出(大多数情况下是硬件内存被耗尽,向操作系统申请内存失败导致)。

3. lotus和lotus-storage-miner在工作期间可以使用ctrl+c安全退出,这个安全的定义是:杀掉进程后,再次启动,存储挖矿流程可以继续进行,但是会出现部分出于某个状态的sector无法恢复,这个对于正式的文件存储是需要被解决的问题。

4. sector不同状态转换,会出现一定概率的出错,这个对于正式的文件存储,也是需要解决的问题。

5. 区块链整个流程都比较流畅,区块同步和出块在测试期间没有出现问题。

 

四、lotus存储主要的资源耗费:

测试过程监测到的主要资源耗费如下:

IO   :主要是磁盘IO,这个是核心,是最难调和的资源耗费,也是整个集群的每天可以产出的存储算力的第一个瓶颈。

CPU:主要的计算资源,全部存储过程都要用到。

内存:内存资源,全部存储过程都会用到。

GPU:这个主要用在时空证明,也可以用于封包加速。

 

五、我们的集群架构:

我们采取是一个主节点+30个密封节点的集群形式,密封的是1G的sector。具体的硬件配置如下:

主节点:

CPU : 8核16线程

内存:32G 硬盘:一个2T的PCIE接口的SSD硬盘 + 2个8T的企业硬盘

网络:千兆网卡 + 内网

GPU : NVIDIA 2080 SUPER (8G显存)

 

30个woker节点:

CPU : 20台(4核8线程) + 10台(2核4线程)

内存:16G

硬盘:1个8T的企业硬盘

网络:千兆网卡 + 内网

GPU : 无

 

七、lotus的sector转换过程和主要的资源耗费分析:

lotus和lotus-storage-miner启动后,从最开始的数据到最后的网络的存储算力,主要的几个过程以及每个过程的耗费的主要的资源如下:

Lotus挖矿:“小米+步枪”与“飞机+大炮”的对决,低配置挖矿的践行

备注:因为测试研究过程需要经常更换硬件和内核配置,此过程的截图数据来自我们本地机器的研究过程,非线上的工作集群,配置:(8核16线程,1个128G的SSD系统盘,1个512的PCIE硬盘,24G内存,无GPU)。

 

第一阶段:

主要工作:把文件数据(这里是指lotus pledge-sector的数据)分片进行addPieces前的工作。

资源耗费截图:

Lotus挖矿:“小米+步枪”与“飞机+大炮”的对决,低配置挖矿的践行

结果分析:这个过程主要耗费的是CPU的计算资源,磁盘IO和内存也会稍微偏高,相对CPU资源的增量来说,不算高。

 

第二阶段:

主要工作:将pieces添加到sector得到precommit的扇区。

资源耗费截图:

Lotus挖矿:“小米+步枪”与“飞机+大炮”的对决,低配置挖矿的践行

结果分析:上述截图发现,对nvme0n1磁盘的读和写的速度到了740M/s,同时该磁盘的占用率已经到了76.93%,CPU还没有充分利用,内存也只用到了不到4G,这个过程主要的资源耗费和瓶颈在磁盘IO上,因为需要从staging中拷贝大量的数据形成sector,用于下一步的pre-commit操作。

重点分析:这个地方的IO产出直接决定整个矿工集群一天的最大产出量。例如:平均一秒写入的速度假设为800M/s,也就是一天的最大的sector数据输出为:800M/s * 3600 * 24 =  69120000M = 67500G = 65.9T。接下来如果集群的密封和GPU的复制证明可以消耗这么多数据的,加上IO方面的优化,理论上一天可以产出65.9T的存储算力。

 

第三阶段:

主要工作:将sector数据进行密封进入到commit状态。

资源耗费截图如下:

Lotus挖矿:“小米+步枪”与“飞机+大炮”的对决,低配置挖矿的践行

结果分析:这个截图是单台的测试结果,发现CPU被占满了,内存也飚到了18G,但是还有不少空余,IO也是少量的,只有密封完了后,回写数据的一段时间IO会偏高,对于单台这个过程主要的瓶颈在CPU,集群模式还得考虑带宽。

重点分析:sector的密封可以分布式进行,例如我们的正式测试环境就使用了30个小节点一起参与并发的密封,只要带宽足够,整个密封的速度可以线性的增长,同时可以解放一些主节点的计算压力。但是密封节点的数量并不是越多越好,瓶颈主要在带宽和主节点产出的pre-commit的sector数量的联动,例如:主节点产出的pre-commit数量不够,增加密封节点也是闲置的。

 

我们线上的密封节点截图如下:

1. 密封节点在拉取和回写数据:

Lotus挖矿:“小米+步枪”与“飞机+大炮”的对决,低配置挖矿的践行

 

2. remote 节点数量:

Lotus挖矿:“小米+步枪”与“飞机+大炮”的对决,低配置挖矿的践行

remote有30个,同时30个在线并且处于忙碌状态。

 

3. 集群情况下的带宽使用情况:

Lotus挖矿:“小米+步枪”与“飞机+大炮”的对决,低配置挖矿的践行

千兆的网卡基本已经处于满负荷的状态了。

第四节点:

主要工作:将进行了密封的扇区进行时空证明。

主要资源耗费截图:

Lotus挖矿:“小米+步枪”与“飞机+大炮”的对决,低配置挖矿的践行

结果分析:这个过程主要耗费的是GPU(CPU效率太低),当然CPU和内存占用也会一定量的增大,这个地方没有截取到整体的监测截图。

 

八、配置和存储算力的关系总结:

这个为了提高输出量得使用master主节点+n个woker节点的集群方案,主要的五个资源因素是:磁盘IO,CPU,内存,带宽,GPU;每个因素维度都可以有很多的落地性的优化方案,但是有一点可以确定的是,这几个配置资源的关系一定要合理,不然会出现一些资源被占满,另一些资源闲置的情况,没法充分利用资源,尤其是主节点的配置,有问题欢迎留言交流探讨。

  • 0
区块链大帝
区块链大帝

0 条评论