วิธีใช้คำสั่ง htop บนเซิร์ฟเวอร์ Linux เพื่อตรวจสอบสคริปต์ที่กิน CPU และ RAM

คำสั่ง htop บนเซิร์ฟเวอร์ Linux เป็นเครื่องมือที่สะดวกและทรงพลังสำหรับตรวจสอบสคริปต์หรือโปรเซสที่ใช้ CPU และ RAM มากเกินไปแบบเรียลไทม์ โดยผ่านหน้าจอ htop คุณสามารถดูค่า CPU%, MEM%, PID, USER, TIME+ และ COMMAND เพื่อระบุได้ว่า PHP, Python, Node.js, cron, ฐานข้อมูล หรือโปรเซสระบบใดที่กำลังทำให้เซิร์ฟเวอร์ช้าลง จากนั้นตรวจสอบเจ้าของโปรเซส, ที่อยู่ไฟล์ และวัตถุประสงค์การทำงาน เพื่อจัดการอย่างปลอดภัยได้อย่างมีประสิทธิภาพ

ไม่ว่าจะเป็นบนโฮสติ้งแชร์, VPS, VDS หรือเซิร์ฟเวอร์เฉพาะ ปัญหาความช้าหรือการตอบสนองช้าโดยฉับพลันส่วนใหญ่เกิดจากสคริปต์ที่ทำงานผิดปกติ เช่น ปลั๊กอิน WordPress ที่มีบั๊ก, ไฟล์ PHP ที่ติดลูปไม่สิ้นสุด, งาน cron ที่ทำงานหนัก, คำสั่งฐานข้อมูลที่ไม่ได้ปรับแต่ง หรือไฟล์เว็บที่ถูกโจมตี จนอาจทำให้การใช้ CPU พุ่งถึง 100% ภายในไม่กี่นาที เมื่อใช้ RAM มากเกินไป บริการต่าง ๆ อาจหยุดตอบสนอง, การเชื่อมต่อ MySQL หลุด, เว็บแสดง 503 error หรือ Linux kernel อาจสั่งหยุดโปรเซสบางอย่างด้วย OOM Killer

บทความนี้จะเริ่มตั้งแต่การติดตั้ง htop, วิธีอ่านหน้าจอ, การแยกแยะสคริปต์ที่กิน CPU และ RAM, การหาไฟล์ต้นทางจาก PID และวิธีการจัดการโปรเซสอย่างปลอดภัยตามขั้นตอน นอกจากนี้ยังมีคำแนะนำด้านความปลอดภัย, การตรวจสอบ cron, การวิเคราะห์ log และวิธีป้องกันไม่ให้ปัญหาเกิดซ้ำ หากเซิร์ฟเวอร์ของคุณเจอปัญหาขีดจำกัดทรัพยากรบ่อยครั้ง อย่าลืมพิจารณาเลือกโครงสร้างพื้นฐานที่เหมาะสมผ่าน แพ็คเกจเซิร์ฟเวอร์ VPS และ web hosting ที่มีประสิทธิภาพสูง

htop คืออะไร และทำไมถึงดีกว่าคำสั่ง top?

htop เป็นเครื่องมือใน Linux ที่ใช้ดูสถานะโปรเซสแบบอินเทอร์แอคทีฟผ่านเทอร์มินัล มีหน้าตาและฟังก์ชันที่อ่านง่ายกว่า top แบบดั้งเดิม พร้อมแสดงสีบอกสถานะ, สามารถจัดเรียง, ค้นหา, กรอง และจัดการโปรเซสได้ง่ายกว่า จึงเป็นเครื่องมืออันดับแรกที่ผู้ดูแลระบบใช้เมื่อวิเคราะห์ปัญหาบนเซิร์ฟเวอร์แบบเรียลไทม์

ข้อมูลที่เห็นได้ทันทีใน htop เช่น:

