LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 区块链资讯 > Lotus挖矿:小米+步枪 vs 飞机+大炮 : 低配置挖矿的践行

Lotus挖矿:小米+步枪 vs 飞机+大炮 : 低配置挖矿的践行

2019-12-18 星际鑫航IPFS社区 来源:区块链网络

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

一,老将残兵的尝试:

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

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

二,本次测试的重点:

星际鑫航关注的重点一直在于对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启动后,从最开始的数据到最后的网络的存储算力,主要的几个过程以及每个过程的耗费的主要的资源如下:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

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

第一阶段:

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

资源耗费截图:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

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

第二阶段:

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

资源耗费截图:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

结果分析:上述截图发现,对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状态。

资源耗费截图如下:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

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

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

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

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

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

2. remote 节点数量:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

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

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

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

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

第四节点:

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

主要资源耗费截图:

640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

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

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

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

九,矿工福利:

星际鑫航会将整个过程集成到GammaOS以便于一键部署、运维、管理和查看基于数据统计的AI分析报告。

分析视频:咱们的工程师整理的一些测试研究过程中的录屏,请戳链接:

https://v.youku.com/v_show/id_XNDQ3MDkzNTIzNg==.html?spm=a2hbt.13141534.app.5~5~5!2~5~5~5!2~5~5!2~5!2~5!2~5~5~A

密码:xjxh123

------------------------------------------------------------------------------

星际鑫航是一家IPFS-Filecoin的云管理平台及存储服务的一体化综合解决方案提供商。

我司技术团队成员之一被协议实验邀请成为社区核心开发者成员之一,我们开发的Filecoin钱包被官方协议实验室收录,这也是国内首家被官方认可并收录的产品。

公司围绕核心产品即GAMMAOS系统、数据机房SEDC、Filecoin钱包,公司核心团队来自于清华大学、中山大学、中科院、亚利桑那州大学等的博士、硕士,以新一代通信协议IPFS和最新云计算架构Serverless为切入点,为企业提供低成本、高性能、更安全的存储与计算服务。

联系我们:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

—-

编译者/作者:星际鑫航IPFS社区

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...