go-ethereum 🚀 - ¿Cuál es el límite superior de las "nuevas entradas de estado importadas"? | bleepcoder.com (2024)

mismo aquí, se describe el estado detallado aquí:
https://github.com/ethereum/go-ethereum/issues/14571

Lo que pude entender de este problema de modo rápido geth es que:

1. Debe utilizar un procesador de cuatro núcleos con 4 GB o más de RAM
2. Debes usar SSD en lugar de HDD
3. Su conexión a Internet debe ser de al menos 2 Mbps o más y confiable .
   Si todo lo anterior está marcado, entonces debería probar con geth. Usando geth en modo completo, lo más probable es que se sincronice en una semana o dos como máximo. En el modo rápido, depende de su suerte, pero lo más probable es que se sincronice en 2-3 días o nunca.

Encontrando problemas similares. Geth: la sincronización rápida no se sincroniza, y mucho menos rápido.

Usando 1.6.7-estable en Ubuntu, y se pone dentro de 100 bloques y luego importa interminablemente entradas de estado.

El mismo problema aquí, ejecuté geth con 1024 caché y sincronización rápida hace tres días y, después de alcanzar el último número de bloque hace un día, nunca había detenido el estado "Importadas nuevas entradas de estado".

Durante esta fase de "entradas de estado", sin embargo, mi saldo cambió de 0 al valor correcto y el número de bloque informado cambió de 0 a un número cercano al valor de bloque más alto.

Esta es la versión geth en mi máquina ubuntu:

Geth
Versión: 1.6.7-estable
Confirmación de Git: ab5646c532292b51e319f290afccf6a44f874372
Arquitectura: amd64
Versiones del protocolo: [63 62]
ID de red: 1
Go Versión: go1.8.1
Sistema operativo: linux
GOPATH =
GOROOT = / usr / lib / go-1.8

y este es el resultado ahora cada medio segundo:
...
INFO [09-08 | 10: 05: 34] Recuento de nuevas entradas de estado importadas = 11 enjuagadas = 7 transcurridas = 216.807ms procesadas = 25170515 pendientes = 1852 reintentos = 1 duplicado = 5293 inesperados = 6261
INFO [09-08 | 10: 05: 34] Recuento de nuevas entradas de estado importadas = 2 enjuagadas = 5 transcurridas = 521,989 µs procesadas = 25170517 pendientes = 1847 reintentos = 0 duplicados = 5293 inesperados = 6261
INFO [09-08 | 10: 05: 34] Recuento de nuevas entradas de estado importadas = 7 enjuagadas = 1 transcurrido = 263,738 ms procesados ​​= 25170524 pendientes = 1862 reintentos = 2 duplicados = 5293 inesperados = 6261
INFO [09-08 | 10: 05: 34] Recuento de nuevas entradas de estado importadas = 2 enjuagadas = 4 transcurridas = 6,934 ms procesadas = 25170526 pendientes = 1859 reintentos = 0 duplicados = 5293 inesperados = 6261
INFO [09-08 | 10: 05: 34] Recuento de nuevas entradas de estado importadas = 1 vaciado = 0 transcurrido = 27,828 ms procesados ​​= 25170527 pendiente = 1861 reintento = 1 duplicado = 5293 inesperado = 6261
INFO [09-08 | 10: 05: 34] Recuento de nuevas entradas de estado importadas = 5 enjuagadas = 5 transcurridas = 19.440 ms procesadas = 25170532 pendientes = 1860 reintentos = 0 duplicados = 5293 inesperados = 6261
...

este es el resultado de eth.syncing y otras herramientas geth:

eth.syncing
{
currentBlock: 4249131,
más altoBloque: 4250814,
knownStates: 25172364,
pullStates: 25170517,
bloque de inicio: 0
}

net.peerCount
25

eth.blockNumber
4244762

El saldo de ether de mi billetera no es 0 y se informa correctamente y se actualiza a la última transacción realizada hace un día.

¿Cuánto tiempo se supone que durará este estado?

ACTUALIZACIÓN: Detuve geth con CTRL-D y lo volví a abrir. Ahora parece que la fase "Nuevas entradas de estado importadas" se detuvo y geth está funcionando correctamente actualizando solo los bloques nuevos.
Parece que el problema es que la sincronización rápida continúa para siempre para descargar estados y no es consciente de que la cadena de bloques ya se encuentra en un estado correcto y consistente.

Entonces, por ahora, hasta que se resuelva el problema, este es mi consejo:

• Iniciar geth sincronización rápida
• espere hasta que el comando eth.syncing informe un bloque actual cerca del bloque más alto
• Después de eso, cada pocas horas ejecute el comando: eth.blockNumber ... primero devuelve probablemente 0 pero continúe esperando.
• Cuando eth.blockNumber devuelve un valor diferente de 0 y cercano al valor del bloque actual, cierre geth con (CTRL-D o con el comando "salir" para que pueda cerrar correctamente y bajo control) y espere hasta que el programa se cierre de la manera correcta y su el shell del sistema operativo vuelve
• Reabrir geth con opción rápida. Verá la advertencia "Blockchain no está vacío, sincronización rápida desactivada" ... este es el comportamiento correcto, le indica que la sincronización rápida ha finalizado.
• Ahora los mensajes de "Nuevas entradas de estado importadas" desaparecen y solo ve estos mensajes cada pocos segundos:
  INFO [09-08 | 21: 12: 06] Nuevos bloques de segmento de cadena importados = 1 txs = 131 mgas = 5.379 transcurridos = 13.855s mgasps = 0.388 número = 4251422 hash = 697652… d85ce8

Ahora su problema ha sido resuelto y probablemente evite descargar muchos estados, reduciendo el espacio en el disco duro que ocupa geth también.

Esto es válido hasta que se resuelva el problema y geth se enterará cuando la cadena de bloques esté sincronizada correctamente.

Esta es mi experiencia, tal vez trabajo, tal vez no. Para mí funcionó.
Espero que esto ayude,
Marco

Creo que solo tiene que esperar hasta que eth.blockNumber muestre un número cerca de currentBlock antes de cerrarlo y comenzar de nuevo.
Olvidé decirle que elimine las cadenas de bloques antiguas antes de comenzar la tarea que dije antes.
Sí, la sincronización rápida se puede usar con una cadena de bloques vacía y solo la primera vez.
El comando para borrar toda la cadena de bloques es "geth eliminadob" en el shell del sistema operativo, elimina todo lo que se ha descargado antes.
Después de eso, puede iniciar una sincronización rápida nuevamente desde una cadena de bloques vacía y seguir el procedimiento que dije en mi publicación anterior con la esperanza de que funcione.

No soy un desarrollador geth, solo lo uso, así que no puedo resolver el problema o decirte qué hace internamente o por qué el comando te devuelve "6" y qué tienes que hacer, pero parece que descarga un muchos estados y, cuando encuentra el estado principal, puede construir la cadena de bloques completa. Para mí, esto sucedió cuando geth.syncing mostró un "estado conocido" cerca de: 20.000.000 pero puede suceder antes o después.

Durante mi prueba, después de que finalizó la sincronización rápida para descargar todos los encabezados de los bloques, se necesitan más de 24 horas para tener eth.blockNumber = 4244762. Ejecuto geth en un servidor con una banda de 100 Mb / s.

Cuando me mostró "0", dejé que hiciera el trabajo y después de 24 horas veo que el comando devuelve 4244762. No he intentado ejecutar el comando en el medio, así que no sé si el comando devuelve otros números antes. llegando al último bloque.

Nunca he usado la paridad, pero parece buena y usa menos espacio en disco que geth, por lo que vale la pena intentarlo.
Quizás algún desarrollador geth pueda aclarar las cosas.

Tengo el mismo problema, estado importado continuo que estoy intentando actualmente como dice @brennino y volveré con el resultado más tarde ... actualmente 350k estados procesados

aquí algo de información:

> eth.syncing{ currentBlock: 4269853, highestBlock: 4270000, knownStates: 357664, pulledStates: 348163, startingBlock: 4268019}

net.peerCount10

eth.blockNumber0
actualización: casi 24 horas después, aquí está el número
blockNumber: 0

eth.syncing
{
currentBlock: 4270728,
hestBlock: 4270793,
knownStates: 6879452,
pullStates: 6875584,
partidaBloque: 4268019
}

el estado importado sigue funcionando, volveré a comprobar mañana ...

hola @ skarn01 No sé si esto me pasa solo a mí, pero cuando comienzo la sincronización rápida con una cadena de bloques vacía, el bloque inicial siempre muestra 0. Puedes ver mi eth.syncing en mi publicación anterior que informo aquí:

eth.syncing
{
currentBlock: 4249131,
más altoBloque: 4250814,
knownStates: 25172364,
pullStates: 25170517,
bloque de inicio: 0
}

Tal vez suceda algo incorrecto durante la sincronización rápida o cierre geth antes de que eth.blockNumber diga un número cerca del último bloque. La sincronización de blockchain consume mucho tiempo y no debe detener la sincronización rápida hasta que finalice o eth.blockNumber! = 0 y cerca de más altoBlock.

¿Qué puedo decir por ayudarlo? Parece que no está iniciando una sincronización rápida desde una cadena de bloques vacía, así que si estoy en usted, comenzaré de nuevo desde el principio.

Si no quieres empezar de nuevo (y te entiendo, me volví loco durante días antes de tener algunos resultados ...) tienes estas oportunidades:

1 - Si solo desea realizar una transacción porque ethereum está bajando de precio ahora y está en pánico, puede usar la sincronización de luz para sincronizar, realizar su transacción y, cuando deje de orar y grite en su habitación por un precio máximo, intente con calma para sincronizar tu blockchain con sincronización rápida nuevamente.
2 - espere dos días más con su situación actual y vea si algo cambia.

Acerca del punto número 1, creo que la sincronización ligera ya no es una característica experimental (pero tal vez alguien más pueda confirmar) ... y logré realizar una transacción con una cadena de bloques de sincronización ligera sin problemas.
Si desea comenzar de nuevo con el punto número 2 más tarde, puede cerrar geth (porque su situación ya está dañada) y cambiar el nombre de su directorio blockchiain .ethereum / geth. Si está bien, en cambio, para borrar su cadena de bloques actual, simplemente use geth eliminadob en el shell del sistema operativo.
Después de eso, para iniciar la sincronización ligera (¡diferente de la sincronización rápida!), Comencé geth con el comando:
geth --light --cache = 1024
y espere solo 2 o 3 horas para descargar una cadena de bloques ligera de 600Mb. Después de eso, puede realizar su transacción. Nuevamente, esta es solo mi experiencia para ayudar a las personas, sin responsabilidades si pierdes tu ethereum.
Espero eso ayude
Marco

hola @brennino , tienes razón, es extraño que mi bloque inicial no sea 0, ya que no he detenido el demonio geth ...

lo que quiero hacer es desarrollar mis propios servicios usando la cadena (obtuve experiencia creando una ICO para mi jefe, ahora tengo algo de interés en esa tecnología ^^) así que no me preocupo por el dinero que pongo aquí actualmente, actualmente no hay ninguno , Ah ah.

Probaré la opción --light después de que se elimine gethb. - ¿La luz todavía me da la posibilidad de trabajar con la cadena y ver el bloqueo completo después de la primera sincronización?

Gracias y volveré con una actualización sobre mi situación.

la sincronización rápida en geth solo funciona cuando la base de datos está vacía, por lo que tiene una oportunidad de sincronización rápida y luego será la sincronización completa después de eso, por lo tanto, sí, si se detiene y reinicia en cualquier momento antes de que finalice la primera sincronización rápida, no lo hará. sincronizar desde ese punto.

Eso no es del todo cierto. La sincronización rápida continuará después del reinicio.

@fjl tiene razón en el modo rápido v1.7.0 continúe desde el último recibo después del reinicio. Empecé a sincronizar con geth 1.7.0 desde cero. Este es el sistema actual:
Hardware: i5 2400, 16 gb, disco duro
(use deliberadamente hdd instread de ssd para verificar los resultados)
Software: Windows x64, geth 1.7.0
Red: FTTH de 512 kbps
Comando: geth --syncmode "fast" cache 1024

Veamos qué pasa.

Editar: geth está completamente sincronizado, pero la velocidad mínima de la red debe ser de 1 Mbps. Durante los primeros 20 días funcionó a 512 kbps, pero no fue suficiente. Entonces aumenté la velocidad de la red a 1 Mbps y en 8 días se sincronizó de 2.1 millones al último bloque. Estoy cerrando este problema porque el problema inicial de las entradas de estado de importación ilimitadas se resuelve en la versión 1.7.0. @nabeelamjad y @fjl son correctos en su enfoque e información.

@sonulrk alguna actualización? Tengo el mismo problema que tú. Estado actual:

eth.syncing
{
currentBlock: 4282458,
HigherBlock: 4282683,
knownStates: 18160211,
pullStates: 18122951,
bloque de inicio: 0
}
Funcionando durante aproximadamente 3 horas ahora

Estoy experimentando un problema muy similar al usar Geth1.7 y Mist 0.9.0 en Win10 Home
Sin embargo, para mí eth.syncing devuelve False y blockNumber devuelve 0

Comencé a ejecutar Geth 1.7 ayer por la tarde después de realizar la eliminaciónb y se completó en algún momento de esta mañana, pero no ejecutó la aplicación (Mist)

Soy un novato, solo estoy contribuyendo (no es una publicación completa ... pero si el problema persiste, publicaré más)

Viendo el mismo problema en Geth 1.7.0

> eth.blockNumber0> eth.syncing{ currentBlock: 4285965, highestBlock: 4286240, knownStates: 512791, pulledStates: 506078, startingBlock: 4273567}

- la luz funciona bien, pero quiero una sincronización rápida. Puedo obtener un bloque completo, así que lo intenté en otra ocasión desde cero y Geth fue asesinado en el bloque 3.8M No sé por qué, voy a actualizar a 1.7.0 y publique lo que suceda con mi próximo intento ...

actualización: el mismo problema, ahora la sincronización dice falso, el número de bloque dice 0, y tengo un estado de 13.5 M procesado y aún así, voy a publicar comentarios más tarde ...

usando geth 1.7.0

update2: acabo de poder hacer una sincronización sin problemas (obtuve un error de falta de memoria, así que cerré todo lo demás mientras se sincronizaba) pero aún no puedo terminar de sincronizar ... ese nunca se detuvo, pero el bloque de inicio no muestra el número de bloque 0 ...

eth.syncing
{
currentBlock: 4312845,
hestBlock: 4313035,
knownStates: 12114361,
pullStates: 12101760,
bloque de inicio: 4312790
}
eth.blockNumber
0

Voy a renunciar a usar el modo ligero por ahora, con la esperanza de que todo lo que necesito esté allí.

para darle retroalimentación.

Actualicé a geth 1.7.0, ajusté mi configuración para que no hubiera errores de memoria (obtuve demasiadas cosas en mi servidor, cerré algunas de ellas) y seguí el procedimiento @brennino .

Después de un tiempo, estaba casi terminado (a unas 100-200 cuadras de distancia) y comenzó a importar solo estados. eth.sync dejó de mostrar s tartblock: 0 y en algún momento se reinició para sincronizar los últimos cien bloques necesarios. Aproximadamente en 28 millones de estados procesados, dejó de importar estados y comenzó a decir "nuevo segmento de cadena". Así que lo dejé ir hasta que finalmente obtuvo el último bloque (la sincronización se detuvo temporalmente y tardó un minuto en ver que era tarde y comenzó nuevamente a sincronizar, cambiando eth.sync de estadísticas a falso a estadísticas ...) . En el último bloque, después de que eth.sync decía falso, y el número de bloque seguía subiendo y mostraba el mismo número de bloque que etherscan, detuve geth y lo reinicié.

