Next-Gen Server Administration and Cloud Workloads
Deep-Dive Linux Kernel Performance Tuning: Optimizing High-Concurrency Network Stacks and NVMe I/O Queues
Default kernel settings are tuned for general-purpose workloads, not for servers handling tens of thousands of connections or millions of IOPS. Network stack defaults, NVMe queue depths, and scheduler parameters all leave performance on the table. This guide tunes the kernel for high-concurrency servers.
要点
- Raise network buffer sizes. net.core.rmem_max and wmem_max control socket buffer ceilings; defaults are too small for high throughput.
- Tune TCP congestion control. Use BBR for high-latency or lossy paths, and tune tcp_notsent_lowat for interactive traffic.
- Increase connection tracking limits. nf_conntrack_max must scale with concurrent connections to avoid dropped packets.
- Optimize NVMe queue depth. Set nr_requests and the scheduler to none or mq-deadline for NVMe devices.
- Pin interrupts to cores. Spread NIC and NVMe interrupts across cores to avoid a single bottleneck.
- Enable busy polling. net.core.busy_poll and busy_read reduce latency for high-frequency small packets.
- Tune the scheduler. EEVDF replaces CFS in recent kernels; adjust sched_latency_ns for your workload.
- Measure with perf. Use perf stat and bpftrace to confirm bottlenecks before and after changes.
Architecture
The network path runs from the NIC through the kernel stack into the application, and the storage path runs from the application through the block layer to NVMe. Interrupts, queues, and buffers at each layer determine throughput and latency. Tuning aligns these layers with the workload.
Production configuration
Edge cases from production
- BBR can be unfair to CUBIC flows on shared links; test in your network before deploying.
- Increasing buffers raises memory usage; size them to your connection count.
- NVMe queue depth above device limits is ignored; check the drive's maximum.
- Interrupt pinning must be redone after a NIC driver reload or reboot.
よくある質問
How do I know which setting to change?
Profile first with perf and ss; change one setting at a time and measure.
Does BBR always improve throughput?
It helps on lossy or high-latency paths; on clean LANs CUBIC is often fine.
Can tuning break connectivity?
Aggressive buffer changes rarely break things, but always test in staging first.
How do I make changes persistent?
Use /etc/sysctl.d for sysctl and udev rules or a systemd service for block device settings.
What is the biggest win?
Usually connection tracking limits and NIC interrupt distribution on busy servers.
next-gen server administration and cloud workloads に対するKinetikatechの支援
next-gen server administration and cloud workloads の専門家になる必要はありません:Kernel tuning, eBPF data planes, and service meshes for fleets that cannot afford downtime. それがまさにサーバー管理とLinuxサーバーセキュリティが存在する理由です。セットアップ、強化、監視、そして昼夜を問わず駆けつける人間のサポート。