erección
v2.60.10
Documentación: erigon.gitbook.io Blog: erigon.substack.com Twitter: x.com/ErigonEth
Erigon es una implementación de Ethereum (capa de ejecución con capa de consenso integrable), en la frontera de la eficiencia. Nodo de archivo de forma predeterminada.
erigoncaplinbeaconAPIsharedother puertossystemdhtop muestra un uso incorrecto de la memoria Valores predeterminados importantes : Erigon es un nodo de archivo de forma predeterminada: use --prune.mode si es necesario, hágalo más pequeño (no se permite cambiarlo después del primer inicio).
In-depth links are marked by the microscope sign (?)
RAM: >=32 GB, Golang >= 1,22; GCC 10+ o Sonido metálico; En Linux: núcleo > v4. Arquitectura de 64 bits.
SSD o NVMe. No recomiendo HDD: en HDD Erigon siempre permanecerá N bloques detrás de la punta de la cadena, pero no se quedará atrás. Tenga en cuenta que el rendimiento de la SSD se deteriora cuando está cerca de su capacidad. CloudDrives (como gp3): la ejecución de bloques es lenta en unidades de red en la nube
? Más detalles sobre el tamaño del directorio de datos de Erigon3
? Más detalles sobre qué tipo de datos se almacenan aquí
Notas de la versión y binarios
Compile la última versión (esto será adecuado para la mayoría de los usuarios que solo desean ejecutar un nodo):
git clone --branch release/ < x.xx > --single-branch https://github.com/erigontech/erigon.git
cd erigon
make erigon
./build/bin/erigon Aumente la velocidad de descarga en --torrent.download.rate=20mb . ? See Downloader docs
Utilice --datadir para elegir dónde almacenar los datos.
Utilice --chain=gnosis para Gnosis Chain, --chain=bor-mainnet para Polygon Mainnet y --chain=amoy para Polygon Amoy. Para Gnosis Chain necesita un cliente de Consensus Layer junto con Erigon (https://docs.gnosischain.com/category/step--3---run-consensus-client).
Al ejecutar make help se enumerarán y describirán los comandos de conveniencia disponibles en el Makefile.
datadir
chaindata # "Recently-updated Latest State", "Recent History", "Recent Blocks"
snapshots # contains `.seg` files - it's old blocks
domain # Latest State
history # Historical values
idx # InvertedIndices: can search/filtering/union/intersect them - to find historical data. like eth_getLogs or trace_transaction
accessors # Additional (generated) indices of history - have "random-touch" read-pattern. They can serve only `Get` requests (no search/filters).
txpool # pending transactions. safe to remove.
nodes # p2p peers. safe to remove.
temp # used to sort data bigger than RAM. can grow to ~100gb. cleaned at startup.
# There is 4 domains: account, storage, code, commitment Si puede permitirse almacenar datadir en 1 nvme-raid, genial. Si no es posible, es posible almacenar el historial en un disco económico.
# place (or ln -s) `datadir` on slow disk. link some sub-folders to fast (low-latency) disk.
# Example: what need link to fast disk to speedup execution
datadir
chaindata # link to fast disk
snapshots
domain # link to fast disk
history
idx
accessors
temp # buffers to sort data >> RAM. sequential-buffered IO - is slow-disk-friendly
# Example: how to speedup history access:
# - go step-by-step - first try store `accessors` on fast disk
# - if speed is not good enough: `idx`
# - if still not enough: `history` # eth-mainnet - archive - April 2024
du -hsc /erigon/ *
6G /erigon/caplin
50G /erigon/chaindata
1.8T /erigon/snapshots
1.9T total
du -hsc /erigon/snapshots/ *
100G /erigon/snapshots/accessor
240G /erigon/snapshots/domain
260G /erigon/snapshots/history
410G /erigon/snapshots/idx
1.7T /erigon/snapshots # bor-mainnet - archive - Jun 2024
du -hsc /erigon/ *
160M /erigon/bor
50G /erigon/chaindata
3.7T /erigon/snapshots
3.8T total
du -hsc /erigon/snapshots/ *
260G /erigon-data/snapshots/accessor
850G /erigon-data/snapshots/domain
650G /erigon-data/snapshots/history
1.4T /erigon-data/snapshots/idx
4.1T /erigon/snapshotsdebug_getModifiedAccountsByNumber lo devuelve--internalcl está habilitado de forma predeterminada. para deshabilitar el uso --externalcl .chaindata pesan menos de 15gb . Está bien rm -rf chaindata . (para evitar el crecimiento: recomiendo --batchSize <= 1G )--prune flags cambiado : consulte --prune.mode (predeterminado: archive , completo: full , EIP-4444: minimal )--sync.loop.block.limit=5_000 habilitado de forma predeterminadaBanderas:
verbositylog.console.verbosity (alias superior para verbosity )log.jsonlog.console.json (alias de log.json )log.dir.pathlog.dir.prefixlog.dir.verbositylog.dir.json Para iniciar sesión solo en stdout/stderr, se puede usar el indicador --verbosity (o log.console.verbosity ) para proporcionar un valor int que especifique el nivel de registro de salida más alto:
LvlCrit = 0
LvlError = 1
LvlWarn = 2
LvlInfo = 3
LvlDebug = 4
LvlTrace = 5
Para configurar un directorio de salida para que los registros se recopilen en el disco, configure --log.dir.path Si desea cambiar el nombre del archivo producido desde erigon también debe configurar el indicador --log.dir.prefix a un nombre alternativo. La bandera --log.dir.verbosity también está disponible para controlar la detalle de este registro, con el mismo valor int que el anterior, o el valor de cadena, por ejemplo, 'debug' o 'info'. La detalle por defecto es 'depurar' (4), para el registro del disco.
El formato de registro se puede configurar en json mediante el uso de los indicadores booleanos log.json o log.console.json , o para la salida del disco --log.dir.json .
Erigon por defecto es una solución "todo en uno binario", pero es posible iniciar TxPool como procesos separados. Lo mismo ocurre con: capa JSON RPC (RPCDaemon), capa p2p (Sentry), capa de descarga de historial (Downloader), consenso. No inicie servicios como procesos separados a menos que tenga una razón clara para ello: limitación de recursos, escala, reemplazo por su propia implementación, seguridad. Cómo iniciar los servicios de Erigon como procesos separados, consulte en docker-compose.yml. Cada servicio tiene su propio archivo ./cmd/*/README.md . Blog de Erigon.
Consenso incorporado para Ethereum Mainnet, Sepolia, Holesky, Gnosis. Para utilizar la capa de consenso externa: --externalcl .
Si quieres probar Erigon: una buena opción es empezar a sincronizar una de las redes de prueba públicas, Holesky (o Amoy). Se sincroniza mucho más rápido y no ocupa tanto espacio en disco:
git clone https://github.com/erigontech/erigon.git
cd erigon
make erigon
./build/bin/erigon --datadir= < your_datadir > --chain=holesky --prune.mode=full Tenga en cuenta la opción --datadir que le permite almacenar archivos Erigon en una ubicación no predeterminada. El nombre del directorio --datadir no tiene que coincidir con el nombre de la cadena en --chain .
La producción de bloques es totalmente compatible con Ethereum y Gnosis Chain. Todavía es experimental para Polygon.
Puede configurar los indicadores de Erigon a través de un archivo de configuración TOML con el indicador --config . Los indicadores establecidos en el archivo de configuración se pueden sobrescribir escribiéndolos directamente en la línea de comando de Erigon.
./build/bin/erigon --config ./config.toml --chain=sepolia
Suponiendo que tenemos chain : "mainnet" en nuestro archivo de configuración, al agregar --chain=sepolia se permite sobrescribir la bandera dentro del archivo de configuración toml y se establece la cadena en sepolia.
datadir = ' your datadir '
port = 1111
chain = " mainnet "
http = true
"private.api.addr" = " localhost:9090 "
"http.api" = [ " eth " , " debug " , " net " ]Erigon se puede utilizar como capa de ejecución (EL) para clientes de capa de consenso (CL). La configuración predeterminada está bien.
Si su cliente CL está en un dispositivo diferente, agregue --authrpc.addr 0.0.0.0 (La API del motor escucha en el host local de forma predeterminada), así como --authrpc.vhosts donde any .
Para establecer una conexión segura entre la capa de consenso y la capa de ejecución, se genera automáticamente una clave secreta JWT.
La clave secreta JWT estará presente en el directorio de datos de forma predeterminada con el nombre jwt.hex y su ruta se puede especificar con la bandera --authrpc.jwtsecret .
Esta información también debe especificarse en la capa de consenso para poder establecer la conexión correctamente. Puede encontrar más información aquí.
Una vez que Erigon se esté ejecutando, debe apuntar su cliente CL a localhost o la dirección IP del dispositivo que ejecuta Erigon, y también apuntar a la ruta secreta JWT creada por Erigon.
Caplin es un cliente de consenso de validación completo como Prysm, Lighthouse, Teku, Nimbus y Lodestar. Su objetivo es:
La razón principal por la que se desarrolló una nueva capa de consenso es experimentar con los posibles beneficios que podría conllevar. Por ejemplo, la API del motor no funciona bien con Erigon. La API del motor envía datos un bloque a la vez, lo que no se adapta al funcionamiento de Erigon. Erigon está diseñado para manejar muchos bloques simultáneamente y necesita ordenar y procesar datos de manera eficiente. Por lo tanto, sería mejor para Erigon manejar los bloques de forma independiente en lugar de depender de la API del motor.
Caplin está habilitado de forma predeterminada. para deshabilitarlo y habilitar la API del motor, use el indicador --externalcl . a partir de ese momento, ya no será necesaria una capa de consenso externa.
Caplin también tiene un modo de archivo para estados y bloques históricos. se puede habilitar a través del indicador --caplin.archive . Para habilitar la API Beacon de caplin, se debe agregar la bandera --beacon.api= . por ejemplo: --beacon.api=beacon,builder,config,debug,node,validator,lighthouse habilitará todos los puntos finales. **NOTA: Caplin no está listo para apostar, por lo que los puntos finales de agregación aún deben implementarse. Además, habilitar la API Beacon generará un uso de RAM 6 GB mayor.
Defina 6 indicadores para evitar conflictos: --datadir --port --http.port --authrpc.port --torrent.port --private.api.addr . Ejemplo de múltiples cadenas en una misma máquina:
# mainnet
./build/bin/erigon --datadir="" --chain=mainnet --port=30303 --http.port=8545 --authrpc.port=8551 --torrent.port=42069 --private.api.addr=127.0.0.1:9090 --http --ws --http.api=eth,debug,net,trace,web3,erigon
# sepolia
./build/bin/erigon --datadir="" --chain=sepolia --port=30304 --http.port=8546 --authrpc.port=8552 --torrent.port=42068 --private.api.addr=127.0.0.1:9091 --http --ws --http.api=eth,debug,net,trace,web3,erigon
Cita tu camino si tiene espacios.
? Detailed explanation is DEV_CHAIN.
Con un buen ancho de banda de red, EthereumMainnet FullNode se sincroniza en 3 horas: OtterSync puede sincronizarse
Almacenamiento plano KV. Erigon utiliza una base de datos de valores clave y almacena cuentas y almacenamiento de una manera sencilla.
? See our detailed DB walkthrough here.
Preprocesamiento . Para algunas operaciones, Erigon utiliza archivos temporales para preprocesar los datos antes de insertarlos en la base de datos principal. Eso reduce la amplificación de escritura y las inserciones de bases de datos son mucho más rápidas.
? See our detailed ETL explanation here.
estado simple
Cuentas individuales/trial estatal . Erigon utiliza un único Merkle Trie tanto para las cuentas como para el almacenamiento.
? Staged Sync Readme
La mayoría de los componentes de Erigon (txpool, rpcdaemon, descargador de instantáneas, sentry, ...) pueden funcionar dentro de Erigon y como procesos independientes en el mismo servidor (u otro servidor). Ejemplo:
make erigon rpcdaemon
./build/bin/erigon --datadir=/my --http=false
# To run RPCDaemon as separated process: use same `--datadir` as Erigon
./build/bin/rpcdaemon --datadir=/my --http.api=eth,erigon,web3,net,debug,trace,txpool --ws--rpc.batch.concurrency , --rpc.batch.limit , --db.read.concurrency--http.compression , --ws.compression ? See RPC-Daemon docs
docker compose up prometheus grafana , documentos detallados.
# please use git branch name (or commit hash). don't use git tags
go mod edit -replace github.com/erigontech/erigon-lib=github.com/erigontech/erigon/erigon-lib@5498f854e44df5c8f0804ff4f0747c0dec3caad5
go get github.com/erigontech/erigon@main
go mod tidy
erigon| Componente | Puerto | Protocolo | Objetivo | debe exponer |
|---|---|---|---|---|
| motor | 9090 | tcp | Servidor gRPC | Privado |
| motor | 42069 | TCP y UDP | Sincronización instantánea (Bittorrent) | Público |
| motor | 8551 | tcp | API del motor (autenticación JWT) | Privado |
| centinela | 30303 | TCP y UDP | emparejamiento eth/68 | Público |
| centinela | 30304 | TCP y UDP | emparejamiento eth/67 | Público |
| centinela | 9091 | tcp | Conexiones entrantes de gRPC | Privado |
| rpcdaemon | 8545 | tcp | HTTP, WebSockets y GraphQL | Privado |
Normalmente, 30303 y 30304 están expuestos a Internet para permitir conexiones de intercambio de tráfico entrantes. 9090 está expuesto sólo internamente para rpcdaemon u otras conexiones (por ejemplo, rpcdaemon -> erigon). El puerto 8551 (autenticado por JWT) está expuesto solo internamente para consultas JSON-RPC de Engine API desde el nodo Consensus Layer.
caplin| Componente | Puerto | Protocolo | Objetivo | debe exponer |
|---|---|---|---|---|
| centinela | 4000 | UDP | Mirando | Público |
| centinela | 4001 | tcp | Mirando | Público |
Para configurar los puertos, utilice:
--caplin.discovery.addr value Address for Caplin DISCV5 protocol (default: "127.0.0.1")
--caplin.discovery.port value Port for Caplin DISCV5 protocol (default: 4000)
--caplin.discovery.tcpport value TCP Port for Caplin DISCV5 protocol (default: 4001)
beaconAPI| Componente | Puerto | Protocolo | Objetivo | debe exponer |
|---|---|---|---|---|
| DESCANSAR | 5555 | tcp | DESCANSAR | Público |
shared| Componente | Puerto | Protocolo | Objetivo | debe exponer |
|---|---|---|---|---|
| todo | 6060 | tcp | pprof | Privado |
| todo | 6061 | tcp | métrica | Privado |
Se pueden habilitar indicadores opcionales que habiliten pprof o métricas (o ambos). Utilice --help con el binario para obtener más información.
other puertos Reservado para uso futuro: puertos gRPC : motor de consenso 9092 , descargador de instantáneas 9093 , TxPool 9094
0.0.0.0/8 "This" Network RFC 1122, Section 3.2.1.3
10.0.0.0/8 Private-Use Networks RFC 1918
100.64.0.0/10 Carrier-Grade NAT (CGN) RFC 6598, Section 7
127.16.0.0/12 Private-Use Networks RFC 1918
169.254.0.0/16 Link Local RFC 3927
172.16.0.0/12 Private-Use Networks RFC 1918
192.0.0.0/24 IETF Protocol Assignments RFC 5736
192.0.2.0/24 TEST-NET-1 RFC 5737
192.88.99.0/24 6to4 Relay Anycast RFC 3068
192.168.0.0/16 Private-Use Networks RFC 1918
198.18.0.0/15 Network Interconnect
Device Benchmark Testing RFC 2544
198.51.100.0/24 TEST-NET-2 RFC 5737
203.0.113.0/24 TEST-NET-3 RFC 5737
224.0.0.0/4 Multicast RFC 3171
240.0.0.0/4 Reserved for Future Use RFC 1112, Section 4
255.255.255.255/32 Limited Broadcast RFC 919, Section 7
RFC 922, Section 7
Lo mismo en la sintaxis de IpTables
systemd Ejecutar erigon desde build/bin como un usuario independiente puede producir un error:
error while loading shared libraries: libsilkworm_capi.so: cannot open shared object file: No such file or directory La biblioteca debe instalarse para otro usuario usando make DIST= . Podrías usar $HOME/erigon o /opt/erigon como ruta de instalación, por ejemplo:
make DIST=/opt/erigon installkill -SIGUSR1 , obtener seguimiento y detener: kill -6 --pprof y ejecútelogo tool pprof -png http://127.0.0.1:6060/debug/pprof/profile?seconds=20 > cpu.png--pprof y ejecútelogo tool pprof -inuse_space -png http://127.0.0.1:6060/debug/pprof/heap > mem.png ? Detailed explanation is here.
Docker utiliza el usuario erigon con UID/GID 1000 (por razones de seguridad). Puede ver la creación de este usuario en Dockerfile. Se puede solucionar otorgando al usuario del host la propiedad de la carpeta, donde el UID/GID del usuario del host es el mismo que el UID/GID del usuario de la ventana acoplable (1000). Más detalles en la publicación
--txpool.nolocals=trueadmin en la lista --http.api--http.corsdomain="*" es una mala práctica: establezca el nombre de host o la IP exactos--rpc.batch.concurrency , --rpc.batch.limithttps://github.com/mathMakesArt/Erigon-on-RPi-4
Docker permite construir y ejecutar Erigon a través de contenedores. Esto alivia la necesidad de instalar dependencias de compilación en el sistema operativo host.
El UID/GID del usuario debe sincronizarse entre el sistema operativo host y el contenedor para que los archivos se escriban con el permiso correcto.
Es posible que desee configurar un usuario/grupo dedicado en el sistema operativo host, en cuyo caso los siguientes destinos make estarán disponibles.
# create "erigon" user
make user_linux
# or
make user_macos Hay un archivo .env.example en la raíz del repositorio.
DOCKER_UID : el UID del usuario de DockerDOCKER_GID : el GID del usuario de DockerXDG_DATA_HOME : el directorio de datos que se montará en los contenedores de la ventana acoplable.Si no se especifica, el UID/GID utilizará el usuario actual.
Una buena opción para XDG_DATA_HOME es utilizar el directorio ~erigon/.ethereum creado por los objetivos auxiliares make user_linux o make user_macos .
Verifique los permisos: en todos los casos, XDG_DATA_HOME (especificado o predeterminado) debe poder escribirse mediante el UID/GID del usuario en la ventana acoplable, lo cual será determinado por DOCKER_UID y DOCKER_GID en el momento de la compilación. Si el inicio de una compilación o servicio falla debido a permisos, verifique que todos los directorios, UID y GID controlados por estas variables de entorno sean correctos.
Se inicia el siguiente comando: Erigon en el puerto 30303, rpcdaemon en el puerto 8545, prometheus en el puerto 9090 y grafana en el puerto 3000.
#
# Will mount ~/.local/share/erigon to /home/erigon/.local/share/erigon inside container
#
make docker-compose
#
# or
#
# if you want to use a custom data directory
# or, if you want to use different uid/gid for a dedicated user
#
# To solve this, pass in the uid/gid parameters into the container.
#
# DOCKER_UID: the user id
# DOCKER_GID: the group id
# XDG_DATA_HOME: the data directory (default: ~/.local/share)
#
# Note: /preferred/data/folder must be read/writeable on host OS by user with UID/GID given
# if you followed above instructions
#
# Note: uid/gid syntax below will automatically use uid/gid of running user so this syntax
# is intended to be run via the dedicated user setup earlier
#
DOCKER_UID= $( id -u ) DOCKER_GID= $( id -g ) XDG_DATA_HOME=/preferred/data/folder DOCKER_BUILDKIT=1 COMPOSE_DOCKER_CLI_BUILD=1 make docker-compose
#
# if you want to run the docker, but you are not logged in as the $ERIGON_USER
# then you'll need to adjust the syntax above to grab the correct uid/gid
#
# To run the command via another user, use
#
ERIGON_USER=erigon
sudo -u ${ERIGON_USER} DOCKER_UID= $( id -u ${ERIGON_USER} ) DOCKER_GID= $( id -g ${ERIGON_USER} ) XDG_DATA_HOME= ~ ${ERIGON_USER} /.ethereum DOCKER_BUILDKIT=1 COMPOSE_DOCKER_CLI_BUILD=1 make docker-composeMakefile crea los directorios iniciales para erigon, prometheus y grafana. El espacio de nombres PID se comparte entre erigon y rpcdaemon, que es necesario para abrir la base de datos de Erigon desde otro proceso (RPCDaemon en modo local). Ver: https://github.com/erigontech/erigon/pull/2392/files
Si la instalación de su ventana acoplable requiere que el demonio de la ventana acoplable se ejecute como root (que es lo predeterminado), deberá anteponer el comando anterior con sudo . Sin embargo, a veces se recomienda ejecutar Docker (y por lo tanto sus contenedores) como usuario no root por razones de seguridad. Para obtener más información sobre cómo hacer esto, consulte este artículo.
correo
--sync.loop.block.limit=10_000SNAPSHOT_MADV_RND=false vmtouch -vdlw /mnt/erigon/snapshots/domain/*bt
ls /mnt/erigon/snapshots/domain/*.kv | parallel vmtouch -vdlw
# if it failing with "can't allocate memory", try:
sync && sudo sysctl vm.drop_caches=3
echo 1 > /proc/sys/vm/compact_memory
Los usuarios de Windows pueden ejecutar erigon de 3 formas posibles:
Cree archivos binarios ejecutables de forma nativa para Windows utilizando el script de PowerShell wmake.ps1 proporcionado. La sintaxis de uso es la misma que la del comando make , por lo que debe ejecutar .wmake.ps1 [-target] . Ejemplo: .wmake.ps1 erigon construye el ejecutable de erigon. Todos los archivos binarios se colocan en la subcarpeta .buildbin . Existen algunos requisitos para una compilación nativa exitosa en Windows:
chocolatey ; consulte el siguiente punto).wmake.ps1 db-tools ), debe instalar el administrador de paquetes Chocolatey para Windows. Por Chocolatey necesitas instalar los siguientes componentes: cmake , make , mingw por choco install cmake make mingw . Asegúrese de que la variable "Ruta" del sistema de Windows tenga: C:ProgramDatachocolateylibmingwtoolsinstallmingw64bin Nota importante sobre antivirus Durante la fase de detección del compilador de MinGW, se generan algunos ejecutables temporales para probar las capacidades del compilador. Se ha informado que algunos programas antivirus detectan esos archivos como posiblemente infectados por el troyano Win64/Kryptic.CIS (o una variante del mismo). Aunque se trata de falsos positivos, no tenemos control sobre más de 100 proveedores de productos de seguridad para Windows y sus respectivos algoritmos de detección, y entendemos que esto podría hacer que su experiencia con las compilaciones de Windows sea incómoda. Para solucionar el problema, puede establecer exclusiones para su antivirus específicamente para la subcarpeta buildbinmdbxCMakeFiles del repositorio clonado o puede ejecutar erigon usando las siguientes dos opciones
Utilice Docker: consulte docker-compose.yml
Utilice WSL (Subsistema de Windows para Linux) estrictamente en la versión 2 . Con esta opción, puede compilar Erigon tal como lo haría en una distribución de Linux normal. También puede apuntar sus datos a cualquiera de las particiones de Windows montadas (por ejemplo, /mnt/c/[...] , /mnt/d/[...] etc), pero en tal caso tenga en cuenta que el rendimiento se ve afectado: esto se debe al hecho de que esos puntos de montaje usan DrvFS , que es un sistema de archivos de red y, además, MDBX bloquea la base de datos para acceso exclusivo, lo que implica que solo un proceso a la vez puede acceder a los datos. Esto tiene consecuencias en la ejecución de rpcdaemon , que debe configurarse como base de datos remota incluso si se ejecuta en la misma computadora. Si, en cambio, sus datos están alojados en el sistema de archivos nativo de Linux, no se aplican limitaciones. Tenga en cuenta también que el entorno WSL2 predeterminado tiene su propia dirección IP que no coincide con la de la interfaz de red del host de Windows: tenga esto en cuenta al configurar NAT para el puerto 30303 en su enrutador.
Las discusiones principales tienen lugar en nuestro servidor de Discord. Para recibir una invitación, envíe un correo electrónico a bloxster [at] proton.me con su nombre, ocupación, una breve explicación de por qué desea unirse a Discord y cómo se enteró de Erigon.
erigon.substack.com
x.com/ErigonEth
Envíe un correo electrónico a security [at] torquem.ch .
htop muestra un uso incorrecto de la memoria La base de datos interna de Erigon (MDBX) que utiliza MemoryMap , cuando el sistema operativo administra todas las operaciones read, write, cache en lugar de la aplicación (linux, windows)
htop en la columna res muestra la memoria de "Aplicación + SO utilizada para mantener el caché de página para una aplicación determinada", pero no es informativo, porque si htop dice que la aplicación usa el 90% de la memoria, aún puedes ejecutar 3 instancias más de la aplicación en la misma máquina. - porque la mayor parte de ese 90% es "caché de páginas del sistema operativo". El sistema operativo libera automáticamente este caché cada vez que necesita memoria. Es posible que un "tamaño de caché de página" más pequeño no afecte en absoluto el rendimiento de Erigon.
Las siguientes herramientas muestran el uso correcto de la memoria de Erigon:
vmmap -summary PID | grep -i "Physical footprint" . Sin grep puedes ver los detalles.section MALLOC ZONE column Resident Size , muestra el uso de memoria de la aplicación, section REGION TYPE column Resident Size muestra el tamaño de caché de las páginas del sistema operativo.Prometheus muestra la memoria de la aplicación Go sin caché de páginas del sistema operativo ( make prometheus , abrir en el navegador localhost:3000 , credenciales admin/admin )cat /proc//smaps Erigon usa ~4Gb de RAM durante la sincronización de génesis y ~1Gb durante el trabajo normal. La caché de páginas del sistema operativo puede utilizar una cantidad ilimitada de memoria.
Advertencia: Varias instancias de Erigon en la misma máquina tocarán el disco al mismo tiempo, lo que afecta el rendimiento; una de las principales optimizaciones de Erigon: "reducir el acceso aleatorio al disco". La "etapa de ejecución de bloques" todavía realiza muchas lecturas aleatorias; esta es la razón por la cual es la etapa más lenta. No recomendamos ejecutar múltiples sincronizaciones de génesis en el mismo disco. Si se aprobó la sincronización de génesis, entonces está bien ejecutar varias instancias de Erigon en el mismo disco.
(Como gp3) Puede leer: #1516 (comentario) En resumen: los discos de red son malos para la ejecución de bloques, porque la ejecución de bloques lee datos de la base de datos de manera no paralela y no por lotes. Trucos: si agrega suficiente RAM y configura la variable de entorno ERIGON_SNAPSHOT_MADV_RND=false , entonces Erigon funcionará lo suficientemente bien en unidades de la nube, con un costo de IO más alto.
Por ejemplo: opción de autodefragmentación de btrfs: puede aumentar la escritura IO 100 veces
Gnome Tracker: detecta mineros y los mata.
Para cualquier otra persona que haya recibido el error BuildKit al intentar iniciar Erigon de la forma anterior, puede utilizar lo siguiente...
XDG_DATA_HOME=/preferred/data/folder DOCKER_BUILDKIT=1 COMPOSE_DOCKER_CLI_BUILD=1 make docker-compose