Ahora todo parece estar bien. Tomó alrededor de 2-3 días para hacer una sincronización rápida. Aproximadamente medio día a 1 día para la primera sincronización, 1 día para importar el estado y una hora para finalizar la sincronización.

Ahora espero que mi computadora no funcione durante los próximos meses, no quiero comenzar a sincronizar nuevamente, ahahah.

Buena suerte a todos los demás

¡Quizás puedas probar el modo de luz la próxima vez que necesites iniciarlo desde cero!

https://github.com/ethereum/mist/issues/3097 🎉 y discusión aquí: https://github.com/ethereum/go-ethereum/issues/15001

Estuve ausente por un tiempo y decidí hacer una sincronización rápida para ahorrar algo de espacio en disco comenzando de nuevo, pero encontré prácticamente el mismo problema que se describe en este hilo, esto es lo que hice para resolverlo (usando Geth 1.7.0) :

Asegúrese de tener un directorio de datos vacío; de lo contrario, ejecute su comando geth habitual seguido de removedb al final una vez para eliminar su base de datos.

1. Ejecute geth --cache 2048 --datadir "D:/my/data/dir" (elimine el argumento -datadir si desea el directorio predeterminado, el uso del comando rápido no fue necesario en 1.7 ya que lo asume automáticamente)
2. Cuando blockchain se acerca a los highestBlock (a unas 100-150 cuadras de distancia), comenzará a importar muchas entradas estatales. Deje que se completen, a partir de hoy serán alrededor de 31 millones de entradas estatales (van muy rápido).
3. Una vez que se completen todas las entradas de estado, comenzará a eliminar automáticamente los pares obsoletos, cuando esto suceda, cerrará por completo.
4. Repen geth usando geth --syncmode "full" --cache 2048 --datadir "D:/my/data/dir" ( syncmode probablemente sea irrelevante)
5. Déjelo funcionar por un tiempo, volverá a indexar la cadena y eventualmente deshabilitará automáticamente el modo rápido y cambiará al modo completo. Me tomó unos 10 minutos durante esta etapa.

Usando la configuración anterior, un SSD y una velocidad de descarga de Internet de 220 Mbps, me tomó aproximadamente 1.5 horas sincronizar la cadena de bloques del 0% al 99%, luego las entradas de estado tomaron unas buenas 3-4 horas antes de que finalmente terminara. Creo que el punto clave es dejar que las entradas estatales se ejecuten hasta su finalización, no cortarlas antes. Hay más de 30 millones de entradas estatales, por lo que tomará un tiempo. Tamaño total de la cadena de bloques: ~ 26 GB desde 0 hasta el bloque 4351952 siguiendo los pasos anteriores.

Me doy cuenta de que hay un modo de luz disponible, pero no me sirve. Lo probé y es muy lento al enviar transacciones (no se recoge por un tiempo o no se recoge en absoluto cuando se repiten las llamadas de 10-20 sendTransaction a la vez usando web3 , mientras que el cliente rápido / completo los recoge instantáneamente y puedo verlos en Etherscan).

Espero que esto ayude.

suspiro, todo lo que se requiere es solo una explicación simple de lo que está haciendo 'rápido' (por parte del equipo), también me sorprendió lo que sucedió (y todos esos valores extraños al importar estados, como ignorados, duplicar cuáles son)

Parece que lo que realmente hace la sincronización rápida es:

1. descargar encabezados de bloque hasta casi lo más cerca posible (4,7 millones a partir del 15 de diciembre de 2017)
2. descargar todos los estados (pero sin verificación) hasta la última versión (o puede estar cerca)
3. dado que cada bloque puede contener múltiples transacciones (?), el número de estado que es efectivamente un registro de transacciones de la base de datos puede ser mucho más grande, creo que 48M a partir del 15 de diciembre de 2017
4. el 'procesado =' se refiere al registro estatal durante la etapa del estado de importación. Así que tengo que esperar hasta que alcance los 48M (en mi caso) y puede ser un indicador para adivinar cuándo se hará.

¿Esta suposición / interpretación es correcta?

Tampoco puedo hacer que funcione. Entré al directorio geth y eliminé manualmente la carpeta de la cadena de tiendas usando el explorador de Windows. Luego ejecuté el comando: "% APPDATA% Ethereum WalletbinariesGethunpackedgeth.exe" geth --syncmode light

Y todo lo que veo actualmente en CMD es simplemente "nuevos encabezados de bloque importados" y "nuevas entradas de bloque importadas". ¿Funciona esto correctamente?

para el modo ligero, debería ver el número en aproximadamente 4.8M (a partir de hoy) y básicamente está hecho

intente 'geth adjuntar' y luego 'eth.syncing' para verificar el estado

se actualizará si se sincroniza

{
currentBlock: 4815023,
HigherBlock: 4815321,
knownStates: 36384431,
pullStates: 36381874,
bloque de inicio: 4810860

Acabo de crear un nuevo nodo en 'rápido' a partir de ayer y ya casi está terminado. de nuevo solo un punto de referencia para quienes lo necesiten:

Al 28 de diciembre de 2017:
El último bloque fue de 4,8 millones, el estado de la transacción fue de unos 58 millones.
Me tomó aproximadamente 26 horas sincronizarlo y está en la etapa final (ya se cambió al equivalente de nodo completo, ya que ese es el diseño de sincronización rápida), quedan unos 300 bloques
el uso promedio del disco es de aproximadamente 10-20 MBps durante la etapa de estado de importación y aproximadamente 1-2 Mbps en términos de ancho de banda de la red
Tengo que eliminarlo una vez, ya que se detuvo durante aproximadamente una hora durante la etapa de estado de importación temprana, pero sabe dónde retomarlo nuevamente (por lo que sigue siendo una especie de sincronización rápida incluso después del reinicio). Creo que esta es una mejora en 1.73
el espacio total en disco utilizado es 49GB

Espero que esto ayude a otros en el futuro.

editar:
y ahora está completamente sincronizado, por lo que ahora es un nodo que puedo usar para enviar transacciones, etc. unos 5 minutos más cuando creé este comentario por primera vez

Dejé geth 1.73 funcionando durante unas 15 horas
geth --rpc --syncmode "fast" --cache 3096 --maxpeers 50
Estaba a unas 500 cuadras del bloque más alto y el estado conocido era ~ 49M
geth se detuvo durante unos 20 minutos, así que reinicié. knownStates se restablece a 0 y ahora va extremadamente lento. Pero el uso del disco es el mismo que antes de reiniciar.

Windows 10
SSD
16 GB de RAM
Conexión de 100 Mbit

geth 1.8
todavía tengo este problema.
después de reiniciar, geth muestra este error

WARN [01-05|02:54:25] Ancestor below allowance peer=2586937320363579 number=4015416 hash=abc963…9b3dc5 allowance=4765509WARN [01-05|02:54:25] Synchronisation failed, dropping peer peer=2586937320363579 err="retrieved ancestor is invalid"

ahora la sincronización rápida elimina a los compañeros y no se sincroniza. ~ 100 bloques para terminar, pero nunca se sincroniza.

Así que estoy en aproximadamente 8 horas sincronizando en 57 Mbps con 16GB DDR4 / SSD / 1080Ti / 8700K y geth --fast --cache = 4024. Mi eth.syncing dice:

 currentBlock: 4900069, highestBlock: 4900328, knownStates: 51148480, pulledStates: 51137757, startingBlock: 0

currentBlock no se ha movido durante horas. 14 pares, eth.blockNumber 0, simplemente recorriendo los nuevos estados entrantes:

INFO [01-13|10:00:32] Imported new state entries count=803 elapsed=3.654ms processed=51095193 pending=8217 retry=0 duplicate=4005 unexpected=12212INFO [01-13|10:00:33] Imported new state entries count=834 elapsed=1.759ms processed=51096027 pending=13439 retry=0 duplicate=4005 unexpected=12212

¿Esto es normal? ¿Dónde puedo encontrar un desglose de esos valores y su comportamiento? ¿De qué sirve 'pendiente' si cambia constantemente ...?

Agradezco tu tiempo, muchas gracias.

¿Recomiendas explorar Parity? Lo veo recomendado sobre Geth, pero solo he sido expuesto personalmente a través de noticias negativas de piratas informáticos y soy cauteloso.

Desconecté mi sincronización, yendo a mirar a Parity. No se puede justificar el espacio y el esfuerzo para mantener un nodo completo real si así es como se ve. La máquina tendría que estar funcionando constantemente, ¿verdad? ¿Se sincroniza constantemente y, en algún momento, probablemente ni siquiera pueda seguir el ritmo? ¿Existen métricas conocidas para que la red crezca más rápido de lo que las velocidades D / L pueden sincronizar?

Pensé que tendría un HD con el que arrancaría y me pondría al día cada vez que quisiera trabajar con ETH, pero no parece que ese sea el caso con un nodo completo real sin poda o deformación o alguna optimización similar.

Gracias nuevamente por su tiempo, apreciamos su información.

No me siento seguro usando MEW, mi Ledger tiene más de lo que me siento cómodo teniendo en un solo lugar y están pendientes para nuevas unidades, así que pensé que tener un cliente oficial sería la mejor opción ... ya que Mist no parece satisfacer mis necesidades, Parity está bastante cerca de ser oficial, así que supongo que me dirijo allí.

¿Mi lógica suena?

Hola tios,

Usé esto para verificar mi bloque actual que necesita sincronizarse

currentBlock: 4506167,
hestBlock: 4934648,
knownStates: 866589,
pullStates: 848856,
bloque de inicio: 4426024
}

Yo uso esto para el mio
geth --datadir ./.ethereum/devnet/ --dev --mine --minerthreads 4 etherbase 0

Utilizo esto para conectar el cliente en ejecución al minero

eth --datadir ./.ethereum/devnet --dev adjuntar ipc: ./. ethereum / devnet / geth.ipc
¡Bienvenido a la consola de JavaScript de Geth!

instancia: Geth / v1.7.2-stable-1db4ecdc / linux-amd64 / go1.9
base de monedas: 0x2 ........................
en el bloque: 330038 (viernes 19 de enero de 2018 13:40:44 CET)
datadir: /home/smartcontract/.ethereum/devnet
módulos: admin: 1.0 depuración: 1.0 eth: 1.0 minero: 1.0 net: 1.0 personal: 1.0 rpc: 1.0 shh: 1.0 txpool: 1.0 web3: 1.0

web3.eth.syncing
falso
web3.fromWei (eth.getBalance (eth.coinbase), "ether")
1445287.5
web3.eth.blockNumber
330039

Cuando quiero enviar una transacción, tengo el siguiente código en esa consola
th.sendTransaction ({ from: eth.coinbase , to: eth.accounts [1], value: web3.toWei (0.05, "ether")}) Desbloquee la cuenta d1ade25ccd3d550a7eb532ac759cac7be09c2719. Frase de contraseña: la cuenta ahora está desbloqueada para esta sesión. '0xeeb66b211e7d9be55232ed70c2ebb1bcc5d5fd9ed01d876fac5cff45b5bf8bf4'.

Al final, no veo la transmisión en Etherscan ni en la billetera a la que estoy enviando. También el equilibrio sigue siendo el mismo.
CÓMO PUEDE ESTAR SUCEDIENDO ESTO OMG :)

background: Tenía una cadena de datos no sincronizada, algunos hicieron un removeb en geth y luego volvieron a importar todos los bloques, ya que la base de datos estaba dañada con un mensaje como "Mensajes de pares fallidos". Realmente ethereum todavía necesita mejorar.

Estoy sincronizando porque cuando intenté implementar con trufa, obtuve el estado de la red desconocido. Al leer, descubrí que necesitaba que eth.blockNumber fuera un número entero positivo. Actualmente es 0 y mi estado se está sincronizando.

