alphanet上节点同步极慢

如果看到太多对等消息,则可以尝试添加更多对等.该脚本应适用于alphanet(您需要安装jq)

 for j in 0 1; do
  for i in `curl -s "http://api.alphanet.tzscan.io/v3/network?state=running&p=$j&number=50" \
    | jq -r '.[] | .point_id' | xargs`; do

    # handle ipv4 or ipv6
    numparts=$(echo $i | awk -F: '{print NF}')
    basenum=$((numparts-1))
    port=$(echo $i | cut -d: -f$numparts)
    base=$(echo $i | cut -d: -f1-$basenum)
    formatted="[$base]:$port"

    echo "Connecting $formatted..."
    ~/tezos/tezos-admin-client connect address $formatted
  done
done
 

信用归于此脚本的创建者.

You could try adding more peers if you are seeing the too few peers message. This script should work for the alphanet (you need jq installed)

for j in 0 1; do
  for i in `curl -s "http://api.alphanet.tzscan.io/v3/network?state=running&p=$j&number=50" \
    | jq -r '.[] | .point_id' | xargs`; do

    # handle ipv4 or ipv6
    numparts=$(echo $i | awk -F: '{print NF}')
    basenum=$((numparts-1))
    port=$(echo $i | cut -d: -f$numparts)
    base=$(echo $i | cut -d: -f1-$basenum)
    formatted="[$base]:$port"

    echo "Connecting $formatted..."
    ~/tezos/tezos-admin-client connect address $formatted
  done
done

Credit goes to creator of this script.

T2实例是通用计算实例,具有较低至中等的网络性能,并且未针对输入/输出操作(IOPS)进行优化.Tezos的所有帐户都需要大量的IO.

尝试启动一个存储优化实例(H1/I3/D2),我怀疑它将提供更好的性能.

请参阅- https://aws.amazon.com/ec2/instance-types/

T2 instances are general purpose compute instances which have low to moderate network performance and are not optimised for Input/Output operations (IOPS). Tezos is very IO intensive by all accounts.

Try spinning up a Storage Optimised instance (H1/I3/D2) and I suspect it will provide better performance.

See - https://aws.amazon.com/ec2/instance-types/

解决方案:实例类型正在更改

在为Alphanet同步节点时,我尝试了多个实例:从T2.micro到T3.xlarge.

在某些时候,我认为RAM大小或网络性能可能在这里起作用.但是,即使是T3.xlarge实例也无法使整个节点快速同步.

真正有用的是定期更改实例类型. 您可能已经注意到,节点刚开始时的同步速度要快得多.然后,一段时间后,它又变得非常缓慢.

我观察到,更大的AWS实例类型将不允许您快速完成此操作.

该计划可能是:

1. 停止面包师,背书人,原告,然后停止节点本身
2. 停止t2.medium实例
3. 将实例的类型更改为t2.small
4. 启动t2.small实例
5. 启动该节点,然后启动贝克,背书人和原告.开始时 这些过程不会忘记将输出重定向到日志文件 分别是:tezos.log,baker.log,endorser.log和accuser.log
6. 开始观察新块在新块上同步的速度 实例.使用tail -f tezos.log.您必须记住新实例的阻止 从
开始
7. 将其放置一段时间.您可能想稍后再来看看自启动节点以来已同步了多少个块.如果我没记错的话,它可能会非常快地同步多达10000个块,尽管这取决于您选择的实例.例如,您可能选择了t2.large而不是t2.small.
8. 当同步过程最终将减慢速度时,请再次重复操作.这次从t2.small迁移到t2.medium.它将为您提供另外1万个快速同步的块.

尽管需要一些手动干预,但此方法有效.

PS:为获得更好的结果,您可以使用t2.large +t2.medium作为更改对,而不是如上所述的t2.small +t2.medium.但是差异不会很大.

solution : instance type changing

while syncing the node for Alphanet I have tried multiple instances : from T2.micro to T3.xlarge.

At some point I thought that RAM size or Network performance may play a role here. But Even T3.xlarge instance did not bring the whole node synced fast.

What really helped is changing the instance types periodically. You may have noticed that node is syncing much faster in very beginning, when it just started. Then, after some time, it became very slow again.

I've made an observation that even bigger AWS instance type won't allow you to finish this operation fast in one take .

The plan may be:

1. Stop the baker, endorser, accuser and then stop the node itself
2. Stop the t2.medium instance
3. Change the type of your instance to t2.small
4. Start the t2.small instance
5. Start the node and then baker, endorser, accuser. While starting these processes do not forget to redirect the output to log files respectively: tezos.log, baker.log, endorser.log and accuser.log
6. Start watching how fast new blocks are getting synced on a new instance. Use tail -f tezos.log . You have to remember the block that new instance has started from
7. Leave it alone for sometime. You may want to come later and see how many blocks have been synced since you started the node. If I recall correctly, it may sync very fast up to 10 000 blocks or so, though it depends on the instance you have chosen. Instead of t2.small, you may have selected t2.large for instance.
8. When sync process will eventually slow down, repeat operation again. This time migrate from t2.small to t2.medium. It will give you another 10k blocks synced fast.

This approach worked, though it required some manual interventions.

PS: for better results you may use t2.large + t2.medium as a changing pair, not t2.small + t2.medium as described above. But the difference won't be significant.