Периодические ошибки ожидания чтения при использовании web3.py для запроса удаленного узла ethereum

Я пытаюсь запустить некоторые вызовы функций web3.py для получения данных с удаленного узла Ethereum geth, на котором запущена тестовая сеть Rinkeby, размещенная на экземпляре AWS EC2 Linux.

Я настроил своего провайдера таким образом из локального интерпретатора Python3, и он успешно подключается и работает с перерывами для определенных базовых вызовов функций:

import web3, json, requests
from web3 import Web3, HTTPProvider
provider = HTTPProvider( 'http://remote-node-ip-address:8545' )
w3 = Web3(provider)

Однако, когда я запускаю определенные вызовы функций (например, w3.eth.accounts из интерпретатора Python3), удаленный сервер значительно замедляется (зависает) и в основном очень часто выходит из строя с этой ошибкой:

requests.exceptions.ReadTimeout: HTTPConnectionPool(host='remote-node-ip', port=8545): Read timed out.

(тайм-аут чтения = 10)

Но иногда это работает просто отлично, так что общее сетевое подключение на месте. Когда я подключаюсь по SSH к удаленному серверу AWS, который на самом деле является контейнером Docker, он кажется отстающим и медленным. Единственное, что я заметил из выходных данных TOP ниже, это то, что %CPU для WA очень высок и составляет 99,5%:

> top - 23:44:51 up  6:42,  0 users,  load average: 1.76, 1.73, 1.75
> Tasks:   4 total,   1 running,   3 sleeping,   0 stopped,   0 zombie
> %Cpu(s):  0.3 us,  0.3 sy,  0.0 ni,  0.0 id, **99.5 wa**,  0.0 hi,  0.0
> si,  0.0 st KiB Mem :  2049248 total,  1102520 free,   596396 used,  
> 350332 buff/cache KiB Swap:        0 total,        0 free,        0
> used.  1289532 avail Mem 
> 
>   PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+
> COMMAND         406 root      20   0 1526260 491008    424 S  0.5 24.0
> 0:05.30 geth         
>     1 root      20   0   56416  11620      0 S  0.3  0.6   1:18.18 supervisord     422 root      20   0   36636   1116    684 R  0.3  0.1
> 0:00.01 top             412 root      20   0   18232    460      8 S 
> 0.0  0.0   0:00.02 bash

Я попытался масштабировать свой экземпляр AWS до экземпляра c5.xlarge с 4 виртуальными ЦП и оптимизированным для ЦП экземпляром c5.xlarge, но у меня возникла та же проблема. Я также протестировал те же команды на локальном узле geth, на котором запущен Rinkeby на моем локальном хосте, и проблем не возникло.

Есть ли у кого-нибудь какие-либо сведения о наилучшем способе устранения этих проблем с моим удаленным узлом geth?


python ethereum web3 geth
person Initial Commit    schedule 03.04.2018    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Похоже, вы исчерпали возможности ввода-вывода. Вы можете попробовать подтвердить с помощью iotop.

Узлы Ethereum лучше всего работают на локальном SSD. Если вы пытаетесь использовать EBS или даже локальный вращающийся диск, ваш узел может регулярно останавливаться.

Ознакомьтесь с экземплярами, поддерживающими локальный SSD:

Следующие экземпляры поддерживают тома хранилища экземпляров, использующие твердотельные накопители (SSD) для обеспечения высокой производительности произвольного ввода-вывода: C3, F1, G2, I2, I3, M3, R3 и X1.

person carver    schedule 05.04.2018
comment
Большинство упомянутых вами типов экземпляров являются устаревшими типами. Я нашел / протестировал C3, но у меня была такая же проблема. Тома EBS gp2 по умолчанию — это SSD, но у AWS есть тип тома с высоким объемом IOPS, который называется io1. Я настроил том io1 с максимальным значением 20000 IOPS (ограничение AWS ECS) и 401 ГБ (соотношение IOPS:GB должно быть ‹= 50). Но я все еще вижу ту же медлительность узла (в тестовой сети Rinkeby). Может быть, тома AWS просто не созданы для быстрых узлов ETH? top - 22:49:23 up 18 мин, 0 пользователей, средняя загрузка: 1,93, 1,54, 0,98 % ЦП: 0,3 us, 3,1 sy, 0,0 ni, 0,0 id, 95,8 wa, 0,0 hi, 0,0 si, 0,8 ул. - person Initial Commit; 10.04.2018