> eth.syncing{ currentBlock: 5186010, highestBlock: 5186166, knownStates: 32389802, pulledStates: 32378516, startingBlock: 5185518

¿Cuándo puedo esperar que termine esto? ¿Cuáles son estos estados?

En este punto (9 de marzo de 2018), se necesitan casi 8 días para sincronizar la cadena de bloques Ethereum con una configuración como esta:

Procesador i7, 8 núcleos, 64 GB de RAM, conexión a Internet de 100 Mbps, unidad SSD, idealmente con RAID

La forma más rápida de sincronizar es comenzar a limpiar eliminando su base de datos existente:
geth removedb
y luego hacer una sincronización rápida con un tamaño de caché grande (es decir, 8 GB si tiene suficiente RAM, como 64 GB de RAM):
geth --syncmode "fast" --cache 8192 console

Hay 3 etapas distintas en el proceso de sincronización:

1. Importación de bloques (consulte Etherchain.org , 5,269,000+, más de 10 horas)
   Después de acercarse al bloque actual, geth cambia automáticamente al modo completo y continúa. Por lo tanto, no es necesario detenerse y reiniciar.
2. Importación de entradas de estado (más de 96 millones, más de 1 día)
3. Importación de segmentos de cadena (el mismo número que los bloques, más de 6 días), por ejemplo:
   INFO [03-10|14:07:44] Imported new chain segment blocks=139 txs=776 mgas=430.595 elapsed=8.039s mgasps=53.560 number=1854160 hash=9d134e…e0adc0 cache=15.85mB

Su carpeta de datos en cadena tendrá más de 220 GB después de que se haya sincronizado por completo.

Puede saber que está completamente sincronizado al obtener mensajes de segmento de cadena de solo 1 bloque, que es idéntico al número de bloque actual:
INFO [03-16|21:23:04] Imported new chain segment blocks=1 txs=341 mgas=7.990 elapsed=435.942ms mgasps=18.329 number=5269405 hash=939ae8…96e825 cache=143.76mB

¡Buena suerte!

Consulte este número para obtener una descripción detallada de lo que sucede bajo el capó: https://github.com/ethereum/go-ethereum/issues/15001#issuecomment -370732526

@quantumproducer :

Vea el comentario de @tinschel arriba y también vea https://github.com/ethereum/go-ethereum/issues/16147#issuecomment -371878483

@tinschel dijiste:

Puede saber que está completamente sincronizado al recibir mensajes de segmento de cadena de solo 1 bloque, que es idéntico al número de bloque actual

¿No sería estupendo si eth.syncing devolviera false solo cuando se alcanza este punto? ¿Y devolver algún tipo de números comprensibles para los humanos detallando el progreso que está haciendo, hasta que llegue allí?

Veo tantas preguntas sobre este punto, los usuarios están totalmente confundidos por el comportamiento de eth.syncing .

Sincronicé y tomé algunas medidas: http://www.freekpaans.nl/2018/04/anatomy-geth-fast-sync/

@tinschel No tome mucho tiempo con "Importar segmentos de cadena". De hecho, solo parece estar haciendo eso para bloques "nuevos". ¿Alguna idea?

Ese es un análisis increíble @FreekPaans ... Reflexioné en diciembre de 2017 sobre si tiene que ver con un método en particular llamado requestTTL ... https://github.com/ethereum/mist/issues/2749 #issuecomment -354282608

Básicamente, puede quedarse estancado esperando que uno de los compañeros le brinde la información que necesita.

Además, algunas partes de la red pueden carecer de bloques o del estado de prueba que está buscando. Efectivamente, si no está conectado a suficientes pares con los datos más recientes, entonces estará esperando en la "red" para responder con la información que necesita para continuar con la validación de la cadena.

Hubo un buen análisis que encontré aquí:

• https://github.com/ethereum/go-ethereum/issues/15824
• https://gist.github.com/holiman/5ec5d518c0ebe602872e37bd5775f0ef

Espero que esto ayude ... Aún no he descubierto la razón exacta por la que se estanca.

@FreekPaans : Me sorprende que su primer mensaje de registro de un solo bloque "Nuevo segmento de cadena importado" haya eth.synching mostrara realmente false .

Tal vez su mayor velocidad tuvo que ver con el mayor número de compañeros (25) que estaba viendo. No desbloqueé el puerto 30303 y, aunque también usé --maxpeers 25 (que es el predeterminado), solo vi 8 pares como máximo.

@tinschel sí, con 30303 cerrado, también se pegó a unos 8 compañeros conmigo. No estoy familiarizado con el protocolo P2P, así que no sé por qué.

El primer Imported new chain segment llegó cuando el proceso estatal terminó de importar, y solo tenía 4 entradas count > 1 .

Ahora también completé una sincronización completa geth: http://www.freekpaans.nl/2018/04/anatomy-of-a-geth-full-sync/. tl; dr: tomó un poco más de 9 días, frente a menos de 8 horas para una sincronización rápida.

si solo realiza una sincronización rápida, los demás no podrán usarlo como nodo para la sincronización de blockchain; Entonces, si todos usaran la sincronización rápida, la cadena de bloques no podría existir.

No, eso es incorrecto. Un nodo sincronizado rápidamente ayuda, tiene muchos estados que otros pueden descargar. Quizás estabas pensando en un otoh de les-client.

@ garyng2000 , sin efecto en la fecha de inicio. Es posible que diferentes meses tengan más transacciones y estado y, por lo tanto, el tamaño de la cadena de bloques crezca más rápidamente durante esos meses. No hay diferencia entre el tamaño de la cadena de bloques en el modo de sincronización rápida y el modo completo porque una vez que se completa la sincronización rápida, cambia automáticamente al modo completo. En otras palabras, la sincronización rápida puede llevarlo al final de los bloques muy rápidamente, pero no tendrá la cadena de bloques completa con todos los estados hasta que complete la sincronización completa.

Así que la sincronización rápida es buena si todo lo que quiere hacer es mantener una billetera o comenzar a minar. La sincronización completa es necesaria para que pueda convertirse en un nodo completo dentro de la cadena de bloques Ethereum.

Estoy experimentando el mismo problema cuando uso geth --fast --cache 1048.

Nuevas entradas de estado importadas

 eth.syncing{ currentBlock: 5535921, highestBlock: 5536021, knownStates: 274, pulledStates: 273, startingBlock: 5535921}

Solo da algo de información:

Comencé la sincronización desde el 18 de mayo. Acabo de terminar hace unos minutos.

Número de bloque: 5740903
pullStates: 191247645

@ Othman21 Otro

Sí, cuando termina, eth.syncing devuelve false .

El número se da arriba. KnownStates es bastante similar a pullStates.

aquí hay una salida mía tomada el 16 de junio de 2018 a las 6:18 am PTD:

>eth.syncing{ currentBlock: 5799102, highestBlock: 5799188, knownStates: 96279752, pulledStates: 96279752, startingBlock: 5799001}

Solo para aclarar ... fastsync ahora es predeterminado ... ¿y puedo salir y reiniciar geth con rápido habilitado?

De todos modos estoy actualmente en:

> eth.syncing{ currentBlock: 5827681, highestBlock: 5827747, knownStates: 96988858, pulledStates: 96988508, startingBlock: 5824114}

> eth.blockNumber0

@tinschel @ Othman21 ¿Cómo es esto posible? ¿100% más de entradas estatales en 3 días?

@codepushr sí puedes, ejecuto este comando:
./geth --caché = 25000 --rpc --maxpeers 25 - rápido

Aún no he terminado de sincronizar, hoy serán 29 días

eth.syncing

{
currentBlock: 5829510,
HigherBlock: 5829582,
knownStates: 203714648,
pullStates: 203714648,
bloque de inicio: 5829510
}

eth.blockNumber
0

Aquí están los detalles de la implementación del pivote: https://github.com/ethereum/go-ethereum/pull/14460 y https://github.com/ethereum/go-ethereum/commit/0042f13d47700987e93e413be549b312e81854ac

@codepushr @tinschel ¿ alguna novedad?

eth.blockNumber
0
eth.syncing
{
currentBlock: 5852375,
hestBlock: 5852457,
knownStates: 213724149,
pullStates: 213706822,
Bloque de inicio: 5852248
}

¿Hay alguien que haya terminado de sincronizar para decirnos los conocimientos actuales que tiene?

eth.syncing
{
currentBlock: 5865970,
más altoBloque: 5866080,
knownStates: 218653449,
pullStates: 218633252,
Bloque de inicio: 5865761
}
eth.blockNumber
0

@FreekPaans ¿
Aún no he terminado de sincronizar, hoy serán 37 días.

eth.syncing{ currentBlock: 5876059, highestBlock: 5876129, knownStates: 223140030, pulledStates: 223136789, startingBlock: 5875977}eth.blockNumber0

Filesystem 1K-blocks Used Available Use% Mounted on/dev/simfs 524288000 126645968 397642032 25% /

@codepushr ejecutarlo en segundo plano
sudo nano /etc/systemd/system/eth.service

[Unit]Description=eth for PoolAfter=network-online.target[Service]ExecStart=/home/eth-geth/build/bin/geth --cache=25000 --rpc --maxpeers 25 --fastRestart=alwaysRestartSec=3User=root[Install]WantedBy=multi-user.target

sudo systemctl enable eth
sudo systemctl start eth
sudo systemctl status eth

@ othman21 sí, ¿viste mis
http://www.freekpaans.nl/2018/04/anatomy-geth-fast-sync/
http://www.freekpaans.nl/2018/04/anatomy-of-a-geth-full-sync/

Esta vez sincronicé desde un nodo que estaba obsoleto durante 1 mes, tardé 10 días.
El viernes 29 de junio de 2018 a las 19:50, Othman21 [emailprotected] escribió:

@FreekPaans https://github.com/FreekPaans ¿ Terminaste la sincronización?
Aún no he terminado de sincronizar, hoy serán 37 días.

eth.syncing
{
currentBlock: 5876059,
hestBlock: 5876129,
knownStates: 223140030,
pullStates: 223136789,
bloque de inicio: 5875977
}
eth.blockNumber
0

@codepushr https://github.com/codepushr ejecutarlo en segundo plano
sudo nano /etc/systemd/system/eth.service
`[Unidad]
Descripción = eth para Pool
Después = network-online.target

[Servicio]
ExecStart = / inicio / eth-geth / build / bin / geth --cache = 15000 --rpc --maxpeers 25
--rápido
Reiniciar = siempre
RestartSec = 3
Usuario = root

[Instalar en pc]
WantedBy = multi-user.targetsudo systemctl enable ethsudo systemctl start
ethsudo systemctl status eth`

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ethereum/go-ethereum/issues/14647#issuecomment-401426522 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADfb6UOvIyow9xag4aVQ-H8j44j_S0x1ks5uBmjrgaJpZM4N9Zz8
.

Tengo 2 servidores para sincronizar. A durante una semana, B durante 2 semanas. Aquí están sus estados:
Máquina A:

> eth.syncing{ currentBlock: 6358077, highestBlock: 6358143, knownStates: 167673098, pulledStates: 167673097, startingBlock: 6357998}> eth.blockNumber0> net.peerCount21

Máquina B:

> eth.syncing{ currentBlock: 6358040, highestBlock: 6358157, knownStates: 208173888, pulledStates: 208173888, startingBlock: 6358040}> eth.blockNumber0> net.peerCount2

Lo logré antes, el registro de "entradas de estado" termina en 150 millones, recuerdo.
Ahora declare las entradas de más de 160 millones y 200 millones. Me pregunto cuando terminará ...

Cuál es el límite superior actual de --testnet en el modo de sincronización fast , ha pasado casi una semana, 8 horas por día:

 { currentBlock: 4479565, hestBlock: 4479638, knownStates: 54592672, pullStates: 54572219, Bloque de inicio: 4474887 }

Recientemente completé una sincronización rápida, comenzando desde cero. Mi nodo procesó 254,811,206 entradas de estado antes de terminar. Aquí estaba la última línea Imported new state entries :

INFO [12-07 | 09: 41: 58.173] Recuento de nuevas entradas de estado importadas = 325 transcurridas = 9.931ms procesados ​​= 254811206 pendientes = 0 reintento = 0 duplicados = 14306 inesperados = 44810

Y aquí hay algo de contexto en torno a esa línea de registro:

INFO [12-07|09:41:52.982] Imported new state entries count=499 elapsed=7.055ms processed=254810260 pending=771 retry=0 duplicate=14306 unexpected=44810INFO [12-07|09:41:57.012] Imported new state entries count=621 elapsed=4.587ms processed=254810881 pending=796 retry=0 duplicate=14306 unexpected=44810INFO [12-07|09:41:58.173] Imported new state entries count=325 elapsed=9.931ms processed=254811206 pending=0 retry=0 duplicate=14306 unexpected=44810INFO [12-07|09:41:58.177] Imported new block receipts count=1 elapsed=3.971ms number=6841800 hash=c4db3b…040b25 age=27m9s size=116.08kBINFO [12-07|09:41:58.178] Committed new head block number=6841800 hash=c4db3b…040b25INFO [12-07|09:42:07.044] Imported new chain segment blocks=10 txs=927 mgas=65.008 elapsed=8.864s mgasps=7.334 number=6841810 hash=2698fa…cebe66 age=25m46s cache=7.55mBINFO [12-07|09:42:15.582] Imported new chain segment blocks=12 txs=1384 mgas=88.370 elapsed=8.537s mgasps=10.351 number=6841822 hash=a9064c…432e78 age=23m32s cache=17.34mBINFO [12-07|09:42:24.527] Imported new chain segment blocks=12 txs=1440 mgas=74.632 elapsed=8.944s mgasps=8.344 number=6841834 hash=c80849…f12f03 age=20m21s cache=27.75mBINFO [12-07|09:42:32.561] Imported new chain segment blocks=14 txs=1246 mgas=83.007 elapsed=8.034s mgasps=10.331 number=6841848 hash=2cbbfe…d173c0 age=18m19s cache=37.18mBINFO [12-07|09:42:41.012] Imported new chain segment blocks=14 txs=1655 mgas=80.438 elapsed=8.451s mgasps=9.518 number=6841862 hash=5d3bc2…bd7289 age=14m19s cache=47.72mBINFO [12-07|09:42:49.356] Imported new chain segment blocks=10 txs=1557 mgas=63.153 elapsed=8.344s mgasps=7.569 number=6841872 hash=1c11a8…ba7cac age=11m44s cache=56.52mBINFO [12-07|09:42:57.637] Imported new chain segment blocks=15 txs=1616 mgas=85.097 elapsed=8.280s mgasps=10.276 number=6841887 hash=1ac03b…622d3e age=7m53s cache=67.46mBINFO [12-07|09:43:06.485] Imported new chain segment blocks=13 txs=1657 mgas=79.934 elapsed=8.847s mgasps=9.034 number=6841900 hash=2300d2…e3076a age=4m38s cache=77.99mBINFO [12-07|09:43:10.533] Imported new chain segment blocks=8 txs=793 mgas=32.020 elapsed=4.048s mgasps=7.909 number=6841908 hash=8dd97c…cb2afe age=3m9s cache=82.81mBINFO [12-07|09:43:10.535] Imported new block headers count=1 elapsed=1m2.045s number=6841909 hash=8bb9a3…27c074 age=3m4sINFO [12-07|09:43:10.544] Imported new block headers count=1 elapsed=8.759ms number=6841910 hash=d3f22b…1d80b0 age=2m24sINFO [12-07|09:43:10.554] Imported new block headers count=2 elapsed=10.131ms number=6841912 hash=67b75c…918ac2 age=1m10sWARN [12-07|09:43:10.610] Discarded bad propagated block number=6841904 hash=b7deda…28b3dcINFO [12-07|09:43:10.683] Imported new block headers count=1 elapsed=7.534ms number=6841913 hash=58f0f9…a9a201INFO [12-07|09:43:11.590] Imported new chain segment blocks=1 txs=165 mgas=7.985 elapsed=808.053ms mgasps=9.882 number=6841909 hash=8bb9a3…27c074 age=3m5s cache=83.99mBINFO [12-07|09:43:14.869] Imported new chain segment blocks=4 txs=755 mgas=29.935 elapsed=3.278s mgasps=9.131 number=6841913 hash=58f0f9…a9a201 cache=88.67mBINFO [12-07|09:43:14.869] Fast sync complete, auto disablingINFO [12-07|09:43:36.504] Imported new chain segment blocks=1 txs=48 mgas=1.493 elapsed=198.174ms mgasps=7.535 number=6841914 hash=1be461…c61103 cache=88.98mBINFO [12-07|09:44:16.096] Imported new chain segment blocks=1 txs=192 mgas=7.996 elapsed=558.982ms mgasps=14.304 number=6841915 hash=e9f46b…989562 cache=90.27mB

@jeremyschlatter ¿Qué tipo de sistema tienes y cuánto tiempo te llevó sincronizar?

¿Y debería reabrirse este tema? Parece que la gente todavía se está "atascando" durante una sincronización rápida esperando estados y confundida debido a la falta de una barra de progreso. Entiendo que construir una barra de progreso para esto de una manera descentralizada y segura no es simple (o tal vez incluso posible), pero luego necesitamos una mejor mensajería.

Hice uno recientemente, aproximadamente la misma cantidad de estados, tomé 5 días en un 4 core / 8
gb + SSD

El sábado 8 de diciembre de 2018 a las 19:37, Bryan Stitt [emailprotected] escribió:

@jeremyschlatter https://github.com/jeremyschlatter qué tipo de sistema
¿tienes y cuánto tiempo te llevó sincronizar?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ethereum/go-ethereum/issues/14647#issuecomment-445480304 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADfb6YAroP8d1bjPjCEwNuHxfC0w1bODks5u3AbPgaJpZM4N9Zz8
.

@kaythxbye, ¿finalmente has sincronizado?

{
currentBlock: 6897129,
hestBlock: 6897235,
knownStates: 266058499,
pullStates: 266043876,
bloque de inicio: 6897063
}

Este nodo se sincroniza desde hace más de 2 semanas. Recientemente actualizado a v1.8.20-stable-24d727b6

Me tomó alrededor de 3 días y 4 horas sincronizar un nodo rápido ETH Geth:

Configuraciones: --syncmode fast --gcmode full --cache 4096
Inicio: 2018-12-15 10:00 UTC
Fin: 2018-12-18 14:08 UTC
Entradas estatales: 260172278
Uso de disco: 149G
Hardware: Virtual machine, 4 cores, 8 GB memory, 300 GB SSD

A partir de hoy. Tomó alrededor de una semana para finalmente sincronizarse.

• Uso de disco: aproximadamente 40G.
• K nowStates: 92 millones más o menos.
• Hardware: máquina de servicio en la nube

Acabo de terminar de sincronizar la red principal en el bloque 7089163. Tiempo total de aproximadamente 36 horas en un quad core con 32 GB de RAM, conexión rápida, SSD de 256 GB. Uso de disco ~ 154GB.

Últimas "Entradas de estado nuevas importadas": 268473324

INFO [01-18|21:27:10.217] Imported new state entries count=1081 elapsed=12.427ms processed=268473324 pending=0 retry=0 duplicate=24770 unexpected=101202

6 de febrero de 2019

sincronización realizada 5 días

2 vCPU
8 GB de RAM
Unidad SSD

uso del disco: 160G
bloque más alto: 7178900
knownStates: 276777218

HARDWARE:
HP ProBook470 G2 / windows7
Núcleo i5-5200 a 2,2 Ghz
8GB
Samsung T5 USB 3.0 SSD 250G

Geth corriendo en VirtuaMachine:
servidor ubuntu en el reproductor Vmware
3 procesadores 3 GB de memoria del sistema
Opción de caché geth de 2GB
opción de sincronización rápida predeterminada

se tarda aproximadamente 1 semana

bloque 7191540
knownStates son aproximadamente 283500000
uso del disco: 167G

Acabo de terminar ahora, tomó alrededor de 4 días en una computadora portátil con

• Intel Core i5-8250U
• Samsung MZ-V7E500BW 970 EVO.

Uso del disco: 162G

processed=284332222 pending=0 retry=0 duplicate=11504 unexpected=67689

Mis estadísticas:

2019-05-06 01:00:32 avg: 1827 max: 1938 min: 1378 states/s remain: 136604075 states 4 peers eta@ 20:46:28.1658282019-05-06 01:00:37 avg: 1864 max: 1938 min: 1378 states/s remain: 136595500 states 3 peers eta@ 20:21:14.9510502019-05-06 01:00:42 avg: 1791 max: 1938 min: 1378 states/s remain: 136583359 states 3 peers eta@ 21:11:16.4810062019-05-06 01:00:48 avg: 1742 max: 1938 min: 1378 states/s remain: 136580287 states 3 peers eta@ 21:46:35.7973052019-05-06 01:00:53 avg: 1721 max: 1938 min: 1378 states/s remain: 136575694 states 3 peers eta@ 22:03:01.1544342019-05-06 01:00:58 avg: 1682 max: 1938 min: 1378 states/s remain: 136569043 states 4 peers eta@ 22:33:15.4024422019-05-06 01:01:03 avg: 1698 max: 1938 min: 1378 states/s remain: 136564293 states 3 peers eta@ 22:20:27.458747

PD. Escribí un pequeño script de Python para revisar el proceso. Está aquí https://github.com/hayorov/ethereum-sync-mertics

322,14 millones de estados el 9 de mayo
INFO [05-09 | 12: 10: 17.599] UTC - Nuevas entradas de estado procesadas = 322150741

~ 1 día para blockchain. ~ 5 días para estados: 206 GB en disco

Acabo de completar otro, tomó un poco menos de 48 horas.

Geth 1.8.27
AWS t2.xlarge (4 núcleos, 16 GB)
Estados 333564669 @ block 7963639

Lo interesante es que, en algún momento, la "tasa" de los estados se vuelve realmente baja:

Sospecho que esto se debe a que ciertas partes del estado no están disponibles en mis pares. Podría ser que reiniciar (o alguna otra forma de conseguir nuevos compañeros) ayudaría en esos casos.

Ahora hay más de 362,778,222 estados.

INFO [07-23|18:30:58.161] Imported new block headers count=1 elapsed=4.196ms number=8208527 hash=6891ea…0a52cb age=1m2sINFO [07-23|18:31:22.870] Imported new state entries count=484 elapsed=4.748ms processed=362778222 pending=2760 retry=0 duplicate=1583 unexpected=9221

Sería realmente bueno si hubiera alguna forma de saber cuánto más tardará esto.

Se inició el nodo de nuevo el 11 de julio. Los bloques se sincronizaron rápidamente, pero los estados van lentos. El servidor está ocupado haciendo otras cosas, pero esto es más largo de lo que esperaba. Todavía se está sincronizando ahora.

También comencé el 12 de julio, pero es demasiado lento. Solo entradas sincronizadas 269325649.
¿Me pueden ayudar con la configuración que está utilizando?

Se inició el nodo de nuevo el 11 de julio. Los bloques se sincronizaron rápidamente, pero los estados van lentos. El servidor está ocupado haciendo otras cosas, pero esto es más largo de lo que esperaba. Todavía se está sincronizando ahora.

También comencé el 12 de julio, pero es demasiado lento. Solo entradas sincronizadas 269325649.
¿Me pueden ayudar con la configuración que está utilizando?

Suena como si estuvieras en un disco duro en lugar de en un SSD

Se inició el nodo de nuevo el 11 de julio. Los bloques se sincronizaron rápidamente, pero los estados van lentos. El servidor está ocupado haciendo otras cosas, pero esto es más largo de lo que esperaba. Todavía se está sincronizando ahora.

También comencé el 12 de julio, pero es demasiado lento. Solo entradas sincronizadas 269325649.
¿Me pueden ayudar con la configuración que está utilizando?

Suena como si estuvieras en un disco duro en lugar de en un SSD

si. Empecé con HDD

Se inició el nodo de nuevo el 11 de julio. Los bloques se sincronizaron rápidamente, pero los estados van lentos. El servidor está ocupado haciendo otras cosas, pero esto es más largo de lo que esperaba. Todavía se está sincronizando ahora.

También comencé el 12 de julio, pero es demasiado lento. Solo entradas sincronizadas 269325649.
¿Me pueden ayudar con la configuración que está utilizando?

Suena como si estuvieras en un disco duro en lugar de en un SSD

si. Empecé con HDD

No se puede sincronizar en un disco duro, es demasiado lento

Para aquellos que buscan solo el número:
13 de agosto de 2019: 400.695.865 estados

Largo camino por recorrer.

4 días 15 horas para mí. Ejecución de Ryzen 1700X con SSD y módem por cable

24794 pts / 2 Sl + 896: 58 build / bin / geth -rpc
[ ron @ Bertha bin] $ ps -p 24794 -o etime
TRANSCURRIDO
4-15: 50: 16

Necesita uno de los servicios de cadena de bloques eth para enumerar las entradas de estado junto con los datos del tamaño de la cadena de bloques, etc., hasta entonces:

2019-11-25: 405,923,438

Acabo de finalizar la sincronización rápida después de 5 días y 12 horas. Este hilo aquí me ayudó a saber qué esperar, así que aquí están mis estadísticas.

2019-12-04
Hardware: Raspberry Pi 4 Modelo B / 4GB, SSD conectado vis USB3, Internet de banda ancha.
Versión Geth: 1.9.8
Tamaño de Datadir: 186 GB
Bloque más alto: 9.048.250
Número de entradas estatales importadas: 441,013,364

17 de enero de 2020
Estados conocidos: 432,391,041
No estoy seguro de por qué es más pequeño que el anterior.

INFO [01-17|18:39:47.580] Imported new state entries count=433 elapsed=2.721ms processed=432391041 pending=0 retry=0 duplicate=71137 unexpected=326170INFO [01-17|18:39:47.590] Imported new block receipts count=1 elapsed=7.889ms number=9300316 hash=7e5fbf…197524 age=24m54s size=54.71KiBINFO [01-17|18:39:47.593] Committed new head block number=9300316 hash=7e5fbf…197524INFO [01-17|18:39:47.624] Deallocated fast sync bloom items=431854683 errorrate=0.001

17 de enero de 2019
Estados conocidos: 432,391,041
No estoy seguro de por qué es más pequeño que el anterior.

INFO [01-17|18:39:47.580] Imported new state entries count=433 elapsed=2.721ms processed=432391041 pending=0 retry=0 duplicate=71137 unexpected=326170INFO [01-17|18:39:47.590] Imported new block receipts count=1 elapsed=7.889ms number=9300316 hash=7e5fbf…197524 age=24m54s size=54.71KiBINFO [01-17|18:39:47.593] Committed new head block number=9300316 hash=7e5fbf…197524INFO [01-17|18:39:47.624] Deallocated fast sync bloom items=431854683 errorrate=0.001

Agradable, actualizado https://github.com/hayorov/ethereum-sync-metrics

¿No es posible extraer esta información de un nodo que ya está sincronizado?

¿Se puede reabrir esto? Si abro un nuevo problema solicitando una API para recuperar el número actual de estados en el trie después de que el nodo haya terminado de sincronizarse, ¿se cerrará sumariamente?

Error similar que todavía está abierto (15616)
Solicitud de función para obtener una forma de recuperar el número de entradas de estado (16558)
https://eips.ethereum.org/EIPS/eip-2029

15 febrero 2020
446266045

INFO [02-15|22:49:59.641] Imported new state entries count=484 elapsed=11.987ms processed=446266045 pending=0 retry=0 duplicate=50314 unexpected=640943

17 Mar 2020
466184476

INFO [03-17|02:20:26.688] Imported new state entries count=343 elapsed=16.813ms processed=466184476 pending=0 retry=0 duplicate=157290 unexpected=584684

INFO [04-11|22:56:13.547] Imported new block receipts count=1 elapsed=999.7µs number=9852885 hash=45231e…244fc9 age=20m32s size=9.53KiBINFO [04-11|22:56:13.566] Committed new head block number=9852885 hash=45231e…244fc9INFO [04-11|22:56:13.618] Deallocated fast sync bloom **items=480155136** errorrate=0.001

elementos = 480155136

Mis problemas con la sincronización durante 2 semanas se basaron en HDD y doble NAT. Pero después de agregar un caché SSD de solo lectura a mi NFS, y después de hoy abrir los puertos en mi NAT externo mientras seguía confiando en UPnP para mi enrutador interno, lo sincronicé.
mi cantidad final de entradas estatales procesadas fue 487040102

INFO [04-14|19:48:25.498] Imported new state entries count=271 elapsed=2.687ms processed=487040102 pending=0 retry=0 duplicate=17264 unexpected=61660INFO [04-14|19:48:25.556] Deallocated fast sync bloom items=486016461 errorrate=0.001

Límite actualizado:

INFO [05-10|23:51:14.924] Imported new state entries count=147 elapsed=7.432ms processed=504700513 pending=0 retry=0 duplicate=1115 unexpected=4208INFO [05-10|23:51:14.968] Imported new block receipts count=1 elapsed=37.733ms number=10040872 hash=27a688…d5f8f4 age=28m12s size=23.45KiBINFO [05-10|23:51:14.978] Committed new head block number=10040872 hash=27a688…d5f8f4INFO [05-10|23:51:14.982] Deallocated fast sync bloom items=504344987 errorrate=0.202INFO [05-10|23:51:25.223] Imported new chain segment blocks=3 txs=407 mgas=29.972 elapsed=10.224s mgasps=2.932 number=10040875 hash=4cb642…c3d687 age=27m45s dirty=3.67MiB

Es decir, 504344987 indican las entradas al 10 de mayo de 2020. Para una sincronización rápida, se trata de aproximadamente 240 GB de datos almacenados en el SSD.

Usando un RPi v4, 4GB RAM, SSD Samsung T5 de 1TB con alimentación externa para sincronizar. Consejo profesional para usuarios de Raspberry Pi: use Ubuntu Server de 64 bits. Actualmente, Raspbian no usa de forma nativa 64 bits. Puede "permitir" esto manualmente a través de algunas configuraciones del kernel, pero todavía me encontré con problemas de falta de memoria. Podría haber hecho algo mal allí. Sin embargo, en Ubuntu, nunca he tenido un error de memoria insuficiente desde la sincronización. Debo tener en cuenta que asigné un intercambio de 8GB en el SSD y usé --cache=512 como parámetro Geth. También asegúrese de que su puerto 30303 esté abierto, para que los nodos externos puedan conectarse (¡y usted puede encontrar pares!).

Lamentablemente, no he escrito cuándo comencé a sincronizar. Sin embargo, sé que tomó menos de una semana. Creo que es entre 5 y 6 días.

11 de junio de 2020
537342779

 INFO [06-11|20:02:41.758] Imported new state entries count=452 elapsed=6.587ms processed=537342779 pending=0 retry=0 duplicate=11612 unexpected=28764

Los horarios están en GMT +0. Comenzó hace aproximadamente 1 semana.

Testnet de Ropsten
INFO [06-19|13:24:06.907] Deallocated fast sync bloom items=245025020 errorrate=0.001
Almacenamiento de datos en cadena: 39,6 GB
Almacenamiento antiguo: 36,8 GB

INFO [06-21|07:57:24.932] Deallocated fast sync bloom items=536929173 errorrate=0.001
Almacenamiento de datos en cadena: 100,2 GB
Almacenamiento antiguo: 133,2 GB

21 de junio de 2020
574408341

INFO [06-21|17:06:28.769] Imported new state entries count=435 elapsed=3.950ms processed=574408341 pending=0 retry=0 duplicate=268 unexpected=578

10 agosto 2020
571739565

INFO [08-09|23:26:03.932] Imported new state entries count=56 elapsed=2.469ms processed=571739565 pending=0 retry=0 duplicate=13914 unexpected=49760INFO [08-09|23:26:03.939] Imported new block receipts count=1 elapsed=6.060ms number=10626424 hash="70eb79…2712a6" age=23m46s size=67.10KiBINFO [08-09|23:26:03.941] Committed new head block number=10626424 hash="70eb79…2712a6"

Bastante arrojadizo, a menudo atascado aquí durante la sincronización:
WARN [08-08|00:09:42.076] Dropping unsynced node during fast sync id=541791c3ce2e53df conn=dyndial addr=198.204.254.10:3030
Pero después de reiniciar, se puede sincronizar normalmente nuevamente. Se supone que el nodo rechazará el límite de corriente del nodo y una cierta cantidad de datos sincronizados.
Luego hice un script de shell para monitorear el registro de sincronización. Cuando el crecimiento del registro en un cierto período de tiempo es demasiado pequeño, se sospecha que el nodo está atascado. El script cerrará automáticamente el programa de sincronización y lo ejecutará nuevamente.
De esta manera, tomó alrededor de 2 días completar la sincronización, y el espacio ssd usó 249G.

Es un poco molesto quedarse atascado aquí mucho durante la sincronización.
WARN [08-08|00:09:42.076] Dropping unsynced node during fast sync id=541791c3ce2e53df conn=dyndial addr=198.204.254.10:3030
Pero una vez que lo reinicia, puede sincronizar nuevamente. La conjetura es que el nodo está limitado en la corriente, y el nodo rechazará una cierta cantidad de datos sincronizados.
Luego hice un script de shell para monitorear el registro sincrónico. Cuando el crecimiento del registro es demasiado pequeño dentro de un cierto período de tiempo, se sospecha que el nodo está atascado. El script cerrará automáticamente el programa sincrónico y lo ejecutará nuevamente.
De esta manera, tardó aproximadamente 2 días en sincronizarse completamente, y el espacio SSD usó 249G.

572083659 9 de agosto de 2020

INFO [08-09|16:37:34.615] Imported new state entries count=1606 elapsed=20.127ms processed=579048027 pending=0 retry=0 duplicate=0 unexpected=0INFO [08-09|16:37:34.618] Imported new block receipts count=1 elapsed=1.940ms number=10626719 hash="444831…2b96ff" age=28m10s size=87.93KiBINFO [08-09|16:37:34.621] Committed new head block number=10626719 hash="444831…2b96ff"INFO [08-09|16:37:34.644] Deallocated fast sync bloom items=572083659 errorrate=0.001

@wellttllew @supenghai
Oye, ¿cuánto tiempo se tardó en realizar una sincronización completa?
Imported new state entries count=384 elapsed=4.84µs processed=665994734

Las entradas de mi estado se han estado descargando durante una semana.

@wellttllew
Me gustaría saber la configuración de su servidor.
La configuración de mi servidor es: procesadores de diez núcleos, 32 M de memoria, 20 M de ancho de banda. La sincronización rápida tomó aproximadamente 48 horas.

INFO [08-18|22:42:47.091] Deallocated fast sync bloom items=581136598 errorrate=0.173

Tamaño ~ 271 GB

¿Eso es un SSD SATA? ¿O un NVME?

El 19 de agosto de 2020, a las 6:42 p.m., steelep [emailprotected] escribió:

Voy a pasar 9 días ahora para una sincronización "rápida" completa, una composición i9 rápida, Internet de fibra con SSD y caché = 2048 ...

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o cancele la suscripción.

SATA, sigue siendo una unidad muy rápida.

El jueves 20 de agosto de 2020 a las 14:34, Bryan Stitt [emailprotected] escribió:

>
>
>

¿Eso es un SSD SATA? ¿O un NVME?

El 19 de agosto de 2020, a las 6:42 p.m., steelep [emailprotected] escribió:

>

Voy a continuar 9 días ahora para una sincronización "rápida" completa, una composición i9 rápida, fibra
Internet con SSD y caché = 2048 ....

>

-

Recibes esto porque te mencionaron.

Responda a este correo electrónico directamente, véalo en GitHub o cancele la suscripción.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ethereum/go-ethereum/issues/14647#issuecomment-676861306 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAKCS2ZM22O2OLYUPT7YUVTSBSDS5ANCNFSM4DPVTT6A
.

-
Patrick Steele

Nueva Zelanda: 0212384777
HK: 6926 1526

@wellttllew
Me gustaría saber la configuración de su servidor.
La configuración de mi servidor es: procesadores de diez núcleos, 32 M de memoria, 20 M de ancho de banda. La sincronización rápida tomó aproximadamente 48 horas.

Aproximadamente 3 días, con un plan aws lightsail de $ 80.
4 núcleos, 16 GB, 320 GB SSD.

La sincronización rápida tomó aproximadamente 10 horas en la instancia Amazon i3.xlarge (4 CPU virtuales, 30 GB de RAM, disco duro NVMe).

575809113 indican las entradas a partir del 25-08-2020.

Usé las siguientes banderas:
--cache = 4096 (esencial para mejorar la velocidad, pero requiere más RAM)
--maxpeers = 50

El tamaño final del directorio .ethereum es de aproximadamente 253 GB.
versión geth: 1.9.20-unstable-7b5107b7-20200824

¿Cuál es el tamaño del directorio db después de una sincronización completa? No he hecho esto por un tiempo (no tenía la función de congelador en ese entonces). TIA.

tamaños completos sin mover nada
mainnet = 402GB
testnet = 96GB

He iniciado la sincronización rápida y ha tardado 3 días.
el primer día, todos los bloques se sincronizaron, pero su estado de sincronización y ahora es muy lento.

aquí está el resultado de la sincronización:

{ "currentBlock": 10735343, "highestBlock": 10735450, "knownStates": 584833661, "pulledStates": 584754308, "startingBlock": 10734477}

aquí está el resultado de la consola:

INFO [08-26|12:13:23.330] Imported new state entries count=384 elapsed=6.877ms processed=584758628 pending=77408 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:13:27.602] Imported new state entries count=636 elapsed=7.330ms processed=584759264 pending=77425 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:13:32.088] Imported new block headers count=2 elapsed=11.847ms number=10735455 hash="71d3b7…0e55db"INFO [08-26|12:13:32.300] Downloader queue stats receiptTasks=0 blockTasks=0 itemSize=193.43KiB throttle=339INFO [08-26|12:13:33.786] Imported new state entries count=680 elapsed=7.854ms processed=584759944 pending=77018 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:13:40.582] Imported new state entries count=618 elapsed=10.019ms processed=584760562 pending=76876 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:13:46.097] Imported new state entries count=768 elapsed=14.378ms processed=584761330 pending=76011 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:13:52.082] Imported new state entries count=588 elapsed=10.860ms processed=584761918 pending=75758 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:13:54.640] Imported new state entries count=384 elapsed=7.061ms processed=584762302 pending=75829 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:00.586] Imported new state entries count=620 elapsed=10.992ms processed=584762922 pending=75610 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:04.091] Imported new state entries count=384 elapsed=5.460ms processed=584763306 pending=75509 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:05.281] Imported new block headers count=1 elapsed=10.060ms number=10735456 hash="261277…ec1ae9"INFO [08-26|12:14:05.316] Downloader queue stats receiptTasks=0 blockTasks=0 itemSize=195.86KiB throttle=335INFO [08-26|12:14:09.136] Imported new state entries count=638 elapsed=6.682ms processed=584763944 pending=75456 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:09.166] Imported new block headers count=1 elapsed=11.364ms number=10735457 hash="6cd8bc…d18c5a"INFO [08-26|12:14:11.997] Imported new state entries count=384 elapsed=1.012ms processed=584764328 pending=76285 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:17.521] Imported new state entries count=768 elapsed=2.411ms processed=584765096 pending=77453 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:20.346] Imported new state entries count=384 elapsed=1.352ms processed=584765480 pending=78070 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:22.298] Imported new block headers count=1 elapsed=12.015ms number=10735458 hash="c50745…4caf1a"INFO [08-26|12:14:22.325] Downloader queue stats receiptTasks=0 blockTasks=0 itemSize=179.93KiB throttle=365INFO [08-26|12:14:23.382] Imported new state entries count=384 elapsed=1.053ms processed=584765864 pending=78578 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:26.121] Imported new state entries count=384 elapsed=1.387ms processed=584766248 pending=79245 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:29.057] Imported new state entries count=395 elapsed=1.074ms processed=584766643 pending=79953 retry=4 duplicate=1090 unexpected=4261INFO [08-26|12:14:32.295] Imported new state entries count=384 elapsed=1.125ms processed=584767027 pending=80679 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:32.435] Imported new block headers count=1 elapsed=12.931ms number=10735459 hash="7d63b2…ff65b6"INFO [08-26|12:14:33.331] Downloader queue stats receiptTasks=0 blockTasks=0 itemSize=187.34KiB throttle=350INFO [08-26|12:14:35.170] Imported new state entries count=384 elapsed=1.509ms processed=584767411 pending=81137 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:37.587] Imported new state entries count=384 elapsed="939.928µs" processed=584767795 pending=82376 retry=2 duplicate=1090 unexpected=4261INFO [08-26|12:14:42.914] Imported new state entries count=768 elapsed=5.270ms processed=584768563 pending=83624 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:45.925] Imported new state entries count=384 elapsed=1.518ms processed=584768947 pending=84116 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:48.339] Imported new state entries count=384 elapsed=1.183ms processed=584769331 pending=85239 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:51.306] Imported new state entries count=433 elapsed=4.434ms processed=584769764 pending=85273 retry=0 duplicate=1090 unexpected=4261INFO [08-26|12:14:52.549] Imported new block headers count=1 elapsed=10.824ms number=10735460 hash="499459…5ccd22"INFO [08-26|12:14:52.972] Imported new block headers count=1 elapsed=10.718ms number=10735461 hash="c25179…457362"INFO [08-26|12:14:53.342] Downloader queue stats receiptTasks=0 blockTasks=0 itemSize=187.89KiB throttle=349INFO [08-26|12:14:54.843] Imported new state entries count=384 elapsed=1.205ms processed=584770148 pending=85616 retry=0 duplicate=1090 unexpected=4261