• เปอร์เซ็นต์การใช้ CPU ของแต่ละโปรเซส
• เปอร์เซ็นต์และปริมาณการใช้ RAM ของแต่ละโปรเซส
• หมายเลข PID ของโปรเซส
• ผู้ใช้ที่รันโปรเซสนั้น
• ชื่อคำสั่งหรือสคริปต์ที่รัน
• เวลาที่ทำงานและค่าความสำคัญ (priority)
• ค่า load average, RAM ทั้งหมด, swap และจำนวนคอร์ CPU ที่ใช้งาน

โดยเฉพาะในระบบโฮสติ้งที่มีหลายเว็บไซต์หรือหลายผู้ใช้บนเซิร์ฟเวอร์เดียว การดูแค่การใช้ทรัพยากรรวมไม่เพียงพอ จำเป็นต้องรู้ว่าปัญหาเกิดจากผู้ใช้, เว็บไซต์, งาน cron หรือสคริปต์ใด htop จึงช่วยให้วินิจฉัยได้รวดเร็วในขั้นต้น

วิธีติดตั้ง htop บน Linux ตามแต่ละดิสทริบิวชัน

บางดิสทริบิวชัน Linux อาจไม่มี htop ติดตั้งมาให้ทันที หากคุณมีสิทธิ์ root หรือ sudo การติดตั้งทำได้ง่ายและรวดเร็ว ควรอัปเดตแพ็กเกจก่อนเพื่อลดข้อผิดพลาด โดยใช้คำสั่งดังนี้

ติดตั้งบน Ubuntu และ Debian

บนเซิร์ฟเวอร์ Ubuntu หรือ Debian ใช้คำสั่ง:

sudo apt update

sudo apt install htop -y

ติดตั้งเสร็จแล้วพิมพ์คำสั่ง htop เพื่อเริ่มใช้งาน หากไม่มีสิทธิ์ sudo ให้ติดต่อผู้ให้บริการโฮสติ้ง หากเป็น VPS ที่คุณจัดการได้ มักจะมีสิทธิ์ root อยู่แล้ว

ติดตั้งบน AlmaLinux, Rocky Linux, CentOS และ RHEL

บนระบบ RHEL-based ใช้แพ็กเกจแมเนเจอร์ dnf หรือ yum ตามเวอร์ชัน:

sudo dnf install htop -y

สำหรับ CentOS รุ่นเก่า อาจต้องติดตั้ง EPEL repo ก่อน:

sudo yum install epel-release -y

sudo yum install htop -y

เมื่อติดตั้งสำเร็จ พิมพ์ htop แล้วจะเห็นหน้าจอแสดงสถานะสีสันสดใส หากคุณยังใหม่กับการจัดการเซิร์ฟเวอร์ Linux แนะนำอ่าน คู่มือคำสั่งลินุกซ์ เพื่อเรียนรู้คำสั่งพื้นฐาน

ทำความเข้าใจหน้าจอ htop: ความหมายของแต่ละคอลัมน์

เมื่อเปิด htop จะเห็นแถบด้านบนแสดงข้อมูล CPU cores, RAM, swap, จำนวน task และ thread, load average และ uptime ส่วนล่างเป็นรายการโปรเซสที่กำลังทำงาน คอลัมน์ที่ใช้วิเคราะห์ปัญหาสำคัญมีดังนี้

ข้อควรระวังคือ การใช้ CPU สูงชั่วคราวอาจไม่ใช่ปัญหา เช่น งานแบ็คอัพ, การจัดการ cache หรือช่วงมีทราฟฟิกสูง แต่อาการที่ต้องจับตาคือโปรเซสเดียวที่ใช้ CPU หรือ RAM สูงต่อเนื่องนานหลายวินาทีถึงนาที, ค่า load average สูงกว่าจำนวนคอร์ CPU มาก และเว็บไม่ตอบสนอง

วิธีค้นหาสคริปต์ที่ใช้ CPU สูงด้วย htop

