알파넷에서 매우 느린 노드 동기화

피어 수가 너무 적다는 메시지가 표시되는 경우 더 많은 피어를 추가 할 수 있습니다.이 스크립트는 알파넷에서 작동합니다 (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. 노드를 시작한 다음baker,endorser,accuser. 시작하는 동안 이러한 프로세스는 출력을 로그 파일로 리디렉션하는 것을 잊지 않습니다. 각각 :tezos.log,baker.log,endorser.log 및 accuser.log
6. 새 블록이 새 블록에 동기화되는 속도를 확인하십시오. 예. tail -f tezos.log를 사용하세요. 당신은 새로운 인스턴스 블록을 기억해야 시작되었습니다
7. 한동안은 그대로 두십시오. 나중에 와서 노드를 시작한 이후 동기화 된 블록 수를 확인할 수 있습니다. 내가 올바르게 기억하면 선택한 인스턴스에 따라 다르지만 최대 10,000 블록 정도까지 매우 빠르게 동기화 될 수 있습니다. 예를 들어t2.small 대신t2.large를 선택했을 수 있습니다.
8. 동기화 프로세스가 결국 느려지면 작업을 다시 반복하십시오. 이번에는t2.small에서t2.medium으로 마이그레이션합니다. 빠르게 동기화 된 또 다른 10k 블록을 제공합니다.

이 방법은 효과가 있었지만 약간의 수동 개입이 필요했습니다.

PS : 더 나은 결과를 얻으려면 위에서 설명한대로t2.small +t2.medium이 아닌t2.large +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.