¿Alguien sabe cuántos estados existen ahora?
¿y que puedo hacer?

Hola @sjlnk. ¿Se completó su sincronización? ¿Qué muestran los registros ahora?
He estado en él durante semanas y todavía recibo entradas estatales importadas

Sí, está completo. Ya informé los resultados arriba. Desplácese hacia arriba. ^^

La configuración --cache hace una gran diferencia, pero es más exigente para el hardware.

Hola @sjlnk ¿
Recibo esto desde hace semanas:

INFO [08-26|17:09:11.398] Imported new block headers count=3 elapsed=30.970ms number=10736801 hash=8df84b…d6ab09INFO [08-26|17:09:15.920] Initializing fast sync bloom items=11047301 errorrate=0.000 elapsed=13m20.633sINFO [08-26|17:09:22.638] Imported new state entries count=719 elapsed=19.118ms processed=698898959 pending=3397 retry=0 duplicate=0 unexpected=13INFO [08-26|17:09:23.924] Initializing fast sync bloom items=11136084 errorrate=0.000 elapsed=13m28.637sINFO [08-26|17:09:31.931] Initializing fast sync bloom items=11215396 errorrate=0.000 elapsed=13m36.644sINFO [08-26|17:09:32.719] Imported new block headers count=1 elapsed=31.119ms number=10736802 hash=01f447…129466INFO [08-26|17:09:38.130] Imported new state entries count=324 elapsed=14.996ms processed=698899283 pending=3309 retry=0 duplic