ขณะอยู่ในหน้าจอ htop กด F6 เพื่อเลือกคอลัมน์เรียงลำดับ หรือคลิกที่หัวข้อ CPU% (ถ้าเมาส์ใช้งานได้) เพื่อจัดเรียงโปรเซสตามการใช้ CPU จากมากไปน้อย โปรเซสที่อยู่ข้างบนสุดคือโปรเซสที่ใช้ CPU มากที่สุด

ขั้นตอนที่ 1: จัดเรียงตาม CPU%

เรียงโปรเซสตามการใช้ CPU เช่น php-fpm, php, python3, node, java, mysqld หรือ bash ถ้าโปรเซสใดอยู่บนสุดตลอด ให้จด PID และ USER ไว้ ระบบที่มีหลายคอร์ อาจเห็นค่า CPU% เกิน 100% เพราะโปรเซสนั้นใช้หลายคอร์พร้อมกัน เช่น 200% หรือ 400%

ขั้นตอนที่ 2: จดบันทึก PID และ USER

บันทึกหมายเลข PID และชื่อ USER ของโปรเซสที่สงสัย เช่น PID 24819, USER เป็น siteuser และ COMMAND เป็น php /home/siteuser/public_html/wp-cron.php แสดงว่าน่าจะเกี่ยวข้องกับ cron หรือระบบ WordPress ของเว็บไซต์นั้น หากชื่อ COMMAND สั้นเกินไป สามารถตั้งค่า htop ให้แสดงคำสั่งเต็ม หรือใช้คำสั่ง ps เพื่อดูรายละเอียด

ขั้นตอนที่ 3: ตรวจสอบคำสั่งเต็มของโปรเซส

ใช้คำสั่งด้านล่างเพื่อดูคำสั่งที่ละเอียดขึ้น:

ps -fp PID

เช่น

ps -fp 24819

ผลลัพธ์จะบอกว่าโปรเซสนี้รันไฟล์ไหน เช่น php /home/user/public_html/index.php อาจเป็นคำสั่งที่มาจากเว็บเรียก หรือ php /home/user/public_html/wp-content/plugins/unknown-plugin/task.php อาจเป็นปัญหาจากปลั๊กอิน

ขั้นตอนที่ 4: ตรวจสอบเส้นทางไฟล์และไฟล์ที่เปิดอยู่

ใช้เครื่องมือ lsof เพื่อตรวจสอบไฟล์ที่โปรเซสเปิดใช้งาน:

lsof -p PID

คำสั่งนี้จะแสดงไฟล์, ไลบรารี, log และการเชื่อมต่อเครือข่ายที่โปรเซสกำลังใช้งาน ในสภาพแวดล้อมเว็บโฮสติ้งจะช่วยให้รู้ว่าโปรเซสทำงานในโฟลเดอร์ของเว็บไซต์ใด เช่นเจอไฟล์ PHP ชื่อแปลกใน /home/example/public_html/wp-content/uploads อาจเป็นสัญญาณการถูกโจมตี ควรทำความสะอาดไฟล์, เปลี่ยนรหัสผ่าน, อัปเดตปลั๊กอินและตรวจสอบความปลอดภัยเพิ่มเติม ดูข้อมูลเกี่ยวกับ SSL และการเชื่อมต่อปลอดภัยได้ที่ โซลูชั่นใบรับรอง SSL

วิธีค้นหาสคริปต์ที่ใช้ RAM สูงด้วย htop

ปัญหา RAM มักแฝงตัวและอาจทำให้บริการล่มโดยไม่ทันตั้งตัว ต่างจาก CPU ที่ใช้สูงจะรู้สึกชัดเจนว่าเครื่องช้า เมื่อ RAM หมด เซิร์ฟเวอร์จะใช้ swap หนักและตอบสนองช้า คุณสามารถจัดเรียงโปรเซสตามคอลัมน์ MEM% เพื่อดูโปรเซสที่ใช้ RAM สูงสุด

ทำความเข้าใจ MEM%, RES และ swap

