Performance

Chapter 47: Memory & CPU Optimization

Overview

Optimizing blockchain node performance is crucial for maintaining network participation, reducing operational costs, and ensuring reliable RPC services. Blockchain nodes are resource-intensive applications that require careful tuning of memory, CPU, storage, and network parameters. This chapter provides comprehensive guidance on optimizing node performance across different hardware configurations and use cases.

---

47.1 Memory Optimization

Understanding Memory Usage

Blockchain nodes have complex memory requirements:

┌─────────────────────────────────────────────────────────────┐
│              GETH MEMORY USAGE BREAKDOWN                       │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  Total Memory: 16-64 GB                                     │
│                                                              │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                    Heap Memory                        │   │
│  │  ┌───────────┬───────────────┬───────────────┐    │   │
│  │  │  State    │  Cache        │  Trie Cache   │    │   │
│  │  │  (EVM)    │  (Blocks)     │  (Merkle)     │    │   │
│  │  │  ~4GB     │  ~2GB         │  ~2GB         │    │   │
│  │  └───────────┴───────────────┴───────────────┘    │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                              │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                Off-Heap Memory                       │   │
│  │  ┌───────────┬───────────────┬───────────────┐    │   │
│  │  │ LevelDB   │  MDBX         │  Snapshots    │    │   │
│  │  │ Cache     │  Cache        │  (Read-Only)  │    │   │
│  │  │ ~4GB      │  ~4GB         │  ~8GB         │    │   │
│  │  └───────────┴───────────────┴───────────────┘    │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Cache Configuration

Geth Cache Flags

# Cache size in megabytes
# Default: 4096 MB (4 GB)

# For 16GB RAM system
geth --cache 4096

# For 32GB RAM system
geth --cache 8192

# For 64GB RAM system
geth --cache 16384

# For high-performance servers
geth --cache 32768

# View cache statistics
geth attach http://localhost:8545
> debug.getBlockChainInfo()

Memory-Tuned Configuration

Configuration for Different RAM Sizes

System RAM	Cache	GC Settings	Notes
8 GB	2048	Default	Minimal configuration
16 GB	4096	Default	Standard configuration
32 GB	8192	GOGC=200	Good performance
64 GB	16384	GOGC=300	High performance
128 GB	32768	GOGC=400	Maximum performance

# High-memory configuration
export GOGC=300
export GOMEMLIMIT=32GiB

geth \
    --cache 16384 \
    --cache.database 8192 \
    --cache.trie 4096 \
    --cache.snapshot 25    # % of cache for snapshots (not MB; default 10%)

Memory Monitoring

# Monitor memory usage
watch -n 5 'free -h'

# Detailed process memory
ps aux | grep geth

# Memory over time
pmap -x $(pgrep geth) | tail -1

# Check for memory leaks
journalctl -u geth | grep -i "memory"
journalctl -u geth | grep -i "gc"

# Using gotop (if installed)
gotop

---

47.2 CPU Optimization

CPU Architecture Considerations

┌─────────────────────────────────────────────────────────────┐
│           CPU OPTIMIZATION STRATEGY                           │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  Blockchain Workload:                                        │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  40% - Cryptographic operations (hashing)          │   │
│  │  30% - Database I/O (LevelDB/RocksDB)              │   │
│  │  20% - Network processing                           │   │
│  │  10% - State trie processing                        │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                              │
│  Recommendations:                                            │
│  ✓ High single-thread performance is critical              │
│  ✓ More cores help with parallel processing                │
│  ✓ AVX2/AVX-512 instructions for crypto                  │
│  ✓ ECC RAM for stability                                    │
│                                                              │
└─────────────────────────────────────────────────────────────┘

CPU Configuration

# Limit CPU usage (useful for shared servers)
taskset -c 0-3 geth --syncmode snap

# View available cores
nproc

# Check CPU flags for crypto support
grep -o 'avx[0-9]*' /proc/cpuinfo | head -1

# Disable hyperthreading (sometimes helps)
# In BIOS, or via:
tuna --cores=0-7 geth

Go Runtime Optimization

# GOMAXPROCS is a Go runtime setting, set via environment, not a geth CLI flag.
# The following is INVALID geth syntax — do not mix attach flags (--exec) with
# daemon flags (--gcmode):
#   geth --gcmode=archive --exec "GOMAXPROCS=16"   ❌

# Correct: set it in the environment / systemd unit
export GOMAXPROCS=16
# In systemd service:
Environment=GOMAXPROCS=16

---

47.3 Disk Optimization

Storage Requirements

Node Type	Storage	Growth/Year
Full Node	~1.2 TB	~100 GB
Archive Node	~12 TB	~500 GB
Pruned Node	~400 GB	~100 GB

Storage Performance Comparison

Storage Type	Read IOPS	Write IOPS	Notes
HDD	100	100	Not recommended
SATA SSD	50,000	20,000	Testnet only
NVMe SSD	500,000+	300,000+	Required for production
NVMe (Gen4)	700,000+	500,000+	Optimal

Optimal Storage Configuration

Partition Alignment

# Check current partition alignment
blockdev --report

# For NVMe, ensure 4K alignment
sudo fdisk -l /dev/nvme0n1

Filesystem Recommendations

# Use ext4 or XFS (not BTRFS for database)
# Format with optimal settings
sudo mkfs.ext4 -E stride=128,stripe-width=128 /dev/nvme0n1

# Mount with noatime for better performance
# /etc/fstab:
# /dev/nvme0n1 /data ext4 defaults,noatime,nodiratime,discard 0 2

Database Optimization

LevelDB Settings (Geth default)

# Geth automatically tunes LevelDB
# But you can override:

# Cache for LevelDB (and trie/snapshot caches)
geth --cache 8192

# Number of open files (real flag: --fdlimit; --cache.fdlimit is not a geth flag)
geth --fdlimit 1024

MDBX Settings (Erigon)

# Erigon uses MDBX (memory-mapped B+ tree), NOT RocksDB — there is no
# --db.allow_unfastiate_geth flag and no "RocksDB tuning" for Erigon.
# Real tuning knobs:
erigon \
    --db.size.limit=3TB \
    --private.api.addr=localhost:9090 \
    --prune htc

Disk Monitoring

# Check disk I/O
iostat -x 5

# Check disk usage
df -h

# Check I/O wait (high = bottleneck)
vmstat 1

# Monitor disk queue
iostat -x 1 | grep -E "Device|vd[a-z]"

# Benchmark storage
fio --name=random_read --ioengine=libaio --iodepth=32 \
    --bs=4k --size=1G --numjobs=4 --runtime=30 \
    --readonly --filename=/tmp/fio_test

---

47.4 Network Optimization

Network Bandwidth

Node Type	Min Bandwidth	Recommended
Light Node	10 Mbps	100 Mbps
Full Node	50 Mbps	1 Gbps
Archive Node	100 Mbps	10 Gbps
Validator	100 Mbps	1 Gbps

Network Configuration

# Increase file descriptors
echo "* soft nofile 65536" | sudo tee -a /etc/security/limits.conf
echo "* hard nofile 65536" | sudo tee -a /etc/security/limits.conf

# For running user:
echo "$USER soft nofile 65536" | sudo tee -a /etc/security/limits.conf
echo "$USER hard nofile 65536" | sudo tee -a /etc/security/limits.conf

# Increase network buffers
sudo sysctl -w net.core.rmem_max=16777216
sudo sysctl -w net.core.wmem_max=16777216

# Persist settings
echo "net.core.rmem_max=16777216" | sudo tee -a /etc/sysctl.conf
echo "net.core.wmem_max=16777216" | sudo tee -a /etc/sysctl.conf

P2P Optimization

# Increase max peers
geth --maxpeers 100

# Adjust dial metrics
geth --nat extip:YOUR_PUBLIC_IP

# Enable pprof (bound to localhost by default; --pprof.addr/--pprof.port configure it)
geth --pprof --pprof.addr localhost

---

47.5 Full Optimization Guide

High-Performance Configuration

systemd Service File

[Unit]
Description=Ethereum Geth Node
After=network.target

[Service]
Type=simple
User=ethereum
WorkingDirectory=/home/ethereum
ExecStart=/usr/local/bin/geth \
    --mainnet \
    --syncmode snap \
    --cache 16384 \
    --cache.database 8192 \
    --cache.trie 4096 \
    --cache.snapshot 25 \
    --maxpeers 100 \
    --http \
    --http.addr 0.0.0.0 \
    --http.port 8545 \
    --http.api eth,net,web3,debug,txpool \
    --http.vhosts "*" \
    --http.corsdomain "*" \
    --ws \
    --ws.addr 0.0.0.0 \
    --ws.port 8546 \
    --ws.api eth,net,web3 \
    --ws.origins "*" \
    --datadir /data/ethereum \
    --keydir /data/ethereum/keystore \
    --allow-insecure-unlock \
    --rpc.gascap 50000000 \
    --rpc.txfeecap 100 \
    --ws.txfeecap 10 \
    --pprof \
    --pprof.addr localhost \
    --pprof.port 6060

# Memory limits
MemoryMax=64G
MemoryHigh=48G

# CPU limits
CPUAffinity=0-15

# Restart settings
Restart=on-failure
RestartSec=5s
StandardOutput=append:/var/log/geth/output.log
StandardError=append:/var/log/geth/error.log

[Install]
WantedBy=multi-user.target

Performance Tuning Script

optimize_node.sh

#!/bin/bash
echo "=== Ethereum Node Performance Optimization ==="

# 1. Set kernel parameters
echo "Configuring kernel parameters..."
cat >> /etc/sysctl.conf << EOF
# Network optimizations
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216

