No consigue arrancar completamente el proceso geth desde aproximadamente las 13:50. N

Lleva lanzado desde las 11:00 sin indicarle el puerto rpc. <div class="snippet-cli

Problemas arranque geth nodo Amtega about alastria-node HOT 6 CLOSED

sistemasamtega commented on September 10, 2024

Problemas arranque geth nodo Amtega

from alastria-node.

Comments (6)

alejandroalffer commented on September 10, 2024

Hola! Prueba a añadir al linea de comando de arranque de geth este argumento:

--cache 1024

Por favor, testea también el espacio en disco, con un "df -h", por ejemplo

from alastria-node.

sistemasamtega commented on September 10, 2024

Ya se estaba llamando con ese argumento de cache, como se puede ver con ps.
Hemos reducido el espacio de logs en unos GB, pero parece que hay espacio de sobra:

root@prd-blockchain-0001:~# df -h
Filesystem                   Size  Used Avail Use% Mounted on
udev                         7,9G     0  7,9G   0% /dev
tmpfs                        1,6G  9,0M  1,6G   1% /run
/dev/mapper/vg_00-lv_root     12G  5,0G  5,5G  48% /
tmpfs                        7,9G     0  7,9G   0% /dev/shm
tmpfs                        5,0M     0  5,0M   0% /run/lock
tmpfs                        7,9G     0  7,9G   0% /sys/fs/cgroup
/dev/sda1                    922M  110M  750M  13% /boot
/dev/mapper/vg_01-lv_data     99G   77G   18G  82% /data
/dev/mapper/vg_00-lv_home    4,5G  9,4M  4,3G   1% /home
/dev/mapper/vg_00-lv_tmp     1,8G  2,9M  1,7G   1% /tmp
/dev/mapper/vg_00-lv_varlog  9,1G   44M  8,6G   1% /var/log
tmpfs                        1,6G     0  1,6G   0% /run/user/1001


root@prd-blockchain-0001:~# du -h --max-depth=1 /data/
6,1M    /data/alastria-node.BACKUP
4,0K    /data/.cache
77G     /data/alastria
16K     /data/lost+found
6,2M    /data/alastria-node
77G     /data/
root@prd-blockchain-0001:~# du -h --max-depth=1 /data/alastria
59G     /data/alastria/data
18G     /data/alastria/logs
129M    /data/alastria/workspace
77G     /data/alastria
root@prd-blockchain-0001:~# du -h --max-depth=1 /data/alastria/data/
20K     /data/alastria/data/keystore
28K     /data/alastria/data/constellation
59G     /data/alastria/data/geth
59G     /data/alastria/data/
root@prd-blockchain-0001:~# du -h --max-depth=1 /data/alastria/data/geth
20K     /data/alastria/data/geth/lightchaindata
152K    /data/alastria/data/geth/nodes
59G     /data/alastria/data/geth/chaindata
59G     /data/alastria/data/geth


root@prd-blockchain-0001:/data/alastria/logs# df -h
Filesystem                   Size  Used Avail Use% Mounted on
udev                         7,9G     0  7,9G   0% /dev
tmpfs                        1,6G  9,0M  1,6G   1% /run
/dev/mapper/vg_00-lv_root     12G  5,0G  5,5G  48% /
tmpfs                        7,9G     0  7,9G   0% /dev/shm
tmpfs                        5,0M     0  5,0M   0% /run/lock
tmpfs                        7,9G     0  7,9G   0% /sys/fs/cgroup
/dev/sda1                    922M  110M  750M  13% /boot
/dev/mapper/vg_01-lv_data     99G   68G   26G  73% /data
/dev/mapper/vg_00-lv_home    4,5G  9,4M  4,3G   1% /home
/dev/mapper/vg_00-lv_tmp     1,8G  2,9M  1,7G   1% /tmp
/dev/mapper/vg_00-lv_varlog  9,1G  1,2G  7,5G  14% /var/log
tmpfs                        1,6G     0  1,6G   0% /run/user/1001

Tras lo cual he reiniciado de nuevo el servidor, pero lleva desde las 8:20 igual que en los casos anteriores.

Me había olvidado de comentar que ya nos surgió un problema similar el 29 de diciembre y se solucionó automáticamente el 31, tras varias ejecuciones del proceso geth, que lanzamos con cron cada minuto si detecta que no hay este proceso en ejecución. En este caso suposimos que el problema se debía a consultas demasiado grandes, ya que en los logs se observaban errores como

INFO [12-29|17:54:23.064] Imported new chain segment               blocks=1931 txs=22  mgas=2.090   elapsed=8.127s    mgasps=0.257  number=57378771 hash=96ab15…2d49eb age=1w4d4h   cache=3.69mB
fatal error: runtime: out of memory

