Closed SCAYLEHPC closed 2 years ago
alejandroalffer
commented
2 years ago Biuenas! Donde está ubicado tu nodo? Tenemos nodos boot en varias ubicaciones en europa, y la latencia no debería ser tan alta. Eso si... hemos tenido un nodo validador fuera de la red, lo que hacía que uno de cada 6 bloques tardará 10 segundos en ser minado.
Por favor, envíanos un admin.peers desde la consola geth para ver con quién est´s conectado
Saludos!
SCAYLEHPC
commented
2 years ago El nodo está ubicado en León, Castilla y León, España.
La salida del comando "admin.peers" es la siguiente:
admin.peers [{ caps: ["eth/63", "eth/64", "eth/65", "istanbul/64", "istanbul/99", "istanbul/100"], enode: "enode://e956a09e29a05a06bfe4049ebdd1f648fd8508c2a63114916aaee9ad41636cce80679e6d3467872fac7f298689243999490adb67d4bd4617329cd545d3f66b67@185.180.8.154:21000?discport=0", id: "1f98688cd11041bceba382fd552dcfab9c020c1afb98fd40be86de5a281f6f30", name: "Geth/BOT_Planisys_Telsius_8_16_01/v1.9.25-stable-919800f0(quorum-v21.10.0)/linux-amd64/go1.15.6", network: { inbound: false, localAddress: "172.17.0.2:60990", remoteAddress: "185.180.8.154:21000", static: true, trusted: false }, protocols: { istanbul: { difficulty: 35838145, head: "0x57dcdb13ce33ed103367e51aa0894de92eaf7ef2c357b6f5ff3640ade4900723", version: 64 } } }, { caps: ["istanbul/64"], enode: "enode://ec816cd01c4b4afc8b7e75b823817bd0b36d1672a42839544a57a312a5c04ab12a3d96a3957f2638a3fee52d10203e6d3351a48b245caea9469f020007fa2d18@54.72.163.31:21000?discport=0", id: "81719621e91c357839d219b23a4fc6a153d530c713773c4491648d105152f7f7", name: "Geth/BOT_Izertis_Telsius_2_4_02/v1.8.12-stable/linux-amd64/go1.9.5", network: { inbound: false, localAddress: "172.17.0.2:44784", remoteAddress: "54.72.163.31:21000", static: true, trusted: false }, protocols: { istanbul: { difficulty: 90393839, head: "0xa258cba4fd601e5cc7acaa9e785e70489b32803c34f18a5c577082b810c16629", version: 64 } } }, { caps: ["istanbul/64"], enode: "enode://623d6f2228378358c0bcae8e2087b5bd6207c4b9a048cd2d9878e4bed61e6af67a3ee30ab4692d226b3280211f4d038c818ccf4253a11cd452db8a6612889022@51.83.79.100:21000?discport=0", id: "a1e0109bc3fb2727c3e91a1156c48716c53886e7b97a7df4ff5087672ef2934b", name: "Geth/BOT_SERES_Telsius_2_8_00/v1.8.12-stable/linux-amd64/go1.9.5", network: { inbound: false, localAddress: "172.17.0.2:38406", remoteAddress: "51.83.79.100:21000", static: true, trusted: false }, protocols: { istanbul: { difficulty: 90393845, head: "0x715b0c007fc5fbae0c04b5581689d853ccf2257d3ad6b14d1168c2f932e9a42f", version: 64 } } }, { caps: ["eth/63", "eth/64", "eth/65", "istanbul/64", "istanbul/99", "istanbul/100"], enode: "enode://d7d50abadb467de05cf474c6c9d1b2b3a399de9ccb1a58ea26141509f6a05c7b68690c8cba812d4db0258add29c349af88f9e61e5ada1c674b16c302083627b8@54.228.169.138:21000?discport=0", id: "a2054ebfafb0f0f5d5aba7068e1f14829e69dace06ad91a4ce23012984de1f06", name: "Geth/BOT_DigitelTS_T_2_8_00/v1.9.25-stable-919800f0(quorum-v21.10.0)/linux-amd64/go1.15.6", network: { inbound: false, localAddress: "172.17.0.2:39336", remoteAddress: "54.228.169.138:21000", static: true, trusted: false }, protocols: { istanbul: { difficulty: 90393827, head: "0x840c8f94524208c17ab61c5ee70a1c36d3a4e5c6c6fafe01d98d7907ea3612b9", version: 64 } } }]
SCAYLEHPC
commented
2 years ago Hola.
@alejandroalffer @irzinfante ¿Se sabe algo con respecto a la incidencia que os comentaba, alguna idea de qué puede estar sucediendo? Parece ser que con el transcurso de los días el tiempo de propagación del nodo se sigue incrementando.
alejandroalffer
commented
2 years ago Hola!
Es un caso extraño: estás usando discos SSD para la BBDD del nodo? Se trata de un disco "local" (DAS), o de una unidad de red (NAS)?
Con un: ' eth_syncing' puedes ver si el nodo está sincronizando, o está en línea con la red
SCAYLEHPC
commented
2 years ago Para la BBDD del nodo se está utilizando discos rotacionales SAS de 10000 RPM en una cabina SAN de velocidad 10 GBe. Son los mismos discos que se utilizaron cuando instalamos el nodo y todo funcionaba correctamente, el problema en el tiempo de propagación lo hemos detectado hace un par de semanas, cuando detectamos que el nodo no aparecía en el monitor y reiniciamos el contenedor.
Por otro lado, el comando 'eth_syncing' retorna constantemente salidas similares a la siguiente (Siempre mantiene el "currentBlock" 6-10 bloques por detrás del "highestBlock"):
eth.syncing { currentBlock: 90677702, highestBlock: 90677708, knownStates: 0, pulledStates: 0, startingBlock: 90676897 }
Hola.
Hace unos meses desplegamos un nodo en la red T y aparentemente todo estaba bien, hace unas semanas al acceder al monitor de la red, detectamos que el nodo no aparecía listado en la misma, por tanto, reiniciamos el contenedor en el que se ejecuta el nodo (por medio de los scripts disponibles en el repositorio "docker/stop.sh" y "docker/start.sh").
Aparentemente, todo funcionó correctamente, el contenedor inició sin problemas y el nodo aparece de nuevo en el monitor de la red. Sin embargo, el nodo muestra un tiempo de propagación muy elevado con respecto al resto (más de 7-8 segundos, cuando la media es unos 500 milisegundos). Como consecuencia de este tiempo de propagación, el último bloque sincronizado siempre se mantiene unos 7-8 bloques por detrás del resto.
A pesar de todo esto, en principio el nodo funciona correctamente, tiene una latencia estable y he podido realizar una transacción y capturarla en el explorador de bloques.
Agradecería si alguien me pudiese indicar algún motivo por los que el nodo presenta este tiempo de propagación, si se debe a problemas en la red, problemas del nodo con los 'peers' o problemas de recursos de la máquina en la que se encuentra el contenedor y el nodo (en principio esta útima parte parece estar bien).