{"id":1316,"date":"2026-10-06T22:36:03","date_gmt":"2026-10-06T22:36:03","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1316"},"modified":"2026-10-06T22:36:03","modified_gmt":"2026-10-06T22:36:03","slug":"linux-kernel-entropy-high-connection-tuning","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/linux-kernel-entropy-high-connection-tuning\/","title":{"rendered":"Tuning Linux Kernel Entropy for High-Connection Servers"},"content":{"rendered":"\n\n

On a busy connection-handling server, the kernel’s random number generator is a shared resource that most operators never think about \u2014 until TLS handshakes stall or a service blocks reading \/dev\/random<\/code>. High-connection workloads consume entropy faster than casual servers do: every getrandom()<\/code> 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.<\/p>\n\n\n\n

What Changed in Modern Kernels<\/h2>\n\n\n\n

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

Reading the Entropy State<\/h2>\n\n\n\n
cat \/proc\/sys\/kernel\/random\/entropy_avail\ncat \/proc\/sys\/kernel\/random\/poolsize\ncat \/proc\/sys\/kernel\/random\/urandom_min_reseed_secs\ndmesg | grep -i crng      # \"crng init done\" marks readiness<\/code><\/pre>\n\n\n\n
entropy_avail<\/code> below ~128 and no crng init done<\/code> 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.<\/p>\n\n\n\n
The Right Fix: Hardware and Paravirtual RNG<\/h2>\n\n\n\n
The clean solution is a real entropy source, not a userspace shuffler. Modern CPUs expose RDSEED<\/code>\/RDRAND<\/code>, and virtualized hosts expose virtio-rng<\/code> or the analogous hypervisor RNG device. Verify what the guest sees:<\/p>\n\n\n\n
grep -m1 rng \/proc\/crypto\nls \/sys\/devices\/virtual\/misc\/ | grep -i hwrng\ncat \/sys\/devices\/virtual\/misc\/hw_random\/rng_available 2>\/dev\/null\ndmesg | grep -Ei 'virtio_rng|hwrng|rng_core'<\/code><\/pre>\n\n\n\n
If no hardware RNG is present, ask the provider to attach a virtual RNG device \u2014 it is a one-line hypervisor setting and eliminates the boot-time stall entirely. Relying on haveged<\/code> or rng-tools<\/code> 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.<\/p>\n\n\n\n
Sizing for High-Connection Workloads<\/h2>\n\n\n\n
Once the CRNG is seeded, throughput is not the bottleneck \u2014 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:<\/p>\n\n\n\n