Sincronización de nodos extremadamente lenta en alphanet
3 respuestas
- votos
-
- 2019-03-07
Puedeintentar agregarmáspares si veelmensaje demuypocospares.Esta secuencia de comandos deberíafuncionarpara alphanet (necesita
jq
instalado)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
El créditoesparael creador de este script .
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.
-
- 2019-03-06
Lasinstancias T2 soninstanciasinformáticas de usogeneral quetienen un rendimiento de red debajo amoderado ynoestán optimizadaspara operaciones deentrada/salida (IOPS).Tezosesmuyintensivoen IOparatodas las cuentas.
Intente crear unainstancia de almacenamiento optimizado (H1/I3/D2) y sospecho queproporcionará unmejor rendimiento.
Consulte - 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.
-
Sibien estoes realmentemás rápido,sigue siendobastante lento y,confrecuencia,deja de sincronizarsepor completo cuando apareceelmensaje de 'muypocas conexiones'.Unmediot2esperfectamente capaz de sincronizartoda la cadena debloques deethereumen untiempo razonable,por lo queme cuesta creer que Tezos seamuchomásexigente que debería ser órdenes demagnitudmás lento soloen la red deprueba.Debe haber otrofactoren juego aquí.Whilst this is indeed faster, it's still pretty slow, and frequently stops syncing entirely when the 'too few connections' message pops up. A t2 medium is perfectly capable of syncing the entire ethereum blockchain in reasonable time, so I have a hard time believing Tezos is so much more demanding that it should be orders of magnitude slower on just the testnet. There must be another factor at play here.
- 0
- 2019-03-07
- AndyK
-
Estoy de acuerdoen queno debería serel caso,estanintenso comoparece.La comunidad sebeneficiaría de laejecución de algunospuntos de referenciapara determinar realmente quétipo de IOPSnecesita una sincronización completa.I agree it shouldn't be the case it is that intensive however it seems to be. The community would benefit from some benchmarks being run to determine actually what sort of IOPS does a full sync need.
- 0
- 2019-03-07
- xtzbaker
-
Unpanaderome dijo que AWSi3.larges son lasinstanciasmásefectivaspara losnodos de Tezos,especialmentepara hornear debido algran rendimiento de los SSD NVMe.También descubrí queel rendimiento del disco suele serel cuello debotellaen un VPS.I was told by a baker that AWS i3.larges are the most effective instances for Tezos nodes, especially for baking due to the great performance of NVMe SSDs. I also found that disk performance usually is the bottleneck on a VPS.
- 0
- 2019-03-21
- cryptodad
-
- 2019-03-07
solución: cambio detipo deinstancia
Mientras sincronizabaelnodopara Alphanet,probé variasinstancias: desde T2.micro a T3.xlarge.
En algúnmomentopensé queeltamaño de la RAM oel rendimiento de la redpuedenjugar unpapel aquí. Peroincluso lainstancia T3.xlargeno sincronizó rápidamentetodoelnodo.
Lo que realmente ayudófue cambiar lostipos deinstanciaperiódicamente. Esposible que hayanotado queelnodo se sincronizamuchomás rápido alprincipio,cuando recién comenzó. Luego,después de untiempo,volvió a sermuy lento.
He observado que untipo deinstancia de AWSinclusomásgrandeno lepermitiráfinalizaresta operación rápidamente de una sola vez.
Elplanpuede ser:
- Detenga alpanadero,endosante,acusador y luego detengaelnodoen sí
- Detenga lainstanciat2.medium
- Cambieeltipo de suinstancia at2.small
- Inicie lainstanciat2.small
- Inicieelnodo y luegopanadero,endosante,acusador. Al comenzar estosprocesosno olvides redirigir la salida a archivos de registro respectivamente:tezos.log,baker.log,endorser.log y accuser.log
- Comience a ver quétan rápido se sincronizan losnuevosbloquesen unnuevo
ejemplo. Utilice
tail -f tezos.log
. Tienes que recordarelbloqueo deesanuevainstancia ha comenzado desde - Déjelo solopor algúntiempo. Esposible que desee venirmástarde y ver cuántosbloques se han sincronizado desde queinicióelnodo. Simalno recuerdo,puede sincronizarsemuy rápido hasta 10 000bloquesmás omenos,aunque depende de lainstancia que hayaelegido. En lugar det2.small,esposible que haya seleccionadot2.large,porejemplo.
- Cuandoelproceso de sincronizaciónfinalmente se ralentice,repita la operaciónnuevamente. Esta vezmigre det2.small at2.medium. Te dará otros 10kbloques sincronizados rápidamente.
Esteenfoquefuncionó,aunque requirió algunasintervencionesmanuales.
PD:para obtenermejores resultados,puede usart2.large +t2.medium comopar cambiante,not2.small +t2.medium como se describe arriba. Pero la diferenciano será significativa.
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:
- Stop the baker, endorser, accuser and then stop the node itself
- Stop the t2.medium instance
- Change the type of your instance to t2.small
- Start the t2.small instance
- 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
- 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 - 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.
- 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.
-
Sospecho que la razónpor la que ve unbuen rendimientoinicialen lasinstancias de TX que se degrada lentamenteesporqueestostipos deinstanciaestán diseñadospara quepuedan aumentartemporalmente su IO y CPUpara hacerfrente apequeñosperíodos demayor actividad.Esto se llamaestallido y solo dura un cortotiempo antes de volver a un rendimientomásmediocre.Para carga sostenida de IO o CPU,se requiere untipo deinstancia diferente.Este sería sin dudael caso de una sincronización denodos.I suspect the reason you see initial good performance on the TX instances that slowly degrades is because these instance types are designed so they can temporarily increase their IO and CPU to deal with small periods of increased activity. This is called bursting and only lasts for a short time before reverting to a more mediocre performance. For sustained IO or CPU load a different instance type is required. This would certainly be the case for a node sync.
- 0
- 2019-03-07
- xtzbaker
-
Recibiendoel siguienteerror usando labase de datos Alphanet anterior: 7 demarzo 09:25:47 -node.main: Iniciandoelnodo Tezos ... 7 demarzo 09:25:47 -node.main: No hay descubrimiento depares locales. 7 demarzo 09:25:47 -node.main: Id. Global delpar:idrJtoLevBnyf6ZzUqcmyGBFKUssa7 7 demarzo 09:25:47 -node.worker: cadena de arranque ... tezos-node: Error: Falta la llaveen latienda: chain/8eceda2f/genesis/hashReceiving the following error using the Alphanet DB above: Mar 7 09:25:47 - node.main: Starting the Tezos node... Mar 7 09:25:47 - node.main: No local peer discovery. Mar 7 09:25:47 - node.main: Peer's global id: idrJtoLevBnyf6ZzUqcmyGBFKUssa7 Mar 7 09:25:47 - node.worker: bootstrapping chain... tezos-node: Error: Missing key in store: chain/8eceda2f/genesis/hash
- 0
- 2019-03-07
- AndyK
Entonces,configuré unnodo Tezosen unainstancia AWS EC2t2.medium.Seguí lasinstrucciones aquí ,peroparaalphaneten lugar demainnet.
Lleguétan lejos como: ./tezos-node run --rpc-addr: 8732
Seestáejecutando y sincronizando,pero MUY lento.En unpar de horas deejecución,los datos devueltospor 'el cliente obtiene lamarca detiempo' se han adelantado solo uno o dos días.También recibo confrecuenciamensajes como p2p.maintenance: Muypocas conexiones (5)
Heintentado abrir TODOS lospuertos deentrada y salida de lainstancia solopara asegurarme de queno sebloqueaeltráfico.No haceninguna diferencia.¿Quépasa?¿Quénecesito cambiar?