คู่มือการใช้งาน เมนู Process Monitor - (DirectAdmin Admin Level)

อ่าน Process, CPU, Memory และ Load จากหน้า Process Monitor พร้อมแนวทางส่ง Signal เฉพาะเมื่อจำเป็นจริง ๆ

อัปเดตข้อมูลเมื่อ 17 ก.ค. 2026

รู้จัก Process Monitor และเข้าเมนูจาก Dashboard

เมนู Process Monitor ใน DirectAdmin ระดับ Admin Level ช่วยให้ผู้ดูแลระบบดูรายการ process ที่กำลังรันอยู่บนเครื่องจากมุมผู้ดูแลระบบ คล้ายการอ่านผลลัพธ์จากคำสั่ง top แบบ snapshot ผ่านหน้า control panel ผู้ดูแลใช้เมนูนี้เพื่อตรวจ load, จำนวน process, การใช้ CPU/memory, process ที่กินทรัพยากรสูง และสถานะของ process ก่อนตัดสินใจตรวจต่อผ่าน SSH หรือส่ง signal เมื่อจำเป็นจริง ๆ

ภาพหน้าจอ DirectAdmin Admin Dashboard ที่ใส่กรอบสีแดงรอบเมนู Process Monitor ในกลุ่ม Admin Tools — เข้าเมนู Process Monitor จากกลุ่ม Admin Tools ในหน้า Admin Dashboard โดยกดเฉพาะเมนูที่ถูกกรอบสีแดงไว้

เส้นทางเข้าเมนูจาก Dashboard คือ:

Admin Level > Admin Tools > Process Monitor

ในหน้า Dashboard ให้ดูเฉพาะกลุ่ม Admin Tools แล้วกดเมนู Process Monitor

คำเตือน: Process Monitor เป็นหน้าระดับผู้ดูแลระบบ แม้การดูรายการ process จะปลอดภัย แต่การส่ง signal ไปยัง process ผิดตัวอาจทำให้เว็บไซต์, ฐานข้อมูล, mail service, monitoring agent หรือ service สำคัญหยุดทำงานได้ ถ้าไม่มั่นใจควรใช้หน้านี้เพื่อเก็บข้อมูลก่อน แล้วตรวจต่อด้วย SSH/console หรือทีมที่ดูแลระบบ

สำรวจหน้ารวม Process และการยืนยันสิทธิ์

เมื่อเข้าเมนู Process Monitor แล้ว breadcrumb ด้านบนแสดง Dashboard > Process Monitor โดย Dashboard เป็นลิงก์กลับหน้าแรก และ Process Monitor คือหน้าปัจจุบัน ใช้ยืนยันว่ากำลังอยู่ในเมนู monitor process ไม่ใช่หน้า Brute Force Monitor, Mail Queue หรือ System Services

ภาพหน้าจอหน้าหลัก Process Monitor แสดง breadcrumb Dashboard Process Monitor help icon ปุ่ม Authenticate to send signals summary และตาราง process — หน้าหลักของ Process Monitor แสดง breadcrumb, help icon, ปุ่ม Authenticate to send signals, summary สถานะเครื่อง และตาราง process

ส่วนหัวของหน้ามีชื่อ Process Monitor และมี help ไอคอน ข้างชื่อหน้า ซึ่งเป็นลิงก์ไปยังเอกสารช่วยเหลือของ DirectAdmin สำหรับเมนูนี้ ด้านขวาของพื้นที่เนื้อหามีปุ่ม Authenticate to send signals พร้อมไอคอน เพื่อเปิดสิทธิ์ส่ง signal ไปยัง process

ปุ่ม Authenticate to send signals ไม่ได้ใช้รหัสผ่าน login ของ DirectAdmin เสมอไป แต่ต้องใช้ Root Password ตามหน้าต่างที่ DirectAdmin เปิดขึ้น ถ้ายังไม่ authenticate สำเร็จ หน้านี้จะอยู่ในโหมดดูข้อมูลเป็นหลัก และยังไม่แสดงคำสั่งสำหรับส่ง signal ราย process

