What is Performance Tuning? How to Perform Tuning Across RHEL, SUSE, & Ubuntu

Performance tuning is the process of identifying bottlenecks and optimizing system resources (CPU, memory, storage, network, kernel, applications). We can achieve these Performance tunings by  adjusting kernel parameters, memory usage, I/O scheduling, and network stack settings to maximize throughput and minimize latency

The methodology is the same across RHEL, SUSE, and Ubuntu, although package managers and some tools differ.

The Performance Tuning Lifecycle

Performance Issue
        │
        ▼
Collect Baseline
        │
        ▼
Find Bottleneck
        │
        ▼
Tune One Component
        │
        ▼
Validate Improvement
        │
        ▼
Monitor Continuously

Note: Never tune multiple parameters at once—you won't know which change helped or caused a regression.

Note:  Please take current settings backup before making any changes.

sudo sysctl -a > "/etc/sysctl-$(date -d "today" +"%Y%m%d%H%M").bak"

1. How to Perform Tuning Across RHEL, SUSE, & Ubuntu

Linux tuning operates across two main tiers: Unified Adaptive Tuning (using TuneD) and Granular Kernel Subsystem Tuning (via sysctl, sysfs, and boot arguments).

A. The Unified Layer: TuneD

TuneD is the standard tuning daemon across RHEL, SUSE (SLES), and Ubuntu. It dynamically or statically applies sets of tuning profiles.

# Install TuneD if not present

RHEL/Rocky: dnf install tuned | SLES: zypper in tuned | Ubuntu: apt install tuned

# Start & enable service
systemctl enable --now tuned

# List available system profiles
tuned-adm list

# Check system recommendation
tuned-adm recommend

# Apply a specific profile
tuned-adm profile throughput-performance

Common Enterprise Profiles:

• throughput-performance: Disables power-saving, increases I/O queue sizes, tunes sysctl for high disk/network throughput.
• latency-performance: Minimizes OS latency/jitter by disabling CPU power states and C-states.
• virtual-guest: Optimized for virtual machines running on hypervisors.
• network-latency / network-throughput: Custom network stack optimizations.

B. Subsystem-Level Tuning

When custom profile adjustments are required, tune the following key kernel subsystems:

1. CPU & Scheduler Tuning

2. Memory Subsystem

3. Disk I/O & Filesystems

4. TCP/IP Network Stack Tuning

Before making changes, capture the current state.

Step 1 : CPU & Scheduler Tuning

top ; htop ; mpstat -P ALL 1 ; vmstat 1 ; sar -u 1 10  && check following  from outputs

CPU utilization
User vs system CPU
Idle %
I/O wait
Steal time (important on VMs)

CPU Power Governor: Switch from powersave or ondemand to performance ( Physical servers)
cpupower frequency-set -g performance

Process Affinity & NUMA: Pin CPU cores and memory nodes for high-performance databases or VMs to prevent cross-node memory latency:
numactl --cpunodebind=0 --membind=0 my_application

Step 2 : Memory Tuning

free -h ; vmstat ; sar -r ; smem  && following  from outputs

Available memory
Swap usage
OOM Killer events
Page faults
HugePages

Swappiness (vm.swappiness): Reduces aggressiveness of swapping memory pages to disk.

Default: 60 | Databases/Hypervisors: 1 to 10

Dirty Memory Page Flushing (vm.dirty_ratio, vm.dirty_background_ratio): Controls when dirty pages in RAM are flushed to storage.

High I/O Burst Workloads: Lower ratios (e.g., dirty_ratio=10, dirty_background_ratio=5) to prevent I/O stalls.

HugePages: Allocate static 2MB or 1GB HugePages for memory-intensive engines (e.g., PostgreSQL, Oracle, KVM) to reduce TLB (Translation Lookaside Buffer) misses.

Step 3 :  Disk I/O & Filesystems

 
iostat -xz 1 ; iotop ; df -h ; du -sh * ; lsof ; sar -d  && check following from outputs

Important metrics

%util

await

queue depth

I/O Schedulers: Set appropriate block layer schedulers via /sys/block/<device>/queue/scheduler:

NVMe / Fast SSDs: none or kyber

SATA SSDs / SAN LUNs: mq-deadline

Virtual Disks: none or mq-deadline

Mount Options: Disable access time updates for file-heavy workloads which will reduce metadata writes.

# in /etc/fstab

UUID=... /data ext4 defaults,noatime,nodiratime 0 0

Increase file descriptor limits for high‑concurrency servers.

Step 4 : TCP/IP Network Stack Tuning

ss -tulpn ;  ip -s link ;  sar -n DEV ; ethtool ; tcpdump && check following from outputs

Packet drops

Retransmissions

Errors

Bandwidth

MTU

Duplex

set custom socket limits in /etc/sysctl.d/99-network-tuning.conf




# Increase socket backlog connection limits

net.core.somaxconn = 4096 or 10240

net.core.netdev_max_backlog = 10000

# Increase TCP read/write buffer limits (for high-bandwidth links)

net.core.rmem_max = 16777216

net.core.wmem_max = 16777216

net.ipv4.tcp_rmem = 4096 87380 16777216

net.ipv4.tcp_wmem = 4096 65536 16777216

# Enable TCP BBR Congestion Control (Kernel 4.9+)

net.core.default_qdisc = fq

net.ipv4.tcp_congestion_control = bbr

Step 5 : Process Analysis

top -c ; ps aux --sort=-%cpu ; ps aux --sort=-%mem ; pidstat &&  look for following logs

CPU hog

Memory leak
Zombie process
Blocked process

Step 6 : File system Analysis

df -h ; df -i ; mount ; xfs_info ; tune2fs  &&  look for following logs
Filesystem nearly full (>85–90%)
Inode exhaustion
Mount options

Step 7 : Kernel Messages Analysis  

dmesg ;  journalctl -xe ; journalctl -k  &&  look for following logs
OOM
Disk errors
NIC resets
Driver problems
Kernel panic

Compare pre-tuning and post-tuning benchmark metrics:

Disk I/O Latency & Throughput (fio):

fio --name=random-rw --ioengine=libaio --rw=randrw --bs=4k --direct=1 --numjobs=4 --iodepth=32 --size=2G --runtime=60 --group_reporting

CPU & Memory Bandwidth (sysbench):

sysbench cpu --cpu-max-prime=20000 run sysbench memory --memory-block-size=1M --memory-total-size=100G run

Network Bandwidth (iperf3):

# Server: iperf3 -s | Client: 

iperf3 -c <server_ip> -P 8