In the world of Web3 infrastructure, disk I\/O is almost always the ultimate bottleneck. Running a high-throughput blockchain node\u2014whether it\u2019s an Ethereum execution client like Erigon, a Solana validator, or a heavy-data indexer\u2014demands relentless, parallel, low-latency disk writes.<\/p>\n\n\n\n
When you run these workloads on virtualized cloud instances, you are inherently fighting a losing battle. Cloud providers throttle your Input\/Output Operations Per Second (IOPS), abstract your storage layers, and charge a premium for “burst” performance.<\/p>\n\n\n\n
Bare-metal hardware changes the game. Running on dedicated iron gives you direct access to the Linux kernel, allowing you to bypass hypervisor overhead and squeeze every ounce of performance out of your NVMe drives.<\/p>\n\n\n\n
Here is how to tune your bare-metal Linux storage stack specifically for the punishing write cycles of blockchain databases.<\/p>\n\n\n\n
Traditional disk schedulers (like For dedicated blockchain infrastructure, you generally want one of two paths:<\/p>\n\n\n\n To see what scheduler your drive (e.g., bfq<\/code>) try to be smart about sorting I\/O requests to accommodate spinning platters or general-purpose workloads. For high-throughput, multi-threaded database writes on modern NVMe drives, this “intelligence” just introduces CPU overhead and latency.<\/p>\n\n\n\n\n
none<\/code><\/strong>: Completely bypasses the OS-level scheduler, handing I\/O management entirely to the NVMe controller’s native hardware queues.<\/li>\n\n\n\nkyber<\/code><\/strong>: A lightweight, modern scheduler designed specifically for fast storage. It prioritizes low latency by capping maximum read\/write delays.<\/li>\n<\/ul>\n\n\n\nCheck Current Scheduler<\/h3>\n\n\n\n
nvme0n1<\/code>) is currently using, run:<\/p>\n\n\n\n