Linux سرور پر "htop" کمانڈ کے ذریعے CPU اور RAM استعمال کرنے والے اسکرپٹس کی شناخت

Linux سرور پر htop کمانڈ اسکرپٹس کو حقیقی وقت میں تلاش کرنے کے لیے استعمال ہونے والے سب سے عملی نگرانی کے ٹولز میں سے ایک ہے جو CPU اور RAM کا زیادہ استعمال کرتے ہیں۔ htop اسکرین پر CPU%, MEM%, PID, USER, TIME+ اور COMMAND کالموں کا جائزہ لے کر آپ یہ دیکھ سکتے ہیں کہ کون سا PHP, Python, Node.js, cron, ڈیٹا بیس یا سسٹم پروسیس سرور کو متاثر کر رہا ہے؛ پھر آپ اس پروسیس کے مالک، فائل کے راستے اور کام کے مقصد کی جانچ کر کے محفوظ طریقے سے مداخلت کر سکتے ہیں۔

شیئرڈ ہوسٹنگ، VPS، VDS یا ڈیڈیکیٹڈ سرور کی کوئی پرواہ کیے بغیر، اچانک سست ہونے کے بہت سے حصے بے قابو چلنے والے اسکرپٹس کی وجہ سے ہوتے ہیں۔ مثلاً ایک غلط WordPress پلگ ان، لامتناہی لوپ میں پھنس جانے والا PHP فائل، کثیر کام کرنے والا cron ٹاسک، غیر منظم ڈیٹا بیس کی تلاش یا ہیک کیا گیا ویب فائل چند منٹوں میں CPU کے استعمال کو 100 فیصد کے قریب لے جا سکتا ہے۔ جب RAM کا استعمال بڑھتا ہے تو خدمات رُک سکتی ہیں، MySQL کنکشن ٹوٹ سکتے ہیں، ویب سائٹس 503 کی غلطی دے سکتی ہیں یا Linux کے کرنل OOM Killer کے ساتھ کچھ پروسیس ختم کر سکتا ہے۔

اس رہنما میں ہم htop کی تنصیب سے شروع کر کے اسکرین کو کیسے پڑھا جائے گا، CPU اور RAM کا زیادہ استعمال کرنے والے اسکرپٹس کی شناخت کیسے کی جائے گی، PID کے ذریعے فائل کے راستے کو کیسے تلاش کیا جائے گا اور پروسیس میں محفوظ طریقے سے کیسے مداخلت کی جائے گی، ان تمام پہلوؤں کو قدم بہ قدم احاطہ کریں گے۔ مزید برآں، ہم سیکیورٹی کے شبہات، cron کی جانچ، لاگ تجزیے اور دوبارہ ہونے سے بچنے کے لیے قابل عمل آپٹمائزیشن کی تجاویز پر بھی بات کریں گے۔ اگر آپ کے سرور پر اکثر وسائل کی حد میں مسئلہ پیش آتا ہے تو آپ بنیادی ڈھانچے کے انتخاب پر نظر ثانی کرنے کے لیے VPS سرور پیکج اور اعلی کارکردگی والی ویب ہوسٹنگ صفحات کا جائزہ لے سکتے ہیں۔

htop کیا ہے اور یہ top کمانڈ سے زیادہ مفید کیوں ہے؟

htop ایک ٹرمینل ٹول ہے جو Linux سسٹمز میں چلنے والے پروسیسز کا تعاملاتی طور پر معائنہ کرنے کے لیے استعمال ہوتا ہے۔ یہ روایتی top کمانڈ کی طرح ہے لیکن اس میں زیادہ پڑھنے کے قابل انٹرفیس، رنگین وسائل کے اشارے، آسان ترتیب، تلاش، فلٹرنگ اور پروسیس کے انتظام کی خصوصیات موجود ہیں۔ اس وجہ سے، خاص طور پر زندہ سرور پر تیزی سے تشخیص کے دوران، htop اکثر سسٹم کے منتظمین کی پہلی نظر میں موجود ٹولز میں سے ایک ہوتا ہے۔

htop کے ساتھ آپ فوری طور پر درج ذیل معلومات دیکھ سکتے ہیں:

• ہر پروسیس کے ذریعہ استعمال کیا جانے والا CPU فیصد
• ہر پروسیس کے ذریعہ استعمال کیا جانے والا RAM فیصد اور میموری کی مقدار
• پروسیس کا PID نمبر
• پروسیس کو چلانے والا صارف
• کمانڈ لائن یا اسکرپٹ کا نام
• چلنے کا وقت اور ترجیحی قیمت
• لوڈ اوسط، کل RAM، سوئپ اور CPU کور کا استعمال

