سوال تقریباً ہمیشہ ایک جیسا ہوتا ہے: رات کو سائٹ جواب دینے میں بیس سیکنڈ لگاتی تھی، اور صبح تک سب کچھ خود ہی ٹھیک ہو گیا۔ اب دیکھنے کو کچھ باقی نہیں — top موجودہ سیکنڈ کا جواب دیتا ہے، جبکہ سوال رات تین بجے کے بارے میں ہے۔ ذیل میں یہ ہے کہ بوجھ کے اعداد اصل میں کیا معنی رکھتے ہیں، ان میں سے کن کو جوڑوں میں پڑھنا چاہیے، اور ایک بار کی پیمائش مدد دینے سے زیادہ گمراہ کیوں کرتی ہے۔

Load average: تین اعداد اور ایک عام غلط فہمی

uptime
cat /proc/loadavg
nproc

یہ تینوں اعداد ایک، پانچ اور پندرہ منٹ کے اوسط ہیں۔ انہیں صفر سے نہیں بلکہ کور کی اُس تعداد سے موازنہ کرنا چاہیے جو nproc بتاتا ہے۔ آٹھ کور والی مشین پر 8 کی قدر مکمل مگر صحت مند بوجھ ہے: کام بالکل اتنا ہی ہے جتنا سرور نمٹا سکتا ہے۔ ایک کور والے VPS پر 2 کی قدر گنجائش سے دُگنی لمبی قطار ہے، اور ہر درخواست اپنی باری کا انتظار کرتی ہے۔

تینوں اعداد کا آپس میں تناسب سمت بتاتا ہے۔ ایک منٹ کی قدر پندرہ منٹ کی قدر سے واضح طور پر زیادہ ہو تو بوجھ ابھی بڑھ رہا ہے۔ اس کے برعکس ہو تو عروج گزر چکا ہے اور آپ اس کی دُم دیکھ رہے ہیں۔

اب وہ غلط فہمی جو ان اعداد کی پڑھت سب سے زیادہ خراب کرتی ہے۔ لینکس میں load average «پروسیسر کا استعمال» نہیں ہے۔ دیگر یونکس نظاموں کے برخلاف، لینکس اس میں صرف چلنے والے یا چلنے کے لیے تیار عمل ہی نہیں گنتا بلکہ وہ بھی جو حالت D میں ہوں — ناقابلِ مداخلت نیند میں۔ یعنی وہ جو ڈسک یا نیٹ ورک فائل سسٹم کا انتظار کر رہے ہوں۔ یہیں سے وہ سرور آتا ہے جس کا بوجھ 12 ہے مگر پروسیسر تقریباً فارغ: کام آگے نہیں بڑھ رہا، سب قطار میں کھڑے ہیں۔

پروسیسر یا ڈسک

ان دونوں صورتوں کو الگ کرنا پہلا کام ہے جو کرنے کے لائق ہے:

vmstat 1 5
iostat -x 1 3

vmstat کے نتیجے میں تین کالم اہم ہیں۔ r بتاتا ہے کہ کتنے عمل پروسیسر کی قطار میں ہیں، b کتنے ان پُٹ اور آؤٹ پُٹ کے انتظار میں رُکے ہوئے ہیں، اور wa وقت کا وہ حصہ ہے جو پروسیسر نے فارغ بیٹھ کر ڈسک کا انتظار کرتے گزارا۔ us اور sy کے معمولی ہوتے ہوئے مسلسل 10–15 % سے اوپر wa کا مطلب ہے کہ سرور ڈسک پر اٹکا ہوا ہے: کور بڑھانا بےسود ہے، موجودہ ویسے بھی فارغ ہیں۔

کون سے عمل انتظار میں ہیں، انہیں نام سے گنوایا جا سکتا ہے:

ps -eo state,pid,comm,wchan:30 | awk '$1 ~ /^D/'

اپنے تجربے سے ایک مثال۔ طے شدہ ترتیب کے ساتھ Suricata تقریباً تیس اقسام کے واقعات لکھتی ہے اور ان کے لیے کوئی گردش مقرر نہیں کرتی — ایک فعال سرور پر اس سے دو دن میں 15 گیگا بائٹ لاگ بن گئے۔ بوجھ اُس وقت مصروف پروسیسر کی صورت میں نہیں بلکہ عین I/O wait کی صورت میں ظاہر ہوا: نظام بلا رکے لکھ رہا تھا اور باقی سب اس کے پیچھے قطار میں تھا۔ علاج بڑا پیکیج نہیں بلکہ واقعات کی مختصر فہرست اور مقرر کردہ گردش ہے۔

الٹی صورت، خالصتاً پروسیسر سے متعلق اور کہیں کم واضح۔ ایک ویب صفحہ apt کو اُس صارف کے نام سے پکار رہا تھا جس کے تحت PHP-FPM چلتا ہے۔ روٹ ایک بائنری کیش /var/cache/apt/pkgcache.bin میں رکھتا ہے — درجن بھر ریپوزٹریوں والے میزبان پر یہ 70 میگا بائٹ ہے — اور اسے مفت میں میموری میں نقشہ بند کر لیتا ہے۔ عام صارف اس ڈائریکٹری میں نہیں لکھ سکتا اور ہر بار کیش نئے سرے سے بناتا ہے۔ ایک ہی مشین پر پیمائش: روٹ کے طور پر 0.01 سیکنڈ پروسیسر وقت اور بغیر اختیارات والے صارف کے طور پر 4.2 سیکنڈ۔ وہی ایک کمانڈ، چار سو گنا فرق، اور یہ فرق صفحے کے ہر بار کھلنے سے ضرب کھاتا رہا۔