เมนูนี้ไม่มี tab แยก และในหน้าปกติไม่มีช่องเลือกหรือคำสั่งแบบหลายรายการ แบบหน้า users/packages การทำงานหลักของหน้าคืออ่าน summary, ใช้ Reload/refresh interval, อ่านตาราง process, เปลี่ยนหน้า pagination และ authenticate ก่อนส่ง signal เฉพาะ process ที่เลือก

อ่านภาพรวม CPU, Memory และจำนวน Process

บล็อก summary ด้านบนเป็นข้อมูลสถานะเครื่องในรูปแบบที่ DirectAdmin แปลงจาก output ของ top โดยในบัญชีตัวอย่างแสดง label หลักคือ Top, Tasks, CPU(s), KiB/MiB Mem และ KiB/MiB Swap ตัวเลขเหล่านี้เปลี่ยนได้ทุกครั้งที่ reload หรือ auto refresh

ภาพหน้าจอ Process Monitor ส่วน Top summary แสดง Top Tasks CPU KiB Mem และ KiB Swap — Top summary ใช้อ่าน load average, จำนวน tasks, CPU usage, memory และ swap จาก snapshot ล่าสุดของ DirectAdmin

ส่วนใน summary	ความหมาย	วิธีอ่านแบบผู้ดูแลระบบ
Top	เวลาปัจจุบัน, uptime, จำนวน user login และ load average	ใช้ดูภาพรวมว่าเครื่องทำงานต่อเนื่องมานานแค่ไหน และ load average สูงผิดปกติหรือไม่
Tasks	จำนวน process ทั้งหมด พร้อมสถานะ running, sleeping, stopped และ zombie	ถ้า zombie หรือ stopped เพิ่มผิดปกติควรตรวจ process ต้นทางและ service ที่เกี่ยวข้อง
CPU(s)	สัดส่วน CPU เช่น user, system, nice, idle, wait และ interrupt	ดูว่า CPU ใช้กับงานจริงมาก, kernel มาก, idle สูง หรือมี wait/interrupt ผิดปกติ
Mem	หน่วยความจำ total, free, used และ buff/cache	ใช้ดูว่า RAM ถูกใช้จริงเท่าไร และยังมี buffer/cache ช่วยระบบอยู่หรือไม่
Swap	swap total, free, used และ available memory	ถ้า swap used สูงต่อเนื่องควรตรวจ memory pressure และ process ที่กิน RAM

ตัวเลขในภาพเป็นค่าของเครื่องระบบตัวอย่างณ เวลาในระบบตัวอย่างเท่านั้น ไม่ใช่ benchmark หรือค่าปกติที่ทุกเครื่องต้องเหมือนกัน เวลาวิเคราะห์ production ให้เทียบกับ baseline ของเครื่องตัวเองและช่วงเวลาที่เกิดปัญหา

กำหนดช่วงเวลารีเฟรชข้อมูล

ใต้ summary มี toolbar สำหรับ refresh ข้อมูล โดยมีปุ่ม Reload และเมนูเลือกรอบ Refresh ที่ค่าเริ่มต้นในหน้าตัวอย่างแสดงเป็น 15s

ภาพหน้าจอ Process Monitor หลังเปิด dropdown refresh interval แสดงปุ่ม Reload และตัวเลือก 5 seconds 15 seconds 30 seconds และ 1 minute — Reload ใช้ดึงข้อมูลทันที ส่วน refresh interval ใช้ตั้งรอบ refresh อัตโนมัติเป็น 5s, 15s, 30s หรือ 1 minute

Reload - ดึงข้อมูล process ล่าสุดทันที ใช้หลังต้องการเทียบว่าค่า CPU/memory หรือ process list เปลี่ยนไปหรือไม่
เมนูรอบ Refresh - ตั้งรอบ refresh อัตโนมัติของหน้า
5 seconds - refresh ถี่ เหมาะกับการเฝ้าดูปัญหาสั้น ๆ แต่ทำให้ตัวเลขกระพริบและเปลี่ยนเร็ว
15 seconds - ค่าเริ่มต้นที่สมดุลสำหรับการดูทั่วไป
30 seconds - ลดความถี่ เหมาะกับการเปิดดูระหว่างรออาการซ้ำ
1 minute - refresh ช้าที่สุดในตัวเลือกที่พบ เหมาะกับการ monitor แบบไม่ต้องจับวินาทีต่อวินาที