ใน htop คอลัมน์ MEM% แสดงเปอร์เซ็นต์การใช้ RAM ของโปรเซส และบางครั้งอาจเห็น VIRT, RES, SHR ซึ่ง RES แสดงขนาด RAM จริงที่โปรเซสใช้ อยู่ในหน่วยกิโลไบต์หรือเมกะไบต์ ส่วน VIRT คือหน่วยความจำเสมือนที่ถูกจัดสรร แต่ไม่จำเป็นต้องใช้งานจริง จึงไม่ควรสับสน

ตัวอย่างเช่น VPS ที่มี RAM 4 GB หากโปรเซส PHP ตัวเดียวใช้ RES ถึง 900 MB ถือว่าไม่ปกติ หรือแอป Node.js ที่ใช้ RAM จาก 200 MB เพิ่มเป็น 1.5 GB อาจเกิด memory leak ส่วน MySQL หรือ MariaDB ใช้ RAM สูงบางครั้งเป็นพฤติกรรมแคชปกติ แต่ต้องพิจารณาร่วมกับประสิทธิภาพและการตั้งค่า buffer ด้วย

สาเหตุทั่วไปของสคริปต์ที่ใช้ RAM สูง

• โค้ด PHP, Python หรือ Node.js ที่ติดลูปไม่สิ้นสุด
• การโหลดไฟล์ CSV, XML หรือ JSON ขนาดใหญ่เข้า RAM ทีเดียว
• ปลั๊กอินหรือธีม WordPress ที่ไม่ได้ปรับแต่งอย่างเหมาะสม
• งานประมวลผลภาพ, สร้าง PDF หรือแปลงวิดีโอที่ใช้ RAM หนัก
• การใช้แคชไม่เพียงพอ ทำให้เกิดการ query ซ้ำซ้อน
• บ็อตหรือทราฟฟิกโจมตีที่ทำให้สคริปต์เดียวรันหลายครั้งพร้อมกัน
• บริการที่มี memory leak ทำงานเป็นเวลานาน

การใช้คำสั่ง kill เพื่อปิดโปรเซสเป็นการแก้ไขแบบชั่วคราว ควรวิเคราะห์สคริปต์ว่าทำอะไร, รับ input อย่างไร และทำไม RAM ถึงไม่ถูกปล่อยออกหลังใช้งาน

ฟีเจอร์การค้นหา กรอง และแสดงแบบต้นไม้ใน htop

ในกรณีที่มีโปรเซสจำนวนมาก การเลื่อนหาเองจะลำบาก htop จึงมีทางลัดให้ใช้ เช่น กด F3 เพื่อค้นหา, F4 เพื่อกรอง และ F5 เพื่อดูแบบ tree view ซึ่งช่วยให้เห็นความสัมพันธ์ parent-child ของโปรเซสได้ชัดเจน เช่น child ของ php-fpm ที่รันโดย nginx หรือ Apache, สคริปต์ที่รันโดย cron, หรือบริการ Node.js ที่ถูกควบคุมโดย supervisor

ตัวอย่างการกรองที่เป็นประโยชน์

• พิมพ์ php เพื่อดูเฉพาะโปรเซส PHP
• พิมพ์ python เพื่อดูสคริปต์ Python
• พิมพ์ wp-cron เพื่อตรวจสอบงาน cron ของ WordPress
• พิมพ์ node เพื่อเช็คแอป Node.js
• กรองด้วยชื่อผู้ใช้ เพื่อดูโปรเซสของบัญชีโฮสติ้งนั้นๆ

การกรองช่วยประหยัดเวลา โดยเฉพาะเซิร์ฟเวอร์ที่มีผู้ใช้หลายสิบเว็บไซต์ หากต้องการบริหารจัดการโดเมนให้เรียบง่ายขึ้น แนะนำดู การตรวจสอบโดเมนและการลงทะเบียน

แผนการจัดการโปรเซสที่น่าสงสัยอย่างปลอดภัย

