CPU 100% پر ہے

“Overview” ٹیب میں CPU گراف کا پلیٹاؤ بذاتِ خود کوئی ایمرجنسی نہیں: پروجیکٹ بنانا یا آرکائیو تیار کرنا واقعی تمام کورز استعمال کر کے پھر انہیں چھوڑ دیتا ہے۔ یہ تشویشناک ہوتا ہے جب پلیٹاؤ گھنٹوں جاری رہے اور مشین جواب دینا بند کر دے۔ آئیے معلوم کریں کہ قصور کس کا ہے۔

مرحلہ 1۔ دیکھیں کہ کون سے وسائل استعمال کر رہا ہے

“Screen” (VNC) ٹیب فل اسکرین پروگراموں کے ساتھ کام کرنے کے لیے آسان ہے:

btop
htop

سیریل کنسول ونڈو کا سائز منتقل نہیں کرتا؛ وہاں ہمیشہ 80×24 ہوتا ہے، اس لیے انٹرفیس کٹ جائے گا۔ ٹیکسٹ کنسول کے لیے معیاری کمانڈز استعمال کریں:

top -b -n1 | head -20
ps aux --sort=-%cpu | head -10

حساب یاد رکھیں: %CPU فی کور شمار ہوتا ہے۔ VDS-3 پر 400% کا مطلب ہے تمام چار کورز، جبکہ VDS-4 پر 100% صرف چھ میں سے ایک ہے۔

مرحلہ 2۔ CPU اور ڈسک میں فرق کریں

اوسط لوڈ (load average) صرف حساب سے نہیں، I/O ویٹ سے بھی بڑھتا ہے:

uptime
vmstat 1 5

vmstat کے آؤٹ پٹ میں کالمز us (یوزر کوڈ)، sy (کرنل)، wa (ڈسک ویٹ) اور st (چھینا گیا وقت) دیکھیں۔ بڑا wa مطلب CPU ڈسک کے انتظار میں خالی بیٹھا ہے — رکاوٹ حساب نہیں بلکہ رائٹ اسپیڈ ہے۔ ہمارے ٹیئرز پر ڈسک کا پلیٹاؤ ایک قاعدے سے طے ہوتا ہے: فی کور 60 MB/s رائٹ، 60 سے کم نہیں اور 400 MB/s سے زیادہ نہیں، ریڈ اس سے دوگنا، اور پلیٹاؤ سے تین گنا زیادہ برسٹ 30 سیکنڈ تک چلتا ہے۔ اگر کوئی ٹاسک مسلسل لکھتا رہے تو برسٹ ختم ہو جائے گا اور آپ پلیٹاؤ پر پہنچ جائیں گے۔

مرحلہ 3۔ کسی مخصوص پروسیس کی جانچ کریں

pidstat -p <pid> 1 5
cat /proc/<pid>/status
journalctl -u <service> -n 100 --no-pager

عام پائے جانے والے مسائل:

• کوئی ویب ایپلیکیشن ناکام درخواست کے بعد لامتناہی لوپ میں گھوم رہی ہے؛
• ڈیٹابیس بغیر انڈیکس کے کوئری چلا رہا ہے — اس کا اپنا سلو کوئری لاگ دیکھیں؛
• کوئی cron جاب اس سے زیادہ بار شروع ہو رہا ہے جتنی بار وہ مکمل ہو سکتا ہے، اور مثالیں جمع ہو رہی ہیں: ps aux | grep <name> درجن بھر کاپیاں دکھائے گا؛
• کوئی مائنر جو کمزور root پاس ورڈ کے ذریعے مشین پر آ گیا۔ نشانی یہ ہے کہ بے معنی نام کا پروسیس غیر معیاری یوزر کے تحت چل رہا ہو اور آؤٹ گوئنگ بینڈوڈتھ زیادہ ہو۔ ایسی صورت میں مشین کو “Access” ٹیب سے دوبارہ انسٹال کرنا صاف کرنے سے آسان ہے۔

مرحلہ 4۔ حد لگائیں، مار نہیں

اگر پروسیس ضروری ہے مگر باقی کاموں میں رکاوٹ نہیں بننا چاہیے:

renice -n 15 -p <pid>
systemctl set-property myapp.service CPUQuota=200%

CPUQuota=200% مطلب دو پورے کورز۔ systemd کی حد سروس ری اسٹارٹ کے بعد بھی برقرار رہتی ہے؛ renice نہیں رہتی۔

کسی پروسیس کو kill -9 سے مارنے سے پہلے عام systemctl stop آزمائیں۔ ڈیٹابیس کو زبردستی مارنے کی قیمت خراب فائلیں اور اگلی بار اسٹارٹ پر طویل ریکوری ہے۔

جب قصور کوڈ کا نہ ہو

اگر لوڈ جائز اور مستقل ہے تو Ryzen 9 7950X CPU اپنا کام کر رہا ہے — کام کے لیے بس کورز کافی نہیں ہیں۔ ٹیئر صرف اوپر کی طرف بدلا جا سکتا ہے، ادائیگی شدہ مدت کے باقی دنوں کی اضافی ادائیگی کے ساتھ: مضمون دیکھیں اپنا پلان اپ گریڈ کرنا اور فرق ادا کرنا۔ واپس نیچے کرنا دستیاب نہیں، اس لیے پہلے ہفتے اور مہینے کے گرافس سے یقین کر لیں کہ پلیٹاؤ ایک بار کا واقعہ نہیں۔