Linux সার্ভারে "htop" কমান্ড দিয়ে প্রসেসর এবং 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/user/public_html/index.php এর মতো হয় তবে এটি ট্রাফিক ভিত্তিক একটি ওয়েব অনুরোধ হতে পারে। যদি php /home/user/public_html/wp-content/plugins/unknown-plugin/task.php এর মতো হয় তবে এটি প্লাগইন ভিত্তিক একটি সমস্যা হতে পারে।

পদক্ষেপ 4: ফাইলের পথ এবং খোলা ফাইলগুলো পরীক্ষা করুন

একটি প্রসেস কোন ফাইল ব্যবহার করছে তা দেখতে lsof টুলটি খুব মূল্যবান:

lsof -p PID

এই কমান্ডটি প্রসেসটি খোলা রাখা ফাইল, লাইব্রেরি, লগ এবং নেটওয়ার্ক সংযোগগুলো দেখায়। ওয়েব হোস্টিং পরিবেশে, এই আউটপুটের মাধ্যমে কোন সাইটের ডিরেক্টরি সক্রিয় তা বোঝা সম্ভব। উদাহরণস্বরূপ, যদি /home/example/public_html/wp-content/uploads মধ্যে একটি অদ্ভুত নামের PHP ফাইল চলমান থাকে তবে এটি একটি নিরাপত্তা লঙ্ঘনের ইঙ্গিত হতে পারে। এমন পরিস্থিতিতে, শুধুমাত্র প্রসেসটি বন্ধ করা যথেষ্ট নয়; ফাইল পরিষ্কার করা, পাসওয়ার্ড পরিবর্তন করা, প্লাগইন আপডেট করা এবং নিরাপত্তা স্ক্যান করা প্রয়োজন। 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 service, supervisor, ওয়েব অনুরোধ বা বট ট্রাফিক থাকতে পারে। cron লগের জন্য crontab -l, সিস্টেম পরিষেবাগুলির জন্য systemctl status service-name, ওয়েব ট্রাফিকের জন্য 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 কোরের একটি ডেডিকেটেড সার্ভারে একই মান স্বাভাবিক হতে পারে। তাই লোড গড়ের ব্যাখ্যা করার সময় কোর সংখ্যা অবশ্যই জানা উচিত।

এই তুলনা অপ্রয়োজনীয় Panic এবং প্রকৃত পারফরম্যান্স সংকটকে পৃথক করতে সহায়ক। বিশেষ করে ই-কমার্স সাইটগুলিতে প্রচারকালীন, পেমেন্ট ইন্টিগ্রেশন এবং স্টক আপডেটগুলি অস্থায়ী রিসোর্স বৃদ্ধির সৃষ্টি করতে পারে। তবে এই বৃদ্ধি ব্যবহারকারীর অভিজ্ঞতা বিঘ্নিত করলে অ্যাপ্লিকেশন অপ্টিমাইজেশন এবং সার্ভার ক্ষমতা একসাথে মূল্যায়ন করা উচিত।

নিরাপত্তার সন্দেহ: রিসোর্স খরচকারী স্ক্রিপ্ট ক্ষতিকারক হতে পারে?

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 সমাধানগুলো বিক্রয় চাপ ছাড়া তুলনা করে আপনার প্রকল্পের জন্য সবচেয়ে উপযুক্ত কাঠামো বেছে নিন।