Además, ¿qué versión de GETH estás usando?

Hola @sjlnk ¿
Recibo esto desde hace semanas:

INFO [08-26|17:09:11.398] Imported new block headers count=3 elapsed=30.970ms number=10736801 hash=8df84b…d6ab09INFO [08-26|17:09:15.920] Initializing fast sync bloom items=11047301 errorrate=0.000 elapsed=13m20.633sINFO [08-26|17:09:22.638] Imported new state entries count=719 elapsed=19.118ms processed=698898959 pending=3397 retry=0 duplicate=0 unexpected=13INFO [08-26|17:09:23.924] Initializing fast sync bloom items=11136084 errorrate=0.000 elapsed=13m28.637sINFO [08-26|17:09:31.931] Initializing fast sync bloom items=11215396 errorrate=0.000 elapsed=13m36.644sINFO [08-26|17:09:32.719] Imported new block headers count=1 elapsed=31.119ms number=10736802 hash=01f447…129466INFO [08-26|17:09:38.130] Imported new state entries count=324 elapsed=14.996ms processed=698899283 pending=3309 retry=0 duplic

Además, ¿qué versión de GETH estás usando?

Sí, recibí ese mensaje. La versión también se informa arriba.

Hola @sjlnk. No entiendo por qué las entradas de mi estado son mucho mayores que las suyas. Pero aún así, la sincronización no se completa:

INFO [08-27|09:38:20.250] Initializing fast sync bloom items=295539384 errorrate=0.000 elapsed=16h22m25.240sINFO [08-27|09:38:25.986] Imported new block headers count=2 elapsed=87.677ms number=10741287 hash="309adc…db751d"INFO [08-27|09:38:28.254] Initializing fast sync bloom items=295539813 errorrate=0.000 elapsed=16h22m33.244sINFO [08-27|09:38:36.256] Initializing fast sync bloom items=295540299 errorrate=0.000 elapsed=16h22m41.246sINFO [08-27|09:38:44.262] Initializing fast sync bloom items=295540709 errorrate=0.000 elapsed=16h22m49.251sINFO [08-27|09:38:49.951] Imported new state entries count=305 elapsed=7.255ms processed=700468113 pending=77486 retry=0 duplicate=0 unexpected=0

Ya estoy en: 700468113

Hola @sjlnk. No entiendo por qué las entradas de mi estado son mucho mayores que las suyas. Pero aún así, la sincronización no se completa:

INFO [08-27|09:38:20.250] Initializing fast sync bloom items=295539384 errorrate=0.000 elapsed=16h22m25.240sINFO [08-27|09:38:25.986] Imported new block headers count=2 elapsed=87.677ms number=10741287 hash="309adc…db751d"INFO [08-27|09:38:28.254] Initializing fast sync bloom items=295539813 errorrate=0.000 elapsed=16h22m33.244sINFO [08-27|09:38:36.256] Initializing fast sync bloom items=295540299 errorrate=0.000 elapsed=16h22m41.246sINFO [08-27|09:38:44.262] Initializing fast sync bloom items=295540709 errorrate=0.000 elapsed=16h22m49.251sINFO [08-27|09:38:49.951] Imported new state entries count=305 elapsed=7.255ms processed=700468113 pending=77486 retry=0 duplicate=0 unexpected=0

Ya estoy en: 700468113

después de 7 días?

¿Usas ssd o nvme?

mi resultado después de 5 días:

INFO [08-27|10:48:43.404] Imported new state entries count=384 elapsed="4.217µs" processed=592286844 pending=65731 retry=0 duplicate=1090 unexpected=4261INFO [08-27|10:48:51.810] Imported new block headers count=2 elapsed=13.184ms number=10741600 hash="0df0e9…8ddd8a"INFO [08-27|10:48:52.667] Downloader queue stats receiptTasks=0 blockTasks=0 itemSize=201.71KiB throttle=325INFO [08-27|10:48:52.808] Imported new state entries count=384 elapsed="5.05µs" processed=592287228 pending=66124 retry=0 duplicate=1090 unexpected=4261INFO [08-27|10:49:02.164] Imported new state entries count=384 elapsed="6.18µs" processed=592287612 pending=66519 retry=0 duplicate=1090 unexpected=4261

Todavía estoy en 540M y sigo contando, pero te lo diré cuando termine.

Si tomamos como buenas las tres estadísticas reportadas en este hilo

| FECHA | COUNT |
|: -------- |: ------------ |
| 14/04/2020 | 487.040.102
| 10/05/2020 | 504.344.987
| 25/08/2020 | 575.809.113

hay alrededor de 500k ~ 600k nuevas entradas de estado todos los días, por lo que ahora deberíamos estar alrededor de ~ 580M. Para estar seguro, debe contar las entradas reales en el levelDB. Puedes hacerlo con un script separado que cuente eso, pero ya lo estaba haciendo en un PR separado para geth, así que si quieres, ya puedes probarlo desde aquí .

Sugiero siempre compilar desde la fuente, pero también cargué una versión ya compilada en mi Ubuntu-20.04.1 de 64 bits.

Enviaré un PR para el maestro, pero tenga en cuenta que si toma desde allí, su base de datos se actualizará al nuevo esquema. No hay nada que temer, solo decirlo.

Este es, por ejemplo, el resultado de una red de prueba de goerli sincronizada por completo hace unos minutos, donde _trie nodos_ son 24272247. Verá la línea _códigos de contrato_ porque ya actualicé mi red para las pruebas.

❯ ./build/bin/geth --goerli --verbosity 3 inspectINFO [08-27|11:48:29.190] Maximum peer count ETH=50 LES=0 total=50INFO [08-27|11:48:29.190] Smartcard socket not found, disabling err="stat /run/pcscd/pcscd.comm: no such file or directory"INFO [08-27|11:48:29.198] Set global gas cap cap=25000000INFO [08-27|11:48:29.198] Allocated cache and file handles database=/home/developer/.ethereum/goerli/geth/chaindata cache=512.00MiB handles=524288INFO [08-27|11:48:29.283] Opened ancient database database=/home/developer/.ethereum/goerli/geth/chaindata/ancientINFO [08-27|11:48:29.313] Persisted trie from memory database nodes=361 size=51.17KiB time=1.37971ms gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00BINFO [08-27|11:48:29.316] Loaded most recent local header number=3296898 hash="886b5b…2b6a4b" td=4811621 age=14m5sINFO [08-27|11:48:29.316] Loaded most recent local full block number=3296898 hash="886b5b…2b6a4b" td=4811621 age=14m5sINFO [08-27|11:48:29.316] Loaded most recent local fast block number=3296898 hash="886b5b…2b6a4b" td=4811621 age=14m5sINFO [08-27|11:48:29.316] Loaded last fast-sync pivot marker number=3292045INFO [08-27|11:48:37.405] Inspecting database count=7148000 elapsed=8.006sINFO [08-27|11:48:45.406] Inspecting database count=14589000 elapsed=16.007sINFO [08-27|11:48:53.408] Inspecting database count=22353000 elapsed=24.009s+-----------------+--------------------+------------+----------+| DATABASE | CATEGORY | SIZE | COUNT |+-----------------+--------------------+------------+----------+| Key-Value store | Headers | 12.86 MiB | 20838 || Key-Value store | Bodies | 39.91 MiB | 21008 || Key-Value store | Receipts | 36.77 MiB | 21008 || Key-Value store | Difficulties | 1.01 MiB | 21472 || Key-Value store | Block number->hash | 924.96 KiB | 20580 || Key-Value store | Block hash->number | 128.95 MiB | 3297807 || Key-Value store | Transaction index | 10.40 MiB | 303011 || Key-Value store | Bloombit index | 102.89 MiB | 1646592 || Key-Value store | Contract codes | 97.18 MiB | 17941 || Key-Value store | Trie nodes | 2.37 GiB | 24272247 || Key-Value store | Trie preimages | 3.51 MiB | 49418 || Key-Value store | Account snapshot | 0.00 B | 0 || Key-Value store | Storage snapshot | 0.00 B | 0 || Key-Value store | Clique snapshots | 79.33 KiB | 98 || Key-Value store | Singleton metadata | 151.00 B | 5 || Ancient store | Headers | 1.04 GiB | NA || Ancient store | Bodies | 1.09 GiB | NA || Ancient store | Receipts | 596.63 MiB | NA || Ancient store | Difficulties | 31.21 MiB | NA || Ancient store | Block number->hash | 118.75 MiB | NA || Light client | CHT trie nodes | 0.00 B | 0 || Light client | Bloom trie nodes | 0.00 B | 0 |+-----------------+--------------------+------------+----------+| TOTAL | 5.65 GIB | +-----------------+--------------------+------------+----------+ERROR[08-27|11:48:58.711] Database contains unaccounted data size=100.74KiB count=3514