การ reload หรือปรับ interval ไม่ได้แก้ปัญหา load สูง เป็นเพียงการดึงข้อมูลล่าสุดจาก DirectAdmin ถ้ากำลังตรวจ incident ควรจดเวลา, PID, USER, %CPU, %MEM และ COMMAND ก่อนค่าเปลี่ยนในรอบ refresh ถัดไป

อ่านทรัพยากรที่แต่ละ Process กำลังใช้

ตารางด้านล่างคือรายการ process ที่ DirectAdmin อ่านจากระบบ ทุกหัวคอลัมน์เป็นจุดที่ใช้ sort ได้ และข้อมูลในแถวจะเปลี่ยนตามรอบ refresh ปัจจุบันหน้าจอตัวอย่างอยู่ในโหมดยังไม่ authenticate จึงไม่มีคอลัมน์คำสั่งส่ง signal ปรากฏให้กด

ภาพหน้าจอตาราง process ใน DirectAdmin แสดงคอลัมน์ PID USER PR NI VIRT RES SHR S CPU MEM TIME และ COMMAND — ตาราง process แสดง PID, user, priority, memory, CPU, runtime และ command ที่ต้องอ่านให้ครบก่อนตัดสินใจส่ง signal

คอลัมน์	ความหมาย	ข้อควรอ่านก่อนสั่งงาน
PID	Process ID ของ process นั้น	ต้องตรวจ PID ให้ตรง เพราะ PID เปลี่ยนได้เมื่อ process restart
USER	user ที่รัน process เช่น `root`, `netdata` หรือ user ของระบบ	ช่วยแยกว่า process เป็นของ system service, monitoring agent หรือ user workload
PR	priority ของ scheduler	ค่า priority แปลกอาจบอกว่า process ถูกปรับ scheduling ไว้เป็นพิเศษ
NI	niceness ของ process	ค่า negative มักมี priority สูงกว่า ต้องระวังเป็นพิเศษก่อนส่ง signal
VIRT	virtual memory ที่ process เห็น	ไม่ใช่ RAM จริงทั้งหมด ใช้เทียบกับ RES/SHR ประกอบกัน
RES	resident memory หรือ RAM ที่ process ใช้จริงโดยประมาณ	ถ้าสูงผิดปกติให้เทียบกับ %MEM และ command
SHR	shared memory	ใช้แยกส่วน memory ที่ share กับ process อื่น
S	สถานะ process เช่น R, S หรือ I	R คือกำลัง run, S คือ sleeping, I คือ idle kernel thread ในหลายกรณี
%CPU	สัดส่วน CPU ที่ process ใช้ในรอบอ่านข้อมูล	ใช้ sort หา process ที่กิน CPU สูง แต่ต้อง reload เทียบหลายรอบ
%MEM	สัดส่วน memory ที่ process ใช้	ใช้หา process ที่กิน RAM สูงหรือทำให้ swap เริ่มถูกใช้
TIME+	เวลา CPU สะสมของ process	ช่วยแยก process ที่เพิ่ง spike กับ process ที่ทำงานหนักมานาน
COMMAND	คำสั่งเต็มหรือชื่อ process	อ่านให้ครบก่อนตัดสินใจ เพราะบาง process เป็น service สำคัญของ OS หรือ DirectAdmin

เมนูนี้ไม่ควรใช้เพื่อ kill process จากชื่อ command อย่างเดียว โดยเฉพาะ process ของ systemd, kernel thread, database, mail service, web server, monitoring agent หรือ process ที่ไม่รู้หน้าที่แน่ชัด ให้ตรวจ PID/USER/COMMAND พร้อมข้อมูลจาก log หรือ SSH ก่อนเสมอ

เลื่อนดู Process เมื่อมีรายการจำนวนมาก

ด้านล่างของตารางมีส่วน pagination สำหรับเลื่อนดู process ที่ไม่ได้อยู่ใน 50 แถวแรก ในภาพระบบตัวอย่างแสดงข้อความลักษณะ 1-50 of 221 processes พร้อมเมนูตัวเลือกและปุ่มเลขหน้า

