4 posts tagged with "memory"

How much machine does an Ethereum execution client need once it sits at the tip of mainnet? Our fleet runs every major execution client on its own host, all with 12 cores, five of six client sets with 16 GiB RAM, one consensus client per pairing on a separate machine. Same chain, same engine-API traffic, one telemetry pipeline. Averaged over the same 36 hours, the synced clients hold between 4.9 and 15.6 GiB of host memory, burn about half a CPU core, and write to disk at anywhere from 0.9 to 22 MB/s. The spread is the story: the client you pick decides whether your box idles or works.

Six Besu nodes, same version, same hardware, same config. Five held a flat JVM heap around 1.0 to 1.3 GB. The sixth climbed about 10 GB a day and was on track to be OOM-killed roughly 30 hours after a restart. The one thing different about it was the consensus client on the other side of the engine API.

This is a walkthrough of how StereumLabs AI, reading our fleet's metrics and logs, took that one anomalous node, traced it to a single method, and filed it upstream. Besu shipped a round of mitigations and closed the issue. A later devnet reproduction showed the underlying layers still pile up, the issue was reopened, and the fix that followed is now in review. The bug is operational: recoverable by a restart, no consensus impact, no double-sign, no state-root divergence. It is also the kind of cross-client interaction a single-node test will never surface, because it only appears when a live pairing lands in a specific state.

A deep dive into how Teku evolved across three releases: the RocksDB migration in 26.2.0, jemalloc in 26.3.0, and what both changes mean for CPU, memory, GC overhead, disk I/O, and block import latency on real hardware.

Let's have a look at both versions of Prysm 7.1.1 and 7.1.2 and it's resource consumption