Documentation : erigon.gitbook.io Blog : erigon.substack.com Twitter : x.com/ErigonEth
Erigon est une implémentation d'Ethereum (couche d'exécution avec couche de consensus intégrable), à la frontière de l'efficacité. Nœud d'archive par défaut.
erigon
caplin
beaconAPI
shared
other
portssystemd
htop
affiche une utilisation incorrecte de la mémoire Valeurs par défaut importantes : Erigon est un nœud d'archive par défaut : utilisez --prune.mode
si besoin, réduisez-le (non autorisé à changer après le premier démarrage)
In-depth links are marked by the microscope sign (?)
RAM : >=32 Go, Golang >= 1,22 ; GCC 10+ ou Clang ; Sous Linux : noyau > v4. Architecture 64 bits.
SSD ou NVMe. Ne recommandez pas le disque dur - sur le disque dur, Erigon restera toujours N blocs derrière la pointe de la chaîne, mais ne prendra pas de retard. Gardez à l’esprit que les performances du SSD se détériorent lorsqu’elles sont proches de leur capacité. CloudDrives (comme gp3) : l'exécution des blocs est lente sur les lecteurs réseau cloud
? Plus de détails sur la taille du répertoire de données Erigon3
? Plus de détails sur le type de données stockées ici
Notes de version et binaires
Construisez la dernière version (cela conviendra à la plupart des utilisateurs souhaitant simplement exécuter un nœud) :
git clone --branch release/ < x.xx > --single-branch https://github.com/erigontech/erigon.git
cd erigon
make erigon
./build/bin/erigon
Augmentez la vitesse de téléchargement de --torrent.download.rate=20mb
. ? See Downloader docs
Utilisez --datadir
pour choisir où stocker les données.
Utilisez --chain=gnosis
pour Gnosis Chain, --chain=bor-mainnet
pour Polygon Mainnet et --chain=amoy
pour Polygon Amoy. Pour Gnosis Chain, vous avez besoin d'un client Consensus Layer aux côtés d'Erigon (https://docs.gnosischain.com/category/step--3---run-consensus-client).
L'exécution make help
listera et décrira les commandes pratiques disponibles dans le 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 vous pouvez vous permettre de stocker datadir sur 1 nvme-raid, parfait. Si ce n'est pas possible, il est possible de stocker l'historique sur un disque bon marché.
# 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/snapshots
debug_getModifiedAccountsByNumber
le renvoie--internalcl
est activé par défaut. pour désactiver, utilisez --externalcl
.chaindata
font moins de 15gb
. C'est ok pour rm -rf chaindata
. (pour empêcher la croissance : recommandez --batchSize <= 1G
)--prune
indicateurs modifiés : voir --prune.mode
(par défaut : archive
, full : full
, EIP-4444 : minimal
)--sync.loop.block.limit=5_000
activé par défautDrapeaux :
verbosity
log.console.verbosity
(alias de remplacement pour verbosity
)log.json
log.console.json
(alias pour log.json
)log.dir.path
log.dir.prefix
log.dir.verbosity
log.dir.json
Afin de se connecter uniquement à stdout/stderr, l'indicateur --verbosity
(ou log.console.verbosity
) peut être utilisé pour fournir une valeur int spécifiant le niveau de journalisation de sortie le plus élevé :
LvlCrit = 0
LvlError = 1
LvlWarn = 2
LvlInfo = 3
LvlDebug = 4
LvlTrace = 5
Pour définir un répertoire de sortie pour les journaux à collecter sur le disque, veuillez définir --log.dir.path
Si vous souhaitez modifier le nom de fichier produit à partir d' erigon
vous devez également définir l'indicateur --log.dir.prefix
sur un autre nom. L'indicateur --log.dir.verbosity
est également disponible pour contrôler la verbosité de cette journalisation, avec la même valeur int que ci-dessus, ou la valeur de chaîne, par exemple « debug » ou « info ». La verbosité par défaut est « debug » (4), pour la journalisation du disque.
Le format du journal peut être défini sur json à l'aide des indicateurs booléens log.json
ou log.console.json
, ou pour la sortie disque --log.dir.json
.
Erigon est par défaut une solution "tout-en-un binaire", mais il est possible de démarrer TxPool en tant que processus séparés. Il en va de même pour : la couche JSON RPC (RPCDaemon), la couche p2p (Sentry), la couche de téléchargement d'historique (Downloader), le consensus. Ne démarrez pas les services en tant que processus séparés, sauf si vous en avez une raison claire : limitation des ressources, mise à l'échelle, remplacement par votre propre implémentation, sécurité. Comment démarrer les services d'Erigon en tant que processus séparés, voir dans docker-compose.yml. Chaque service possède son propre fichier ./cmd/*/README.md
. Blog Érigon.
Consensus intégré pour Ethereum Mainnet, Sepolia, Holesky, Gnosis. Pour utiliser une couche de consensus externe : --externalcl
.
Si vous souhaitez essayer Erigon : une bonne option consiste à commencer à synchroniser l'un des réseaux de test publics, Holesky (ou Amoy). Il se synchronise beaucoup plus rapidement et ne prend pas beaucoup d'espace disque :
git clone https://github.com/erigontech/erigon.git
cd erigon
make erigon
./build/bin/erigon --datadir= < your_datadir > --chain=holesky --prune.mode=full
Veuillez noter l'option --datadir
qui vous permet de stocker les fichiers Erigon dans un emplacement autre que celui par défaut. Le nom du répertoire --datadir
ne doit pas nécessairement correspondre au nom de la chaîne dans --chain
.
La production de blocs est entièrement prise en charge pour Ethereum et Gnosis Chain. C'est encore expérimental pour Polygon.
Vous pouvez définir les indicateurs Erigon via un fichier de configuration TOML avec l'indicateur --config
. Les indicateurs définis dans le fichier de configuration peuvent être écrasés en écrivant les indicateurs directement sur la ligne de commande Erigon
./build/bin/erigon --config ./config.toml --chain=sepolia
En supposant que nous ayons chain : "mainnet"
dans notre fichier de configuration, en ajoutant --chain=sepolia
permet l'écrasement de l'indicateur à l'intérieur du fichier de configuration toml et définit la chaîne sur sepolia
datadir = ' your datadir '
port = 1111
chain = " mainnet "
http = true
"private.api.addr" = " localhost:9090 "
"http.api" = [ " eth " , " debug " , " net " ]
Erigon peut être utilisé comme couche d'exécution (EL) pour les clients de couche de consensus (CL). La configuration par défaut est OK.
Si votre client CL se trouve sur un autre appareil, ajoutez --authrpc.addr 0.0.0.0
(l'API Engine écoute sur localhost par défaut) ainsi que --authrpc.vhosts
où
est votre hôte source ou any
.
Afin d'établir une connexion sécurisée entre la couche de consensus et la couche d'exécution, une clé secrète JWT est automatiquement générée.
La clé secrète JWT sera présente dans le datadir par défaut sous le nom de jwt.hex
et son chemin pourra être précisé avec le flag --authrpc.jwtsecret
.
Cette information doit également être spécifiée dans la couche de consensus afin d'établir une connexion avec succès. Plus d’informations peuvent être trouvées ici.
Une fois qu'Erigon est en cours d'exécution, vous devez pointer votre client CL vers
, où
est soit localhost
, soit l'adresse IP du périphérique exécutant Erigon, et également pointer vers le chemin secret JWT créé par Erigon.
Caplin est un client de consensus de validation à part entière comme Prysm, Lighthouse, Teku, Nimbus et Lodestar. Son objectif est :
La principale raison pour laquelle nous avons développé une nouvelle couche de consensus est d’expérimenter les avantages possibles qui pourraient en découler. Par exemple, l'API Engine ne fonctionne pas bien avec Erigon. L'API Engine envoie les données bloc par bloc, ce qui ne convient pas au fonctionnement d'Erigon. Erigon est conçu pour gérer plusieurs blocs simultanément et doit trier et traiter les données efficacement. Par conséquent, il serait préférable qu'Erigon gère les blocs de manière indépendante plutôt que de s'appuyer sur l'API Engine.
Caplin est activé par défaut. pour le désactiver et activer l'API Engine, utilisez l'indicateur --externalcl
. à partir de ce moment, une couche de consensus externe ne sera plus nécessaire.
Caplin dispose également d'un mode d'archivage pour les états et blocs historiques. il peut être activé via l'indicateur --caplin.archive
. Afin d'activer l'API Beacon du caplin, le drapeau --beacon.api=
doit être ajouté. Par exemple : --beacon.api=beacon,builder,config,debug,node,validator,lighthouse
activera tous les points de terminaison. **REMARQUE : Caplin n'est pas prêt pour le jalonnement, les points de terminaison d'agrégation doivent donc encore être implémentés. L’activation supplémentaire de l’API Beacon entraînera une utilisation de RAM supérieure de 6 Go.
Définissez 6 indicateurs pour éviter les conflits : --datadir --port --http.port --authrpc.port --torrent.port --private.api.addr
. Exemple de plusieurs chaînes sur une même machine :
# 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
Citez votre chemin s'il comporte des espaces.
? Detailed explanation is DEV_CHAIN.
Sur une bonne bande passante réseau, EthereumMainnet FullNode se synchronise en 3 heures : OtterSync peut se synchroniser
Stockage KV plat. Erigon utilise une base de données clé-valeur et stocke les comptes et le stockage de manière simple.
? See our detailed DB walkthrough here.
Prétraitement . Pour certaines opérations, Erigon utilise des fichiers temporaires pour prétraiter les données avant de les insérer dans la base de données principale. Cela réduit l'amplification d'écriture et les insertions de base de données sont plusieurs fois plus rapides.
? See our detailed ETL explanation here.
État simple
Comptes uniques/essai d'état . Erigon utilise un seul essai Merkle pour les comptes et le stockage.
? Staged Sync Readme
La plupart des composants d'Erigon (txpool, rpcdaemon, snapshots downloader, sentry, ...) peuvent fonctionner au sein d'Erigon et en tant que processus indépendant sur le même serveur (ou un autre serveur). Exemple:
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
, documentation détaillée.
# 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
Composant | Port | Protocole | But | Devrait exposer |
---|---|---|---|---|
moteur | 9090 | TCP | Serveur gRPC | Privé |
moteur | 42069 | TCP et UDP | Synchronisation instantanée (Bittorrent) | Publique |
moteur | 8551 | TCP | API du moteur (authentification JWT) | Privé |
sentinelle | 30303 | TCP et UDP | peering eth/68 | Publique |
sentinelle | 30304 | TCP et UDP | peering eth/67 | Publique |
sentinelle | 9091 | TCP | Connexions gRPC entrantes | Privé |
rpcdaemon | 8545 | TCP | HTTP, WebSockets et GraphQL | Privé |
En règle générale, les numéros 30303 et 30304 sont exposés à Internet pour permettre les connexions d'appairage entrantes. 9090 est exposé uniquement en interne pour rpcdaemon ou d'autres connexions (par exemple rpcdaemon -> erigon). Le port 8551 (authentifié JWT) est exposé uniquement en interne pour les requêtes JSON-RPC de l'API Engine à partir du nœud Consensus Layer.
caplin
Composant | Port | Protocole | But | Devrait exposer |
---|---|---|---|---|
sentinelle | 4000 | UDP | Appairage | Publique |
sentinelle | 4001 | TCP | Appairage | Publique |
Afin de configurer les ports, utilisez :
--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
Composant | Port | Protocole | But | Devrait exposer |
---|---|---|---|---|
REPOS | 5555 | TCP | REPOS | Publique |
shared
Composant | Port | Protocole | But | Devrait exposer |
---|---|---|---|---|
tous | 6060 | TCP | pprof | Privé |
tous | 6061 | TCP | métrique | Privé |
Des indicateurs facultatifs peuvent être activés pour activer pprof ou des métriques (ou les deux). Utilisez --help
avec le binaire pour plus d'informations.
other
ports Réservé à une utilisation future : ports gRPC : moteur de consensus 9092
, téléchargeur d'instantanés 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
Idem dans la syntaxe IpTables
systemd
L'exécution d'Erigon depuis build/bin
en tant qu'utilisateur distinct peut produire une erreur :
error while loading shared libraries: libsilkworm_capi.so: cannot open shared object file: No such file or directory
La bibliothèque doit être installée pour un autre utilisateur à l'aide de make DIST=
. Vous pouvez utiliser $HOME/erigon
ou /opt/erigon
comme chemin d'installation, par exemple :
make DIST=/opt/erigon install
kill -SIGUSR1
, obtenez la trace et arrêtez : kill -6
--pprof
et exécutezgo tool pprof -png http://127.0.0.1:6060/debug/pprof/profile?seconds=20 > cpu.png
--pprof
et exécutezgo tool pprof -inuse_space -png http://127.0.0.1:6060/debug/pprof/heap > mem.png
? Detailed explanation is here.
Docker utilise l'utilisateur Erigon avec l'UID/GID 1000 (pour des raisons de sécurité). Vous pouvez voir cet utilisateur en cours de création dans le Dockerfile. Peut être corrigé en donnant à l'utilisateur d'un hôte la propriété du dossier, où l'UID/GID de l'utilisateur de l'hôte est le même que l'UID/GID de l'utilisateur du docker (1000). Plus de détails dans l'article
--txpool.nolocals=true
admin
dans la liste --http.api
--http.corsdomain="*"
est une mauvaise pratique : définir le nom d'hôte ou l'adresse IP exact--rpc.batch.concurrency
, --rpc.batch.limit
https://github.com/mathMakesArt/Erigon-on-RPi-4
Docker permet de créer et d'exécuter Erigon via des conteneurs. Cela évite d'avoir à installer des dépendances de build sur le système d'exploitation hôte.
L'UID/GID de l'utilisateur doit être synchronisé entre le système d'exploitation hôte et le conteneur afin que les fichiers soient écrits avec l'autorisation correcte.
Vous souhaiterez peut-être configurer un utilisateur/groupe dédié sur le système d'exploitation hôte, auquel cas les cibles make
suivantes sont disponibles.
# create "erigon" user
make user_linux
# or
make user_macos
Il existe un fichier .env.example
à la racine du dépôt.
DOCKER_UID
- L'UID de l'utilisateur du dockerDOCKER_GID
- Le GID de l'utilisateur du dockerXDG_DATA_HOME
- Le répertoire de données qui sera monté sur les conteneurs DockerS’il n’est pas spécifié, l’UID/GID utilisera l’utilisateur actuel.
Un bon choix pour XDG_DATA_HOME
consiste à utiliser le répertoire ~erigon/.ethereum
créé par les cibles auxiliaires make user_linux
ou make user_macos
.
Vérifiez les autorisations : dans tous les cas, XDG_DATA_HOME
(spécifié ou par défaut) doit être accessible en écriture par l'UID/GID de l'utilisateur dans Docker, qui sera déterminé par le DOCKER_UID
et DOCKER_GID
au moment de la construction. Si le démarrage d'une build ou d'un service échoue en raison d'autorisations, vérifiez que tous les répertoires, UID et GID contrôlés par ces variables d'environnement sont corrects.
La commande suivante démarre : Erigon sur le port 30303, rpcdaemon sur le port 8545, prometheus sur le port 9090 et grafana sur le port 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-compose
Makefile crée les répertoires initiaux pour erigon, prometheus et grafana. L'espace de noms PID est partagé entre erigon et rpcdaemon, ce qui est nécessaire pour ouvrir la base de données d'Erigon à partir d'un autre processus (mode local RPCDaemon). Voir : https://github.com/erigontech/erigon/pull/2392/files
Si votre installation Docker nécessite que le démon Docker s'exécute en tant que root (ce qui est le cas par défaut), vous devrez préfixer la commande ci-dessus avec sudo
. Cependant, il est parfois recommandé d'exécuter Docker (et donc ses conteneurs) en tant qu'utilisateur non root pour des raisons de sécurité. Pour plus d’informations sur la façon de procéder, reportez-vous à cet article.
poste
--sync.loop.block.limit=10_000
SNAPSHOT_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
Les utilisateurs Windows peuvent exécuter erigon de 3 manières possibles :
Créez des binaires exécutables de manière native pour Windows à l'aide du script PowerShell wmake.ps1
fourni. La syntaxe d'utilisation est la même que celle de la commande make
, vous devez donc exécuter .wmake.ps1 [-target]
. Exemple : .wmake.ps1 erigon
construit l'exécutable erigon. Tous les binaires sont placés dans le sous-dossier .buildbin
. Il y a certaines exigences pour une build native réussie sur Windows :
chocolatey
- voir point suivant).wmake.ps1 db-tools
), le gestionnaire de packages Chocolatey pour Windows doit être installé. Par Chocolatey, vous devez installer les composants suivants : cmake
, make
, mingw
par choco install cmake make mingw
. Assurez-vous que la variable « Chemin » du système Windows contient : C:ProgramDatachocolateylibmingwtoolsinstallmingw64bin Remarque importante sur les antivirus Pendant la phase de détection du compilateur MinGW, certains exécutables temporaires sont générés pour tester les capacités du compilateur. Il a été signalé que certains programmes antivirus détectent ces fichiers comme étant potentiellement infectés par le cheval de Troie Win64/Kryptic.CIS
(ou une variante de celui-ci). Bien qu'il s'agisse de faux positifs, nous n'avons aucun contrôle sur plus de 100 fournisseurs de produits de sécurité pour Windows et leurs algorithmes de détection respectifs et nous comprenons que cela puisse rendre votre expérience avec les versions Windows inconfortable. Pour contourner le problème, vous pouvez soit définir des exclusions pour votre antivirus spécifiquement pour le sous-dossier buildbinmdbxCMakeFiles
du référentiel cloné, soit exécuter erigon en utilisant les deux autres options suivantes.
Utiliser Docker : voir docker-compose.yml
Utilisez WSL (Windows Subsystem for Linux) uniquement sur la version 2 . Avec cette option, vous pouvez construire Erigon comme vous le feriez sur une distribution Linux classique. Vous pouvez également pointer vos données vers n'importe laquelle des partitions Windows montées (par exemple /mnt/c/[...]
, /mnt/d/[...]
etc), mais dans ce cas, sachez que les performances sont affectées : ceci est dû au fait que ces points de montage utilisent DrvFS
qui est un système de fichiers réseau et, de plus, MDBX verrouille la base de données pour un accès exclusif, ce qui implique qu'un seul processus à la fois peut accéder aux données. Cela a des conséquences sur le fonctionnement de rpcdaemon
qui doit être configuré en tant que Remote DB même s'il est exécuté sur le même ordinateur. Si, au contraire, vos données sont hébergées sur le système de fichiers Linux natif, aucune limitation ne s'applique. Veuillez également noter que l'environnement WSL2 par défaut possède sa propre adresse IP qui ne correspond pas à celle de l'interface réseau de l'hôte Windows : tenez-en compte lors de la configuration du NAT pour le port 30303 de votre routeur.
Les principales discussions se déroulent sur notre serveur Discord. Pour recevoir une invitation, envoyez un e-mail à bloxster [at] proton.me
avec votre nom, votre profession, une brève explication de la raison pour laquelle vous souhaitez rejoindre le Discord et comment vous avez entendu parler d'Erigon.
erigon.substack.com
x.com/ErigonEth
Envoyez un email à security [at] torquem.ch
.
htop
affiche une utilisation incorrecte de la mémoire Base de données interne d'Erigon (MDBX) utilisant MemoryMap
- lorsque le système d'exploitation gère toutes les opérations read, write, cache
au lieu de l'application (linux, Windows)
htop
sur la colonne res
affiche la mémoire de "App + OS utilisé pour contenir le cache de page pour une application donnée", mais ce n'est pas informatif, car si htop
indique que cette application utilise 90% de la mémoire, vous pouvez toujours exécuter 3 instances supplémentaires de l'application sur la même machine. - parce que la majeure partie de ces 90%
est du "cache des pages du système d'exploitation". Le système d'exploitation libère automatiquement ce cache chaque fois qu'il a besoin de mémoire. Une « taille de cache de page » plus petite peut ne pas avoir d'impact sur les performances d'Erigon.
Les outils suivants montrent l'utilisation correcte de la mémoire d'Erigon :
vmmap -summary PID | grep -i "Physical footprint"
. Sans grep
vous pouvez voir les détailssection MALLOC ZONE column Resident Size
indique l'utilisation de la mémoire de l'application, section REGION TYPE column Resident Size
indique la taille du cache des pages du système d'exploitation.Prometheus
affiche la mémoire de l'application Go sans cache des pages du système d'exploitation ( make prometheus
, ouvert dans le navigateur localhost:3000
, informations d'identification admin/admin
)cat /proc//smaps
Erigon utilise ~ 4 Go de RAM pendant la synchronisation Genesis et ~ 1 Go pendant le travail normal. Le cache des pages du système d’exploitation peut utiliser une quantité illimitée de mémoire.
Attention : plusieurs instances d'Erigon sur la même machine toucheront le disque simultanément, cela aura un impact sur les performances - l'une des principales optimisations d'Erigon : "réduire l'accès aléatoire au disque". "L'étape d'exécution des blocs" effectue encore de nombreuses lectures aléatoires - c'est la raison pour laquelle il s'agit de l'étape la plus lente. Nous ne recommandons pas d'exécuter plusieurs synchronisations Genesis sur le même disque. Si la synchronisation Genesis a réussi, vous pouvez exécuter plusieurs instances Erigon sur le même disque.
(Comme gp3) Vous pouvez lire : #1516 (commentaire) En bref : les disques réseau sont mauvais pour l'exécution des blocs - car l'exécution des blocs lit les données de la base de données de manière non parallèle et non par lots. Astuces : si vous lancez suffisamment de RAM et définissez la variable d'environnement ERIGON_SNAPSHOT_MADV_RND=false
- alors Erigon fonctionnera assez bien sur les lecteurs Cloud - avec un coût d'E/S plus élevé.
Par exemple : l'option de défragmentation automatique de btrfs - peut multiplier par 100 les E/S en écriture.
Gnome Tracker - détecte les mineurs et les tue.
Pour toute autre personne qui recevait l'erreur BuildKit en essayant de démarrer Erigon de l'ancienne manière, vous pouvez utiliser ce qui suit...
XDG_DATA_HOME=/preferred/data/folder DOCKER_BUILDKIT=1 COMPOSE_DOCKER_CLI_BUILD=1 make docker-compose