From 9f32c8fea2d3edd65eb2d923c6e0ee97dedbb81a Mon Sep 17 00:00:00 2001 From: Alex Sharov Date: Mon, 1 Jul 2024 15:34:45 +0700 Subject: [PATCH] e3: docs update (#10949) --- README.md | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 19dc6c4392f..69965278a28 100644 --- a/README.md +++ b/README.md @@ -787,13 +787,13 @@ Supported networks: all (except Mumbai). - E3 can execute 1 historical transaction - without executing it's block - because history/indices have transaction-granularity, instead of block-granularity. - E3 doesn't store Logs (aka Receipts) - it always re-executing historical txn (but it's cheaper then in E2 - see point - above). Also Logs LRU added in E2 (release/2.60) and E3: https://github.com/ledgerwatch/erigon/pull/10112 - here. Likely later we will add optional flag "to persist receipts". + above). Known perf issues: https://github.com/ledgerwatch/erigon/issues/10747 - `--sync.loop.block.limit` is enabled by default. (Default: `5_000`. Set `--sync.loop.block.limit=10_000 --batchSize=1g` to increase sync speed on good hardware). -- datadir/chaindata is small now - to prevent it's grow: we recommend set `--batchSize <= 1G`. And it's fine +- datadir/chaindata is small now - to prevent it's grow: we recommend set `--batchSize <= 2G`. And it's fine to `rm -rf chaindata` - can symlink/mount latest state to fast drive and history to cheap drive +- ArchiveNode is default. FullNode same as in E2: --prune=hrtc ### E3 datadir structure @@ -871,13 +871,8 @@ du -hsc /erigon/snapshots/* ### E3 other perf trics -- `--sync.loop.block.limit=10_000_000 --batchSize=1g` - likely will help for sync speed. -- on cloud-drives (good throughput, bad latency) - can enable OS's brain to pre-fetch some data (`madv_normal` instead - of `madv_random`). For `snapshots/domain` folder (latest - state) `KV_MADV_NORMAL_NO_LAST_LVL=accounts,storage,commitment` (or if have enough - RAM: `KV_MADV_NORMAL=accounts,storage,commitment`). For `chaindata` folder (latest updates) `MDBX_READAHEAD=true`. - For all files - `SNAPSHOT_MADV_RND=false` - +- `--sync.loop.block.limit=10_000 --batchSize=2g` - likely will help for sync speed. +- on cloud-drives (good throughput, bad latency) - can enable OS's brain to pre-fetch: `SNAPSHOT_MADV_RND=false` - can lock latest state in RAM - to prevent from eviction (node may face high historical RPC traffic without impacting Chain-Tip perf):