خاص طور پر ایک ہوسٹنگ ماحول میں جہاں ایک ہی سرور پر کئی سائٹس، صارفین یا خدمات چل رہی ہیں، صرف کل وسائل کے استعمال کو دیکھنا کافی نہیں ہے۔ یہ جاننا ضروری ہے کہ مسئلہ کس صارف، کس ویب سائٹ، کس cron ٹاسک یا کس اسکرپٹ فائل سے متعلق ہے۔ Linux سرور پر htop کمانڈ اس مقام پر تیز ابتدائی تشخیص فراہم کرتا ہے۔

htop کی تنصیب: تقسیم کے مطابق کمانڈز

بہت سی جدید Linux تقسیم میں htop پہلے سے موجود نہیں ہو سکتا۔ اگر آپ کے پاس روٹ یا sudo حقوق ہیں تو آپ اسے چند سیکنڈز میں انسٹال کر سکتے ہیں۔ تنصیب سے پہلے پیکج کی فہرست کو اپ ڈیٹ کرنا، خاص طور پر نئے سرورز پر، غلطی کے امکانات کو کم کرتا ہے۔

Ubuntu اور Debian سرورز پر htop کی تنصیب

Ubuntu یا Debian پر مبنی سرور پر درج ذیل کمانڈز استعمال کی جا سکتی ہیں:

sudo apt update

sudo apt install htop -y

تنصیب کے بعد آپ htop کمانڈ لکھ کر ٹول کو شروع کر سکتے ہیں۔ اگر آپ کے پاس sudo کی حیثیت نہیں ہے تو آپ کو اپنی ہوسٹنگ فراہم کنندہ سے مدد طلب کرنی پڑ سکتی ہے۔ اگر آپ ایک قابل انتظام VPS استعمال کر رہے ہیں تو عموماً روٹ رسائی آپ کی ہوتی ہے۔

AlmaLinux، Rocky Linux، CentOS اور RHEL کی تنصیب

RHEL پر مبنی سسٹمز پر پیکج منیجر ورژن کے لحاظ سے dnf یا yum ہو سکتا ہے:

sudo dnf install htop -y

پرانے CentOS ورژنز میں EPEL ریپوزٹری کی ضرورت ہو سکتی ہے:

sudo yum install epel-release -y

sudo yum install htop -y

اگر تنصیب کامیاب ہے تو، جب آپ ٹرمینل میں htop لکھیں گے تو رنگین نگرانی کی اسکرین کھل جائے گی۔ اگر آپ سرور انتظامیہ میں نئے ہیں تو بنیادی Linux کمانڈز کے لیے لینکس کمانڈز کی رہنمائی مواد بھی عملی طور پر شروع کرنے میں مددگار ثابت ہو سکتا ہے۔

htop اسکرین کو پڑھنا: کون سا کالم کیا معنی رکھتا ہے؟

htop کھلنے پر اسکرین کے اوپر CPU کور، RAM، سوئپ، ٹاسک کی تعداد، تھریڈ کی تعداد، لوڈ اوسط اور اپ ٹائم کی معلومات موجود ہوتی ہیں۔ نیچے والے حصے میں چلنے والے پروسیس کی فہرست دی گئی ہے۔ مسئلے کی تشخیص میں سب سے زیادہ استعمال ہونے والے شعبے ذیل میں ہیں۔

یہاں ایک اہم نقطہ یہ ہے کہ CPU کی عارضی چھلانگ ہمیشہ مسئلہ نہیں ہوتی۔ مثلاً بیک اپ، بصری اصلاح، کیش صاف کرنے یا بھاری ٹریفک کے دوران CPU عارضی طور پر بڑھ سکتا ہے۔ مسئلہ یہ ہے کہ اگر ایک ہی پروسیس کئی منٹوں تک زیادہ CPU یا RAM استعمال کر رہا ہے، لوڈ اوسط کی قیمتیں کور کی تعداد سے بہت اوپر جا رہی ہیں اور ویب سروسز جواب دینا بند کر رہی ہیں۔

CPU زیادہ استعمال کرنے والے اسکرپٹس کو htop کے ذریعے تلاش کرنا

CPU کا زیادہ استعمال کرنے والے اسکرپٹس کو تلاش کرنے کے لیے htop اسکرین پر F6 کی کو دباکر ترتیب کے میدان کا انتخاب کر سکتے ہیں یا CPU% کالم کے لحاظ سے ترتیب دے سکتے ہیں۔ کچھ ٹرمینلز میں اگر ماؤس کی حمایت موجود ہے تو CPU% کے عنوان پر کلک کرنا بھی کافی ہے۔ اوپر والے پروسیس وہ ہوتے ہیں جو اس وقت سب سے زیادہ CPU استعمال کر رہے ہوتے ہیں۔

مرحلہ 1: CPU% کالم کے لحاظ سے ترتیب دیں

