ประสิทธิภาพ

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

Load Average (1m)
1.51
CPU
5.1%
RAM
31.3%
ESTABLISHED
57
โปรเซส
3 / 445
Load Average
CPU
หน่วยความจำ
เครือข่าย (KB/s)
Disk I/O (KB/s)
การเชื่อมต่อ TCP
ดิสก์และลิมิต (%)
MySQL
โปรเซสในการวัดล่าสุด 00:40
โปรเซสCPU %RAM %
falco 7.4 5.6
mysqld 4.4 7.3
crowdsec 2.6 15.6
apache2 1.4 4.5
fail2ban-server 0.7 17.1
โปรเซสในช่วงพีคของวัน 11.10 08:20 · load 2.74
โปรเซสCPU %RAM %
apache2 18.0 9.3
mysqld 12.8 14.0
clamd 8.9 14.3
falco 6.2 11.0
suricata 2.8 18.4

ประวัติภาระของเซิร์ฟเวอร์โดยไม่ต้องใช้ 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 หมดก่อนพื้นที่ว่างอยู่มาก