NOC online · 24/7Longview, TX · +1 323 412 0665
KinetikatechServers · Security · Websites
KO

이 심층 가이드는 영어로 제공됩니다.

English version

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.

핵심 내용

  1. Raise network buffer sizes. net.core.rmem_max and wmem_max control socket buffer ceilings; defaults are too small for high throughput.
  2. Tune TCP congestion control. Use BBR for high-latency or lossy paths, and tune tcp_notsent_lowat for interactive traffic.
  3. Increase connection tracking limits. nf_conntrack_max must scale with concurrent connections to avoid dropped packets.
  4. Optimize NVMe queue depth. Set nr_requests and the scheduler to none or mq-deadline for NVMe devices.
  5. Pin interrupts to cores. Spread NIC and NVMe interrupts across cores to avoid a single bottleneck.
  6. Enable busy polling. net.core.busy_poll and busy_read reduce latency for high-frequency small packets.
  7. Tune the scheduler. EEVDF replaces CFS in recent kernels; adjust sched_latency_ns for your workload.
  8. 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

Network stack tuning bash
# /etc/sysctl.d/99-network.conf
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_congestion_control = bbr
net.core.netdev_max_backlog = 5000
net.core.somaxconn = 65535
net.netfilter.nf_conntrack_max = 1048576
NVMe and I/O tuning bash
# set scheduler to none for NVMe
echo none > /sys/block/nvme0n1/queue/scheduler
# increase queue depth
echo 1024 > /sys/block/nvme0n1/queue/nr_requests
# disable readahead for random I/O
echo 0 > /sys/block/nvme0n1/queue/read_ahead_kb
# verify
nvme list
iostat -x 1 5
Interrupt and CPU affinity bash
# spread NIC interrupts across cores
for irq in $(grep eth0 /proc/interrupts | awk '{print $1}' | tr -d ':'); do
  echo $((1 << (RANDOM % 8))) > /proc/irq/$irq/smp_affinity

done
# verify distribution
cat /proc/interrupts | grep eth0
# profile
perf stat -e 'net:net_dev_xmit,block:block_rq_issue' -a sleep 10

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의 지원

저희가 매일 하는 일: Kernel tuning, eBPF data planes, and service meshes for fleets that cannot afford downtime. 당사의 서버 관리 및 Linux 서버 보안 서비스는 평가, 구현, 24시간 연중무휴 모니터링, 30분 이내 긴급 대응을 엔드투엔드로 제공합니다.

엔지니어와 상담하기

서버 문제? 해킹된 웹사이트? 느린 페이지?

심각한 장애에 30분 이내 대응 — 24시간, 주 7일.

긴급 지원 요청 support@kinetikatech.com