Hola @sjlnk. No entiendo por qué las entradas de mi estado son mucho mayores que las suyas. Pero aún así, la sincronización no se completa:

INFO [08-27|09:38:20.250] Initializing fast sync bloom items=295539384 errorrate=0.000 elapsed=16h22m25.240sINFO [08-27|09:38:25.986] Imported new block headers count=2 elapsed=87.677ms number=10741287 hash="309adc…db751d"INFO [08-27|09:38:28.254] Initializing fast sync bloom items=295539813 errorrate=0.000 elapsed=16h22m33.244sINFO [08-27|09:38:36.256] Initializing fast sync bloom items=295540299 errorrate=0.000 elapsed=16h22m41.246sINFO [08-27|09:38:44.262] Initializing fast sync bloom items=295540709 errorrate=0.000 elapsed=16h22m49.251sINFO [08-27|09:38:49.951] Imported new state entries count=305 elapsed=7.255ms processed=700468113 pending=77486 retry=0 duplicate=0 unexpected=0

Ya estoy en: 700468113

Eso es extraño. Me gustaría saber también por qué sucede esto. Quizás alguien con más conocimientos podría intervenir e iluminarnos ...

@sjlnk es porque detuvo y reinició la sincronización varias veces. O eso supongo, ya que sigue siendo Initializing fast sync bloom . Cada vez que reinicia, geth entra en un modo en el que, al importar el estado, también lee la base de datos completa para crear un filtro de floración de los estados existentes. Lo que ralentiza la sincronización. Además, cada vez que reinicia, elige un nuevo punto de pivote para sincronizar, por lo que hay más estado para descargar.

@karalabe acaba de fusionar un gran PR que hace que la sincronización rápida sea mucho más estable y menos propensa a fallar debido a la falta de memoria. Recomendaría actualizar a la última master y comenzar desde cero o continuar (sí, con otro reinicio, no se puede evitar).

@sjlnk es porque detuvo y reinició la sincronización varias veces. O eso supongo, ya que sigue siendo Initializing fast sync bloom . Cada vez que reinicia, geth entra en un modo en el que, al importar el estado, también lee la base de datos completa para crear un filtro de floración de los estados existentes. Lo que ralentiza la sincronización. Además, cada vez que reinicia, elige un nuevo punto de pivote para sincronizar, por lo que hay más estado para descargar.

@karalabe acaba de fusionar un gran PR que hace que la sincronización rápida sea mucho más estable y menos propensa a fallar debido a la falta de memoria. Recomendaría actualizar a la última master y comenzar desde cero o continuar (sí, con otro reinicio, no se puede evitar).

¡Gracias por aclararlo! En realidad, mi sincronización se completó en 10 horas con una potente instancia habilitada para AWS NVMe. Solo quería saber por qué algunas personas tienen que descargar más estados que otras. Nunca reinicié el proceso, así que supongo que las otras personas aquí lo hicieron y es por eso que tienen muchos más estados para descargar.

Terminé con el contador en 652299180 . Tenga en cuenta que, en mi caso, el contador processed al final fue más grande de aproximadamente ~ 12M de entradas en comparación con las entradas reales almacenadas en levelDB. Reinicié geth durante la sincronización rápida muchas veces en estos días.

INFO [08-30|10:01:52.403] Imported new state entries count=1605 elapsed=22.003ms processed=652296924 pending=3467 retry=0 duplicate=41127 unexpected=121037INFO [08-30|10:01:53.302] Imported new state entries count=1157 elapsed=11.998ms processed=652298081 pending=2059 retry=0 duplicate=41127 unexpected=121037INFO [08-30|10:01:54.214] Imported new state entries count=1001 elapsed=14.992ms processed=652299082 pending=348 retry=0 duplicate=41127 unexpected=121037INFO [08-30|10:01:54.523] Imported new state entries count=98 elapsed=2.837ms processed=652299180 pending=0 retry=0 duplicate=41127 unexpected=121037INFO [08-30|10:01:54.535] Imported new block receipts count=1 elapsed=2ms number=10760885 hash="e5569e…7ead3c" age=29m44s size=101.58KiBINFO [08-30|10:01:54.545] Committed new head block number=10760885 hash="e5569e…7ead3c"INFO [08-30|10:01:54.613] Deallocated fast sync bloom items=639248389 errorrate=0.001INFO [08-30|10:02:03.025] Imported new chain segment blocks=12 txs=2533 mgas=149.011 elapsed=8.402s mgasps=17.735 number=10760897 hash="f8d397…0dafd0" age=26m49s dirty=18.46MiBINFO [08-30|10:02:11.409] Imported new chain segment blocks=14 txs=3369 mgas=174.232 elapsed=8.384s mgasps=20.780 number=10760911 hash="1adada…67ecc0" age=21m55s dirty=41.57MiBINFO [08-30|10:02:19.956] Imported new chain segment blocks=18 txs=3487 mgas=210.546 elapsed=8.546s mgasps=24.636 number=10760929 hash="97dcea…9d023b" age=16m20s dirty=68.14MiBINFO [08-30|10:02:27.303] New local node record seq=39281 id=82090fbe6ea27663 ip=127.0.0.1 udp=30303 tcp=30303INFO [08-30|10:02:27.389] New local node record seq=39282 id=82090fbe6ea27663 ip=93.40.103.165 udp=30303 tcp=30303INFO [08-30|10:02:28.037] Imported new chain segment blocks=17 txs=3815 mgas=209.530 elapsed=8.081s mgasps=25.927 number=10760946 hash="4165bb…e09268" age=11m39s dirty=94.33MiBINFO [08-30|10:02:36.621] Imported new chain segment blocks=12 txs=2487 mgas=136.747 elapsed=8.584s mgasps=15.930 number=10760958 hash="c59ba3…d33c9e" age=8m32s dirty=111.89MiBINFO [08-30|10:02:40.190] New local node record seq=39283 id=82090fbe6ea27663 ip=127.0.0.1 udp=30303 tcp=30303INFO [08-30|10:02:45.795] New local node record seq=39284 id=82090fbe6ea27663 ip=93.40.103.165 udp=30303 tcp=30303INFO [08-30|10:02:45.895] Imported new chain segment blocks=10 txs=2042 mgas=120.584 elapsed=9.273s mgasps=13.003 number=10760968 hash="82b2bd…ea0969" age=6m43s dirty=126.93MiBINFO [08-30|10:02:46.400] Deep froze chain segment blocks=30001 elapsed=18.624s number=10057008 hash="ffaddb…05d9b1"INFO [08-30|10:02:54.190] Imported new chain segment blocks=13 txs=2915 mgas=161.846 elapsed=8.295s mgasps=19.511 number=10760981 hash="e653ff…70529a" age=3m40s dirty=146.58MiBINFO [08-30|10:03:00.113] Imported new chain segment blocks=7 txs=1296 mgas=87.019 elapsed=5.923s mgasps=14.691 number=10760988 hash="a655a4…7c6ca5" age=1m31s dirty=156.69MiBINFO [08-30|10:03:00.126] Imported new block headers count=1 elapsed=1m4.052s number=10760989 hash="31df12…bc9465" age=1m30sINFO [08-30|10:03:00.139] Imported new block headers count=1 elapsed=4.998ms number=10760990 hash="04c374…9a92dc" age=1m27sINFO [08-30|10:03:00.153] Imported new block headers count=3 elapsed=6.000ms number=10760993 hash="c6fffb…265cae"INFO [08-30|10:03:00.225] Downloader queue stats receiptTasks=0 blockTasks=0 itemSize=221.62KiB throttle=296INFO [08-30|10:03:00.997] Imported new chain segment blocks=1 txs=235 mgas=12.392 elapsed=763.005ms mgasps=16.241 number=10760989 hash="31df12…bc9465" age=1m30s dirty=158.37MiBINFO [08-30|10:03:01.008] Imported new block headers count=1 elapsed=572.995ms number=10760994 hash="e3afed…f9afef"INFO [08-30|10:03:03.377] Imported new chain segment blocks=1 txs=200 mgas=12.423 elapsed=2.361s mgasps=5.261 number=10760990 hash="04c374…9a92dc" age=1m30s dirty=160.05MiBINFO [08-30|10:03:04.270] Deep froze chain segment blocks=30001 elapsed=17.860s number=10087009 hash="e2f6c6…fe7f20"WARN [08-30|10:03:07.574] Fast syncing, discarded propagated block number=10760994 hash="e3afed…f9afef"INFO [08-30|10:03:08.411] Imported new chain segment blocks=4 txs=666 mgas=49.755 elapsed=5.023s mgasps=9.905 number=10760994 hash="e3afed…f9afef" dirty=165.73MiBINFO [08-30|10:03:08.422] Fast sync complete, auto disabling

Estadísticas de base de datos detalladas

> geth --datadir s:\Ethereum inspectINFO [08-30|12:49:32.043] Maximum peer count ETH=50 LES=0 total=50INFO [08-30|12:49:32.388] Set global gas cap cap=25000000INFO [08-30|12:49:32.393] Allocated cache and file handles database=s:\Ethereum\geth\chaindata cache=512.00MiB handles=8192INFO [08-30|12:49:34.040] Opened ancient database database=s:\Ethereum\geth\chaindata\ancientINFO [08-30|12:49:34.074] Disk storage enabled for ethash caches dir=s:\Ethereum\geth\ethash count=3INFO [08-30|12:49:34.079] Disk storage enabled for ethash DAGs dir=C:\Users\giuse\AppData\Local\Ethash count=2INFO [08-30|12:49:34.090] Loaded most recent local header number=10761038 hash="95d315…aac7a9" td=17106408363816477706008 age=2h38m10sINFO [08-30|12:49:34.099] Loaded most recent local full block number=10760905 hash="a638f7…ecd63c" td=17106043165864029076711 age=3h10m31sINFO [08-30|12:49:34.106] Loaded most recent local fast block number=10761038 hash="95d315…aac7a9" td=17106408363816477706008 age=2h38m10sINFO [08-30|12:49:34.107] Deep froze chain segment blocks=18 elapsed=33.995ms number=10670905 hash="8c3832…cb9018"INFO [08-30|12:49:34.115] Loaded last fast-sync pivot marker number=10760885INFO [08-30|12:49:42.130] Inspecting database count=6482000 elapsed=8.001s...INFO [08-30|13:22:16.661] Counting ancient database receipts blocknumber=10670906 percentage=100 elapsed=32m42.533s+-----------------+--------------------+------------+-----------+| DATABASE | CATEGORY | SIZE | ITEMS |+-----------------+--------------------+------------+-----------+| Key-Value store | Headers | 55.00 MiB | 100554 || Key-Value store | Bodies | 3.64 GiB | 98505 || Key-Value store | Receipts | 4.20 GiB | 17751843 || Key-Value store | Difficulties | 6.25 MiB | 110238 || Key-Value store | Block number->hash | 5.16 MiB | 110222 || Key-Value store | Block hash->number | 420.76 MiB | 10761043 || Key-Value store | Transaction index | 27.44 GiB | 818569194 || Key-Value store | Bloombit index | 1.64 GiB | 5380096 || Key-Value store | Contract codes | 37.33 MiB | 6636 || Key-Value store | Trie nodes | 74.51 GiB | 639023322 || Key-Value store | Trie preimages | 1.07 MiB | 17051 || Key-Value store | Account snapshot | 0.00 B | 0 || Key-Value store | Storage snapshot | 0.00 B | 0 || Key-Value store | Clique snapshots | 0.00 B | 0 || Key-Value store | Singleton metadata | 151.00 B | 5 || Ancient store | Headers | 4.51 GiB | 10670906 || Ancient store | Bodies | 97.85 GiB | 10670906 || Ancient store | Receipt lists | 44.38 GiB | 10670906 || Ancient store | └ counted receipts | -- | 802441861 || Ancient store | Difficulties | 166.01 MiB | 10670906 || Ancient store | Block number->hash | 386.71 MiB | 10670906 || Light client | CHT trie nodes | 0.00 B | 0 || Light client | Bloom trie nodes | 0.00 B | 0 |+-----------------+--------------------+------------+-----------+| TOTAL | 259.22 GIB | |+-----------------+--------------------+------------+-----------+ERROR[08-30|13:22:16.783] Database contains unaccounted data size=121.08KiB count=2632

Hola @sjlnk . ¿Podría darnos la especificación de su servidor? Porque yo también tengo un buen servidor ... Pero no se ha completado durante un mes. ¿Cuál es su tasa de E / S de disco específicamente?

Usé i3.xlarge en Amazon EC2.

Terminó una sincronización rápida hoy (bloque 10770930) con:

processed=608439377

(_lo estaba ejecutando en una máquina de trabajo durante el día, por lo que el tiempo total es irrelevante en mi caso_)

Hola @Neurone ¿Cuántos días tarda en promedio la sincronización completa? ¿Cómo puedo saber qué tan cerca estoy? He estado sincronizando durante un mes ...

No es fácil de decir porque probé muchas cosas durante el proceso de sincronización, reinicié muchas veces (40 ~ 50 veces) y moví los archivos por diferentes sistemas. En cualquier caso, busqué todos los registros que guardé entre reinicios (no todos) y creé el resumen a continuación, solo para tener una idea.

La mayor parte del tiempo se dedica a la sincronización rápida de las entradas de estado, pero los encabezados de bloque se descargan en pocas horas en cualquier caso. Por lo tanto, debe verificar sus estadísticas y calcular su tasa para descargar entradas de estado por hora: si es lo suficientemente alta, le sugiero que elimine la base de datos, no la antigua, y vuelva a descargar las entradas de estado desde el principio.

Si su tasa es como la mía al final (~ 8.2 millones de entradas por hora), debería poder alcanzar el estado actual desde cero en ~ 3 días.

