7 Practical Linux Performance Optimization Tips Every Engineer Should Know

1. What factors generally affect Linux system performance?

CPU load – high utilization slows processes and increases latency.

Memory usage – insufficient RAM leads to swapping, process termination, and degraded throughput.

Disk I/O – heavy I/O load raises response times and reduces overall throughput.

Network load – high traffic or packet loss can cause latency and resource contention.

Process scheduling – kernel scheduler settings influence priority and load balancing.

Filesystem performance – different filesystems and mount options impact I/O efficiency.

Kernel parameters – TCP/IP, memory management, and filesystem cache tweaks can improve resource utilization.

Resource limits and quotas – per‑user or per‑process caps prevent a single workload from exhausting system resources.

These factors interact, so effective optimization requires a holistic view and targeted adjustments.

2. Quick ways to diagnose problems at work

CPU performance analysis

Use top, vmstat, pidstat, strace or perf to collect CPU metrics.

Identify the offending process, then drill down with strace for system calls or perf for hotspot functions.

Memory performance analysis

Check free and vmstat output to spot memory pressure.

Investigate leaks, allocation patterns, or cache usage with tools such as pmap, smem or htop.

Disk and filesystem I/O analysis

Run iostat to detect high I/O utilization.

Correlate with pidstat, vmstat, lsof or perf to pinpoint the responsible process or filesystem.

Network performance analysis

Inspect interface throughput, packet loss and errors.

Use netstat, tcpdump or BCC tools to trace traffic and identify bottlenecks.

3. How to investigate high system load in Linux?

Run top or htop and check the load‑average; values above 70‑80 % of CPU cores indicate overload.

Examine CPU usage per process.

Check memory with free; watch for swapping.

Use iotop to see disk I/O pressure.

Inspect network connections with netstat or similar tools.

Review system and application logs for errors.

Apply perf or strace for detailed process‑level profiling.

Verify kernel and sysctl parameters (e.g., /etc/sysctl.conf) match workload requirements.

4. How to find the top‑5 load‑generating processes and their bottleneck resource?

CPU ranking: ps aux --sort=-%cpu | head -n 5 Memory ranking: ps aux --sort=-%mem | head -n 6 Disk I/O ranking: iotop -oP Additional commands used in practice:

# ps aux|grep -v USER|sort +2|tail -n 10

# ps aux|grep -v USER|sort +3|tail -n 10

iostat 1 10

– watch which disk shows high busy percentage.

5. Why does Linux memory reporting sometimes appear inaccurate?

Differences arise because:

Cache and buffers are counted as used memory by free but not by ps / top.

Shared memory is included in per‑process tallies but often omitted from aggregate reports.

Memory reclamation can cause a lag between what a process has released and what the kernel reports.

For a more precise view, combine free, /proc/meminfo, and specialized tools such as pmap, smem or monitoring platforms that retain historical data.

6. Current scenarios where swap is still useful

Memory shortage – provides a safety net when RAM is exhausted.

Hibernate/suspend – stores the RAM image on disk for later restoration.

Virtualized environments – allows the host to overcommit memory across VMs.

Memory reclamation and page replacement – enables the kernel to free physical pages for higher‑priority workloads.

Excessive swapping degrades performance; therefore, adequate physical memory and proper swap sizing are recommended.

7. Linux TCP tuning experiences and cases

Scenario 1 – Large numbers of TIME_WAIT connections

Increase net.ipv4.tcp_max_tw_buckets and net.netfilter.nf_conntrack_max.

Reduce net.ipv4.tcp_fin_timeout and net.netfilter.nf_conntrack_tcp_timeout_time_wait.

Enable port reuse: net.ipv4.tcp_tw_reuse = 1.

Expand local port range: net.ipv4.ip_local_port_range.

Raise file‑descriptor limits via fs.nr_open, fs.file-max or LimitNOFILE in systemd units.

Scenario 2 – Mitigating SYN‑FLOOD attacks

Increase half‑open queue size: net.ipv4.tcp_max_syn_backlog or enable SYN cookies with net.ipv4.tcp_syncookies = 1 (mutually exclusive).

Reduce retransmissions of SYN‑ACK: net.ipv4.tcp_synack_retries.

Scenario 3 – Long‑lived connections and Keepalive

Shorten keepalive probe interval: net.ipv4.tcp_keepalive_time.

Reduce interval between probes: net.ipv4.tcp_keepalive_intvl.

Limit number of failed probes before giving up: net.ipv4.tcp_keepalive_probes.

Conclusion

Enterprise Linux performance optimization is a challenging but essential skill for operations engineers. Mastering CPU, memory, disk, and network fundamentals, knowing which metrics to collect, and being proficient with tools such as top, vmstat, iostat, netstat, perf, and strace enables systematic analysis, accurate bottleneck identification, and effective tuning.