ภาพหน้าจอด้านล่างตาราง Process Monitor แสดงข้อความ 1-50 of processes dropdown และ pagination Previous เลขหน้า Next — Pagination ใช้เลื่อนดู process หน้าถัดไป พร้อมบอกช่วงรายการที่กำลังแสดงและจำนวน process ทั้งหมดในรอบอ่านข้อมูลนั้น

ส่วนควบคุมที่เกี่ยวกับ pagination ได้แก่:

1-50 of ... processes - บอกช่วงรายการที่กำลังแสดงและจำนวน process ทั้งหมดที่ DirectAdmin อ่านได้ในขณะนั้น
Previous - ย้อนกลับหน้าก่อนหน้า ปุ่มนี้ถูก disable เมื่ออยู่หน้าแรก
เลขหน้า 1, 2, 3, 4, 5 - เปิดหน้าของ process list ตามลำดับ
Next - ไปหน้าถัดไป ถ้ายังมี process ต่อจากช่วงที่แสดงอยู่
เมนูตัวเลือกข้างจำนวนรายการ - ใช้ควบคุม/แสดงช่วงรายการต่อหน้าในตารางตาม UI ของ DirectAdmin

ถ้ากำลังตามหา process ที่กิน CPU สูง ให้เริ่มจาก sort คอลัมน์ %CPU หรือ %MEM ก่อนเปลี่ยนหน้า pagination เพราะ process ที่สำคัญมักอยู่หน้าแรกหลัง sort แล้ว แต่ถ้าต้องหา PID เฉพาะ ให้ใช้ข้อมูลจาก log/SSH มายืนยันร่วมด้วย

ยืนยันสิทธิ์ Root ก่อนส่ง Signal

เมื่อกด Authenticate to send signals DirectAdmin เปิดหน้าต่างชื่อเดียวกันบนหน้าเดิม พื้นหลังของหน้า Process Monitor จะถูก dim/blur เพื่อบอกว่าตอนนี้กำลังทำงานในหน้าต่าง

ภาพหน้าจอ dialog Authenticate to send signals ใน DirectAdmin Process Monitor แสดงช่อง Root Password ปุ่ม Show icon Close และ Authenticate — ก่อนส่ง signal ต้อง authenticate ด้วย Root Password ผ่าน dialog ที่มีปุ่ม Close, ช่อง Root Password, icon Show และปุ่ม Authenticate

องค์ประกอบในหน้าต่างมีดังนี้:

Close X - ปิดหน้าต่างโดยไม่ authenticate
Root Password - ช่องกรอกรหัสผ่าน root ที่ DirectAdmin ต้องใช้เพื่อเปิดสิทธิ์ส่ง signal
Show ไอคอน - ไอคอนรูปตาในช่องรหัสผ่าน ใช้แสดง/ซ่อนรหัสที่กำลังกรอกเพื่อตรวจ typo
Authenticate - ปุ่มยืนยันการตรวจ Root Password

ในการ การทดสอบครั้งนี้ credential ที่ใช้ login เป็น admin ได้ แต่เมื่อนำรหัสเดียวกันไปใส่ในช่อง Root Password แล้ว DirectAdmin ตอบกลับจาก endpoint ว่า Unable to authenticate: Invalid password และยังคงไม่เปิด signal คำสั่งให้ใช้งาน นี่เป็นพฤติกรรมสำคัญ: รหัสเข้า panel กับ Root Password สำหรับส่ง signal อาจไม่ใช่รหัสเดียวกัน

ข้อควรระวัง: อย่าเดารหัส root หลายครั้งบนเครื่องจริง ถ้าไม่มี Root Password ให้หยุดที่โหมดอ่านข้อมูล และส่ง PID/COMMAND/เวลาเกิดเหตุให้ผู้ดูแล server ตรวจผ่าน SSH หรือ console ที่เหมาะสมกว่า

ส่ง Signal ให้ Process อย่างปลอดภัย

จาก route ของ DirectAdmin Evolution สำหรับหน้า Process Monitor เมื่อ authenticate สำเร็จ ค่า require_root_auth จะเปลี่ยนเป็นสถานะที่ทำให้หน้าแสดงคำสั่งสำหรับส่ง signal ราย process และมีคำสั่ง Remove Authentication เพื่อถอนสถานะ authentication ออกจากหน้านี้