htop چلتے وقت پروسیس کو CPU کے استعمال کے لحاظ سے ترتیب دیں۔ مثلاً، اگر php-fpm، php، python3، node، java، mysqld یا bash جیسے پروسیس میں سے کوئی بھی مسلسل اوپر رہتا ہے تو اس پروسیس کو نوٹ کریں۔ سنگل کور کے استعمال میں 100 فیصد کا ہونا معمولی حد لگتا ہے، جبکہ ملٹی کور سسٹمز میں ایک پروسیس 200 یا 400 فیصد جیسی قیمتیں دکھا سکتا ہے۔ یہ اس بات کی نشاندہی کرتا ہے کہ پروسیس ایک سے زیادہ کورز کا استعمال کر رہا ہے۔

مرحلہ 2: PID اور USER کی معلومات نوٹ کریں

مشکوک پروسیس کا PID نمبر اور USER کی معلومات محفوظ کریں۔ مثلاً، اگر PID 24819، USER کے طور پر siteuser اور COMMAND کے علاقے میں php /home/siteuser/public_html/wp-cron.php نظر آتا ہے تو یہ ممکنہ طور پر مسئلہ اس ویب سائٹ کے cron یا WordPress میکانزم سے متعلق ہے۔ اگر COMMAND کا علاقہ بہت مختصر ہے تو آپ htop کی ترتیب میں کمانڈ لائن کو مکمل طور پر دکھانے کو فعال کر سکتے ہیں یا ps کمانڈ کے ذریعے تفصیلات حاصل کر سکتے ہیں۔

مرحلہ 3: پروسیس کی حقیقی کمانڈ دیکھیں

PID کے ذریعے تفصیلی کمانڈ لائن دیکھنے کے لیے درج ذیل کمانڈ استعمال کی جا سکتی ہے:

ps -fp PID

مثال کے طور پر:

ps -fp 24819

یہ آؤٹ پٹ عام طور پر اسکرپٹ کے کس فائل سے چلنے کو ظاہر کرتا ہے۔ اگر کمانڈ php /home/kullanici/public_html/index.php جیسی نظر آتی ہے تو یہ ٹریفک کے نتیجے میں ہونے والی ویب درخواست ہو سکتی ہے۔ اگر php /home/kullanici/public_html/wp-content/plugins/bilinmeyen-eklenti/task.php نظر آتا ہے تو یہ پلگ ان کی بنیاد پر ایک مسئلہ ہو سکتا ہے۔

مرحلہ 4: فائل کے راستے اور کھلی فائلوں کی جانچ کریں

یہ دیکھنے کے لیے کہ کوئی پروسیس کون سی فائلیں استعمال کر رہا ہے، lsof ٹول بہت مفید ہے:

lsof -p PID

یہ کمانڈ پروسیس کی کھلی فائلوں، لائبریریوں، لاگوں اور نیٹ ورک کنکشنز کو دکھاتی ہے۔ ویب ہوسٹنگ ماحول میں، اس آؤٹ پٹ کے ذریعے یہ سمجھنا ممکن ہے کہ کون سی سائٹ ڈائرکٹری فعال ہے۔ مثلاً، اگر آپ /home/example/public_html/wp-content/uploads میں ایک عجیب نام کی PHP فائل دیکھتے ہیں تو یہ ایک سیکیورٹی خلاف ورزی کی علامت ہو سکتی ہے۔ اس صورت میں صرف پروسیس کو ختم کرنا کافی نہیں ہے؛ فائل کی صفائی، پاس ورڈ کی تبدیلی، پلگ ان کی تازہ کاری اور سیکیورٹی سکیننگ کی جانی چاہیے۔ SSL اور محفوظ کنکشن کی ترتیب کے لیے SSL سرٹیفکیٹ کے حل صفحہ بھی دوبارہ دیکھا جا سکتا ہے۔

RAM زیادہ استعمال کرنے والے اسکرپٹس کو htop کے ذریعے تلاش کرنا

RAM کے مسائل CPU کے مسائل کی نسبت زیادہ چالاکی سے ترقی کر سکتے ہیں۔ جب CPU بڑھتا ہے تو عام طور پر عارضی سست روی محسوس کی جاتی ہے؛ جب RAM ختم ہو جاتی ہے تو خدمات غیر متوقع طور پر بند ہو سکتی ہیں، سوئپ کا زیادہ استعمال ہوتا ہے اور سرور میں عمومی تاخیر بڑھ جاتی ہے۔ htop اسکرین پر MEM% کالم کے لحاظ سے ترتیب دے کر آپ سب سے زیادہ میموری استعمال کرنے والے پروسیس کی فہرست بنا سکتے ہیں۔

MEM%، RES اور سوئپ کے تعلقات کو سمجھنا