เมื่อพบโปรเซสที่ใช้ทรัพยากรสูง การสั่ง kill -9 ทันทีอาจทำให้ข้อมูลเสียหาย งานเขียนไฟล์ค้าง หรือบริการขัดข้อง ควรทำตามขั้นตอนนี้เพื่อความปลอดภัย

1. บันทึกข้อมูลโปรเซส

จด PID, USER, COMMAND, CPU%, MEM% และเวลาที่เจอปัญหา พร้อมถ่ายภาพหน้าจอ htop เพื่อเก็บข้อมูลเปรียบเทียบในอนาคต โดยเฉพาะในโปรเจกต์ที่ต้องรายงานลูกค้าหรือทีมงาน

2. ยืนยันเส้นทางไฟล์ของโปรเซส

ใช้คำสั่ง ps -fp PID และ lsof -p PID เพื่อตรวจสอบที่อยู่ไฟล์ หากโปรเซสอยู่ใน root เว็บ ให้ตรวจสอบ log ของแอป เช่น wp-content/debug.log สำหรับ WordPress, access log และ error log ของเว็บเซิร์ฟเวอร์ หรือ PHP-FPM slow log เพื่อหาเบาะแส

3. พยายามปิดโปรเซสอย่างนุ่มนวลก่อน

ส่งสัญญาณ kill ธรรมดาก่อน:

kill PID

รอสักครู่แล้วตรวจสอบว่าโปรเซสปิดหรือไม่ หากไม่ยอมปิดและส่งผลกระทบรุนแรง อาจใช้ kill -9 เป็นทางเลือกสุดท้าย:

kill -9 PID

คำสั่ง kill -9 จะหยุดโปรเซสทันทีโดยไม่ให้เวลาทำความสะอาด จึงควรระวังหากโปรเซสนั้นกำลังทำงานกับไฟล์หรือฐานข้อมูล

4. หากโปรเซสกลับมาใหม่ ให้หาสาเหตุที่แท้จริง

ถ้าปิดโปรเซสแล้วแต่กลับมาใหม่อย่างรวดเร็ว อาจถูกสั่งให้รันซ้ำโดย cron, ระบบ service manager เช่น systemd, supervisor, หรือเกิดจากทราฟฟิกเว็บหรือบ็อต ตรวจสอบด้วยคำสั่ง crontab -l, systemctl status ชื่อบริการ และวิเคราะห์ access log หากเกี่ยวข้องกับ WordPress wp-cron ควรตั้งค่า cron แทนการใช้ wp-cron ภายในเว็บและปรับนโยบาย cache

การนำข้อมูล htop มาผนวกกับ log เพื่อวิเคราะห์

htop แสดงว่าโปรเซสไหนกินทรัพยากร แต่ log จะช่วยให้เข้าใจเหตุผลและสาเหตุ ตัวอย่าง log ที่ควรตรวจสอบได้แก่:

• access log ของเว็บเซิร์ฟเวอร์ เพื่อดู URL ที่ถูกเรียกบ่อย
• error log ของเว็บเซิร์ฟเวอร์ เพื่อตรวจสอบข้อผิดพลาด เช่น PHP error หรือ permission
• PHP-FPM slow log เพื่อติดตามไฟล์ PHP ที่ทำงานช้า
• MySQL slow query log สำหรับคำสั่ง SQL ที่ช้า
• auth log หรือ secure log เพื่อตรวจสอบการพยายามเข้าสู่ระบบที่น่าสงสัย
• cron log เพื่อตรวจสอบเวลารันงานที่ตั้งไว้

เช่น หาก htop แสดง PID ที่ใช้ CPU สูง ในช่วงเดียวกัน access log พบว่ามีการเรียก /wp-admin/admin-ajax.php จำนวนมาก อาจเกิดจากบ็อต หรือปลั๊กอินที่ออกแบบไม่ดี ควรพิจารณาใช้ WAF, rate limit, cache และปรับแต่งปลั๊กอินร่วมกัน สำหรับแนวทางปรับแต่งเว็บให้โหลดเร็วขึ้น ดูที่ การเพิ่มประสิทธิภาพความเร็วเว็บไซต์

