欢迎光临
我们一直在努力

500个节点和性能测试

这是一个负载测试,旨在尝试对网络施加较大的负载

测试节点分布:

  • Dual节点(API +收获+投票):每个AWS区域40-50个测试节点
  • Peer节点:每个AWS区域10 -20
  • AWS区域7个:ap-northeast-1,ap-southeast-1,eu-central-1,eu-west-1,us-east-1,us-west-1,us-west-2

测试节点硬件配置:

  • Dual节点:t3.xlarge,4个vCPU,16GB
  • Peer节点:t3.large,2 x vCPU,8GB

测试方法:负载工具以100 tps在网络发送txs,接下来几天监控其故障,错误,性能等

测试团队已完成初步调查,有关发现,请参见下文:

概要

好消息是,我们已经测试了高达100tps的速度,并且Testnet毫无问题地对其进行了处理。

不好的消息是,在130tps的速度下,我们发现了一个看起来像MongoDB配置问题。这已经得到验证,但是在此阶段几乎可以肯定是原因。

该问题导致受影响的节点失败,并且最终性停止,因为它们是投票节点。

发生了什么

  • 上周末,我们进行了高达100 tps(传输交易)的测试,并顺利通过了测试
  • 昨晚UTC,我们以130 tps(传输交易)的速度开始测试,它导致MongoDB上出现一些内存问题
  • 随着MongoDB逐渐使用越来越多的内存,这些问题导致NGL节点开始出现故障,因为这些节点是有投票权的节点,最终性停滞了,但是块生产仍在进行中。
  • 另外,在过去几天中,增加了6-7百万个交易,因此该链现在约为40-45GB,双节点将使用更多的空间,因此可能还会发现一些磁盘较小的节点造成挑战

下一步

以下是从这里开始的计划:

  1. 恢复Testnet并使其正常运行,我们需要从投票池中注销失败的节点,并进行最终确定,希望在接下来的24小时内(可能更快),在公共备用频道上发布一条消息,以确认何时完成
  2. 有一个设置可用于限制MongoDB上的内存使用,我们将在本地对其进行测试以确保它满足需求
  3. 假设第2点有效,它将在NGL节点和针对社区节点提供的说明(以及默认值添加到引导程序)中推广,然后我们将重新运行测试。

评论 抢沙发