งาน performance บน Linux ควรเริ่มจากคำถามว่า ทรัพยากรใด หรือขั้นตอนใดในการประมวลผล request ที่ทำให้บริการช้าลง การเปิดเครื่องมือทุกตัวพร้อมกันมักได้ตัวเลขจำนวนมากที่อธิบายไม่ได้ เครื่องมือมีประโยชน์ที่สุดเมื่อใช้ทดสอบสมมติฐานที่ตั้งไว้ บทความนี้สรุปเครื่องมือพื้นฐานแยกตาม CPU, memory, storage และ network พร้อมข้อควรระวังในการอ่านค่าแต่ละตัว
ควรเริ่มหาคอขวดบน Linux จากตรงไหน?
เริ่มจากอาการที่ผู้ใช้หรือระบบ monitoring เห็นจริง เช่น response time สูงขึ้นในช่วงเวลาใด แล้วไล่ตรวจทรัพยากรที่เกี่ยวข้องอย่างเป็นระบบ วิธีที่ใช้ได้ดีคือ USE method ของ Brendan Gregg ซึ่งให้ตรวจ utilization, saturation และ errors ของแต่ละทรัพยากรที่เกี่ยวข้อง
โครงสร้างนี้ช่วยให้ไม่ข้ามทรัพยากรใดไป และช่วยแยกระหว่างทรัพยากรที่ "ถูกใช้มาก" กับทรัพยากรที่ "มีงานรอคิว" ซึ่งเป็นคนละสัญญาณกัน
ตรวจ CPU และ system load ด้วยเครื่องมืออะไร?
ใช้ uptime, top, htop, mpstat หรือ pidstat เพื่อดู load, การใช้ CPU และพฤติกรรมของแต่ละ process ส่วน vmstat 1 ช่วยดูภาพรวมของ CPU, memory และ context switch เป็นรายวินาที
ข้อควรระวังคือ load average ไม่ใช่ค่าเดียวกับ CPU utilization บน Linux ค่า load นับทั้ง task ที่พร้อมรัน (runnable) และ task ที่รอ I/O แบบ uninterruptible จึงอาจสูงได้แม้ CPU ไม่เต็ม และต้องตีความเทียบกับจำนวน CPU ที่มีในเครื่อง
Memory เหลือน้อยแปลว่า memory ไม่พอหรือไม่?
ไม่จำเป็น ค่า "free" ที่ต่ำเพียงอย่างเดียวยังไม่ใช่หลักฐานว่า memory ขาดแคลน เพราะ Linux ใช้ memory ที่ว่างเป็น buffer และ cache ซึ่งส่วนใหญ่คืนให้ application ได้เมื่อต้องการ แต่ไม่ทั้งหมด ค่า available จึงเป็นตัวเลขที่ควรดูมากกว่า เพราะเป็นค่าประมาณของ memory ที่ application ใช้ได้โดยไม่ต้อง swap
ใช้ free และ vmstat เพื่อดูค่า available memory และกิจกรรม paging หรือ swap หากเปิดเก็บสถิติด้วย sysstat ไว้ คำสั่ง sar -r ช่วยดูแนวโน้มการใช้ memory ย้อนหลังได้ ให้อ่านค่าเหล่านี้ร่วมกับพฤติกรรมของ workload ไม่ใช่ดูตัวเลขเดียว
Disk หรือ storage เป็นคอขวดจริงหรือไม่?
ใช้ iostat (เช่น iostat -xz 1) เพื่อดู latency และกิจกรรมของแต่ละ device และใช้เครื่องมือระดับ process อย่าง iotop ในกรณีที่เหมาะสม เพื่อดูว่า process ใดทำ I/O มาก จากนั้นโยงผลที่เห็นกลับไปที่ device และ workload ที่เกี่ยวข้อง
ค่าที่บอกว่า device ทำงานหนักต้องมีบริบทประกอบก่อนจะสรุปว่าต้องซื้อ storage ที่เร็วขึ้น เช่น latency ที่ application เห็นจริง และรูปแบบการอ่านเขียนของ workload
ตรวจ network อย่างไรโดยไม่สร้างความเสี่ยงด้านข้อมูล?
ใช้ ss (เช่น ss -s) เพื่อดูสรุปและสถานะของ connection และใช้เครื่องมือวิเคราะห์ traffic หรือ packet ที่เหมาะสม เพื่อดู retransmission, throughput และ connection ที่ค้างสะสม
การจับ packet ด้วยเครื่องมืออย่าง tcpdump อาจเก็บข้อมูลที่อ่อนไหวมาด้วย ควรจำกัดขอบเขตการเก็บ ระยะเวลา และสิทธิ์การเข้าถึงไฟล์ให้เท่าที่การตรวจสอบต้องใช้
เมื่อไรควรใช้ perf, flame graph หรือ eBPF?
ใช้เมื่อหลักฐานจากเครื่องมือพื้นฐานชี้ว่าต้องเจาะลึกลงไปในระดับ application หรือ kernel เช่น CPU สูงแต่ยังไม่รู้ว่าเวลาหมดไปกับฟังก์ชันใด เครื่องมือ profiling อย่าง perf และการแสดงผลแบบ CPU flame graph ช่วยให้เห็นว่าเวลา CPU ถูกใช้ไปที่ code path ใด ส่วนเครื่องมือที่ใช้ eBPF ช่วยติดตามพฤติกรรมภายใน kernel ได้ละเอียดขึ้น
อย่างไรก็ตาม เครื่องมือที่ติดตั้งได้ สิทธิ์ที่ต้องใช้ และ overhead ต่างกันไปตาม kernel และ distribution ควรตรวจระบบที่ติดตั้งอยู่และทดลองวิธีเก็บข้อมูลบนสภาพแวดล้อมที่ไม่ใช่ระบบสำคัญก่อนใช้กับ workload จริง
สรุปเครื่องมือตามทรัพยากร
| ทรัพยากร | เครื่องมือพื้นฐาน | ข้อควรระวังในการอ่านค่า |
|---|---|---|
| CPU และ load | uptime, top, htop, mpstat, pidstat, vmstat | load average ไม่เท่ากับ CPU utilization นับรวม task ที่รอ I/O ด้วย และต้องเทียบกับจำนวน CPU |
| Memory | free, vmstat, sar -r | free ต่ำอย่างเดียวยังไม่ใช่หลักฐานว่า memory ไม่พอ ให้ดู available memory และ paging |
| Storage และ I/O | iostat, iotop | ต้องโยงกับ latency ที่ application เห็นและรูปแบบ workload |
| Network | ss, tcpdump หรือเครื่องมือวิเคราะห์ traffic | packet capture อาจมีข้อมูลอ่อนไหว จำกัดขอบเขตและสิทธิ์ |
| เจาะลึก | perf, flame graph, เครื่องมือที่ใช้ eBPF | ตรวจสิทธิ์และ overhead ก่อนใช้กับระบบสำคัญ |
เช็กลิสต์ก่อนปรับจูนระบบ
- ระบุอาการและช่วงเวลาที่เกิดปัญหาให้ชัด
- บันทึก baseline พร้อมช่วงเวลาและ workload ที่ใช้วัด
- ไล่ตรวจ utilization, saturation และ errors ของ CPU, memory, storage และ network
- ตั้งสมมติฐานจากหลักฐาน แล้วเลือกเครื่องมือที่ใช้ทดสอบสมมติฐานนั้น
- จำกัดการจับ packet และ profiling ให้เท่าที่จำเป็น และทดลองก่อนใช้กับ production
- เปลี่ยนทีละอย่าง แล้ววัดซ้ำด้วยเงื่อนไขเดิม
เมื่อไรควรให้ทีมผู้เชี่ยวชาญช่วยวิเคราะห์ performance?
เมื่อวัดแล้วยังโยงตัวเลขกับสาเหตุไม่ได้ หรือรู้สาเหตุแล้วแต่ยังไม่แน่ใจว่าการแก้ไขจะกระทบระบบอื่นอย่างไร ตัวเลขจากเครื่องมือมีประโยชน์เมื่อแปลเป็นการตัดสินใจที่ตรวจสอบได้ หากต้องการให้ทีมช่วยวิเคราะห์ระบบ Linux ที่มีอยู่และดูแลต่อเนื่อง ดูบริการ DevOps และดูแลระบบองค์กร และ งานวิศวกรรม Linux อ่านต่อเรื่องการกระจาย traffic ไปยังฐานข้อมูลได้ใน HAProxy กับการปรับ performance ฐานข้อมูล
บทความโดย UNIXDEV Team · ปรับปรุง 23 ตุลาคม 2026
คำถามที่พบบ่อย
ควรเริ่มหาคอขวดบน Linux จากตรงไหน?
เริ่มจากอาการที่เห็นจริงและช่วงเวลาที่เกิดปัญหา แล้วไล่ตรวจทรัพยากรอย่างเป็นระบบ เช่น ใช้ USE method ของ Brendan Gregg ตรวจ utilization, saturation และ errors ของ CPU, memory, storage และ network พร้อมบันทึก baseline ช่วงเวลา และ workload ที่ใช้วัด
load average สูงแปลว่า CPU ทำงานเต็มหรือไม่?
ไม่จำเป็น load average ไม่ใช่ค่าเดียวกับ CPU utilization เพราะบน Linux นับทั้ง task ที่พร้อมรัน (runnable) และ task ที่รอ I/O แบบ uninterruptible จึงอาจสูงได้แม้ CPU ไม่เต็ม และต้องตีความเทียบกับจำนวน CPU ในเครื่อง ควรดูร่วมกับเครื่องมืออย่าง top, mpstat หรือ pidstat
ค่า free memory ต่ำแปลว่า memory ไม่พอหรือไม่?
ไม่จำเป็น Linux ใช้ memory ที่ว่างเป็น buffer และ cache ซึ่งส่วนใหญ่คืนให้ application ได้เมื่อต้องการ แต่ไม่ทั้งหมด ควรดูค่า available ซึ่งเป็นค่าประมาณของ memory ที่ application ใช้ได้โดยไม่ต้อง swap และดูกิจกรรม paging หรือ swap ด้วย free และ vmstat ประกอบกัน
การใช้ tcpdump ตรวจ network มีข้อควรระวังอะไร?
การจับ packet อาจเก็บข้อมูลที่อ่อนไหวมาด้วย จึงควรจำกัดขอบเขตการเก็บ ระยะเวลา และสิทธิ์การเข้าถึงไฟล์ให้เท่าที่การตรวจสอบต้องใช้
เมื่อไรควรใช้ perf หรือเครื่องมือที่ใช้ eBPF?
เมื่อหลักฐานจากเครื่องมือพื้นฐานชี้ว่าต้องเจาะลึกระดับ application หรือ kernel เช่น CPU สูงแต่ยังไม่รู้ว่าเวลาหมดไปกับ code path ใด ทั้งนี้สิทธิ์ที่ต้องใช้และ overhead ต่างกันตามระบบ ควรทดลองบนสภาพแวดล้อมที่ไม่ใช่ระบบสำคัญก่อน