แยกแยะระหว่างโหลดปกติกับโหลดที่เป็นปัญหาได้อย่างไร?

การใช้ทรัพยากรสูงไม่ใช่ทุกกรณีจะเป็นวิกฤติ ต้องพิจารณาฮาร์ดแวร์, ปริมาณทราฟฟิก, ประเภทแอปพลิเคชัน และงานบำรุงรักษา เช่น VPS 2 คอร์ ที่มี load average ค้างอยู่ที่ 6-8 เป็นสัญญาณติดขัด แต่บนเซิร์ฟเวอร์ dedicated 16 คอร์ ค่าเดียวกันอาจปกติ ดังนั้นต้องดูจำนวนคอร์ควบคู่ไปด้วย

การเปรียบเทียบนี้ช่วยให้ไม่ตื่นตระหนกกับการใช้ทรัพยากรชั่วคราว และแยกแยะปัญหาจริงได้ดี โดยเฉพาะเว็บไซต์อีคอมเมิร์ซช่วงโปรโมชั่นหรืออัปเดตสต็อกที่อาจทำให้โหลดเพิ่มขึ้นชั่วคราว หากส่งผลกระทบต่อประสบการณ์ผู้ใช้ ควรปรับแต่งแอปและเพิ่มประสิทธิภาพเซิร์ฟเวอร์ควบคู่กัน

กรณีสงสัยด้านความปลอดภัย: สคริปต์ที่ใช้ทรัพยากรสูงอาจถูกแฮ็กได้?

สคริปต์ที่ใช้ CPU หรือ RAM สูงไม่ใช่แค่บั๊กธรรมดา บางครั้งอาจเป็นผลจากเว็บไซต์โดนแฮ็ก ผู้โจมตีสามารถใช้สคริปต์ส่งสแปมหรือขุดคริปโต, โปรกซี, บ็อต DDoS หรือสคริปต์หลังบ้านที่แอบแฝง ในหน้าจอ htop ถ้าเจอโปรเซสที่รันโดยผู้ใช้ไม่ปกติ, ไฟล์ชื่อแปลก ๆ, ไฟล์ไบนารีใน /tmp หรือ PHP ที่รันในโฟลเดอร์ uploads ควรตรวจสอบอย่างจริงจัง

สัญญาณน่าสงสัย

• ชื่อไฟล์ใน COMMAND เป็นชุดอักขระไร้ความหมายหรือสุ่ม
• โปรเซสที่รันจากโฟลเดอร์ /tmp, /dev/shm หรือ uploads
• โปรเซส perl, python หรือ bash ที่ไม่ควรมีในระบบปกติ
• โปรเซสที่สร้างการเชื่อมต่อเครือข่ายภายนอกจำนวนมาก
• ผู้ใช้เดียวกันเปิดโปรเซสจำนวนมากในเวลาสั้น
• ไฟล์เว็บมีการเปลี่ยนแปลงโดยไม่ได้รับอนุญาตเมื่อเร็ว ๆ นี้

ในกรณีนี้ ควรเก็บหลักฐานด้วยคำสั่งต่าง ๆ ก่อนปิดโปรเซส ตรวจสอบสิทธิ์ไฟล์, แยกไฟล์ที่น่าสงสัยออก, เปลี่ยนรหัสผ่านในระบบทั้งหมด, อัปเดตปลั๊กอินและธีม, และสแกนหามัลแวร์เพิ่มเติม รวมถึงเปิดใช้งานการยืนยันตัวตนสองขั้นตอนและจำกัดสิทธิ์เขียนไฟล์เพื่อลดความเสี่ยงในอนาคต

แนวทางปฏิบัติที่ดีที่สุดเพื่อป้องกันปัญหาประสิทธิภาพซ้ำซาก