htop کی ڈیفالٹ ویو میں MEM% کی شرح دکھائی جاتی ہے۔ کچھ کنفیگریشنز میں VIRT، RES اور SHR کالم بھی نظر آتے ہیں۔ RAM کا تجزیہ کرتے وقت RES کی قدر خاص طور پر اہم ہوتی ہے؛ کیونکہ یہ پروسیس کی جسمانی میموری میں واقعی استعمال ہونے والی جگہ کو ظاہر کرتا ہے۔ VIRT کی قدر ہمیشہ حقیقی RAM کے استعمال کا مطلب نہیں رکھتی، اس لیے یہ تنہا گمراہ کن ہو سکتی ہے۔

مثلاً، 4 GB RAM والے VPS پر ایک ہی PHP پروسیس کا 900 MB RES استعمال کرنا معمولی بات نہیں ہے۔ اسی طرح، اگر Node.js ایپلیکیشن کے وقت کے ساتھ 200 MB سے 1.5 GB تک بڑھتا ہے تو یہ میموری کی لیک ہونے کا امکان ظاہر کرتا ہے۔ MySQL یا MariaDB کی جانب سے زیادہ RAM کا استعمال کبھی کبھار معمول کی کیش کے رویے کی وجہ سے ہو سکتا ہے؛ یہاں تلاش کی کارکردگی، بفر کی ترتیب اور کل سسٹم کی میموری کو ایک ساتھ جانچنا ضروری ہے۔

RAM استعمال کرنے والے اسکرپٹس میں عام وجوہات

• لامتناہی لوپ میں پھنس جانے والے PHP، Python یا Node.js کوڈ
• بڑے CSV، XML یا JSON فائلوں کا میموری میں ایک ہی بار میں لینا
• غیر منظم WordPress پلگ ان اور تھیم کی فنکشنز
• بصری پروسیسنگ، PDF پیدا کرنے یا ویڈیو کو تبدیل کرنے کے عمل
• ناکافی کیش کے استعمال کی وجہ سے بار بار بھاری تلاشیں
• بوٹ کی ٹریفک یا حملے کی وجہ سے ایک ہی اسکرپٹ کا بہت زیادہ چلنا
• میموری کی لیک ہونے والے طویل مدت تک چلنے والے پس منظر کی خدمات

ایسی صورتوں میں صرف kill کمانڈ کے ذریعے پروسیس کو بند کرنا عارضی راحت فراہم کرتا ہے۔ مستقل حل کے لیے اسکرپٹ کی سرگرمی، کن ان پٹس کے ساتھ متحرک ہوتا ہے اور کیوں میموری کو خالی نہیں کرتا، کا تجزیہ کیا جانا چاہیے۔

htop میں تلاش، فلٹرنگ اور درخت کی شکل

اگر سرور پر سینکڑوں پروسیس چل رہے ہیں تو فہرست میں دستی تلاش کرنا مشکل ہو جاتا ہے۔ htop اس معاملے میں مفید شارٹ کٹس فراہم کرتا ہے۔ F3 کے ساتھ تلاش کر سکتے ہیں، F4 کے ساتھ فلٹر لگا سکتے ہیں، F5 کے ساتھ درخت کی شکل میں جا سکتے ہیں۔ درخت کی شکل خاص طور پر والد-بچے کے تعلقات کو دیکھنے کے لیے اہم ہے۔ مثلاً، nginx یا Apache کے تحت چلنے والے php-fpm بچے کے پروسیس، cron کے تحت متحرک ہونے والے اسکرپٹس یا سپروائزر کے ذریعے منظم Node.js کی خدمات کو زیادہ واضح طور پر دیکھا جا سکتا ہے۔

عملی فلٹر کی مثالیں

• php لکھ کر صرف PHP پروسیس کو دیکھیں۔
• python لکھ کر Python اسکرپٹس کو الگ کریں۔
• wp-cron لکھ کر WordPress cron کے رویے کو کنٹرول کریں۔
• node لکھ کر Node.js ایپلیکیشنز کا معائنہ کریں۔
• صارف کا نام فلٹر کر کے ایک ہی ہوسٹنگ اکاؤنٹ کے پروسیس کو دیکھیں۔

یہ فلٹر خاص طور پر کثیر صارفین والے سرورز میں وقت کی بچت کرتے ہیں۔ مثلاً، اگر ایک ہی سرور پر 30 مختلف سائٹس ہوسٹ کی جا رہی ہیں تو USER کالم اور کمانڈ کے راستے کو ایک ساتھ جانچنے سے یہ جلدی سے سمجھا جا سکتا ہے کہ مسئلہ کس اکاؤنٹ سے متعلق ہے۔ اگر آپ کے ڈومین پروجیکٹس کے لیے انتظامی حصے کو سادہ کرنا ہے تو ڈومین تلاش اور رجسٹریشن صفحہ دیکھیں۔

مشکوک PID کے لیے محفوظ مداخلت کا منصوبہ