runtime stack:
runtime.throw(0x1152292, 0x16)
        /usr/local/go/src/runtime/panic.go:605 +0x95
runtime.sysMap(0xccbb010000, 0x10000000, 0x0, 0x1e91c18)
        /usr/local/go/src/runtime/mem_linux.go:216 +0x1d0
runtime.(*mheap).sysAlloc(0x1e78160, 0x10000000, 0x70029e189)
        /usr/local/go/src/runtime/malloc.go:470 +0xd7
runtime.(*mheap).grow(0x1e78160, 0x8000, 0x0)
        /usr/local/go/src/runtime/mheap.go:887 +0x60
runtime.(*mheap).allocSpanLocked(0x1e78160, 0x8000, 0x1e91c28, 0x7f2f48c1dea0)
        /usr/local/go/src/runtime/mheap.go:800 +0x334
runtime.(*mheap).alloc_m(0x1e78160, 0x8000, 0xc496700101, 0xc42023a780)
        /usr/local/go/src/runtime/mheap.go:666 +0x118
runtime.(*mheap).alloc.func1()
        /usr/local/go/src/runtime/mheap.go:733 +0x4d
runtime.systemstack(0x7f2f4affce10)
        /usr/local/go/src/runtime/asm_amd64.s:360 +0xab
runtime.(*mheap).alloc(0x1e78160, 0x8000, 0x7f2f4a010101, 0x42a224)

from alastria-node.

alejandroalffer commented on September 10, 2024

¿Sería posible arrancar geth sin puerto de aplicaciones?

Al menos hasta que sincronice la cadena, y comprobar que es geth es estable, antes de probar otras soluciones. Ya sabes... eliminar de la línea de argumentos aquellos que tengan que ver con el rcp, o bien hacer que escuche en un puerto diferente al tcp/22000: sólo temporalmente... dejar que sincronice la DLT sin aplicaciones, y vemos si es estable.

Creo que el problema puede venir por ahí: geth no se lleva bien con demasiadas trasacciones/conexiones concurrentes vía RCP (según mi experiencia, 3-4 simultáneas como mucho). Otros socios usan WebSockets y se obtiene mayor throughput, pero seguirá siendo un punto de fallo si no implementas un control... vía colas, o similar.

También vigila que tengas delante del RPC un firewall, dado que está abierto al 0.0.0.0

Seguimos comentando!

from alastria-node.

sistemasamtega commented on September 10, 2024

Lleva lanzado desde las 11:00 sin indicarle el puerto rpc.

root@prd-blockchain-0001:/data/alastria-node/scripts# ps aux|grep geth |grep -v grep
blockch+   7186  103  8.0 1880888 1325256 ?     Sl   11:00   0:42 geth --datadir /data/alastria/data --networkid 83584648538 --identity REG_AMTEGA_Telsius_4_8_00 --permissioned --rpcvhosts=prd-blockchain-0001.xunta.local --rpc --rpcaddr 0.0.0.0 --rpcapi admin,db,eth,debug,miner,net,shh,txpool,personal,web3,quorum,istanbul --port 21000 --cache 1024 --istanbul.requesttimeout 10000 --ethstats REG_AMTEGA_Telsius_4_8_00:[email protected]:80 --verbosity 3 --vmdebug --emitcheckpoints --targetgaslimit 8000000 --syncmode full --gcmode full --vmodule consensus/istanbul/core/core.go=5 --nodiscover

Se ha permitido el tráfico tcp de 80 y 443 con iptables, pero se ven paquetes al hacer los tcpdump en ninguno de los puertos.
El log sigue sin pasar del setting new local account.

from alastria-node.

alejandroalffer commented on September 10, 2024

Hola! Qué devuelve la consola? Sigue dando el problema de memoria?

Contáctame por Slack y revisamos juntos el nodo

El puerto 80 y 443 se usan para acceder a RPC a través de un proxy ngnix (puedes ver el repositorio https://github.com/alastria/alastria-access-point) Se trata de una funcionalidad poco mantenida, pero interesante: permite filtrar la familia de aplicaciones que quieras que accedan a RPC/WS de Geth

from alastria-node.

sistemasamtega commented on September 10, 2024

Se contactó por Slack y se examinó la situación en detalle.
Tras estar ejecutando varios días el proceso geth de forma interrumpida se terminó sincronizando de nuevo el siguiente bloque tras 30h de ejecución del proceso de forma ininterrumpida. Si esto no hubiera funcionado seguramente habríamos tenido que reconstruír la base de datos (60GB).
Actualmente lleva 8 días ejecutándose de forma ininterrumpida, por lo que cerramos el issue.

from alastria-node.

Problemas arranque geth nodo Amtega about alastria-node HOT 6 CLOSED

Comments (6)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent