Tuning Linux Kernel Entropy for High-Connection Servers

On a busy connection-handling server, the kernel’s random number generator is a shared resource that most operators never think about — until TLS handshakes stall or a service blocks reading /dev/random. High-connection workloads consume entropy faster than casual servers do: every getrandom() call for a session key, nonce, or TCP initial sequence number taps the pool. This guide explains how the modern Linux RNG works, how to measure it, and how to make sure high-connection instances never block on randomness.

What Changed in Modern Kernels

For years, /dev/random blocked once the estimated entropy count was exhausted. Since Linux 5.6, the ChaCha20-based CRNG is seeded early and /dev/random no longer blocks after the pool is initialised — it behaves like /dev/urandom once the CRNG is ready. The practical consequence: the only window where randomness can be scarce is early boot, before the CRNG is initialised, which matters a lot for VMs that curl secrets or generate keys at startup.

Reading the Entropy State

cat /proc/sys/kernel/random/entropy_avail
cat /proc/sys/kernel/random/poolsize
cat /proc/sys/kernel/random/urandom_min_reseed_secs
dmesg | grep -i crng      # "crng init done" marks readiness

entropy_avail below ~128 and no crng init done line in the log means the pool is not yet ready. On a physical server this is a boot-time blip; on a freshly cloned VM with no hardware RNG and a fixed disk image, the same state can persist for seconds and stall anything that needs a key. Watch for services logging “waiting for random” during startup, and correlate any first-minute latency spike with this window.

The Right Fix: Hardware and Paravirtual RNG

The clean solution is a real entropy source, not a userspace shuffler. Modern CPUs expose RDSEED/RDRAND, and virtualized hosts expose virtio-rng or the analogous hypervisor RNG device. Verify what the guest sees:

grep -m1 rng /proc/crypto
ls /sys/devices/virtual/misc/ | grep -i hwrng
cat /sys/devices/virtual/misc/hw_random/rng_available 2>/dev/null
dmesg | grep -Ei 'virtio_rng|hwrng|rng_core'

If no hardware RNG is present, ask the provider to attach a virtual RNG device — it is a one-line hypervisor setting and eliminates the boot-time stall entirely. Relying on haveged or rng-tools to top up the pool is a workaround for environments that cannot expose a real source; it works, but a paravirtual RNG is strictly better because it feeds the kernel’s own CRNG rather than a userspace estimate of entropy.

Sizing for High-Connection Workloads

Once the CRNG is seeded, throughput is not the bottleneck — a single core can generate hundreds of megabytes of output per second, far beyond any TLS workload. The failure mode is never “ran out of entropy during steady state”; it is “booted without a seed and blocked once.” Two habits prevent it:

• Persist the seed across reboots. systemd-random-seed saves the CRNG state to disk on shutdown and restores it early on boot, so a well-behaved VM starts with a primed pool. Ensure the save happens on every clean shutdown.
• Seed early, not lazily. Services that generate keys at first start should wait for CRNG readiness, not run before it. Mark such units to start after systemd-random-seed.service.
• Avoid cloned-image duplication. Two VMs cloned from the same snapshot can inherit identical seed state; make sure each restores a distinct seed rather than sharing one image’s entropy.

Verifying Under Load

Test the real path your workload uses. A quick loop that pulls random bytes at connection rate confirms nothing blocks, and a bulk read confirms sustained throughput is far above any realistic TLS demand:

for i in $(seq 1 10000); do head -c 32 /dev/urandom > /dev/null; done
time dd if=/dev/urandom of=/dev/null bs=1M count=256

If a TLS termination tier occasionally shows handshake latency spikes that correlate with instance startup, suspect CRNG readiness on freshly booted nodes rather than entropy exhaustion in steady state. That correlation is the giveaway: spikes clustered at instance launch point to boot-time seeding, not to sustained load. On ephemeral or rapidly scaled fleets this is especially likely, and it is another reason to prefer hosts that expose a virtual RNG and give each instance a persistent seed. When you evaluate providers, check whether the platform documents its RNG device and per-instance resource guarantees — details like these are listed on the plan specifications page.

Summary Checklist

Treat entropy as a boot-time concern first and a steady-state concern second. On modern kernels the CRNG will not starve under normal connection load, but a VM with no hardware RNG and a duplicated seed can block exactly when it matters — during startup, when keys and session secrets are first generated. A virtual RNG device plus a persistent, per-instance seed removes that risk permanently. Because this failure mode is intermittent and correlated with instance launch, it is easy to misattribute to the network; the checklist below keeps the diagnosis grounded.

• Confirm crng init done appears early in dmesg.
• Expose virtio-rng or CPU RDRAND to the guest where possible.
• Let systemd-random-seed persist and restore the CRNG state.
• Order key-generating services after the random-seed unit.
• Benchmark /dev/urandom and a realistic handshake loop before and after changes — measure, do not assume.
• Alert on handshake latency spikes that correlate with instance startup.

For the broader tuning picture that surrounds this — CPU, memory, and network knobs that shape high-connection performance — start from the main hosting overview.