جب آپ کسی وسائل کو زیادہ استعمال کرنے والے پروسیس کو تلاش کرتے ہیں تو فوری طور پر kill -9 کا استعمال کرنا کشش کی بات ہو سکتی ہے۔ تاہم، یہ طریقہ کار ڈیٹا کے نقصان، نامکمل تحریری عمل یا سروس کی عدم استحکام کا موجب بن سکتا ہے۔ اس کے لیے ایک زیادہ محفوظ منصوبہ اپنانا ضروری ہے۔

1. پروسیس کی دستاویز بنائیں

پہلے PID، USER، COMMAND، CPU%、 MEM% اور وقت نوٹ کریں۔ اگر ممکن ہو تو htop اسکرین کی اسکرین شاٹ لیں۔ یہ ریکارڈز بار بار ہونے والے مسائل میں موازنہ کرنے میں آسانی پیدا کرتے ہیں۔ خاص طور پر ایجنسی، ای کامرس یا کاروباری منصوبوں میں کلائنٹ کو تکنیکی وضاحت فراہم کرتے وقت یہ معلومات کارآمد ہوتی ہیں۔

2. پروسیس کے فائل کے راستے کی تصدیق کریں

ps -fp PID اور lsof -p PID کے نتائج کے ذریعے فائل کے راستے کی تصدیق کریں۔ اگر فائل ویب روٹ ڈائرکٹری میں ہے تو متعلقہ ایپلیکیشن کے لاگ کا معائنہ کریں۔ WordPress کے لیے wp-content/debug.log، ویب سرور کے لیے access log اور error log، PHP-FPM کے لیے slow log اہم اشارے فراہم کرتے ہیں۔

3. پہلے نرم بندش کی کوشش کریں

اگر پروسیس واقعی بے قابو ہے تو پہلے معیاری بندش کا اشارہ بھیجیں:

kill PID

چند سیکنڈ انتظار کریں اور htop اسکرین پر دیکھیں کہ آیا پروسیس بند ہو رہا ہے یا نہیں۔ اگر بند نہیں ہو رہا اور نظام کی صحت کو شدید نقصان پہنچا رہا ہے تو آخری چارہ کے طور پر یہ کمانڈ استعمال کی جا سکتی ہے:

kill -9 PID

kill -9 اشارہ پروسیس کو صفائی کا موقع دیے بغیر بند کر دیتا ہے۔ اس لیے، ڈیٹا بیس کے آپریشنز، فائل لکھنے کے عمل یا بیک اپ کے کاموں کے لیے احتیاط سے استعمال کیا جانا چاہیے۔

4. دوبارہ شروع ہونے کی صورت میں محرک تلاش کریں

اگر آپ نے کسی پروسیس کو بند کر دیا ہے لیکن وہ چند سیکنڈ کے اندر دوبارہ شروع ہو رہا ہے تو اس کے پیچھے cron، systemd سروس، سپروائزر، ویب درخواست یا بوٹ کی ٹریفک ہو سکتی ہے۔ cron کی ریکارڈ کے لیے crontab -l، سسٹم سروسز کے لیے systemctl status سروس کا نام، ویب ٹریفک کے لیے access log کا معائنہ کیا جانا چاہیے۔ اگر مسئلہ WordPress کے wp-cron کی وجہ سے ہے تو اصلی cron کی تشکیل اور کیش کی پالیسی کو دوبارہ دیکھنا ضروری ہے۔

htop کے نتائج کو لاگ کے ساتھ ملانا

htop آپ کو یہ دکھاتا ہے کہ کون سی چیز وسائل کا استعمال کر رہی ہے؛ لاگ آپ کو یہ سمجھنے میں مدد دیتے ہیں کہ کیوں یہ استعمال کر رہی ہے۔ جب یہ دونوں اعداد و شمار مل کر استعمال نہیں ہوتے تو تشخیص نامکمل رہتی ہے۔ مثلاً، htop پر php-fpm پروسیس 180 فیصد CPU استعمال کر رہا ہو سکتا ہے؛ لیکن یہ معلوم نہیں کر سکتے کہ کون سی URL یا کون سا بوٹ اس پروسیس کو متحرک کر رہا ہے اگر access log نہ ہو۔

چیک کرنے کے قابل لاگ کی مثالیں یہ ہیں:

• ویب سرور access log: زیادہ درخواستیں وصول کرنے والے URL کو ظاہر کرتا ہے۔
• ویب سرور error log: PHP کی غلطیاں، فائل کی اجازتیں اور 500 کی غلطیاں دکھاتا ہے۔
• PHP-FPM slow log: سست چلنے والی PHP فائلوں اور فنکشنز کو دکھاتا ہے۔
• MySQL slow query log: بھاری SQL تلاشوں کا پتہ لگاتا ہے۔
• Auth log یا secure log: مشکوک لاگ ان کوششوں کو دکھاتا ہے۔
• cron log: طے شدہ ٹاسک کب چلتے ہیں یہ ظاہر کرتا ہے۔