การใช้ htop หาโปรเซสที่กินทรัพยากรเป็นจุดเริ่มต้นที่ดี แต่สิ่งที่สำคัญกว่าคือการป้องกันไม่ให้ปัญหาเกิดซ้ำ ต่อไปนี้คือคำแนะนำสำหรับเซิร์ฟเวอร์ Linux ที่ช่วยลดปัญหาการใช้ CPU และ RAM สูง:

• ตั้งค่า PHP memory_limit, max_execution_time และ pm.max_children ให้เหมาะสมกับความสามารถเซิร์ฟเวอร์
• ใช้ระบบ cache ใน WordPress, Joomla หรือซอฟต์แวร์เฉพาะทาง
• ลบปลั๊กอิน, ธีม และโมดูลที่ไม่จำเป็นออก
• ปรับแต่งคำสั่ง SQL ที่ช้าโดยใช้ MySQL slow query log
• ตั้งเวลางาน cron ให้ไม่รันพร้อมกันทั้งหมด แต่กระจายเวลาออก
• ป้องกันบ็อตด้วย rate limit, robots.txt และกฎ firewall
• จัดการ log ให้อยู่ในขนาดที่เหมาะสมและหมุนเวียน log อย่างสม่ำเสมอ เพื่อไม่ให้กระทบ disk และ RAM
• ติดตามสถานะเซิร์ฟเวอร์เป็นประจำ ไม่ใช่แค่ตอนเกิดปัญหา

หากทำตามนี้แล้วยังใช้ทรัพยากรสูง อาจเป็นสัญญาณว่าซอฟต์แวร์หรือแพ็กเกจโฮสติ้งไม่ตอบสนองความต้องการ ควรพิจารณา VPS ที่ปรับขนาดได้ RAM เพิ่มขึ้น, ใช้ดิสก์ NVMe ความเร็วสูง หรือเซิร์ฟเวอร์แยกเฉพาะ ดูตัวเลือกได้ที่ แพ็กเกจโฮสติ้ง และ โซลูชันเซิร์ฟเวอร์ธุรกิจ

ตัวอย่างสถานการณ์: CPU พุ่งสูงบนเว็บไซต์ WordPress

สมมติว่าคุณมี VPS 4 คอร์ 8 GB RAM รัน WordPress หลายไซต์ ผู้ใช้รายงานว่าเว็บช้าและบางครั้งเจอ 502 error เปิด htop พบ load average 12, CPU ทุกคอร์ใช้เต็ม และมี php-fpm process หลายตัวรันโดย user เดียวกัน

ใช้ F4 กรองโปรเซสด้วยชื่อผู้ใช้ จด PID ของโปรเซสที่ใช้ CPU สูง จากนั้นใช้คำสั่ง ps -fp PID พบว่าเป็น php-fpm worker และ lsof -p PID พบว่าเปิดไฟล์ /home/site/public_html/wp-content/plugins/example-importer/import.php ตรวจสอบ access log พบว่ามีคำสั่งเริ่ม import และ AJAX เรียกซ้ำหลายครั้ง

แก้ไขโดยหยุด import, ปิดงาน cron ของปลั๊กอินนั้น, แบ่งงาน import เป็นส่วนเล็ก ๆ และปรับ max_execution_time ของ PHP รวมทั้งเปลี่ยนมาใช้ system cron แทน wp-cron ผลคือ load average ลดลงเหลือ 1.8, การใช้ CPU กลับสู่ปกติ และเว็บตอบสนองเร็วขึ้นมาก ตัวอย่างนี้แสดงให้เห็นว่า htop ร่วมกับ ps, lsof และ log ช่วยวิเคราะห์ได้อย่างมีประสิทธิภาพ

ข้อผิดพลาดทั่วไปที่พบบ่อยในการใช้ htop

