Чрезвычайно медленная синхронизация узлов в 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 очень интенсивно требует ввода-вывода.

Попробуйте развернуть экземпляр с оптимизацией хранилища (H1/I3/D2),и я подозреваю,что он обеспечит лучшую производительность.

См. - https://aws.amazon.com/ec2/instance-types/

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

решение: изменение типа экземпляра

при синхронизации узла для Alphanet я пробовал несколько экземпляров: от T2.micro до T3.xlarge.

В какой-то момент я подумал,что здесь может сыграть роль размер ОЗУ или производительность сети. Но даже экземпляр 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. Оставьте это на время в покое. Вы можете прийти позже и посмотреть,сколько блоков было синхронизировано с момента запуска узла. Если я правильно помню,он может очень быстро синхронизироваться до 10 000 блоков или около того,хотя это зависит от выбранного вами экземпляра. Например,вместоt2.small вы могли выбратьt2.large.
8. Когда процесс синхронизации со временем замедлится,повторите операцию еще раз. На этот раз перейдите сt2.small наt2.medium. Это даст вам еще 10k блоков,которые будут быстро синхронизированы.

Этот подход сработал,хотя и потребовал некоторого ручного вмешательства.

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.