مثلاً، اگر htop میں زیادہ CPU استعمال کرنے والے PID کے ساتھ ایک ہی منٹ میں access log میں /wp-admin/admin-ajax.php ایڈریس پر ہزاروں درخواستیں آتی ہیں تو مسئلہ ایک پلگ ان، بوٹ کی ٹریفک یا غلط ڈیزائن کردہ AJAX پروسیس ہو سکتا ہے۔ اس صورت میں WAF، ریٹ کی حد، کیش اور پلگ ان کی اصلاح کو ایک ساتھ سوچنا چاہیے۔ ویب سائٹ کی کارکردگی کو زیادہ وسیع پیمانے پر دیکھنے کے لیے ویب سائٹ کی رفتار کی اصلاح مواد مفید ثابت ہو سکتا ہے۔

معمولی لوڈ اور مسائل والے لوڈ کے درمیان فرق کیسے کریں؟

ہر زیادہ وسائل کا استعمال بحران کا مطلب نہیں ہوتا۔ سرور کا ہارڈ ویئر، ٹریفک کی سطح، ایپلیکیشن کی نوعیت اور دیکھ بھال کے عمل کو مدنظر رکھنا چاہیے۔ 2 کور والے VPS کے لیے لوڈ اوسط کی قیمت کا طویل عرصے تک 6-8 کی سطح پر رہنا ایک سنگین گلوٹ ہے۔ جبکہ 16 کور والے ڈیڈیکیٹڈ سرور پر یہی قیمت معمول کی ہو سکتی ہے۔ اس لیے لوڈ اوسط کی تشریح کرتے وقت کور کی تعداد کا جاننا ضروری ہے۔

یہ موازنہ، غیر ضروری ہنگامے سے حقیقی کارکردگی کے بحران کو الگ کرنے میں مدد کرتا ہے۔ خاص طور پر ای کامرس سائٹس میں، مہم کے ادوار، ادائیگی کے انضمام اور اسٹاک کی تازہ کاری عارضی طور پر وسائل میں اضافہ کر سکتی ہیں۔ تاہم، اگر یہ اضافہ صارف کے تجربے کو بگاڑتا ہے تو ایپلیکیشن کی اصلاح اور سرور کی صلاحیت کا یکجا اندازہ لگانا ضروری ہے۔

سیکیورٹی کے شبہات: وسائل کے استعمال کرنے والا اسکرپٹ خطرناک ہو سکتا ہے؟

CPU یا RAM کا زیادہ استعمال کرنے والا اسکرپٹ ہمیشہ ایک بے گناہ غلطی نہیں ہو سکتی۔ ہیک شدہ ویب سائٹس میں حملہ آور اسپام بھیجنے، کرپٹو مائننگ، پراکسی ٹریفک، DDoS بوٹس، یا بیک ڈور اسکرپٹس کو چلا سکتے ہیں۔ htop اسکرین پر غیر متوقع صارف کے تحت چلنے والے عجیب کمانڈز، بے ترتیب نام والی فائلیں، /tmp ڈائرکٹری سے چلنے والی بائنری فائلیں یا public_html/uploads میں چلنے والی PHP فائلیں سیکیورٹی کے لحاظ سے سنجیدگی سے لی جانی چاہئیں۔

مشکوک علامات

• COMMAND کے علاقے میں بے معنی یا بے ترتیب کردار والی فائل کے نام
• /tmp، /dev/shm یا uploads فولڈر سے چلنے والی فائلیں
• عام طور پر نہ ہونے والے perl، python یا bash پروسیس
• زیادہ بیرونی نیٹ ورک کنکشن بنانے والے پروسیس
• ایک ہی صارف کے ذریعے جلدی سے بہت سے پروسیس شروع کرنا
• ویب فائلوں میں حالیہ تاریخ کی غیر مجاز تبدیلیاں

ایسی صورت میں، پروسیس کو بند کرنے سے پہلے ممکنہ ثبوت کے طور پر کمانڈ کے نتائج حاصل کریں۔ اس کے بعد فائل کی اجازتوں کی جانچ کریں، نقصان دہ فائلوں کو الگ کریں، تمام پینل اور CMS کے پاس ورڈ کو تبدیل کریں، پلگ ان-تھیم کی بنیادی فائلوں کو اپ ڈیٹ کریں اور سیکیورٹی سکیننگ کریں۔ مزید برآں، ایڈمن پینلز میں دو عنصر کی تصدیق کا استعمال اور غیر ضروری تحریری اجازتوں کو ہٹانا طویل مدتی میں خطرے کو کم کرتا ہے۔

کارکردگی کے مسائل کے دہرائی سے بچنے کے لیے بہترین طریقے

