ตรวจสอบ CPU, RAM และ Load Average ของ Linux Server

เมื่อเว็บไซต์หรือแอปบนเซิร์ฟเวอร์ตอบสนองช้า สิ่งแรกที่ควรทำคือดูว่าทรัพยากรส่วนไหนกำลังตึง CPU ถูกใช้เต็ม RAM ไม่พอจนต้องใช้ Swap หรือดิสก์ตอบสนองไม่ทัน แต่ละกรณีแก้ต่างกัน คู่มือนี้รวบรวมคำสั่งมาตรฐานที่มีในแทบทุก Linux Distro พร้อมวิธีอ่านค่าที่ได้

สิ่งที่ต้องเตรียม

• เข้าเซิร์ฟเวอร์ผ่าน SSH ได้ (ถ้าเครื่องช้ามากจน SSH ไม่ตอบ ใช้ Console ตามคู่มือ การ Remote เข้า Console Server ผ่าน Web UI)
• คำสั่งส่วนใหญ่ไม่ต้องใช้ root ยกเว้นการอ่าน Log ของ Kernel
• Ubuntu 22.04/24.04 หรือ AlmaLinux/Rocky Linux 8-9

ขั้นตอนที่ 1: ดูจำนวน CPU และ Load Average

nproc
uptime

ตัวอย่างผลลัพธ์

4
 10:15:32 up 12 days,  3:04,  1 user,  load average: 3.20, 2.85, 1.90

Load Average สามตัวคือค่าเฉลี่ย 1, 5 และ 15 นาทีล่าสุด หมายถึงจำนวนโปรเซสที่กำลังใช้ CPU หรือรอคิวอยู่ รวมถึงโปรเซสที่รอดิสก์ (สถานะ D) บน Linux วิธีอ่านคร่าว ๆ คือเทียบกับจำนวน CPU จาก nproc

• Load ต่ำกว่าจำนวน CPU: ยังมีกำลังเหลือ
• Load ใกล้เคียงจำนวน CPU: ใช้งานเต็มพอดี
• Load สูงกว่าจำนวน CPU ต่อเนื่อง: มีงานรอคิว เครื่องจะเริ่มช้า

ตัวอย่างด้านบนคือเครื่อง 4 Core มี Load 3.20 ถือว่ายังรับได้ และค่า 1 นาทีสูงกว่า 15 นาที แปลว่าโหลดกำลังเพิ่มขึ้น หาก Load สูงแต่ CPU ไม่เต็ม มักเป็นเพราะรอดิสก์ ให้ดูขั้นตอนที่ 4

ขั้นตอนที่ 2: ดูภาพรวมแบบเรียลไทม์ด้วย top

top

บรรทัดที่ขึ้นต้นด้วย %Cpu(s) สำคัญที่สุด

ปุ่มลัดที่ใช้บ่อยใน top: 1 แสดงแยกทีละ Core, P เรียงตาม CPU, M เรียงตามหน่วยความจำ, c แสดงคำสั่งเต็ม และ q ออก หากต้องการหน้าจอที่อ่านง่ายกว่า ติดตั้ง htop ได้ด้วย sudo apt install -y htop หรือ sudo dnf install -y htop (บน AlmaLinux และ Rocky Linux ต้องเปิด EPEL ก่อนด้วย sudo dnf install -y epel-release)

หมายเหตุ: หากค่า st สูงต่อเนื่อง (เช่นเกิน 10%) ทั้งที่โปรแกรมบนเครื่องใช้ CPU ไม่มาก ให้เก็บผลลัพธ์ของ top พร้อมเวลาที่เกิดไว้ แล้วแจ้งทีม Support เพื่อตรวจสอบฝั่ง Host

ขั้นตอนที่ 3: ตรวจหน่วยความจำ RAM และ Swap

free -h

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       5.1Gi       310Mi       120Mi       2.3Gi       2.2Gi
Swap:          2.0Gi       1.4Gi       600Mi

ค่าที่ควรดูคือ available ไม่ใช่ free เพราะ Linux นำ RAM ที่ว่างไปใช้เป็น Cache ของไฟล์ (buff/cache) และคืนให้โปรแกรมได้ทันทีเมื่อต้องการ ค่า free ที่ต่ำจึงเป็นเรื่องปกติ สัญญาณที่น่ากังวลคือ available ต่ำมาก และ Swap ถูกใช้เพิ่มขึ้นเรื่อย ๆ

ดูว่ามีการสลับหน่วยความจำไป Swap อยู่จริงหรือไม่ด้วย vmstat ทุก 1 วินาที 5 ครั้ง

vmstat 1 5

คอลัมน์ si และ so (Swap In/Out) ควรเป็น 0 หรือใกล้ 0 หากมีค่าต่อเนื่อง แปลว่า RAM ไม่พอ คอลัมน์ r คือจำนวนโปรเซสที่รอ CPU ถ้ามากกว่าจำนวน Core ต่อเนื่องแปลว่า CPU ไม่พอ ส่วน wa คือเวลารอดิสก์เช่นเดียวกับใน top หากเครื่องไม่มี Swap เลยและ RAM ตึงบ่อย ดูวิธีเพิ่มได้ที่ เพิ่ม Swap File บน Linux Server

ขั้นตอนที่ 4: ตรวจการทำงานของดิสก์

