ประสิทธิภาพ

ประวัติโหลดของเซิร์ฟเวอร์: 24 ชั่วโมง, 7 หรือ 30 วัน (เก็บข้อมูลทุก 5 นาที)

Load Average (1m)
1.24
CPU
3.6%
RAM
26.8%
ESTABLISHED
53
โปรเซส
2 / 404
ในช่วงนี้แสดงค่าเฉลี่ยรายชั่วโมง ไม่ใช่การวัดแต่ละครั้ง
Load Average
CPU
หน่วยความจำ
เครือข่าย (KB/s)
Disk I/O (KB/s)
การเชื่อมต่อ TCP
ดิสก์และลิมิต (%)
MySQL
โปรเซสในการวัดล่าสุด 23:54
โปรเซสCPU %RAM %
crowdsec 4.7 4.2
clamd 3.0 18.1
mysqld 1.9 11.9
falco 0.9 14.2
apache2 0.6 0.7
โปรเซสในช่วงพีคของวัน 11.10 08:49 · load 2.73
โปรเซสCPU %RAM %
fail2ban-server 9.0 17.5
falco 4.9 1.9
clamd 3.5 11.0
crowdsec 2.4 1.8
mysqld 1.4 4.5

ประวัติภาระของเซิร์ฟเวอร์โดยไม่ต้องใช้ Prometheus และ Grafana

top ตอบคำถามเกี่ยวกับวินาทีปัจจุบัน ขณะที่คำถามที่ถามกันจริงมักเป็นเรื่องของคืนที่ผ่านมา ว่าทำไมตอนตีสามทุกอย่างจึงหยุดนิ่งแล้วกลับมาเองได้ ถึงตอนนั้นก็ไม่เหลืออะไรให้ดูแล้ว เพราะไม่มีสิ่งใดถูกบันทึกไว้ ส่วนการตั้ง Prometheus และ Grafana เพื่อ VPS เพียงเครื่องเดียวก็เป็นปัญหาในตัวเอง เพราะกองซอฟต์แวร์ที่คอยเฝ้าดูหนักกว่าเซิร์ฟเวอร์ที่ถูกเฝ้าดู

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

กราฟเหล่านี้ควรอ่านเป็นคู่ ค่า I/O wait สูงขณะที่ CPU สงบหมายความว่าเซิร์ฟเวอร์กำลังรอดิสก์ การเพิ่มคอร์จึงไม่ช่วยอะไร swap ที่เคยขึ้นครั้งหนึ่งแล้วไม่เคยกลับมาที่ศูนย์บอกว่าจุดสูงสุดของหน่วยความจำได้ผ่านไปแล้ว ไม่ว่าตอนนี้จะดูสงบเพียงใด ตัวชี้ไฟล์ที่ไต่ใกล้ร้อยเปอร์เซ็นต์คือข้อผิดพลาด too many open files ล่วงหน้าหลายชั่วโมงก่อนเกิดจริง และบนเซิร์ฟเวอร์ส่วนใหญ่ inodes หมดก่อนพื้นที่ว่างอยู่มาก