htop کے ذریعے مسئلے کا پتہ لگانا اہم ہے؛ لیکن اصل قیمت یہ ہے کہ اسی مسئلے کے دوبارہ ہونے سے بچا جائے۔ درج ذیل احتیاطی تدابیر Linux سرورز پر CPU اور RAM سے متعلق رکاوٹوں کو نمایاں طور پر کم کرتی ہیں۔

• PHP memory_limit، max_execution_time اور pm.max_children کی قدروں کو سرور کی صلاحیت کے مطابق ترتیب دیں۔
• WordPress، Joomla یا خصوصی سافٹ ویئر میں کیش کے نظام کا استعمال کریں۔
• غیر ضروری پلگ ان، تھیم اور ماڈیولز کو ہٹا دیں۔
• MySQL slow query log کے ساتھ بھاری تلاشوں کو بہتر بنائیں۔
• cron کے کاموں کو ایک ہی منٹ میں مت جمع کریں؛ وقفوں سے چلائیں۔
• بوٹ کی ٹریفک کے لیے ریٹ کی حد، robots.txt اور فائر وال کے قواعد نافذ کریں۔
• ایپلیکیشن لاگ کو باقاعدگی سے گھمائیں؛ بڑے لاگ فائلوں کے ڈسک اور RAM پر اثرات کی نگرانی کریں۔
• سرور کے میٹرکس کو صرف بحران کے وقت نہیں بلکہ باقاعدگی سے مانیٹر کریں۔

اگر آپ کی اصلاح کے باوجود وسائل کا استعمال مسلسل زیادہ ہے تو مسئلہ صرف سافٹ ویئر کی طرف نہیں ہو سکتا۔ ٹریفک بڑھ چکا ہے، ایپلیکیشن بڑھ چکی ہے یا موجودہ ہوسٹنگ پیکج ناکافی ہو سکتا ہے۔ اس صورت میں، ایک اسکیل ایبل VPS، زیادہ RAM، زیادہ تیز NVMe ڈسک یا الگ وسائل والا سرور منطقی ہو جاتا ہے۔ ضرورت کے تجزیے کے لیے ہوسٹنگ پیکجز اور کاروباری سرور کے حل لنکس کے ذریعے آپشنز کا موازنہ کیا جا سکتا ہے۔

مثالی منظرنامہ: WordPress سائٹ میں CPU دھماکہ

ایک حقیقی منظرنامے کے ذریعے آگے بڑھتے ہیں۔ 4 کور اور 8 GB RAM والے VPS پر کئی WordPress سائٹس چل رہی ہیں۔ صارفین سائٹ کی سست روی اور کبھی کبھار 502 کی غلطی کی اطلاع دے رہے ہیں۔ ٹرمینل میں htop کھلتے وقت لوڈ اوسط 12 کی سطح پر ہے، CPU کورز مکمل طور پر بھرے ہوئے ہیں اور اوپر والے حصے میں ایک ہی صارف کے تحت بہت سے php-fpm پروسیس نظر آ رہے ہیں۔

F4 کے ذریعے صارف کے نام کو فلٹر کیا جا رہا ہے۔ CPU استعمال کرنے والے پروسیس میں سے ایک کا PID نوٹ کیا جا رہا ہے۔ ps -fp PID کے نتائج میں php-fpm ورک نظر آتا ہے؛ lsof -p PID کے ذریعے /home/site/public_html/wp-content/plugins/example-importer/import.php فائل تک رسائی ہونے کا پتہ چلتا ہے۔ Access log کی جانچ کرنے پر یہ دیکھا جاتا ہے کہ اسی منٹ میں اس فائل کو متحرک کرنے والی ایڈمن کی درخواست اور اس کے بعد بار بار AJAX کالز ہیں۔

حل کے طور پر، درآمد کے عمل کو روک دیا جاتا ہے، پلگ ان کا طے شدہ کام بند کر دیا جاتا ہے، بڑے ڈیٹا کی درآمد کے عمل کو چھوٹے حصوں میں تقسیم کیا جاتا ہے اور PHP max_execution_time کی حد دوبارہ ترتیب دی جاتی ہے۔ مزید برآں، wp-cron کے بجائے سسٹم cron کا استعمال کیا جا رہا ہے۔ نتیجتاً، لوڈ اوسط 12 سے 1.8 کی سطح پر گر جاتی ہے، CPU کا استعمال معمول پر آتا ہے اور ویب کے جواب کی رفتار نمایاں طور پر بہتر ہوتی ہے۔ یہ مثال یہ ظاہر کرتی ہے کہ htop اکیلا نہیں بلکہ ps، lsof اور لاگ تجزیہ کے ساتھ مل کر کتنا مؤثر ہے۔

htop استعمال کرتے وقت ہونے والی عام غلطیاں

