ereção
v2.60.10
Documentação: erigon.gitbook.io Blog: erigon.substack.com Twitter: x.com/ErigonEth
Erigon é uma implementação do Ethereum (camada de execução com camada de consenso incorporável), na fronteira da eficiência. Nó de arquivamento por padrão.
erigoncaplinbeaconAPIsharedother portossystemdhtop mostra uso incorreto de memória Padrões importantes : Erigon é um nó de arquivo por padrão: use --prune.mode se necessário, diminua-o (não é permitido alterar após a primeira inicialização)
In-depth links are marked by the microscope sign (?)
RAM: >=32GB, Golang >= 1,22; GCC 10+ ou Clang; No Linux: kernel > v4. Arquitetura de 64 bits.
SSD ou NVMe. Não recomendo HDD - no HDD Erigon sempre ficará N blocos atrás da ponta da corrente, mas não ficará para trás. Tenha em mente que o desempenho do SSD se deteriora quando está próximo da capacidade. CloudDrives (como gp3): a execução de blocos é lenta em unidades de rede em nuvem
? Mais detalhes sobre o tamanho do datadir Erigon3
? Mais detalhes sobre que tipo de dados armazenados aqui
Notas de versão e binários
Crie a versão mais recente (isso será adequado para a maioria dos usuários que desejam apenas executar um nó):
git clone --branch release/ < x.xx > --single-branch https://github.com/erigontech/erigon.git
cd erigon
make erigon
./build/bin/erigon Aumente a velocidade de download em --torrent.download.rate=20mb . ? See Downloader docs
Use --datadir para escolher onde armazenar os dados.
Use --chain=gnosis para Gnosis Chain, --chain=bor-mainnet para Polygon Mainnet e --chain=amoy para Polygon Amoy. Para Gnosis Chain, você precisa de um cliente Consensus Layer junto com Erigon (https://docs.gnosischain.com/category/step--3---run-consensus-client).
A execução de make help listará e descreverá os comandos de conveniência disponíveis no 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 Se você puder armazenar o datadir em 1 nvme-raid - ótimo. Se não for possível, é possível armazenar o histórico em uma unidade barata.
# 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 retorne-a--internalcl está habilitado por padrão. para desabilitar use --externalcl .chaindata tem menos de 15gb . Não há problema em rm -rf chaindata . (para evitar o crescimento: recomendo --batchSize <= 1G )--prune alterados : consulte --prune.mode (padrão: archive , completo: full , EIP-4444: minimal )--sync.loop.block.limit=5_000 habilitado por padrãoBandeiras:
verbositylog.console.verbosity (substituindo alias por verbosity )log.jsonlog.console.json (alias para log.json )log.dir.pathlog.dir.prefixlog.dir.verbositylog.dir.json Para registrar apenas no stdout/stderr, o sinalizador --verbosity (ou log.console.verbosity ) pode ser usado para fornecer um valor int especificando o nível de log de saída mais alto:
LvlCrit = 0
LvlError = 1
LvlWarn = 2
LvlInfo = 3
LvlDebug = 4
LvlTrace = 5
Para definir um diretório de saída para logs a serem coletados no disco, defina --log.dir.path Se você deseja alterar o nome do arquivo produzido a partir de erigon você também deve definir o sinalizador --log.dir.prefix para um nome alternativo. A flag --log.dir.verbosity também está disponível para controlar o detalhamento deste log, com o mesmo valor int acima, ou o valor da string, por exemplo, 'debug' ou 'info'. A verbosidade padrão é 'debug' (4), para registro em disco.
O formato de log pode ser definido como json usando os sinalizadores booleanos log.json ou log.console.json ou para a saída do disco --log.dir.json .
Erigon por padrão é a solução "tudo em um binário", mas é possível iniciar o TxPool como processos separados. O mesmo vale para: camada JSON RPC (RPCDaemon), camada p2p (Sentry), camada de download de histórico (Downloader), consenso. Não inicie serviços como processos separados, a menos que tenha um motivo claro para isso: limitação de recursos, escala, substituição por sua própria implementação, segurança. Como iniciar os serviços do Erigon como processos separados, veja em docker-compose.yml. Cada serviço possui seu próprio arquivo ./cmd/*/README.md . Blog Erigon.
Consenso integrado para Ethereum Mainnet, Sepolia, Holesky, Gnosis. Para usar a camada de consenso externa: --externalcl .
Se você quiser experimentar o Erigon: uma boa opção é começar a sincronizar uma das redes de teste públicas, Holesky (ou Amoy). Ele sincroniza muito mais rápido e não ocupa muito espaço em disco:
git clone https://github.com/erigontech/erigon.git
cd erigon
make erigon
./build/bin/erigon --datadir= < your_datadir > --chain=holesky --prune.mode=full Observe a opção --datadir que permite armazenar arquivos Erigon em um local não padrão. O nome do diretório --datadir não precisa corresponder ao nome da cadeia em --chain .
A produção de blocos é totalmente suportada pela Ethereum & Gnosis Chain. Ainda é experimental para Polygon.
Você pode definir sinalizadores Erigon por meio de um arquivo de configuração TOML com o sinalizador --config . Os sinalizadores definidos no arquivo de configuração podem ser substituídos escrevendo-os diretamente na linha de comando do Erigon
./build/bin/erigon --config ./config.toml --chain=sepolia
Supondo que temos chain : "mainnet" em nosso arquivo de configuração, adicionar --chain=sepolia permite a substituição da flag dentro do arquivo de configuração toml e define a cadeia como sepolia
datadir = ' your datadir '
port = 1111
chain = " mainnet "
http = true
"private.api.addr" = " localhost:9090 "
"http.api" = [ " eth " , " debug " , " net " ]Erigon pode ser usado como uma camada de execução (EL) para clientes da camada de consenso (CL). A configuração padrão está OK.
Se o seu cliente CL estiver em um dispositivo diferente, adicione --authrpc.addr 0.0.0.0 (a API do mecanismo escuta no host local por padrão), bem como --authrpc.vhosts onde any .
Para estabelecer uma conexão segura entre a Camada de Consenso e a Camada de Execução, uma chave secreta JWT é gerada automaticamente.
A chave secreta JWT estará presente no datadir por padrão sob o nome jwt.hex e seu caminho pode ser especificado com o sinalizador --authrpc.jwtsecret .
Esta informação também precisa ser especificada na camada de consenso para estabelecer a conexão com sucesso. Mais informações podem ser encontradas aqui.
Assim que o Erigon estiver em execução, você precisará apontar seu cliente CL para localhost ou o endereço IP do dispositivo que executa o Erigon e também apontar para o caminho secreto JWT criado pelo Erigon.
Caplin é um cliente de consenso de validação completo como Prysm, Lighthouse, Teku, Nimbus e Lodestar. Seu objetivo é:
A principal razão pela qual desenvolveu uma nova Camada de Consenso é experimentar os possíveis benefícios que poderiam advir dela. Por exemplo, a API Engine não funciona bem com Erigon. A API do mecanismo envia dados um bloco por vez, o que não combina com o funcionamento do Erigon. Erigon foi projetado para lidar com muitos blocos simultaneamente e precisa classificar e processar dados com eficiência. Portanto, seria melhor para Erigon lidar com os blocos de forma independente, em vez de depender da API do mecanismo.
Caplin está habilitado por padrão. para desativá-lo e ativar a API do mecanismo, use o sinalizador --externalcl . a partir daí, uma Camada de Consenso externa não será mais necessária.
Caplin também possui um modo de arquivamento para estados e blocos históricos. ele pode ser habilitado através do sinalizador --caplin.archive . Para habilitar a API Beacon do caplin, o sinalizador --beacon.api= deve ser adicionado. por exemplo: --beacon.api=beacon,builder,config,debug,node,validator,lighthouse habilitará todos os endpoints. **NOTA: Caplin não está pronto para piquetagem, portanto os endpoints de agregação ainda precisam ser implementados. Além disso, ativar a API Beacon resultará em um uso de RAM 6 GB maior.
Defina 6 sinalizadores para evitar conflitos: --datadir --port --http.port --authrpc.port --torrent.port --private.api.addr . Exemplo de múltiplas cadeias na mesma 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
Cite seu caminho se tiver espaços.
? Detailed explanation is DEV_CHAIN.
Com boa largura de banda de rede, EthereumMainnet FullNode sincroniza em 3 horas: OtterSync pode sincronizar
Armazenamento plano KV. Erigon usa um banco de dados de valores-chave e armazena contas e armazenamento de maneira simples.
? See our detailed DB walkthrough here.
Pré-processamento . Para algumas operações, Erigon usa arquivos temporários para pré-processar os dados antes de inseri-los no banco de dados principal. Isso reduz a amplificação de gravação e as inserções de banco de dados são muito mais rápidas.
? See our detailed ETL explanation here.
Estado simples
Contas únicas/teste estadual . Erigon usa um único teste Merkle para contas e armazenamento.
? Staged Sync Readme
A maioria dos componentes do Erigon (txpool, rpcdaemon, snapshots downloader, sentry, ...) podem funcionar dentro do Erigon e como processos independentes no mesmo servidor (ou outro servidor). Exemplo:
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 detalhados.
# 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 | Porta | Protocolo | Propósito | Deveria expor |
|---|---|---|---|---|
| motor | 9090 | TCP | Servidor gRPC | Privado |
| motor | 42069 | TCP e UDP | Sincronização instantânea (Bittorrent) | Público |
| motor | 8551 | TCP | API do mecanismo (autenticação JWT) | Privado |
| sentinela | 30303 | TCP e UDP | peering eth/68 | Público |
| sentinela | 30304 | TCP e UDP | peering eth/67 | Público |
| sentinela | 9091 | TCP | conexões gRPC de entrada | Privado |
| rpcdaemon | 8545 | TCP | HTTP e WebSockets e GraphQL | Privado |
Normalmente, 30303 e 30304 são expostos à Internet para permitir conexões de peering de entrada. 9090 é exposto apenas internamente para rpcdaemon ou outras conexões (por exemplo, rpcdaemon -> erigon). A porta 8551 (autenticada por JWT) é exposta apenas internamente para consultas JSON-RPC da API do mecanismo do nó da camada de consenso.
caplin| Componente | Porta | Protocolo | Propósito | Deveria expor |
|---|---|---|---|---|
| sentinela | 4000 | UDP | Espreitando | Público |
| sentinela | 4001 | TCP | Espreitando | Público |
Para configurar as portas, use:
--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 | Porta | Protocolo | Propósito | Deveria expor |
|---|---|---|---|---|
| DESCANSAR | 5555 | TCP | DESCANSAR | Público |
shared| Componente | Porta | Protocolo | Propósito | Deveria expor |
|---|---|---|---|---|
| todos | 6060 | TCP | prof. | Privado |
| todos | 6061 | TCP | métricas | Privado |
Sinalizadores opcionais podem ser habilitados para ativar pprof ou métricas (ou ambos). Use --help com o binário para mais informações.
other portos Reservado para uso futuro: portas gRPC : mecanismo de consenso 9092 , downloader de snapshot 9093 , 9094 TxPool
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
O mesmo na sintaxe IpTables
systemd Executar erigon a partir de build/bin como um usuário separado pode produzir um erro:
error while loading shared libraries: libsilkworm_capi.so: cannot open shared object file: No such file or directory A biblioteca precisa ser instalada para outro usuário usando make DIST= . Você poderia usar $HOME/erigon ou /opt/erigon como caminho de instalação, por exemplo:
make DIST=/opt/erigon installkill -SIGUSR1 , obtenha rastreamento e pare: kill -6 --pprof e executego tool pprof -png http://127.0.0.1:6060/debug/pprof/profile?seconds=20 > cpu.png--pprof e executego tool pprof -inuse_space -png http://127.0.0.1:6060/debug/pprof/heap > mem.png ? Detailed explanation is here.
Docker usa usuário erigon com UID/GID 1000 (por motivos de segurança). Você pode ver esse usuário sendo criado no Dockerfile. Pode ser corrigido concedendo ao usuário do host a propriedade da pasta, onde o UID/GID do usuário do host é igual ao UID/GID do usuário do docker (1000). Mais detalhes na postagem
--txpool.nolocals=trueadmin na lista --http.api--http.corsdomain="*" é uma prática inadequada: definir o nome de host ou IP exato--rpc.batch.concurrency , --rpc.batch.limithttps://github.com/mathMakesArt/Erigon-on-RPi-4
Docker permite construir e executar Erigon por meio de contêineres. Isso alivia a necessidade de instalar dependências de compilação no sistema operacional host.
O UID/GID do usuário precisa ser sincronizado entre o sistema operacional host e o contêiner para que os arquivos sejam gravados com a permissão correta.
Você pode desejar configurar um usuário/grupo dedicado no sistema operacional host; nesse caso, os seguintes alvos make estarão disponíveis.
# create "erigon" user
make user_linux
# or
make user_macos Há um arquivo .env.example na raiz do repositório.
DOCKER_UID - O UID do usuário do dockerDOCKER_GID - O GID do usuário dockerXDG_DATA_HOME - O diretório de dados que será montado nos contêineres dockerSe não for especificado, o UID/GID usará o usuário atual.
Uma boa escolha para XDG_DATA_HOME é usar o diretório ~erigon/.ethereum criado pelos destinos auxiliares make user_linux ou make user_macos .
Verifique as permissões: em todos os casos, XDG_DATA_HOME (especificado ou padrão) deve ser gravável pelo usuário UID/GID no docker, que será determinado pelo DOCKER_UID e DOCKER_GID no momento da construção. Se uma compilação ou inicialização de serviço falhar devido a permissões, verifique se todos os diretórios, UID e GID controlados por essas variáveis de ambiente estão corretos.
O próximo comando começa: Erigon na porta 30303, rpcdaemon na porta 8545, prometheus na porta 9090 e grafana na porta 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 cria os diretórios iniciais para erigon, prometheus e grafana. O namespace PID é compartilhado entre erigon e rpcdaemon, que é necessário para abrir o banco de dados de Erigon a partir de outro processo (modo local RPCDaemon). Consulte: https://github.com/erigontech/erigon/pull/2392/files
Se a instalação do docker exigir que o daemon do docker seja executado como root (que é o padrão), você precisará prefixar o comando acima com sudo . No entanto, às vezes é recomendado executar o docker (e, portanto, seus contêineres) como um usuário não root por motivos de segurança. Para obter mais informações sobre como fazer isso, consulte este artigo.
publicar
--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
Os usuários do Windows podem executar o erigon de três maneiras possíveis:
Crie binários executáveis nativamente para Windows usando o script wmake.ps1 do PowerShell fornecido. A sintaxe de uso é a mesma do comando make , então você deve executar .wmake.ps1 [-target] . Exemplo: .wmake.ps1 erigon cria o executável erigon. Todos os binários são colocados na subpasta .buildbin . Existem alguns requisitos para uma compilação nativa bem-sucedida no Windows:
chocolatey - veja o ponto a seguir).wmake.ps1 db-tools ), o gerenciador de pacotes Chocolatey para Windows deverá ser instalado. Por Chocolatey você precisa instalar os seguintes componentes: cmake , make , mingw por choco install cmake make mingw . Certifique-se de que a variável "Path" do sistema Windows tenha: C:ProgramDatachocolateylibmingwtoolsinstallmingw64bin Nota importante sobre antivírus Durante a fase de detecção do compilador do MinGW, alguns executáveis temporários são gerados para testar as capacidades do compilador. Foi relatado que alguns programas antivírus detectam esses arquivos como possivelmente infectados pelo cavalo de troia Win64/Kryptic.CIS (ou uma variante dele). Embora esses sejam falsos positivos, não temos controle sobre mais de 100 fornecedores de produtos de segurança para Windows e seus respectivos algoritmos de detecção e entendemos que isso pode tornar sua experiência com compilações do Windows desconfortável. Para solucionar o problema, você pode definir exclusões para seu antivírus especificamente para a subpasta buildbinmdbxCMakeFiles do repositório clonado ou pode executar o erigon usando as outras duas opções a seguir
Use Docker: consulte docker-compose.yml
Use WSL (Windows Subsystem for Linux) estritamente na versão 2 . Nesta opção você pode construir o Erigon da mesma forma que faria em uma distribuição Linux normal. Você também pode apontar seus dados para qualquer uma das partições montadas do Windows (por exemplo, /mnt/c/[...] , /mnt/d/[...] etc), mas nesse caso, esteja ciente de que o desempenho será afetado: isso isso se deve ao fato de esses pontos de montagem usarem DrvFS , que é um sistema de arquivos de rede e, além disso, o MDBX bloqueia o banco de dados para acesso exclusivo, o que implica que apenas um processo por vez pode acessar os dados. Isto tem consequências na execução do rpcdaemon que deve ser configurado como BD Remoto mesmo que seja executado no mesmo computador. Se, em vez disso, seus dados estiverem hospedados no sistema de arquivos nativo do Linux, não serão aplicadas limitações. Observe também que o ambiente WSL2 padrão possui seu próprio endereço IP que não corresponde ao da interface de rede do host Windows: leve isso em consideração ao configurar o NAT para a porta 30303 em seu roteador.
As principais discussões estão acontecendo em nosso servidor Discord. Para receber um convite, envie um e-mail para bloxster [at] proton.me com seu nome, profissão, uma breve explicação de por que deseja ingressar no Discord e como ouviu falar de Erigon.
erigon.substack.com
x.com/ErigonEth
Envie um e-mail para security [at] torquem.ch .
htop mostra uso incorreto de memória Banco de dados interno de Erigon (MDBX) usando MemoryMap - quando o sistema operacional gerencia todas as operações de read, write, cache em vez de aplicativo (linux, windows)
htop na coluna res mostra a memória de "App + OS usado para armazenar o cache da página para um determinado aplicativo", mas não é informativo, porque se htop disser que o aplicativo está usando 90% da memória, você ainda poderá executar mais 3 instâncias do aplicativo na mesma máquina - porque a maior parte desses 90% é "cache de páginas do sistema operacional". O sistema operacional libera automaticamente esse cache sempre que precisar de memória. Um "tamanho de cache de página" menor pode não afetar o desempenho do Erigon.
As próximas ferramentas mostram o uso correto da memória do Erigon:
vmmap -summary PID | grep -i "Physical footprint" . Sem grep você pode ver detalhessection MALLOC ZONE column Resident Size mostra o uso de memória do aplicativo, section REGION TYPE column Resident Size mostra o tamanho do cache das páginas do sistema operacional.Prometheus mostra a memória do aplicativo Go sem cache de páginas do sistema operacional ( make prometheus , aberto no navegador localhost:3000 , credenciais admin/admin )cat /proc//smaps Erigon usa aproximadamente 4 Gb de RAM durante a sincronização do genesis e aproximadamente 1 Gb durante o trabalho normal. O cache de páginas do sistema operacional pode utilizar uma quantidade ilimitada de memória.
Aviso: Múltiplas instâncias do Erigon na mesma máquina tocarão no disco simultaneamente, o que afeta o desempenho - uma das principais otimizações do Erigon: "reduzir o acesso aleatório ao disco". O "estágio de execução de blocos" ainda faz muitas leituras aleatórias - por isso é o estágio mais lento. Não recomendamos executar várias sincronizações do genesis no mesmo disco. Se a sincronização do genesis for aprovada, não há problema em executar várias instâncias do Erigon no mesmo disco.
(Como gp3) Você pode ler: # 1516 (comentário) Resumindo: discos de rede são ruins para a execução de blocos - porque bloqueia a execução lendo dados de maneira não paralela e não em lote do banco de dados. Truques: se você usar RAM suficiente e definir a variável de ambiente ERIGON_SNAPSHOT_MADV_RND=false - então o Erigon funcionará bem o suficiente em unidades de nuvem - com custo de IO mais alto.
Por exemplo: opção autodefrag do btrfs - pode aumentar o IO de gravação 100x vezes
Gnome Tracker - detectando mineiros e matando-os.
Para qualquer outra pessoa que estava recebendo o erro BuildKit ao tentar iniciar o Erigon da maneira antiga, você pode usar o seguinte ...
XDG_DATA_HOME=/preferred/data/folder DOCKER_BUILDKIT=1 COMPOSE_DOCKER_CLI_BUILD=1 make docker-compose
