
ทำไมต้อง Linux Performance Tuning?
การปรับแต่ง Linux Server ให้ทำงานเร็วขึ้นเป็นหนึ่งในทักษะสำคัญที่สุดของ SysAdmin และ DevOps Engineer ในปี 2026 Server ที่ไม่ได้รับการปรับแต่งอาจใช้ทรัพยากรได้ไม่เต็มประสิทธิภาพ ทำให้แอปพลิเคชันตอบสนองช้า ค่าใช้จ่ายสูงขึ้น และประสบการณ์ผู้ใช้แย่ลง
บทความนี้จะครอบคลุมการปรับแต่งทุกด้านของ Linux Server ตั้งแต่ CPU, Memory, Disk I/O, Network ไปจนถึง Application-specific tuning
Tuning Workflow: แนวทางการปรับแต่งอย่างเป็นระบบ
ก่อนเริ่มปรับแต่ง ต้องเข้าใจ Tuning Workflow ที่ถูกต้อง ซึ่งประกอบด้วย 4 ขั้นตอนที่ทำซ้ำได้:
- Measure (วัด): เก็บ Baseline metrics ก่อนปรับแต่ง ใช้ tools เช่น vmstat, iostat, sar เก็บข้อมูลอย่างน้อย 24-48 ชั่วโมง
- Identify (ระบุ): วิเคราะห์ Bottleneck ว่าปัญหาอยู่ที่ CPU, Memory, Disk I/O หรือ Network ดูว่า Resource ตัวไหนถูกใช้เกิน 80%
- Tune (ปรับแต่ง): เปลี่ยน Parameter ทีละอย่าง อย่าเปลี่ยนหลายอย่างพร้อมกัน เพราะจะไม่รู้ว่าอะไรทำให้ดีขึ้นหรือแย่ลง
- Verify (ตรวจสอบ): วัดผลหลังปรับแต่ง เปรียบเทียบกับ Baseline ถ้าดีขึ้น เก็บไว้ ถ้าแย่ลง Rollback ทันที
# Tuning Workflow Loop:
# 1. Measure: เก็บ baseline
sar -A 1 3600 > /tmp/baseline_before.txt
# 2. Identify: วิเคราะห์ bottleneck
# CPU: sar -u, top, mpstat
# Memory: free -m, vmstat, /proc/meminfo
# Disk: iostat -xz, iotop
# Network: sar -n DEV, ss -s
# 3. Tune: เปลี่ยนทีละ parameter
sysctl -w vm.swappiness=10
# 4. Verify: วัดผลอีกครั้ง
sar -A 1 3600 > /tmp/baseline_after.txt
# เปรียบเทียบ before vs after
CPU Tuning
nice / renice — ปรับ Priority ของ Process
Nice value กำหนดความสำคัญของ Process ค่ายิ่งต่ำ (ติดลบ) ยิ่งได้ CPU มาก ค่ายิ่งสูง (บวก) ยิ่งได้ CPU น้อย ช่วง -20 ถึง 19 โดย 0 เป็นค่าเริ่มต้น
# เริ่ม Process ด้วย nice value ต่ำ (สำคัญมาก)
nice -n -10 /opt/myapp/server --workers 8
# ปรับ nice value ของ Process ที่กำลังรัน
renice -n -5 -p $(pidof nginx)
# ดู nice value ของทุก process
ps -eo pid,ni,comm --sort=-ni | head -20
# ตั้งค่าถาวรผ่าน systemd service
# [Service]
# Nice=-10
cgroups v2 — จำกัดทรัพยากร CPU
cgroups (Control Groups) ช่วยจำกัดทรัพยากรที่ Process หรือ Group ของ Processes สามารถใช้ได้ ใน cgroups v2 ทุกอย่างจัดการผ่าน unified hierarchy:
# ตรวจสอบว่าใช้ cgroups v2 หรือไม่
mount | grep cgroup2
# cgroup2 on /sys/fs/cgroup type cgroup2
# จำกัด CPU 50% สำหรับ application group
mkdir -p /sys/fs/cgroup/myapp
echo "50000 100000" > /sys/fs/cgroup/myapp/cpu.max
# 50000/100000 = 50% ของ 1 CPU core
# ใส่ Process เข้า cgroup
echo $PID > /sys/fs/cgroup/myapp/cgroup.procs
# จำกัด CPU สำหรับ systemd service
# systemctl set-property myapp.service CPUQuota=200%
# (200% = 2 cores max)
CPU Governor — โหมดความเร็ว CPU
# ดู Governor ปัจจุบัน
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# ตั้ง Performance mode (ความเร็วสูงสุดเสมอ)
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
# Governor ที่มีให้เลือก:
# performance - ความเร็วสูงสุดเสมอ (แนะนำสำหรับ Server)
# powersave - ความเร็วต่ำสุด (ประหยัดไฟ)
# ondemand - ปรับตาม Load (default บาง distro)
# conservative - เหมือน ondemand แต่ขยับช้ากว่า
# schedutil - kernel scheduler ตัดสินใจ (modern)
# ตั้งค่าถาวรด้วย cpupower (ติดตั้ง: apt install linux-tools-common)
cpupower frequency-set -g performance
IRQ Affinity — กระจาย Interrupt ไปหลาย CPU
# ดู IRQ distribution
cat /proc/interrupts | head -20
# ตั้ง IRQ affinity สำหรับ NIC (กระจายไปหลาย core)
# eth0 IRQ 25 -> CPU 0
echo 1 > /proc/irq/25/smp_affinity
# eth0 IRQ 26 -> CPU 1
echo 2 > /proc/irq/26/smp_affinity
# ใช้ irqbalance (แนะนำ - จัดการอัตโนมัติ)
systemctl enable --now irqbalance
# สำหรับ Server ที่มี NIC หลายตัว
# ใช้ RPS (Receive Packet Steering) กระจาย Network load
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
# f = binary 1111 = CPU 0,1,2,3
Memory Tuning
vm.swappiness — ควบคุมการใช้ Swap
vm.swappiness กำหนดว่า Kernel จะเริ่มย้ายข้อมูลจาก RAM ไป Swap เมื่อไหร่ ค่า 0-100 โดยค่าสูงหมายถึง Swap เร็วขึ้น ค่าต่ำหมายถึงพยายามเก็บข้อมูลไว้ใน RAM:
# ดูค่าปัจจุบัน (default = 60)
cat /proc/sys/vm/swappiness
# สำหรับ Database Server (ไม่อยาก Swap เลย)
sysctl -w vm.swappiness=1
# สำหรับ Web Server ทั่วไป
sysctl -w vm.swappiness=10
# สำหรับ Desktop
sysctl -w vm.swappiness=30
# ตั้งค่าถาวร
echo "vm.swappiness=10" >> /etc/sysctl.conf
sysctl -p
vm.dirty_ratio — ควบคุม Disk Write Cache
# dirty_ratio: % ของ RAM ที่ถูก dirty pages ก่อน force write
# dirty_background_ratio: % ที่ background writeback เริ่มทำงาน
# ค่า Default
cat /proc/sys/vm/dirty_ratio # 20
cat /proc/sys/vm/dirty_background_ratio # 10
# สำหรับ Database Server (write เร็วขึ้น ลดเสี่ยงข้อมูลหาย)
sysctl -w vm.dirty_ratio=5
sysctl -w vm.dirty_background_ratio=2
sysctl -w vm.dirty_expire_centisecs=500
# สำหรับ Throughput-heavy workload (batch processing)
sysctl -w vm.dirty_ratio=40
sysctl -w vm.dirty_background_ratio=10
# ตั้งค่าถาวร
cat >> /etc/sysctl.conf << 'EOF'
vm.dirty_ratio=5
vm.dirty_background_ratio=2
vm.dirty_expire_centisecs=500
EOF
Transparent Huge Pages (THP)
THP ช่วยให้ Kernel ใช้ Memory pages ขนาด 2MB แทน 4KB ลด TLB miss แต่สำหรับบาง Application (เช่น Redis, MongoDB) THP ทำให้ Latency spike เพราะ compaction:
# ดูสถานะ THP
cat /sys/kernel/mm/transparent_hugepage/enabled
# [always] madvise never
# ปิด THP สำหรับ Redis, MongoDB, Oracle DB
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
# เปิด THP mode madvise (แนะนำ - app เลือกเองได้)
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
# ตั้งค่าถาวรผ่าน GRUB
# GRUB_CMDLINE_LINUX="transparent_hugepage=never"
# update-grub
OOM Killer — ควบคุมการ Kill Process เมื่อ Memory เต็ม
# ดู OOM score ของทุก process (ค่าสูง = ถูก kill ก่อน)
for pid in $(ls /proc/ | grep -E '^[0-9]+$'); do
echo "$(cat /proc/$pid/oom_score 2>/dev/null) $(cat /proc/$pid/cmdline 2>/dev/null | tr ' ' ' ')"
done | sort -rn | head -20
# ปกป้อง Process สำคัญ (เช่น Database) จาก OOM killer
echo -1000 > /proc/$(pidof mysqld)/oom_score_adj
# ตั้งให้ Process ไม่สำคัญถูก Kill ก่อน
echo 1000 > /proc/$(pidof batch-job)/oom_score_adj
# systemd: ตั้ง OOMScoreAdjust ใน service file
# [Service]
# OOMScoreAdjust=-900 # ปกป้องจาก OOM
# vm.overcommit_memory:
# 0 = heuristic (default) - kernel ประมาณเอง
# 1 = always overcommit - ไม่ check (อันตราย)
# 2 = never overcommit - strict mode
sysctl -w vm.overcommit_memory=0
Disk I/O Tuning
I/O Scheduler — เลือก Algorithm ที่เหมาะสม
# ดู I/O scheduler ปัจจุบัน
cat /sys/block/sda/queue/scheduler
# [mq-deadline] kyber bfq none
# Scheduler ที่มี:
# mq-deadline - ดีสำหรับ Database, mixed workload (แนะนำ SSD)
# kyber - ดีสำหรับ fast SSD/NVMe
# bfq - ดีสำหรับ Desktop, fairness
# none/noop - ดีสำหรับ NVMe ที่มี internal scheduler
# เปลี่ยน scheduler
echo mq-deadline > /sys/block/sda/queue/scheduler
echo none > /sys/block/nvme0n1/queue/scheduler
# ตั้งค่าถาวรผ่าน udev rule
# /etc/udev/rules.d/60-io-scheduler.rules
# ACTION=="add|change", KERNEL=="sd*", ATTR{queue/scheduler}="mq-deadline"
# ACTION=="add|change", KERNEL=="nvme*", ATTR{queue/scheduler}="none"
readahead — Prefetch ข้อมูลล่วงหน้า
# ดู readahead ปัจจุบัน (หน่วย: 512-byte sectors)
cat /sys/block/sda/queue/read_ahead_kb
# default: 128 KB
# สำหรับ Sequential I/O (backup, log processing)
echo 2048 > /sys/block/sda/queue/read_ahead_kb # 2 MB
# สำหรับ Random I/O (Database)
echo 64 > /sys/block/sda/queue/read_ahead_kb # 64 KB
# สำหรับ NVMe (ลด latency)
echo 128 > /sys/block/nvme0n1/queue/read_ahead_kb
Filesystem Mount Options
# /etc/fstab tuning options:
# ext4 สำหรับ Database
/dev/sda1 /data ext4 defaults,noatime,nodiratime,data=ordered,barrier=1,commit=60 0 2
# XFS สำหรับ Large files, High throughput
/dev/sdb1 /storage xfs defaults,noatime,nodiratime,logbufs=8,logbsize=256k,allocsize=64m 0 2
# noatime: ไม่อัพเดท Access time (ลด write)
# nodiratime: ไม่อัพเดท Directory access time
# commit=60: flush ทุก 60 วินาที (ext4)
# barrier=1: เปิด write barriers (data safety)
# ตรวจสอบ mount options ปัจจุบัน
mount | grep "on /data"
tmpfs สำหรับ Temporary Files
# Mount /tmp เป็น tmpfs (ใช้ RAM แทน Disk)
mount -t tmpfs -o size=2G,mode=1777 tmpfs /tmp
# ตั้งค่าถาวรใน /etc/fstab
# tmpfs /tmp tmpfs defaults,size=2G,mode=1777 0 0
# ใช้สำหรับ:
# - /tmp (temporary files)
# - /var/run (runtime data)
# - Application cache ที่ต้องการ Speed
# ข้อดี: เร็วมาก (RAM speed)
# ข้อเสีย: ข้อมูลหายเมื่อ Reboot, ใช้ RAM
Network Tuning
TCP Buffer Sizes
# เพิ่ม TCP buffer sizes สำหรับ High-throughput
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# net.ipv4.tcp_rmem = "min default max"
# min: 4KB (minimum buffer)
# default: 87KB (default buffer)
# max: 16MB (maximum buffer, auto-tuned)
# เพิ่ม Network backlog
sysctl -w net.core.netdev_max_backlog=5000
Connection Tracking
# เพิ่ม Connection tracking table (สำหรับ Firewall/NAT)
sysctl -w net.netfilter.nf_conntrack_max=1048576
# ลด Timeout (ปล่อย Connection เร็วขึ้น)
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30
# ดู Connection tracking usage
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
net.core.somaxconn — TCP Listen Queue
# เพิ่ม Listen backlog (จำนวน pending connections)
sysctl -w net.core.somaxconn=65535
# เพิ่ม SYN backlog
sysctl -w net.ipv4.tcp_max_syn_backlog=65535
# เปิด TCP SYN cookies (ป้องกัน SYN flood)
sysctl -w net.ipv4.tcp_syncookies=1
# เปิด TCP reuse/recycle
sysctl -w net.ipv4.tcp_tw_reuse=1
# ลด TIME_WAIT
sysctl -w net.ipv4.tcp_fin_timeout=15
BBR Congestion Control
BBR (Bottleneck Bandwidth and Round-trip propagation time) เป็น TCP Congestion Control ที่ Google พัฒนา ทำให้ Throughput สูงขึ้นและ Latency ต่ำลง โดยเฉพาะบน Long-distance links:
# ตรวจสอบ Congestion Control ปัจจุบัน
sysctl net.ipv4.tcp_congestion_control
# net.ipv4.tcp_congestion_control = cubic
# ตรวจสอบว่า BBR มีให้ใช้ (Kernel 4.9+)
sysctl net.ipv4.tcp_available_congestion_control
# เปิด BBR
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
# ตั้งค่าถาวร
cat >> /etc/sysctl.conf << 'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sysctl -p
# ตรวจสอบว่า BBR ทำงาน
sysctl net.ipv4.tcp_congestion_control
# net.ipv4.tcp_congestion_control = bbr
Process Limits (ulimit & sysctl)
# ดู ulimit ปัจจุบัน
ulimit -a
# เพิ่ม Open file descriptors
ulimit -n 65535
# ตั้งค่าถาวรใน /etc/security/limits.conf
cat >> /etc/security/limits.conf << 'EOF'
* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535
root soft nofile 65535
root hard nofile 65535
EOF
# เพิ่ม System-wide file descriptor limit
sysctl -w fs.file-max=2097152
# เพิ่ม inotify watchers (สำหรับ file monitoring)
sysctl -w fs.inotify.max_user_watches=524288
# ตั้งค่าถาวร
cat >> /etc/sysctl.conf << 'EOF'
fs.file-max=2097152
fs.inotify.max_user_watches=524288
EOF
Monitoring Tools
Real-time Monitoring
| Tool | ดูอะไร | ใช้เมื่อไหร่ |
|---|---|---|
| top / htop | CPU, Memory per process | ดู Process ที่กิน Resource สูง |
| vmstat 1 | CPU, Memory, I/O, Context switches | ดู System overview ทุกวินาที |
| iostat -xz 1 | Disk I/O per device | หา Disk bottleneck (%util, await) |
| sar | ทุกอย่าง (historical) | ดูย้อนหลังและเก็บ Baseline |
| perf | CPU profiling, Cache miss | Debug Performance issues ลึกๆ |
# vmstat — System overview ทุก 1 วินาที
vmstat 1 10
# procs -----memory------ ---swap-- -----io---- -system-- ------cpu-----
# r b swpd free si so bi bo in cs us sy id wa st
# 1 0 0 1024000 0 0 5 10 200 300 10 5 85 0 0
# iostat — Disk performance
iostat -xz 1 5
# ดู %util (> 80% = bottleneck), await (ms per I/O), r/s, w/s
# sar — เก็บ Historical data
# CPU: sar -u 1 10
# Memory: sar -r 1 10
# Disk: sar -d 1 10
# Network: sar -n DEV 1 10
# perf — CPU profiling
perf top # Real-time CPU hotspot
perf stat -a sleep 10 # System-wide stats for 10 seconds
perf record -g -a sleep 30 # Record call graphs
perf report # Analyze recording
Benchmarking Tools
sysbench — CPU & MySQL Benchmark
# ติดตั้ง
apt install sysbench # Debian/Ubuntu
yum install sysbench # CentOS/RHEL
# CPU benchmark
sysbench cpu --cpu-max-prime=20000 --threads=4 run
# Memory benchmark
sysbench memory --memory-block-size=1M --memory-total-size=10G run
# MySQL benchmark
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=127.0.0.1 --mysql-user=root --mysql-password=pass --mysql-db=sbtest --tables=10 --table-size=100000 --threads=16 --time=300 prepare
sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=127.0.0.1 --mysql-user=root --mysql-password=pass --mysql-db=sbtest --tables=10 --table-size=100000 --threads=16 --time=300 run
fio — Disk I/O Benchmark
# ติดตั้ง
apt install fio
# Sequential Read
fio --name=seq-read --ioengine=libaio --rw=read --bs=1M --direct=1 --size=4G --numjobs=1 --runtime=60
# Random Read (IOPS test)
fio --name=rand-read --ioengine=libaio --rw=randread --bs=4k --direct=1 --size=4G --numjobs=4 --runtime=60 --iodepth=32
# Mixed Read/Write (Database-like workload)
fio --name=mixed --ioengine=libaio --rw=randrw --rwmixread=70 --bs=8k --direct=1 --size=4G --numjobs=4 --runtime=60
iperf3 — Network Benchmark
# ติดตั้ง
apt install iperf3
# Server side
iperf3 -s
# Client side (TCP throughput)
iperf3 -c server_ip -t 30 -P 4
# -t 30: ทดสอบ 30 วินาที
# -P 4: ใช้ 4 parallel streams
# UDP test
iperf3 -c server_ip -u -b 10G -t 30
# Reverse mode (server -> client)
iperf3 -c server_ip -t 30 -R
Kernel Parameter Tuning (/etc/sysctl.conf)
รวม Kernel parameters ที่แนะนำสำหรับ Production Linux Server ทุกตัว:
# === /etc/sysctl.conf ===
# Production Linux Server Tuning 2026
# -- Memory --
vm.swappiness=10
vm.dirty_ratio=5
vm.dirty_background_ratio=2
vm.dirty_expire_centisecs=500
vm.overcommit_memory=0
# -- Network (TCP) --
net.core.somaxconn=65535
net.core.netdev_max_backlog=5000
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_max_syn_backlog=65535
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_fin_timeout=15
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
# -- Network (Connection tracking) --
net.netfilter.nf_conntrack_max=1048576
net.netfilter.nf_conntrack_tcp_timeout_established=3600
# -- File system --
fs.file-max=2097152
fs.inotify.max_user_watches=524288
# Apply: sysctl -p
Application-Specific Tuning
MySQL / MariaDB Tuning
# /etc/mysql/mysql.conf.d/mysqld.cnf (Production)
[mysqld]
# InnoDB Buffer Pool = 70-80% ของ RAM
innodb_buffer_pool_size=12G # สำหรับ Server 16GB RAM
innodb_buffer_pool_instances=4
innodb_log_file_size=1G
innodb_flush_method=O_DIRECT
innodb_flush_log_at_trx_commit=2 # 1=safe, 2=fast
innodb_io_capacity=2000
innodb_io_capacity_max=4000
innodb_read_io_threads=8
innodb_write_io_threads=8
# Connection
max_connections=500
thread_cache_size=50
# Query Cache (ปิดใน MySQL 8.0+)
# query_cache_type=0
# Temp tables
tmp_table_size=256M
max_heap_table_size=256M
# Sort / Join buffer
sort_buffer_size=4M
join_buffer_size=4M
read_buffer_size=2M
PostgreSQL Tuning
# postgresql.conf (Production)
# Memory
shared_buffers = '4GB' # 25% ของ RAM
effective_cache_size = '12GB' # 75% ของ RAM
work_mem = '64MB' # per sort/hash operation
maintenance_work_mem = '1GB' # VACUUM, CREATE INDEX
# WAL
wal_buffers = '64MB'
checkpoint_completion_target = 0.9
max_wal_size = '4GB'
min_wal_size = '1GB'
# Query planner
random_page_cost = 1.1 # SSD (HDD = 4.0)
effective_io_concurrency = 200 # SSD (HDD = 2)
# Connection
max_connections = 200
# ใช้ PgBouncer สำหรับ Connection pooling
Nginx Tuning
# nginx.conf (Production)
worker_processes auto; # = จำนวน CPU cores
worker_rlimit_nofile 65535;
events {
worker_connections 4096;
multi_accept on;
use epoll;
}
http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 30;
keepalive_requests 1000;
# Gzip
gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 1000;
gzip_types text/plain text/css application/json application/javascript text/xml;
# Buffer
client_body_buffer_size 16k;
client_max_body_size 50m;
proxy_buffer_size 128k;
proxy_buffers 4 256k;
# Cache
open_file_cache max=10000 inactive=60s;
open_file_cache_valid 120s;
open_file_cache_min_uses 2;
}
Redis Tuning
# redis.conf (Production)
maxmemory 4gb
maxmemory-policy allkeys-lru
# Persistence
save "" # ปิด RDB snapshots (ถ้าใช้เป็น Cache)
appendonly no # ปิด AOF (ถ้าใช้เป็น Cache)
# Network
tcp-backlog 511
timeout 0
tcp-keepalive 300
# Memory optimization
activedefrag yes
lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
# ปิด THP บน Host!
# echo never > /sys/kernel/mm/transparent_hugepage/enabled
Docker / Kubernetes Host Tuning
# สำหรับ Host ที่รัน Docker / Kubernetes
# เพิ่ม PID limit
sysctl -w kernel.pid_max=4194304
# เพิ่ม inotify (K8s ต้องการมาก)
sysctl -w fs.inotify.max_user_watches=1048576
sysctl -w fs.inotify.max_user_instances=8192
# Network สำหรับ Container networking
sysctl -w net.bridge.bridge-nf-call-iptables=1
sysctl -w net.bridge.bridge-nf-call-ip6tables=1
sysctl -w net.ipv4.ip_forward=1
# เพิ่ม ARP cache
sysctl -w net.ipv4.neigh.default.gc_thresh1=4096
sysctl -w net.ipv4.neigh.default.gc_thresh2=8192
sysctl -w net.ipv4.neigh.default.gc_thresh3=16384
# IPVS สำหรับ kube-proxy mode ipvs
modprobe ip_vs
modprobe ip_vs_rr
modprobe ip_vs_wrr
modprobe ip_vs_sh
# Docker daemon.json
# {
# "storage-driver": "overlay2",
# "log-driver": "json-file",
# "log-opts": {
# "max-size": "10m",
# "max-file": "3"
# },
# "default-ulimits": {
# "nofile": { "Name": "nofile", "Hard": 65535, "Soft": 65535 }
# }
# }
รวม Checklist: Linux Performance Tuning 2026
| หมวด | Parameter | ค่าแนะนำ (Production) |
|---|---|---|
| CPU | Governor | performance |
| CPU | irqbalance | enabled |
| Memory | vm.swappiness | 1-10 (DB), 10-30 (Web) |
| Memory | vm.dirty_ratio | 5-10 (DB), 20-40 (batch) |
| Memory | THP | never (Redis/MongoDB), madvise (อื่นๆ) |
| Disk | I/O Scheduler | mq-deadline (SSD), none (NVMe) |
| Disk | Mount options | noatime, nodiratime |
| Network | somaxconn | 65535 |
| Network | TCP congestion | bbr |
| Network | tcp_tw_reuse | 1 |
| System | fs.file-max | 2097152 |
| System | ulimit nofile | 65535 |
สรุป
Linux Performance Tuning ไม่ใช่เรื่องที่ทำครั้งเดียวแล้วจบ แต่เป็นกระบวนการต่อเนื่อง Measure → Identify → Tune → Verify ที่ต้องทำซ้ำเมื่อ Workload เปลี่ยนหรือ Application เพิ่มขึ้น สิ่งสำคัญคือต้องเข้าใจว่ากำลังแก้ปัญหาอะไร อย่าปรับแต่งแบบสุ่ม และเก็บ Baseline ก่อนทุกครั้ง
เริ่มจาก Kernel parameters ใน /etc/sysctl.conf ที่ใช้ได้กับทุก Server จากนั้นค่อยปรับแต่งเฉพาะ Application (MySQL, PostgreSQL, Nginx, Redis) ตาม Workload ของคุณ ใช้ Monitoring tools เช่น sar, vmstat, iostat ติดตาม Performance อย่างต่อเนื่อง และ Benchmark ด้วย sysbench, fio, iperf3 เพื่อวัดผลจริง