دونوں صورتوں کا نتیجہ ایک ہی ہے: بوجھ ناپا جاتا ہے، اندازہ نہیں لگایا جاتا۔ ہر مشکوک کمانڈ کا الگ الگ وقت لینا آدھا گھنٹہ لیتا ہے اور عموماً وہاں اشارہ کرتا ہے جہاں سے شک شروع نہیں ہوا تھا۔

میموری: free وہ نہیں دکھاتا جو لگتا ہے

free -h

کالم used بذاتِ خود بہت کم بتاتا ہے، اور کالم free تو سیدھا گمراہ کرتا ہے: لینکس غیر استعمال شدہ میموری صفحہ کیش کو دے دیتا ہے اور پہلی درخواست پر ایپلی کیشنز کو واپس کر دیتا ہے۔ پڑھنے کا کالم available ہے — یعنی swap میں گئے بغیر کتنی میموری لی جا سکتی ہے۔ بڑا buff/cache مسئلہ نہیں بلکہ اس بات کی علامت ہے کہ نظام درست چل رہا ہے۔

swap میں موجودہ قدر نہیں بلکہ شکل اہم ہے۔ بڑھا اور صفر پر واپس آ گیا: مختصر عروج تھا۔ ایک بار بڑھا اور وہیں رہ گیا: عروج گزر چکا، صفحات باہر دھکیلے جا چکے اور کوئی انہیں واپس نہیں لاتا — سرور پُرسکون دکھتا ہے حالانکہ کسی لمحے اس کی میموری کم پڑ گئی تھی۔ تبادلہ ابھی جاری ہے یا نہیں، یہ vmstat کے کالم si اور so دکھاتے ہیں؛ وہاں صفر سے مختلف اقدار سستی کی وہ صورت ہیں جو صارفین سب سے زیادہ محسوس کرتے ہیں۔

اگر رات کے زوال کے دوران کوئی عمل محض غائب ہو گیا ہو تو وضاحت عموماً یہاں ملتی ہے:

journalctl -k --since yesterday | grep -i "out of memory"
dmesg -T | grep -i "killed process"

Out of memory: Killed process 1234 (mysqld) جیسی سطر معاملہ کسی بھی گراف سے بہتر طے کر دیتی ہے: ڈیٹابیس «خود سے نہیں گرا»، کرنل نے اسے روکا کیونکہ میموری ختم ہو گئی تھی۔

یہ کون کر رہا ہے

ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10

ایک تحفظ: ps میں %CPU عمل کی پوری زندگی کا اوسط ہے، اس لیے مختصر اُچھال اس فہرست میں کھو جاتا ہے۔ اس کے لیے top یا pidstat 1 5 چاہیے، جو ایک وقفے پر ناپتے ہیں۔

بوجھ کب سلامتی کا سوال بن جاتا ہے

رات بھر پروسیسر کا ہموار 100 %، ساتھ ایسا عمل جس کا نام بےمعنی ہو اور کام کرنے کی ڈائریکٹری /tmp یا /dev/shm میں ہو، کان کن کی کلاسیکی تصویر ہے، بڑھی ہوئی سائٹ کی نہیں۔ آنے والے ٹریفک میں اُچھال کے ساتھ لاگ میں لکھائی کا بڑھنا جاری پاس ورڈ حملہ ہے۔ لاگ کا حجم اچانک بڑھ جائے تو یہ عموماً کسی فلٹر کے جھوٹے الارموں کا طوفان ہوتا ہے۔

حفاظتی اوزار خود ایک الگ زمرہ ہیں۔ ہمارے ایک سرور پر کسی بھی وزیٹر کے بغیر بوجھ تین کے آس پاس رہا، اور جمع شدہ پروسیسر وقت کے حساب سے ps کی فہرست میں سب سے اوپر نہ سائٹ تھی نہ ڈیٹابیس، بلکہ CrowdSec، fail2ban، Falco اور Suricata تھے۔ یہ نہ خرابی ہے نہ انہیں بند کرنے کی وجہ، لیکن تحفظ کی قیمت اعداد میں جاننا مفید ہے: چھوٹے VPS پر یہ محسوس ہوتی ہے۔

نگرانی کس لیے

اوپر بیان کردہ سب کچھ اس سوال کا جواب دیتا ہے کہ «ابھی کیا ہو رہا ہے»۔ صبح کا سوال — رات تین بجے کیا ہوا — ان کمانڈوں سے پورا نہیں ہوتا: گزری رات کا کوئی ڈیٹا نہیں ہوتا اگر کسی نے اسے ریکارڈ نہ کیا ہو۔ اور صرف ایک VPS کے لیے Prometheus اور Grafana کھڑا کرنا مشکوک ہے، کیونکہ نگرانی کرنے والا ڈھانچہ زیرِ نگرانی سرور سے بھاری نکلتا ہے۔

ہر پانچ منٹ بعد ڈیٹابیس میں ایک سطر اور ایک ایسا صفحہ کافی ہے جو اس سے پچھلے چوبیس گھنٹے کھینچ دے: load average، پروسیسر کا استعمال اور الگ سے I/O wait، میموری اور swap، ڈسک پر پڑھائی اور لکھائی، پارٹیشن کا بھراؤ، inodes، فائل ڈسکرپٹرز، کنکشنز۔ ایک ہی وقتی پیمانے پر جوڑے کھلی آنکھ سے پڑھے جاتے ہیں: پُرسکون پروسیسر کے ساتھ بلند wa، وہ swap جو کبھی صفر پر واپس نہ آیا، حد کے قریب پہنچتے ڈسکرپٹرز — آنے والی خرابی too many open files ہونے سے گھنٹوں پہلے نظر آنے لگتی ہے۔ یہ سب یکجا ہو کر کیسا لگتا ہے، نیچے دیا گیا ڈیمو صفحہ دکھاتا ہے۔