ภาพหน้าจอ dialog Authenticate to send signals หลังกรอกรหัสในช่อง Root Password โดยยังต้องยืนยันก่อนเปิดสิทธิ์ส่ง signal — การเปิดสิทธิ์ส่ง signal ต้องใช้ Root Password ที่ถูกต้อง หาก authenticate ไม่ผ่าน DirectAdmin จะไม่เปิด action ส่ง signal ให้ใช้งาน

Signal ที่ UI ของ DirectAdmin เตรียมไว้ในเมนูนี้ ได้แก่:

Signal	ใช้เมื่อไร	คำเตือน
1 - HUP	มักใช้ให้ process reload configuration หรือ hangup ตาม behavior ของโปรแกรมนั้น	บาง service อาจ restart/reload connection ต้องรู้ behavior ก่อนใช้
2 - INT	interrupt คล้ายกด Ctrl+C ให้ process หยุดอย่างสุภาพกว่า kill	ถ้า process ไม่ handle signal อาจหยุดทันที
3 - QUIT	ขอให้ process quit และบางโปรแกรมอาจสร้าง core dump	ไม่ควรใช้กับ service สำคัญโดยไม่รู้ผลข้างเคียง
6 - ABRT	abort process	เสี่ยงสูง อาจทำให้เกิด dump หรือข้อมูลค้าง
9 - KILL	บังคับหยุด process ทันที	รุนแรงที่สุด ไม่มีโอกาส cleanup ควรใช้เป็นทางเลือกท้าย ๆ
10 - USR1	custom signal ที่โปรแกรมแต่ละตัวตีความเอง	ต้องอ่านเอกสารของ service นั้นก่อนใช้
12 - USR2	custom signal อีกช่องหนึ่งสำหรับโปรแกรมที่รองรับ	ผลลัพธ์ขึ้นกับโปรแกรม ไม่ควรเดา
14 - ALRM	alarm signal	ใช้เฉพาะกรณีที่รู้ว่า process รองรับ
15 - TERM	ขอให้ process terminate แบบสุภาพกว่าการ KILL	แม้สุภาพกว่า แต่ยังทำให้ service หยุดได้จริง

จาก component ของ DirectAdmin หน้า Process Monitor การส่ง signal เป็นคำสั่งราย process และเมื่อส่งสำเร็จจะแจ้งว่า Signal was successfully received แต่ไม่มีหน้าต่างยืนยันแยกก่อนส่ง signal ดังนั้นต้องถือว่าการเลือก signal คือคำสั่งจริงทันที ไม่ใช่หน้าทดลอง

Checklist ก่อนส่ง signal บน production:

ยืนยัน PID ล่าสุด - reload ก่อนส่ง เพราะ PID อาจเปลี่ยนหลัง process restart
อ่าน USER และ COMMAND ให้ครบ - อย่าส่ง signal จาก %CPU สูงอย่างเดียว
เลือก signal ที่เบาที่สุดก่อน - ถ้าต้องหยุด process ให้พิจารณา TERM ก่อน KILL เมื่อเหมาะสม
หลีกเลี่ยง process ระบบหลัก - เช่น init/systemd, database, mail, web server, DirectAdmin, monitoring agent หรือ kernel thread
เตรียม rollback/monitoring - หลังส่ง signal ให้ดู service status, logs และผลกระทบกับเว็บไซต์/อีเมลทันที
กด Remove Authentication เมื่อจบงาน - ลดโอกาสที่ session เดิมจะถูกใช้ส่ง signal ต่อโดยไม่ตั้งใจ

ใช้ Process Monitor เป็นเครื่องมืออ่านสถานะและเก็บหลักฐานก่อนตัดสินใจ เมื่อถึงขั้นส่ง signal ให้ทำเหมือนกำลังสั่งงานบน shell ด้วยสิทธิ์ root เพราะผลลัพธ์มีผลกับ process จริงบน server

หากไม่แน่ใจว่าค่าหรือคำสั่งใดจะกระทบส่วนไหนของเซิร์ฟเวอร์ ให้หยุดไว้ก่อน แล้วเก็บภาพหน้าจอกับรายละเอียดที่เกี่ยวข้องส่งให้ทีมงาน PhalconHost ช่วยตรวจสอบได้ครับ