# File descriptor limits
fs.file-max=65536

# Blockchain specific
vm.max_map_count=1048576
EOF

sysctl -p

# 2. Set resource limits
echo "Configuring resource limits..."
cat >> /etc/security/limits.conf << EOF
* soft nofile 65536
* hard nofile 65536
* soft memlock unlimited
* hard memlock unlimited
EOF

# 3. CPU governor
echo "Setting CPU governor..."
for cpu in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
    echo performance > $cpu
done

# 4. Disable transparent huge pages
echo "Disabling transparent huge pages..."
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# 5. Set IO scheduler (for SSDs)
echo "Setting IO scheduler..."
for disk in /sys/block/sd*/queue/scheduler; do
    echo none > $disk
done

echo "=== Optimization Complete ==="
echo "Please restart your node for changes to take effect"

---

47.6 Performance Monitoring

Key Metrics

Metric	Good	Warning	Critical
CPU Usage	< 60%	60-80%	> 80%
Memory Usage	< 70%	70-85%	> 85%
Disk I/O Wait	< 10%	10-20%	> 20%
Network In	Stable	Variable	Dropping
Peer Count	> 10	5-10	< 5

Prometheus Metrics

# node_exporter config for system metrics
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

  - job_name: 'geth'
    static_configs:
      - targets: ['localhost:6060']

Grafana Dashboard

Create a dashboard with these key queries:

# CPU Usage
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Memory Usage
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100

# Disk I/O
rate(node_disk_read_bytes_total[5m])
rate(node_disk_written_bytes_total[5m])

# Network Traffic
rate(node_network_receive_bytes_total{device="eth0"}[5m])
rate(node_network_transmit_bytes_total{device="eth0"}[5m])

# Geth sync progress — there is no ethereum_block_height / ethereum_network_block
# pair. Use the node's own metrics: chain_head_block vs the highest header seen
# (a wide gap = node behind while the network advances):
chain_head_block
chain_head_header
# stalled-sync alert instead of a percentage:
increase(chain_head_block[10m]) == 0

---

47.7 Troubleshooting Performance

Common Issues

High Memory Usage

# Check memory consumption
ps aux --sort=-%mem | head -10

# Check for memory leaks
journalctl -u geth | grep -i "out of memory"

# Reduce cache if needed
geth --cache 4096

High CPU Usage

# Find process using most CPU
top -o %CPU

# Check for runaway goroutines
curl http://localhost:6060/debug/pprof/goroutine?debug=1

# Reduce sync activity
geth --syncmode full

Disk Bottleneck

# Check I/O wait
iostat -x 1

# Find I/O heavy processes
iotop

# Consider upgrading to NVMe
lsblk -d -o NAME,TYPE,ROTA

---

47.8 Operating System & Kernel Tuning

System-level (kernel + limits) tuning complements client flags. These settings apply to any node daemon and generally use mainstream Linux sysctls.

File Descriptor Limits

Blockchain clients open many sockets and files. The default ulimit -n of 1024 is far too low:

/etc/security/limits.conf

* soft nofile 65536
* hard nofile 65536
root soft nofile 65536
root hard nofile 65536

# Apply to the current shell / service
ulimit -n 65536
# verify
ulimit -n

Network Kernel Tuning

# /etc/sysctl.conf — socket buffers and backlog
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.core.netdev_max_backlog=50000

# Apply
sudo sysctl -p

Disable Transparent Huge Pages

Transparent Huge Pages (THP) can cause latency spikes for memory-heavy daemons (this is also the standard recommendation for PostgreSQL and Redis):

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

Disable Hyper-Threading (Optional)

Some validators see more consistent performance with HT disabled, because concurrent threads on the same core compete for execution units, causing jitter in block-processing latency:

# Check current sibling layout
lscpu -e
# Symmetric multiprocessing off via kernel cmdline: add "nosmt" to GRUB_CMDLINE_LINUX
# /etc/default/grub → GRUB_CMDLINE_LINUX="nosmt"  then update-grub

CPU Frequency Scaling

# Verify the governor
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# Pin to performance mode (cpupower from linux-tools)
sudo cpupower frequency-set -g performance

⚠️ Validators on consumer hardware should also disable C-states / use a stable clock if the firmware allows; clock jitter increases missed attesting slots in PoS networks.

---

Summary

• Memory: Allocate appropriate cache based on available RAM (typically 50-75% of available memory)
• CPU: Prioritize single-thread performance; more cores help with parallelism
• Storage: NVMe SSDs are mandatory for production nodes
• Network: Ensure adequate bandwidth and configure file descriptor limits
• Monitoring: Track key metrics and set up alerts for degradation
• Tuning: Use the comprehensive configuration examples provided for your hardware
• Optimization: Run the optimization script for system-level improvements

---

Next Chapter

In Chapter 48: Network Connectivity Issues, we’ll explore network troubleshooting.

---

Last Updated: 2026-10-07