পারফরম্যান্স

সার্ভার লোডের ইতিহাস: ২৪ ঘণ্টা, ৭ বা ৩০ দিন (সংগ্রহ — প্রতি ৫ মিনিটে একবার)

Load Average (1m)
1.22
CPU
11.8%
RAM
30.8%
ESTABLISHED
92
প্রসেস
1 / 397
এই সময়ে ঘণ্টাভিত্তিক গড় দেখানো হয়, আলাদা আলাদা পরিমাপ নয়।
Load Average
CPU
মেমরি
নেটওয়ার্ক (KB/s)
ডিস্ক I/O (KB/s)
TCP সংযোগ
ডিস্ক ও লিমিট (%)
MySQL
সর্বশেষ পরিমাপের প্রক্রিয়া 01:27
প্রক্রিয়াCPU %RAM %
apache2 13.4 4.7
clamd 9.8 5.3
crowdsec 6.6 9.6
suricata 4.7 0.9
falco 2.6 16.5
দিনের সর্বোচ্চ সময়ের প্রক্রিয়া 11.10 08:57 · load 2.00
প্রক্রিয়াCPU %RAM %
falco 19.5 5.3
mysqld 13.1 9.6
fail2ban-server 8.1 8.8
crowdsec 5.7 13.6
apache2 3.5 11.0

Prometheus ও Grafana ছাড়া সার্ভার লোডের ইতিহাস

top চলতি সেকেন্ড নিয়ে প্রশ্নের উত্তর দেয়, অথচ আসল প্রশ্নটি সাধারণত গত রাত নিয়ে: রাত তিনটায় কেন সব থেমে গিয়ে নিজে থেকেই ফিরে এল। ততক্ষণে দেখার আর কিছু থাকে না, কারণ কোথাও কিছু জমা হয়নি। একটিমাত্র VPS-এর জন্য Prometheus ও Grafana দাঁড় করানোও নিজেই একটি সমস্যা: যে স্ট্যাক নজর রাখে, সেটি নজরে থাকা সার্ভারের চেয়ে ভারী হয়ে দাঁড়ায়।

একটি সংগ্রাহক প্রতি পাঁচ মিনিটে ডেটাবেসে একটি সারি যোগ করে, আর এই পাতা সেগুলি থেকে শেষ চব্বিশ ঘণ্টা আঁকে। Load average, CPU-এর ব্যবহার এবং আলাদা করে I/O wait, RAM ও swap, আসা ও যাওয়া নেটওয়ার্ক ট্র্যাফিক, ডিস্কের পড়া ও লেখা, স্থাপিত TCP সংযোগ, প্রক্রিয়া, পার্টিশনের ভরাট, inodes ও ফাইল ডেসক্রিপ্টর তাদের সীমার শতাংশে, এবং MySQL সংযোগ। সবই এক পাতায় ও এক সময়-অক্ষে, ফলে মিলগুলি খালি চোখে ধরা পড়ে।

এই লেখচিত্রগুলি জোড়ায় পড়া ভালো। শান্ত CPU-এর পাশে উঁচু I/O wait মানে সার্ভার ডিস্কের অপেক্ষায় আছে, আর কোর বাড়িয়ে লাভ হবে না। যে swap একবার বেড়ে আর কখনও শূন্যে ফেরেনি, সেটি বলে দেয় মেমরির চূড়া আগেই ঘটে গেছে, এখন যতই শান্ত দেখাক। শতভাগের কাছে পৌঁছানো ফাইল ডেসক্রিপ্টর হলো too many open files ত্রুটি, ঘটার কয়েক ঘণ্টা আগেই। আর বেশির ভাগ সার্ভারে খালি জায়গার অনেক আগেই inodes ফুরিয়ে যায়।