| SISTEMA / SO | RAM GB | DISCO | HORAS EN LÍNEA | REINICIOS | ENTRADAS ESTATALES ALCANZADAS | ENTRADAS ESTATALES POR HORA | HORA DE INICIAR FAST SYNC BLOOM CUANDO SE REINICIE |
|: -: |: -: |: -: |: -: |: -: |: -: |: -: |: -: |
| Rock64 / Armbian 20.02.1 Bionic | 4 | HDD | ~ 1.800 | ~ 40 | 469.380.958 | ~ 100k (disminuyendo con el tiempo, este es el valor medio en los últimos 26 días) | 3h16m29 |
| Escritorio / Ubuntu 20.04 (WSL2 en Windows 10) | 16 | SSD | 134 | 1 | 578.598.409 | ~ 815k | 2h38m14 |
| Escritorio / Windows 10 | 16 | SSD | 9 | 0 | 652.299.180 | ~ 8.2M | 30m28 |

• Escritorio:
  
  
  
  • Procesador: Intel i7-3820 3.6Ghz (2012)
  
  
  • SSD: Crucial CT525MX300SSD1 (2016)
  
  

Por lo tanto, debe verificar sus estadísticas y calcular su tasa para descargar entradas de estado por hora: si es lo suficientemente alta, le sugiero que elimine la base de datos, no la antigua, y vuelva a descargar las entradas de estado desde el principio.

Hola @Neurone, gracias por agregar algunos bits de sus datos. Estoy tratando de averiguar si tengo una tasa lo suficientemente alta. Actualmente, aproximadamente 600k por hora en un SSD Samsung de 8GB Pi 4, 1 TB. Ha sido difícil encontrar información sobre lo que podría ser una tasa lo suficientemente alta. Simplemente tomé un valor estacionario estimado de 600M y me hice algunos objetivos móviles de 3000 cambios de estado estimados bajos por bloque y estimados altos de 6000 cambios de estado por bloque. Lo que me pondría en necesitar 720k-1.44M por hora para mantenerme al día con el mínimo de la cadena. ¿Qué tasa crees que es razonable?

He estado considerando eliminar la cadena y comenzar de nuevo para ver si me he quedado demasiado atrás. ¿También sabe si el comando eliminadob se mantendría antiguo al especificar el directorio de datos incluso si ambos están en la carpeta chaindata?

¡Gracias!

Por lo tanto, debe verificar sus estadísticas y calcular su tasa para descargar entradas de estado por hora: si es lo suficientemente alta, le sugiero que elimine la base de datos, no la antigua, y vuelva a descargar las entradas de estado desde el principio.

Hola @Neurone, gracias por agregar algunos bits de sus datos. Estoy tratando de averiguar si tengo una tasa lo suficientemente alta. Actualmente, aproximadamente 600k por hora en un SSD Samsung de 8GB Pi 4, 1 TB. Ha sido difícil encontrar información sobre lo que podría ser una tasa lo suficientemente alta. Simplemente tomé un valor estacionario estimado de 600M y me hice algunos objetivos móviles de 3000 cambios de estado estimados bajos por bloque y estimados altos de 6000 cambios de estado por bloque. Lo que me pondría en necesitar 720k-1.44M por hora para mantenerme al día con el mínimo de la cadena. ¿Qué tasa crees que es razonable?

He estado considerando eliminar la cadena y comenzar de nuevo para ver si me he quedado demasiado atrás. ¿También sabe si el comando eliminadob se mantendría antiguo al especificar el directorio de datos incluso si ambos están en la carpeta chaindata?

¡Gracias!