ติดตั้งชุดเครื่องมือ sysstat ก่อน

sudo apt install -y sysstat      # Ubuntu
sudo dnf install -y sysstat      # AlmaLinux / Rocky Linux

iostat -x 1 3

ดูรอบที่ 2 และ 3 (รอบแรกเป็นค่าเฉลี่ยตั้งแต่บูต) คอลัมน์ %util ที่ใกล้ 100% ต่อเนื่อง และค่า r_await หรือ w_await (มิลลิวินาที) ที่สูงผิดปกติ แปลว่าดิสก์ทำงานไม่ทัน มักเกิดจากฐานข้อมูลที่ไม่มี Index, งานสำรองข้อมูล หรือ RAM ไม่พอจนต้องใช้ Swap หนัก

ขั้นตอนที่ 5: หาโปรเซสที่ใช้ทรัพยากรมากที่สุด

ps aux --sort=-%cpu | head -n 11
ps aux --sort=-%mem | head -n 11

คำสั่งแรกแสดง 10 โปรเซสที่ใช้ CPU มากที่สุด คำสั่งที่สองเรียงตามหน่วยความจำ คอลัมน์ RSS คือ RAM ที่ใช้จริงหน่วย KB ถ้าเจอโปรเซสจำนวนมากชื่อเดียวกัน เช่น php-fpm หรือ apache2 ให้รวมผลดู เพราะแต่ละตัวอาจใช้ไม่มากแต่รวมกันแล้วเยอะ

ps -C php-fpm8.3 -o rss= | awk '{s+=$1} END {printf "%.0f MB\n", s/1024}'

เปลี่ยน php-fpm8.3 เป็นชื่อโปรเซสที่เห็นในคอลัมน์ COMMAND ของเครื่องคุณ (บน AlmaLinux และ Rocky Linux มักเป็น php-fpm)

ขั้นตอนที่ 6: ตรวจว่าเคยเกิด Out of Memory หรือไม่

เมื่อ RAM และ Swap หมด Kernel จะเลือกฆ่าโปรเซสทิ้ง (OOM Killer) ซึ่งมักเป็น MySQL หรือแอปหลัก ทำให้เว็บล่มกะทันหัน ตรวจย้อนหลังได้ด้วย

sudo journalctl -k | grep -i -E "out of memory|killed process"

หากพบบรรทัดเช่น Out of memory: Killed process 1234 (mysqld) แปลว่าเครื่องเคยหน่วยความจำไม่พอ ควรลดการใช้หน่วยความจำของโปรแกรม เพิ่ม Swap หรือพิจารณาเพิ่มสเปก ดูวิธีได้ที่ การ Upgrade/Downgrade สเปค Cloud Server แบบอัตโนมัติบน TDC

ตรวจสอบผลลัพธ์

หลังแก้ไขแล้ว ให้วัดซ้ำด้วยคำสั่งชุดเดิมในช่วงเวลาที่มีผู้ใช้งานจริง แล้วเปรียบเทียบกับค่าก่อนแก้ ค่าที่ถือว่าปกติโดยทั่วไปคือ Load ต่ำกว่าจำนวน CPU, available เหลือพอสมควร, si/so เป็น 0 และ wa ต่ำ หากต้องการดูย้อนหลัง ให้เปิดเก็บสถิติของ sysstat (บน Ubuntu ตั้ง ENABLED="true" ใน /etc/default/sysstat ก่อน) แล้วรัน sudo systemctl enable --now sysstat หลังจากนั้นดูข้อมูลย้อนหลังของวันนี้ได้ด้วย sar -u (CPU) และ sar -r (RAM)

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

Load สูงแต่ CPU ว่าง

ดู wa ใน top และ %util ใน iostat ถ้าสูง แปลว่าโปรเซสรอดิสก์ ตรวจงานที่อ่านเขียนดิสก์หนักในช่วงนั้น เช่น Backup หรือ Query ที่ไม่มี Index รวมถึงดิสก์ใกล้เต็มตามคู่มือ ดิสก์เต็ม: ตรวจสอบพื้นที่และหาไฟล์ขนาดใหญ่บน Linux

RAM ดูเหมือนเต็มตลอดเวลา

ถ้าค่า used สูงแต่ available ยังเหลือ เป็นพฤติกรรมปกติของ Linux ที่ใช้ RAM ว่างเป็น Cache ไม่ต้องแก้ไข

CPU เต็มจากโปรเซสที่ไม่รู้จัก

หากเจอโปรเซสชื่อแปลกใช้ CPU เกือบ 100% ต่อเนื่อง อาจเป็นมัลแวร์ขุดเหรียญ ดู Path ของโปรแกรมด้วย sudo ls -l /proc/PID/exe (เปลี่ยน PID เป็นหมายเลขโปรเซส) อย่าเพิ่งลบไฟล์เอง ให้เก็บข้อมูลไว้และติดต่อทีม Support เพื่อวางแผนแก้ไข

หากทำตามขั้นตอนแล้วยังติดปัญหา สามารถติดต่อทีมงาน Support ของ THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/ โดยแจ้งชื่อเซิร์ฟเวอร์ ระบบปฏิบัติการ ขั้นตอนที่ทำไปแล้ว และข้อความ Error ที่พบ เพื่อให้ตรวจสอบได้รวดเร็วขึ้น