• صرف اوپر والے پروسیس کو بند کرنا اور اصل وجہ کی تحقیقات نہ کرنا۔
• VIRT کی قدر کو حقیقی RAM کے استعمال کے طور پر سمجھنا۔
• MySQL کی کیش کے لیے RAM کے استعمال کو براہ راست مسئلہ سمجھنا۔
• kill -9 کمانڈ کو پہلے آپشن کے طور پر استعمال کرنا۔
• لاگ کو چیک کیے بغیر ایپلیکیشن یا صارف کو الزام دینا۔
• لوڈ اوسط کی قیمت کو CPU کور کی تعداد سے آزادانہ طور پر تشریح کرنا۔
• سیکیورٹی کی خلاف ورزی کے امکان میں فائل کی سالمیت کا معائنہ نہ کرنا۔

ان غلطیوں سے بچنا نہ صرف رکاوٹ کے وقت کو کم کرتا ہے بلکہ غلط مداخلت کی وجہ سے ڈیٹا کے نقصان کے خطرے کو بھی کم کرتا ہے۔ سسٹم کی انتظامیہ میں صحیح تشخیص، اکثر فوری مداخلت سے زیادہ قیمتی ہوتی ہے۔

اکثر پوچھے جانے والے سوالات

Linux سرور پر htop کمانڈ کیا کرتی ہے؟

Linux سرور پر htop کمانڈ چلنے والے پروسیسز کے CPU، RAM، صارف، PID اور کمانڈ کی معلومات کو حقیقی وقت میں دکھاتی ہے۔ اس سے آپ کو CPU یا RAM کا زیادہ استعمال کرنے والے اسکرپٹس کو جلدی سے شناخت کرنے کی اجازت ملتی ہے۔

htop کے ذریعے CPU کا زیادہ استعمال کرنے والے اسکرپٹ کو کیسے تلاش کروں؟

htop اسکرین پر پروسیس کو CPU% کالم کے لحاظ سے ترتیب دیں، طویل عرصے تک اوپر رہنے والے پروسیس کا PID اور USER معلومات نوٹ کریں۔ پھر ps -fp PID اور lsof -p PID کمانڈز کے ذریعے اسکرپٹ کی فائل کے راستے اور جو کچھ چل رہا ہے اس کی تصدیق کریں۔

RAM کے استعمال میں MEM% یا VIRT کو مدنظر رکھنا چاہیے؟

RAM کے تجزیے میں MEM% اور خاص طور پر RES کی قدر زیادہ معنی خیز ہوتی ہے۔ VIRT مختص کردہ ورچوئل میموری کی مقدار دکھاتا ہے اور ہمیشہ جسمانی RAM کے استعمال کا مطلب نہیں ہوتا۔

وسائل کا زیادہ استعمال کرنے والے پروسیس کو فوراً kill -9 سے بند کرنا درست ہے؟

عام طور پر نہیں۔ پہلے پروسیس کی دستاویز بنانا، فائل کے راستے کی جانچ کرنا اور kill PID کمانڈ کو آزمانا زیادہ محفوظ ہے۔ kill -9 صرف اس صورت میں استعمال کیا جانا چاہیے جب پروسیس بند نہ ہو رہا ہو اور سرور کی صحت کو سنجیدہ طور پر متاثر کر رہا ہو۔

htop پر زیادہ CPU کا استعمال ہمیشہ حملے کی علامت ہے؟

نہیں۔ بیک اپ، درآمد، کیش بنانا یا بھاری ٹریفک بھی CPU کے استعمال میں اضافہ کر سکتا ہے۔ لیکن بے ترتیب فائل کے نام، /tmp یا uploads میں چلنے والے اسکرپٹس اور غیر متوقع صارف پروسیس سیکیورٹی کے شبہات پیدا کرتے ہیں۔

خلاصہ یہ ہے کہ Linux سرور پر htop کمانڈ CPU اور RAM کا زیادہ استعمال کرنے والے اسکرپٹس کو تلاش کرنے کے لیے ایک تیز، عملی اور مؤثر نقطہ آغاز ہے۔ سب سے صحیح نتائج کے لیے، htop کے اعداد و شمار کو PID تجزیے، lsof کے نتائج، cron کی جانچ اور لاگ کے معائنے کے ساتھ یکجا کرنے کی ضرورت ہے۔ اگر آپ کے سرور پر وسائل کے مسائل بار بار پیش آ رہے ہیں تو سافٹ ویئر کی اصلاح اور بنیادی ڈھانچے کی صلاحیت کا ایک ساتھ اندازہ لگائیں؛ ضرورت کی صورت میں Hostragons کی ہوسٹنگ، VPS اور SSL کے حل کو بغیر کسی فروخت کے دباؤ کے آپ کے منصوبے کے لیے بہترین ڈھانچہ منتخب کرنے کے لیے موازنہ کریں۔