`INFO [11-10 | 15: 05: 14.458] Recuento de nuevas entradas de estado importadas = 384 transcurridas =" 11.648µs "procesadas = 501571121 pendientes = 49648 trieretry = 0 reintento de código = 0 duplicado = 15215 inesperado = 73697
INFO [11-10 | 15: 05: 19.526] Recuento de encabezados de bloque nuevos importados = 1 transcurrido = 242.947 ms número = 11229982 hash = "aff1eb▒616e67" edad = 1m18s
INFO [11-10 | 15: 05: 22.529] Recuento de nuevas entradas de estado importadas = 384 transcurridas = "8.352µs" procesadas = 501571505 pendientes = 50058 trieretry = 0 coderetry = 0 duplicado = 15215 inesperado = 73697
INFO [11-10 | 15: 05: 30.183] Recuento de nuevas entradas de estado importadas = 384 transcurridas = "180.219µs" procesadas = 501571889 pendientes = 50553 trieretry = 0 coderetry = 0 duplicado = 15215 inesperado = 73697
INFO [11-10 | 15: 05: 43.575] Recuento de nuevas entradas de estado importadas = 384 transcurridas = "288.309µs" procesadas = 501572273 pendientes = 50935 trieretry = 4 reintentos de códigos = 0 duplicados = 15215 inesperados = 73697
INFO [11-10 | 15: 05: 51.439] Recuento de nuevas entradas de estado importadas = 386 transcurridas = "190.904µs" procesadas = 501572659 pendientes = 51429 trieretry = 0 coderetry = 0 duplicado = 15215 inesperado = 73697
INFO [11-10 | 15: 05: 59.872] Recuento de nuevas entradas de estado importadas = 384 transcurridas = "8.074µs" procesadas = 501573043 pendientes = 51883 trieretry = 0 coderetry = 0 duplicado = 15215 inesperado = 73697
INFO [11-10 | 15: 06: 11.695] Recuento de nuevas entradas de estado importadas = 384 transcurridas = "212.496µs" procesadas = 501573427 pendientes = 52268 trieretry = 0 coderetry = 0 duplicado = 15215 inesperado = 73697
INFO [11-10 | 15: 06: 19.745] Cantidad de encabezados de bloque nuevos importados = 1 transcurrido = 568.387ms número = 11229983 hash = "d10a7b▒22dbf3" edad = 2m9s
INFO [11-10 | 15: 06: 20.106] Recibo de estadísticas de cola de descargaTasks = 0 blockTasks = 0 itemSize = 216.91KiB throttle = 303
INFO [11-10 | 15: 06: 22.905] Recuento de nuevas entradas de estado importadas = 384 transcurridas = "17.499µs" procesadas = 501573811 pendientes = 52654 trieretry = 0 coderetry = 0 duplicado = 15215 inesperado = 73697
INFO [11-10 | 15: 06: 25.797] Recuento de encabezados de bloque nuevos importados = 1 transcurrido = 197.033ms número = 11229984 hash = "624d1f▒04161a" edad = 1m25s
INFO [11-10 | 15: 06: 33.955] Recuento de nuevas entradas de estado importadas = 384 transcurridas = "8.407µs" procesadas = 501574195 pendientes = 53041 trieretry = 0 reintento de código = 0 duplicado = 15215 inesperado = 73697
INFO [11-10 | 15: 06: 38.346] Recuento de encabezados de bloque nuevos importados = 1 transcurrido = 41.740 ms número = 11229985 hash = "530417▒f68043" edad = 1m20s
INFO [11-10 | 15: 06: 44.704] Recuento de nuevas entradas de estado importadas = 384 transcurridas = "8.907µs" procesadas = 501574579 pendientes = 53428 trieretry = 0 coderetry = 0 duplicado = 15215 inesperado = 73697
INFO [11-10 | 15: 06: 47.901] Recuento de encabezados de bloque nuevos importados = 1 transcurrido = 31.135ms número = 11229986 hash = "11688f▒0590b5"
INFO [11-10 | 15: 06: 51.181] Recuento de encabezados de bloque nuevos importados = 1 transcurrido = 20.278ms número = 11229987 hash = "2e93db▒b5fa93"
INFO [11-10 | 15: 06: 55.595] Recuento de nuevas entradas de estado importadas = 384 transcurridas = "163.312µs" procesadas = 501574963 pendientes = 53811 trieretry = 0 coderetry = 0 duplicado = 15215 inesperado = 73697
INFO [11-10 | 15: 07: 05.701] Recuento de nuevas entradas de estado importadas = 384 transcurridas = "16.314µs" procesadas = 501575347 pendientes = 54197 trieretry = 0 coderetry = 0 duplicado = 15215 inesperado = 73697
INFO [11-10 | 15: 07: 13.349] Recuento de encabezados de bloque nuevos importados = 1 transcurrido = 27.639 ms número = 11229988 hash = "9b7a99▒8cd706"

'
@ Duncan-Cerebro
esta es una muestra de mi rasp4 (4gb ram) con samsung T5 ssd
dice que está funcionando 4 días, pero creo que reinicié una vez debido a un corte de energía ... por lo que debería ser de 4 a 5 días
tenga en cuenta que está ejecutando un Raspbian completo de 64 bits

@ sirnicolas21 Lo siento, estoy confundido por su respuesta aquí. ¿Cuál es su tasa? Me parece que estás en la fase de prueba del estado de importación y todavía estás a unos 80 bloques de retraso. He estado corriendo durante 15 días y he estado en la fase de prueba estatal durante 12 días. He aumentado mi asignación de --cache para intentar aumentar mi tasa como se describe anteriormente. Puedo ver que tiene ~ 196 millones menos de entradas de estado que yo, por lo que parece que ha hecho algo bien o le queda mucho camino por recorrer. ¿Qué opciones de geth especificaste? ¡Gracias!

ps -ef | grep gethpi 1015 757 39 Nov05 pts/1 2-00:59:02 geth --datadir /data/nodes/geth --cache 1024

@ Duncan-Brain solo configuré el caché en geth nada más "--cache 1024"

• asegúrese de tener su disco formateado en ext4 y no ntfs
• También tuve que habilitar el intercambio ya que 4 gb no es mucho RAM, dudo que lo necesites, pero pruébalo
• asegúrese de que está ejecutando raspbian 64 y no 32, la instalación predeterminada es 32 pero fallará gravemente
• asegúrese de que el disco esté en el usb rápido (los azules)

también tenga en cuenta que en la fase de sincronización rápida no importa si estoy 80 bloques atrás porque debo alcanzar el punto de entrada de 600 mil para sincronizar completamente y luego usar la cadena de bloques, antes de que ethereum sea solo una cosa de consumo de recursos y nada más

ahora mismo estoy @ 502983948 entradas y mi publicación anterior hace 6 horas fue 501575347, por lo que son 240.000 entradas por hora aproximadamente

después de la fase de sincronización inicial, descarga los bloques y los analiza uno por uno y el proceso es ligeramente diferente de lo que está sucediendo ahora

y por último, pero no menos importante ... asegúrese de que no se está sobrecalentando, personalmente hice un pequeño disipador de calor y un ventilador funcionando en el rpi con encendido automático alrededor de 60c

Hola @ sirnicolas21 . Gracias por la discusión, tengo todas esas sugerencias implementadas (estoy usando la guía de configuración de raspberry pi de Kauri.io con algunos ajustes, es decir, --cache 2048). Según este hilo de discusión, estoy tratando de encontrar un límite superior en el número de estados (que entiendo es un objetivo en movimiento) para estar seguro de que después de 15 días puedo decirme a mí mismo "Estoy casi completamente sincronizado" o "Estoy Necesito empezar de nuevo ". En este hilo sobre el número 15616, algunos nodos llegan hasta ~ 800M algunos ~ 650M.

Como aún no está completamente sincronizado, ¿cómo puede estar seguro de que se sincronizará por completo alguna vez?

Puede consultar algunas de mis estadísticas de pi aquí en una hoja de Google -

Por lo tanto, debe verificar sus estadísticas y calcular su tasa para descargar entradas de estado por hora: si es lo suficientemente alta, le sugiero que elimine la base de datos, no la antigua, y vuelva a descargar las entradas de estado desde el principio.

Hola @Neurone, gracias por agregar algunos bits de sus datos. Estoy tratando de averiguar si tengo una tasa lo suficientemente alta. Actualmente, aproximadamente 600k por hora en un SSD Samsung de 8GB Pi 4, 1 TB. Ha sido difícil encontrar información sobre lo que podría ser una tasa lo suficientemente alta. Simplemente tomé un valor estacionario estimado de 600M y me hice algunos objetivos móviles de 3000 cambios de estado estimados bajos por bloque y estimados altos de 6000 cambios de estado por bloque. Lo que me pondría en necesitar 720k-1.44M por hora para mantenerme al día con el mínimo de la cadena. ¿Qué tasa crees que es razonable?

He estado considerando eliminar la cadena y comenzar de nuevo para ver si me he quedado demasiado atrás. ¿También sabe si el comando eliminadob se mantendría antiguo al especificar el directorio de datos incluso si ambos están en la carpeta chaindata?

¡Gracias!

Hola @ Duncan-Brain No puedo recordar mi tasa de importación de estado, pero puedo compartir la estadística actual de mi nodo completamente sincronizado para que pueda tener una idea de los números que necesita alcanzar para obtener un nodo completamente sincronizado (actualmente 880 millones de entradas de estado) . Acerca de la eliminación de la base de datos, cuando ejecuta el comando removedb le permite elegir si eliminar la base de datos antigua también: sugiero mantenerla porque no hay ganancia en eliminarla (las entradas de estado de prueba siempre se almacenan en leveldb, nunca van dentro de la antigua base de datos)

D:\Program Files\Geth>geth --datadir s:\Ethereum inspectINFO [11-11|19:19:15.793] Maximum peer count ETH=50 LES=0 total=50INFO [11-11|19:19:16.156] Set global gas cap cap=25000000INFO [11-11|19:19:16.160] Allocated cache and file handles database=s:\Ethereum\geth\chaindata cache=512.00MiB handles=8192INFO [11-11|19:19:27.022] Opened ancient database database=s:\Ethereum\geth\chaindata\ancientINFO [11-11|19:19:27.046] Disk storage enabled for ethash caches dir=s:\Ethereum\geth\ethash count=3INFO [11-11|19:19:27.051] Disk storage enabled for ethash DAGs dir=C:\Users\giuse\AppData\Local\Ethash count=2INFO [11-11|19:19:27.059] Loaded most recent local header number=11237906 hash="d8c4b8…c3f1e9" td=18641055599883751407245 age=53sINFO [11-11|19:19:27.069] Loaded most recent local full block number=11237906 hash="d8c4b8…c3f1e9" td=18641055599883751407245 age=53sINFO [11-11|19:19:27.079] Loaded most recent local fast block number=11237906 hash="d8c4b8…c3f1e9" td=18641055599883751407245 age=53sINFO [11-11|19:19:27.087] Loaded last fast-sync pivot marker number=10760885INFO [11-11|19:19:35.100] Inspecting database count=4996000 elapsed=8.002sINFO [11-11|19:19:43.108] Inspecting database count=10062000 elapsed=16.010sINFO [11-11|19:19:51.115] Inspecting database count=14730000 elapsed=24.017s...INFO [11-11|19:50:53.083] Inspecting database count=1821919000 elapsed=31m25.985sINFO [11-11|19:51:01.090] Inspecting database count=1828550000 elapsed=31m33.992sINFO [11-11|19:51:09.097] Inspecting database count=1835247000 elapsed=31m41.999s+-----------------+--------------------+------------+-----------+| DATABASE | CATEGORY | SIZE | ITEMS |+-----------------+--------------------+------------+-----------+| Key-Value store | Headers | 54.97 MiB | 100438 || Key-Value store | Bodies | 3.52 GiB | 98390 || Key-Value store | Receipt lists | 4.48 GiB | 98390 || Key-Value store | Difficulties | 7.11 MiB | 113813 || Key-Value store | Block number->hash | 6.04 MiB | 113813 || Key-Value store | Block hash->number | 439.41 MiB | 11237928 || Key-Value store | Transaction index | 30.13 GiB | 898783141 || Key-Value store | Bloombit index | 1.76 GiB | 5617664 || Key-Value store | Contract codes | 264.01 MiB | 44710 || Key-Value store | Trie nodes | 130.27 GiB | 880287080 || Key-Value store | Trie preimages | 2.98 GiB | 45170757 || Key-Value store | Account snapshot | 0.00 B | 0 || Key-Value store | Storage snapshot | 0.00 B | 0 || Key-Value store | Clique snapshots | 0.00 B | 0 || Key-Value store | Singleton metadata | 151.00 B | 5 || Ancient store | Headers | 4.75 GiB | 11147907 || Ancient store | Bodies | 108.13 GiB | 11147907 || Ancient store | Receipt lists | 50.63 GiB | 11147907 || Ancient store | Difficulties | 173.74 MiB | 11147907 || Ancient store | Block number->hash | 404.00 MiB | 11147907 || Light client | CHT trie nodes | 0.00 B | 0 || Light client | Bloom trie nodes | 0.00 B | 0 |+-----------------+--------------------+------------+-----------+| TOTAL | 337.97 GIB | |+-----------------+--------------------+------------+-----------+ERROR[11-11|19:51:16.769] Database contains unaccounted data size=126.40KiB count=2748

SISTEMA / SO RAM GB HORAS DE DISCO REINICIOS EN LÍNEA ENTRADAS ESTATALES ALCANZADAS ENTRADAS ESTATALES POR HORA HORA PARA INICIAR FAST SYNC BLOOM CUANDO SE REINICIE
Rock64 / Armbian 20.02.1 Bionic 4 HDD ~ 1.800 ~ 40469.380.958 ~ 100k (disminuyendo con el tiempo, este es el valor medio en los últimos 26 días) 3h16m29
Escritorio / Ubuntu 20.04 (WSL2 en Windows 10) 16 SSD 134 1578.598.409 ~ 815k 2h38m14
Escritorio / Windows 10 16 SSD 9 0 652.299.180 ~ 8.2M 30m28

@Neurone Gracias,

¿Se sincronizó la segunda configuración de prueba (Ubuntu de escritorio) en su tabla? ¿O solo se completó la sincronización de la última configuración (escritorio Windows 10)?

@Neurone okay gracias, última pregunta mía: ¿Qué te hace pensar que si vuelves a sincronizarlo sería ~ 700M? Y para el caso, 25 Gb liberados ... parece que podría ser parte del mismo cálculo. Según sus números (~ 652M 31 de agosto 880M en la actualidad), diría que el promedio de 3000 estados por bloque parece bastante preciso una vez que está completamente sincronizado. Pero como sugieres, es posible podar allí. Si estoy sincronizado rápidamente, aún puedo ponerme al día, si necesito superar los 3000 estados por bloque en este momento, entonces he estado atrasado durante 2 semanas.

@ sirnicolas21 Actualicé mi hoja de cálculo de mi publicación anterior para que pueda ver - actualmente ~ 710M

@ Duncan-Brain About ~ 700M es solo una _conjetura en el medio_ basada en estadísticas de otras personas, estadísticas tomadas incluso de este número: https://github.com/ethereum/go-ethereum/issues/15616. Parece que los más afortunados, es decir, https://github.com/ethereum/go-ethereum/issues/15616#issuecomment -720311292, se sincronizan completamente con ~ 620M de entradas, mientras que los menos afortunados alcanzan los ~ 800M. Con mi ~ 880M creo que soy un caso _extreme_ porque reinicié el proceso muchas veces y no quiero volver a hacerlo desde cero, así que digamos que me detendré a ~ 700M si reinicio todo el estado proceso de sincronización. Debido a que mis nodos trie toman ~ 130 Gb de disco (puede verlo en las estadísticas de inspección), significa que cada 1 millón de estados toma ~ 147Mb. Entonces, si guardo ~ 180 millones de estados (880-700), ganaré ~ 26 GB de disco.

Mi disco es un SSD de 512GB dedicado a Ethereum, la cadena crece relativamente lento y, si necesito más espacio, todavía tengo esos ~ 150GB de datos antiguos para mover fuera del SSD, así que por ahora prefiero mantener las cosas como están. hasta que sea realmente necesario.

Mi disco es un SSD de 512GB dedicado a Ethereum, la cadena crece relativamente lento y, si necesito más espacio, todavía tengo esos ~ 150GB de datos antiguos para mover fuera del SSD, así que por ahora prefiero mantener las cosas como están. hasta que sea realmente necesario.

@ rjl493456442 está trabajando en la poda, que podrá eliminar parte de la basura que no es necesaria.

Estadísticas de sincronización nuevas:

Mando:

geth --http

Hubo 640,610,869 entradas estatales
La sincronización completa tardó aproximadamente 37 horas
Toma 297G

¿Cómo hubo solo 640,610,869 entradas estatales hace 5 días?
Ya estoy en 698,492,860 y todavía no he terminado de sincronizar.

Las entradas estatales son diferentes para cada uno. @holiman explicó por qué es así aquí: https://github.com/ethereum/go-ethereum/issues/14647#issuecomment -682098181

Aquí otro hilo abierto donde puede encontrar estadísticas de verificación y experiencias de otros: https://github.com/ethereum/go-ethereum/issues/15616

Y aquí los datos de un nodo completo eth1 que terminé de sincronizar ayer después de 64 horas , procesando 650.634.632 entradas de estado , usando 282.75 GIB . Estadísticas completas a continuación.

Tenga en cuenta que durante la sincronización, la misma máquina estaba ejecutando un nodo de baliza Teku, por lo que el rendimiento podría haber sido mejor sin él.

CLAVE | VALOR
--- | ---
Sincronización rápida completa | 64 horas
Entradas de estado procesadas | 650.634.632
Almacenamiento utilizado | 282.75 GIB
OS | Ubuntu 20.04.1
Cliente | Geth / v1.9.24-estable-cc05b050 / linux-amd64 / go1.15.5
Máquina | MINISFORUM DeskMini UM300 Mini PC
Procesador | AMD Ryzen ™ 3 3300U, 4 núcleos / 4 subprocesos
Memoria | DDR4 de 8 GB de doble canal (mínimo 1 GB reservado para la tarjeta gráfica, por lo que la RAM real es de 7 GB )
Almacenamiento n. 1 | SSD SATA Kingston M.2 2280 de 256 GB _ (utilizado por Teku) _
Almacenamiento n. 2 | SSD SATA Crucial BX500 de 1 TB _ (utilizado por Geth) _
Conectividad | Ethernet de 1 Gb
ISP | Fastweb, Italia

./gethINFO [12-02|03:57:17.926] Starting Geth on Ethereum mainnet...INFO [12-02|03:57:17.927] Bumping default cache on mainnet provided=1024 updated=4096WARN [12-02|03:57:17.927] Sanitizing cache to Go's GC limits provided=4096 updated=2323INFO [12-02|03:57:17.934] Maximum peer count ETH=50 LES=0 total=50INFO [12-02|03:57:17.934] Smartcard socket not found, disabling err="stat /run/pcscd/pcscd.comm: no such file or directory"INFO [12-02|03:57:17.936] Set global gas cap cap=25000000INFO [12-02|03:57:17.936] Allocated trie memory caches clean=580.00MiB dirty=580.00MiB...INFO [12-02|03:57:18.015] Writing default main-net genesis blockINFO [12-02|03:57:18.279] Persisted trie from memory database nodes=12356 size=1.78MiB time=84.346878ms gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00BINFO [12-02|03:57:18.279] Initialised chain configuration config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 4370000 Constantinople: 7280000 Petersburg: 7280000 Istanbul: 9069000, Muir Glacier: 9200000, YOLO v2: <nil>, Engine: ethash}"...INFO [12-02|03:57:18.280] Initialising Ethereum protocol versions="[65 64 63]" network=1 dbversion=<nil>WARN [12-02|03:57:18.280] Upgrade blockchain database version from=<nil> to=8INFO [12-02|03:57:18.281] Loaded most recent local header number=0 hash="d4e567…cb8fa3" td=17179869184 age=51y7mo4wINFO [12-02|03:57:18.281] Loaded most recent local full block number=0 hash="d4e567…cb8fa3" td=17179869184 age=51y7mo4wINFO [12-02|03:57:18.281] Loaded most recent local fast block number=0 hash="d4e567…cb8fa3" td=17179869184 age=51y7mo4wINFO [12-02|03:57:18.281] Regenerated local transaction journal transactions=0 accounts=0INFO [12-02|03:57:18.298] Allocated fast sync bloom size=1.13GiBINFO [12-02|03:57:18.304] Starting peer-to-peer node instance=Geth/v1.9.24-stable-cc05b050/linux-amd64/go1.15.5...INFO [12-02|03:57:18.667] Initialized fast sync bloom items=12356 errorrate=0.000 elapsed=367.872ms...INFO [12-02|03:57:28.334] Block synchronisation started...INFO [12-02|03:57:35.319] Imported new state entries count=1152 elapsed=5.229ms processed=45201 pending=20345 trieretry=0 coderetry=0 duplicate=0 unexpected=0INFO [12-02|03:57:35.425] Imported new state entries count=1152 elapsed=4.800ms processed=46353 pending=20673 trieretry=0 coderetry=0 duplicate=0 unexpected=0INFO [12-02|03:57:35.751] Imported new state entries count=1536 elapsed=8.549ms processed=47889 pending=19409 trieretry=0 coderetry=0 duplicate=0 unexpected=0...INFO [12-04|20:52:06.008] Imported new state entries count=1996 elapsed=62.015ms processed=650631754 pending=9510 trieretry=0 coderetry=0 duplicate=126032 unexpected=765459INFO [12-04|20:52:06.239] Imported new state entries count=2191 elapsed=141.737ms processed=650633945 pending=2499 trieretry=0 coderetry=0 duplicate=126032 unexpected=765459INFO [12-04|20:52:10.981] Imported new state entries count=687 elapsed=45.228ms processed=650634632 pending=0 trieretry=0 coderetry=0 duplicate=126032 unexpected=765459INFO [12-04|20:52:10.998] Committed new head block number=11388325 hash="4dfe95…2574b4"INFO [12-04|20:52:11.049] Deallocated fast sync bloom items=646967270 errorrate=0.006...INFO [12-04|20:52:11.049] Deallocated fast sync bloom items=646967270 errorrate=0.006...INFO [12-04|20:58:18.180] Fast sync complete, auto disabling

./geth inspectINFO [12-04|22:37:47.671] Maximum peer count ETH=50 LES=0 total=50INFO [12-04|22:37:47.671] Smartcard socket not found, disabling err="stat /run/pcscd/pcscd.comm: no such file or directory"INFO [12-04|22:37:47.672] Set global gas cap cap=25000000...INFO [12-04|22:37:52.507] Loaded most recent local header number=11388879 hash="0ec041…573550" td=19169271088158317937607 age=3m28sINFO [12-04|22:37:52.507] Loaded most recent local full block number=11388879 hash="0ec041…573550" td=19169271088158317937607 age=3m28sINFO [12-04|22:37:52.507] Loaded most recent local fast block number=11388879 hash="0ec041…573550" td=19169271088158317937607 age=3m28sINFO [12-04|22:37:52.510] Loaded last fast-sync pivot marker number=11388325INFO [12-04|22:38:00.533] Inspecting database count=10557000 elapsed=8.000sINFO [12-04|22:38:08.533] Inspecting database count=21006000 elapsed=16.000sINFO [12-04|22:38:16.533] Inspecting database count=31660000 elapsed=24.000s...INFO [12-04|22:52:30.881] Inspecting database count=1561224000 elapsed=14m38.348sINFO [12-04|22:52:38.881] Inspecting database count=1573276000 elapsed=14m46.348sINFO [12-04|22:52:46.881] Inspecting database count=1581359000 elapsed=14m54.348s+-----------------+--------------------+------------+-----------+| DATABASE | CATEGORY | SIZE | ITEMS |+-----------------+--------------------+------------+-----------+| Key-Value store | Headers | 49.31 MiB | 90033 || Key-Value store | Bodies | 3.28 GiB | 90033 || Key-Value store | Receipt lists | 4.08 GiB | 90033 || Key-Value store | Difficulties | 5.66 MiB | 99853 || Key-Value store | Block number->hash | 4.68 MiB | 99771 || Key-Value store | Block hash->number | 445.31 MiB | 11388911 || Key-Value store | Transaction index | 31.01 GiB | 924916880 || Key-Value store | Bloombit index | 1.80 GiB | 5693440 || Key-Value store | Contract codes | 1.59 GiB | 333905 || Key-Value store | Trie nodes | 71.08 GiB | 647171117 || Key-Value store | Trie preimages | 8.82 MiB | 132275 || Key-Value store | Account snapshot | 0.00 B | 0 || Key-Value store | Storage snapshot | 0.00 B | 0 || Key-Value store | Clique snapshots | 0.00 B | 0 || Key-Value store | Singleton metadata | 151.00 B | 5 || Ancient store | Headers | 4.83 GiB | 11298879 || Ancient store | Bodies | 111.38 GiB | 11298879 || Ancient store | Receipt lists | 52.63 GiB | 11298879 || Ancient store | Difficulties | 176.19 MiB | 11298879 || Ancient store | Block number->hash | 409.47 MiB | 11298879 || Light client | CHT trie nodes | 0.00 B | 0 || Light client | Bloom trie nodes | 0.00 B | 0 |+-----------------+--------------------+------------+-----------+| TOTAL | 282.75 GIB | |+-----------------+--------------------+------------+-----------+ERROR[12-04|22:52:52.717] Database contains unaccounted data size=128.10KiB count=2785

¿Las entradas de mi estado parecen ser mucho más largas de lo que informan otras personas?

Actualmente (después de una semana aún sin sincronizar):

Dec 10 10:14:20 vmi480454.contaboserver.net geth[422]: INFO [12-10|10:14:20.382] Imported new state entries count=384 elapsed="145.832µs" processed=745635339 pending=115802 trieretry=0 coderetry=0 duplicate=492 unexpected=34366

| DATABASE | CATEGORY | SIZE | ITEMS |+-----------------+--------------------+------------+-----------+| Key-Value store | Headers | 215.65 MiB | 394004 || Key-Value store | Bodies | 14.00 GiB | 393879 || Key-Value store | Receipt lists | 17.90 GiB | 393879 || Key-Value store | Difficulties | 21.23 MiB | 404356 || Key-Value store | Block number->hash | 17.08 MiB | 404331 || Key-Value store | Block hash->number | 447.19 MiB | 11436819 || Key-Value store | Transaction index | 31.28 GiB | 933024549 || Key-Value store | Bloombit index | 1.80 GiB | 5697536 || Key-Value store | Contract codes | 1.59 GiB | 333673 || Key-Value store | Trie nodes | 83.95 GiB | 679328402 || Key-Value store | Trie preimages | 547.13 KiB | 8893 || Key-Value store | Account snapshot | 0.00 B | 0 || Key-Value store | Storage snapshot | 0.00 B | 0 || Key-Value store | Clique snapshots | 0.00 B | 0 || Key-Value store | Singleton metadata | 151.00 B | 5 || Ancient store | Headers | 4.70 GiB | 11042816 || Ancient store | Bodies | 105.90 GiB | 11042816 || Ancient store | Receipt lists | 49.25 GiB | 11042816 || Ancient store | Difficulties | 172.04 MiB | 11042816 || Ancient store | Block number->hash | 400.19 MiB | 11042816 || Light client | CHT trie nodes | 0.00 B | 0 || Light client | Bloom trie nodes | 0.00 B | 0 |+-----------------+--------------------+------------+-----------+| TOTAL | 311.62 GIB | |+-----------------+--------------------+------------+-----------+ERROR[12-12|08:25:16.301] Database contains unaccounted data size=128.19KiB count=2787

¿Fue útil esta página

0 / 5 - 0 calificaciones