• ปิดโปรเซสที่ใช้ทรัพยากรสูงทันทีโดยไม่ตรวจสอบสาเหตุ
• สับสนค่า VIRT กับการใช้ RAM จริง
• คิดว่า MySQL ใช้ RAM สูงเป็นปัญหาเสมอ โดยไม่ดูพฤติกรรมแคช
• ใช้ kill -9 เป็นตัวเลือกแรก แทนที่จะลอง kill ธรรมดาก่อน
• ตัดสินใจผิดพลาดโดยไม่ตรวจสอบ log หรือข้อมูลเพิ่มเติม
• ตีความ load average โดยไม่เปรียบเทียบจำนวนคอร์ CPU
• ไม่ตรวจสอบความสมบูรณ์ของไฟล์เมื่อสงสัยว่าโดนแฮ็ก

หลีกเลี่ยงข้อผิดพลาดเหล่านี้จะช่วยลดเวลาหยุดทำงานและความเสียหายจากการแก้ไขผิดพลาด การวินิจฉัยที่ถูกต้องสำคัญกว่าการแก้ไขเร็วเสมอในงานดูแลระบบ

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

คำสั่ง htop บน Linux ใช้ทำอะไร?

คำสั่ง htop แสดงข้อมูลโปรเซสที่กำลังทำงาน พร้อมรายละเอียด CPU, RAM, ผู้ใช้, PID และคำสั่งที่ใช้แบบเรียลไทม์ ช่วยระบุสคริปต์หรือโปรเซสที่ใช้ทรัพยากรมากได้อย่างรวดเร็ว

จะหาโปรเซสที่ใช้ CPU สูงด้วย htop ได้อย่างไร?

ในหน้าจอ htop จัดเรียงโปรเซสตามคอลัมน์ CPU% จากมากไปน้อย จดบันทึก PID และ USER ของโปรเซสที่ใช้ CPU สูง และใช้คำสั่ง ps -fp PID กับ lsof -p PID เพื่อตรวจสอบไฟล์และคำสั่งที่รัน

ในการวิเคราะห์ RAM ควรดู MEM% หรือ VIRT?

ควรดู MEM% และโดยเฉพาะ RES เพราะแสดง RAM จริงที่โปรเซสใช้ ส่วน VIRT แสดงหน่วยความจำเสมือนซึ่งไม่ใช่ RAM จริง จึงอาจทำให้เข้าใจผิดได้

ควรกด kill -9 เพื่อปิดโปรเซสที่ใช้ทรัพยากรสูงทันทีหรือไม่?

ไม่ควรทำทันที ควรบันทึกข้อมูลโปรเซส ตรวจสอบเส้นทางไฟล์ และลอง kill ธรรมดาก่อน หากโปรเซสไม่ยอมปิดและส่งผลกระทบรุนแรง ค่อยใช้ kill -9 เป็นทางเลือกสุดท้าย

CPU ใช้สูงใน htop คือสัญญาณการถูกโจมตีเสมอไหม?

ไม่เสมอไป อาจเกิดจากงานแบ็คอัพ, การนำเข้าข้อมูล, สร้าง cache หรือทราฟฟิกสูง แต่ถ้ามีชื่อไฟล์แปลก, รันจากโฟลเดอร์ /tmp หรือ uploads และโปรเซสไม่ปกติ อาจเป็นสัญญาณถูกโจมตี

สรุปได้ว่า คำสั่ง htop บนเซิร์ฟเวอร์ Linux เป็นเครื่องมือเริ่มต้นที่รวดเร็วและมีประสิทธิภาพในการหาโปรเซสที่กิน CPU และ RAM ร่วมกับการวิเคราะห์ PID, lsof, การตรวจสอบ cron และ log ต่าง ๆ จะช่วยให้เข้าใจสาเหตุและแก้ไขปัญหาได้ตรงจุด หากเซิร์ฟเวอร์คุณประสบปัญหาทรัพยากรจำกัดบ่อยครั้ง ควรพิจารณาปรับซอฟต์แวร์และอัปเกรดโครงสร้างพื้นฐานควบคู่กัน และเปรียบเทียบบริการโฮสติ้ง, VPS และ SSL ของ Hostragons โดยไม่ต้องกังวลเรื่องการขาย เพื่อเลือกโซลูชันที่เหมาะสมที่สุดสำหรับโปรเจกต์ของคุณ