ดีบัก Process ด้วย strace และ perf บน VPS

ดีบัก Process ด้วย strace และ perf บน VPS

มิถุนายน 2026 · อ่าน 8 นาที

เมื่อ process บน VPS ค้าง ช้าผิดปกติ หรือกิน resource มากกว่าที่ควร เครื่องมืออย่าง strace และ perf ช่วยให้เห็นว่า process กำลังทำอะไรอยู่ในระดับ system call โดยไม่ต้องหยุด service หรือแก้ code ทั้งคู่เป็น standard tools ที่มีบน Linux ทุก distro และใช้ได้กับ production server จริง

ติดตั้ง strace และ perf

sudo apt update
sudo apt install strace linux-tools-common linux-tools-$(uname -r) -y

# ตรวจ version
strace --version
perf --version

ใช้ strace ดู System Call ของ Process

# Attach ไปยัง process ที่รันอยู่ด้วย PID
sudo strace -p 1234

# ดูแค่ file I/O
sudo strace -p 1234 -e trace=read,write,open,close

# ดู network call
sudo strace -p 1234 -e trace=network

# บันทึก output ไฟล์ + ดู timestamp
sudo strace -p 1234 -T -tt -o /tmp/strace.log

# รัน command ใหม่พร้อม strace
strace -T ls /var/log

strace สรุป System Call ที่ใช้มากที่สุด

# -c = count mode แสดง summary
sudo strace -c -p 1234
# Ctrl+C เพื่อหยุดแล้วดู summary

# ตัวอย่าง output:
# % time     seconds  usecs/call     calls    syscall
# 45.23       0.054        54      1000    epoll_wait
# 23.11       0.027        27      1000    read
# 18.45       0.022        22       500    write

ดู File ที่ Process เปิดอยู่ด้วย lsof

# ดู file ทั้งหมดที่ process เปิด
sudo lsof -p 1234

# ดูเฉพาะ network connection
sudo lsof -p 1234 -i

# ดู file ที่ process ใดก็ตามเปิดใน directory นี้
sudo lsof +D /var/log/nginx/

ใช้ perf หา Performance Bottleneck

# ดู top function ที่ใช้ CPU มากที่สุด
sudo perf top -p 1234

# Record 10 วินาที แล้วแสดง report
sudo perf record -g -p 1234 sleep 10
sudo perf report

# ดู CPU event ทั้ง system 30 วินาที
sudo perf stat -a sleep 30

Debug Process ที่ค้าง (Hung Process)

# ดูว่า process รอ system call อะไรอยู่
sudo cat /proc/1234/wchan
# "futex" = รอ mutex/semaphore
# "poll_schedule_timeout" = รอ network/file
# "disk_sleep" = รอ I/O (อันตราย)

# ดู stack trace แบบ real-time
sudo cat /proc/1234/stack

# ดู file descriptor ที่เปิดอยู่
ls -la /proc/1234/fd/
Tip: ถ้า wchan บอกว่า process อยู่ใน disk_sleep (D state) นานผิดปกติ มักหมายความว่า disk I/O ติดขัดหรือ NFS/network mount มีปัญหา ตรวจ iostat -x 1 ควบคู่กัน

ตรวจสอบว่า Tools ทำงานถูกต้อง

# ทดสอบ strace กับ simple command
strace -c ls /etc 2>&1 | head -20

# ทดสอบ perf บน system (ต้องใช้ root)
sudo perf stat ls /etc

# ตรวจ strace attach ไปยัง process ได้
sudo strace -p 1 -e trace=none 2>&1
# ไม่ error = ptrace permission ผ่าน

# ดู system load ด้วย tools ที่ใช้งานง่ายกว่า
sudo apt install htop iotop -y
sudo iotop -oPa  # ดู I/O รายกระบวนการ
Tip: บน container หรือ VPS บางเจ้าที่จำกัด ptrace permission strace จะ error "Operation not permitted" ต้องให้ host เพิ่ม CAP_SYS_PTRACE capability ก่อน

แก้ปัญหาที่พบบ่อย

strace error: "attach: ptrace(PTRACE_SEIZE): Operation not permitted"

Kernel ปิด ptrace สำหรับ process อื่น ต้องรันด้วย root หรือปลด restriction ชั่วคราว:

sudo strace -p 1234
# ถ้ายังไม่ได้:
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
# คืนค่าหลังใช้เสร็จ:
echo 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope

strace ทำให้ process ช้าลงมาก

strace มี overhead สูงเมื่อดู syscall ทุกตัว ใช้ filter:

# ดูแค่ syscall ที่ใช้เวลานาน (> 1ms)
sudo strace -T -p 1234 2>&1 | awk '/<[0-9]/ && $NF > 0.001'

# หรือใช้ perf แทน มี overhead น้อยกว่ามาก
sudo perf top -p 1234

perf error: "No permission to collect stats"

ต้องรัน perf ด้วย root หรือตั้ง perf_event_paranoid:

sudo perf stat ls
# หรือลด restriction:
echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
# คืนค่าหลังใช้เสร็จ:

Process กิน CPU 100% แต่หา bottleneck ไม่เจอ

ใช้ flamegraph เพื่อ visualize call stack:

sudo perf record -F 99 -p 1234 -g sleep 30
sudo perf script > /tmp/out.perf
# ดึง FlameGraph tools
git clone https://github.com/brendangregg/FlameGraph
perl FlameGraph/stackcollapse-perf.pl /tmp/out.perf | perl FlameGraph/flamegraph.pl > /tmp/flame.svg

คำถามที่พบบ่อย

strace กับ ltrace ต่างกันอย่างไร?

strace ดู system call (kernel interface) ltrace ดู library call (เช่น libc functions) ถ้า process ช้าเพราะ algorithm ใน user space ให้ใช้ perf หรือ ltrace ถ้าช้าเพราะ I/O หรือ network ให้ใช้ strace

ดู memory leak ด้วย strace ได้ไหม?

ดูได้บางส่วน สังเกต mmap/brk syscall ที่เพิ่มขึ้นต่อเนื่อง แต่เครื่องมือที่ดีกว่าคือ Valgrind (valgrind --leak-check=full) หรือ AddressSanitizer สำหรับ C/C++ programs

ใช้ strace กับ Docker container ได้ไหม?

ได้ถ้า container รันด้วย --cap-add SYS_PTRACE หรือ --security-opt seccomp=unconfined สำหรับ container ที่รันอยู่แล้ว:

docker exec -it container_name bash
# ภายใน container:
apt install strace -y
strace -p $(pgrep myapp)