Optimizing Database Server Hardware: CPU, Memory, Disk, and Network Best Practices

Various official databases have hardware requirements; this article explains why these settings are needed, how they differ, and explores hardware parameter optimization based on those requirements.

CPU

CPU selection : Distinguish between compute‑oriented and storage‑oriented CPUs. Compute CPUs need more cores and higher frequencies, while storage CPUs can be modest. For TiDB, consider TiDB server (compute) vs. TiKV (storage) when planning hardware to reduce cost.

CPU architecture : X86 (Intel/AMD) is the dominant server architecture; ARM appears in phones, Macs, and some Chinese servers. Most companies purchase X86‑64 CPUs, but ARM servers are being evaluated for databases like MySQL, Redis, and TiDB.

NUMA binding : Enabling NUMA prefers local memory, improving latency on multi‑core CPUs. When local memory is insufficient, allocation falls back to other NUMA nodes, similar to disabling NUMA. Recommended for single‑machine multi‑database deployments.

CPU dynamic power management : The cpufreq module offers several modes. For best performance, use the performance governor to keep the CPU at its highest frequency; the default powersave can be changed with cpupower frequency-set .

Memory

Disable swap : Swap uses disk when memory usage exceeds a threshold (default vm.swappiness=60). Production TiDB clusters need ample RAM; using swap degrades performance, so permanently disable it.

min_free_kbytes : Controls how much memory stays free from filesystem cache. For systems with >40 GB RAM, set this to at least 1 GB but not more than 5 % of total memory to avoid OOM kills.

Turn off Transparent Huge Pages (THP) : Databases access memory sparsely; THP can cause high latency and CPU spikes. Disabling THP improves stability.

dirty_ratio / dirty_background_ratio : Define when the kernel starts flushing dirty pages. Defaults (20 % and 10 %) are usually fine; for high‑performance NVMe SSDs, lower values can speed up memory reclamation.

Disk

Disk selection : Options include SAS/SATA SSD, PCIe SSD, and persistent memory (e.g., Intel Optane). SAS pairs with RAID cards; SATA supports hot‑swap at up to 6 GB/s; PCIe SSDs use NVMe for superior performance; persistent memory offers low‑latency writes for demanding workloads.

I/O scheduler : Noop – simple FIFO, best for fast NVMe devices. CFQ – fair queuing per process, may suffer under heavy I/O. Deadline – prioritizes reads, provides higher throughput when few processes compete.

Filesystem choice : ext4 supports up to 1 EB and 16 TB files, with optimized fsck; XFS offers excellent scalability, parallel I/O, and online defragmentation. TiDB prefers ext4 for its stability.

ext4 mount options : nodelalloc – disables delayed allocation to avoid write latency spikes. noatime – prevents updating access timestamps on reads, reducing unnecessary writes.

Network

Network speed : Choose 1 GbE for typical traffic; upgrade to 10 GbE for components with frequent heartbeats (e.g., PD, TiKV) or when handling 100 GbE workloads.

Network stability : Use dual NICs for redundancy (bonding mode 4) or separate NICs for data traffic and management/backup to avoid backup traffic impacting service.

Network troubleshooting steps : Monitor NIC utilization. Check connectivity with ethtool , ping , telnet . Use traceroute and iftop to view latency and bandwidth. Detect packet loss with ethtool -S eth0 | grep drop or tcpdump .