HestiaCP-তে ইনোড ব্যবহার কীভাবে পরীক্ষা করব? ডিস্কে পর্যাপ্ত জায়গা থাকা সত্ত্বেও ফাইল লিখতে না পারার কারণ কী?

কয়েকদিন আগে এক বন্ধু গভীর রাতে আমাকে মেসেজ করে জানায় যে তার সার্ভার ক্র্যাশ করেছে।

নির্দিষ্ট লক্ষণগুলো ছিল বেশ অদ্ভুত: ওয়েবসাইটটি হঠাৎ করে ত্রুটি দেখাতে শুরু করে, লগ লেখা যাচ্ছিল না, এবং নতুন ফাইল তৈরি করতে গেলেই সঙ্গে সঙ্গে ডিস্ক পূর্ণ হয়ে যাওয়ার বার্তা আসছিল।

কিন্তু `df -h` দিয়ে পরীক্ষা করে সে হতবাক হয়ে গেল, কারণ ডিস্কটিতে স্পষ্টতই কয়েক দশ গিগাবাইট খালি জায়গা ছিল। এটা কীভাবে পূর্ণ হতে পারে?

আমি ঠিক তখনই তাকে বললাম, "ভাই, আপনার স্টোরেজ স্পেস শুধু পূর্ণই নয়, আপনার ইনোডটি ওভারলোড হয়ে গেছে।"

সে প্রশ্নবোধক চিহ্ন দিয়ে জবাব দিল: ইনোড আসলে কী?

প্রকৃতপক্ষে, প্রথমবার এই ফাঁদে পড়ার পর অনেকেই ঠিক তার মতোই প্রতিক্রিয়া দেখায়, কারণ স্কুলে তাদের এই বিষয়গুলো কেউ শেখায়নি।

প্রথমে ইনোড কী, তা স্পষ্ট করা যাক।

এটিকে একটি লাইব্রেরির ইনডেক্স কার্ডের মতো ভাবুন, তাহলে বুঝতে সহজ হবে।

ডিস্ক স্পেস একটি বইয়ের তাকের মতো; এতে কতগুলো বই রাখা যাবে তা নির্ভর করে এর ধারণক্ষমতার ওপর, যা সকলের কাছেই সহজবোধ্য।

একটি আইনোড হলো প্রতিটি বইয়ের জন্য একটি ইনডেক্স কার্ডের মতো, যেখানে বইটির নাম, অবস্থান এবং কে এটি সরিয়েছে তার তথ্য লিপিবদ্ধ থাকে।

লিনাক্সে , প্রতিটি ফাইল এবং ডিরেক্টরিকে অবশ্যই একটি আইনোড দখল করতে হয়, ফাইলটি যতই ছোট হোক না কেন ।

ফাইলটি খালি হলেও সিস্টেম এর জন্য একটি ইনডেক্স কার্ড ব্যবহার করবে।

সিস্টেমটি মোট যতগুলো ফাইল তৈরি করতে পারে তার একটি সীমা আছে; এই সীমাটি হলো মোট ইননোডের সংখ্যা।

আইনোড একবার শেষ হয়ে গেলে, আপনার ডিস্কে তখনও শত শত গিগাবাইট খালি জায়গা থাকলেও অপারেটিং সিস্টেম কোনো নতুন ফাইল তৈরি করতে অস্বীকার করবে।

লগ লেখা যাচ্ছে না, ক্যাশে তৈরি করা যাচ্ছে না এবং ওয়েবসাইটটি পুরোপুরি ক্র্যাশ করছে—এটাই সেই অদ্ভুত দৃশ্য যা আপনি দেখছেন।

সত্যি বলতে, এটি একটি বেশ জটিল পরিস্থিতি, কারণ ত্রুটির বার্তাটি এমন একটি জায়গা থেকে পাঠানো হচ্ছে যেখানে আপনি দেখছেন না।

প্রথম কৌশলটি হলো `df -i` ব্যবহার করে একটি সম্পূর্ণ চিত্র পাওয়া।

HestiaCP পরিবেশে , আপনি খুব সহজেই টার্মিনালে SSH করে এই লাইনটি টাইপ করতে পারেন।

df -i

এটি প্রতিটি মাউন্ট করা পার্টিশনের জন্য মোট ইননোডের সংখ্যা, ব্যবহৃত সংখ্যা এবং অবশিষ্ট সংখ্যা তালিকাভুক্ত করবে।

আউটপুটে IUse% নামে একটি কলাম আছে, যেটি হলো মূল মেট্রিক যার উপর আপনার নজর রাখা উচিত।

যদি কোনো পার্টিশনের IUse% ১০০%-এ পৌঁছে যায়, তাহলে সেই পার্টিশনে পর্যাপ্ত ডিস্ক স্পেস থাকা সত্ত্বেও, এটি আর কোনো নতুন ফাইল বা লগ তৈরি করতে পারবে না।

আমি আমার বন্ধুকে পরামর্শ দিয়েছিলাম যে সে যেন প্রথমে এটি চালায়, যাতে এটি এক সেকেন্ডের মধ্যে সঠিকভাবে বলে দিতে পারে যে সমস্যাটি ইনোডের কিনা , যা অনুমান করার চেয়ে অনেক দ্রুত হবে।

দ্বিতীয় পদ্ধতিটি হলো `find` ব্যবহার করে কোনো নির্দিষ্ট ব্যবহারকারীকে নির্ভুলভাবে গণনা করা।

সমস্যাটি যে ইননোডের, তা নিশ্চিত করার পর পরবর্তী পদক্ষেপ হলো, কে অতিরিক্ত পরিমাণে ইনডেক্স কার্ড ব্যবহার করছে তা খুঁজে বের করা।

HestiaCP-তে প্রতিটি ব্যবহারকারীর জন্য একটি আলাদা হোম ডিরেক্টরি রয়েছে। আপনি খুব সহজেই একটি নির্দিষ্ট ওয়েবসাইট ডিরেক্টরির অধীনে থাকা মোট ফাইল এবং ডিরেক্টরির সংখ্যা গণনা করতে পারেন।

find /home/用户名/web/你的域名/public_html | wc -l

'username' এবং 'your domain name'-এর জায়গায় আপনার আসল পাথটি বসান। টার্মিনাল থেকে প্রাপ্ত সংখ্যাটি হলো সেই ডিরেক্টরিতে থাকা সমস্ত ফাইল ও ফোল্ডারের মোট যোগফল।

প্রতিটি ফাইল বা ডিরেক্টরি একটি আইনোডের সমতুল্য, তাই এই সংখ্যাটি আইনোড ব্যবহারের পরিমাণ নির্দেশ করে।

যদি আপনি আলাদাভাবে প্রতিটি পরীক্ষা করতে খুব অলস হন এবং পুরো সাইট জুড়ে সমস্ত ব্যবহারকারীর ব্যবহারের বণ্টন একবারে দেখতে চান, তাহলে একটি লুপ কমান্ডও রয়েছে।

for d in /home/*; do echo -n "$d: "; find "$d" 2>/dev/null | wc -l; done

এই লাইনটি /home-এর অধীনে থাকা প্রতিটি ইউজার ডিরেক্টরিতে মোট ফাইলের সংখ্যা প্রিন্ট করবে, যার ফলে কোন ইউজার ডিরেক্টরিতে অস্বাভাবিকভাবে বেশি ফাইল রয়েছে তা সহজেই চিহ্নিত করা যাবে।

তৃতীয় কৌশলটি হলো সেই সাবডিরেক্টরিগুলো শনাক্ত করা যেগুলো সবচেয়ে বেশি আয়োডিন ব্যবহার করে।

মাঝে মাঝে আপনি জানেন যে একটি ওয়েবসাইটের ইনোড ভ্যালু অস্বাভাবিকভাবে বেশি, কিন্তু ফাইল ভর্তি স্ক্রিনটির সমস্যাটা ঠিক কোথায়, তা আপনি বুঝে উঠতে পারেন না।

এই ধরনের ক্ষেত্রে, আপনাকে এক স্তর নিচে গিয়ে এমন সাবফোল্ডারগুলো খুঁজে বের করতে হবে যেগুলোতে প্রচুর পরিমাণে ছোট ফাইল থাকে, যেমন ক্যাশ ডিরেক্টরি, সেশন ডিরেক্টরি এবং লগ ডিরেক্টরি—এগুলোই সবচেয়ে সমস্যাজনক এলাকা।

find /home/用户名/web/你的域名/public_html -type d -exec sh -c 'echo -n "{}: "; find "{}" -maxdepth 1 | wc -l' \; | sort -n -r -k 2 | head -n 10

এই কমান্ডটি সর্বাধিক ফাইল ব্যবহারকারী শীর্ষ ১০টি সাবফোল্ডারের তালিকা দেখাবে।

তালিকার একেবারে শীর্ষে থাকা পথটিতে প্রচুর সংখ্যক ছোট ফাইল একসাথে জড়ো হয়ে আছে।

আমি আমার বন্ধুকে বলেছিলাম যে সম্ভবত কোনো ক্যাশিং প্লাগইন গোপনে ছোট ছোট ফাইল তৈরি করছে, এবং এই লাইনটি চালালে বিষয়টি মূলত নিশ্চিত হওয়া যাবে।

চতুর্থ পরামর্শটি হলো repquota ব্যবহার করে কোটার সীমা যাচাই করে নেওয়া।

আপনার সার্ভারে যদি লিনাক্স ফাইল সিস্টেম কোটা সক্রিয় থাকে, তাহলে আপনি সমস্যাটিকে ভিন্ন দৃষ্টিকোণ থেকে দেখতে পারেন।

repquota -a

এই কমান্ডটি সকল ব্যবহারকারীর ফাইল সীমা এবং প্রকৃত ফাইল ব্যবহারের পরিমাণ দেখাবে।

আউটপুটের 'ফাইল লিমিটস' অংশটিতে বিশেষভাবে মনোযোগ দিন; 'ব্যবহৃত' কলামটি নির্দেশ করে কতগুলো ফাইল ব্যবহৃত হয়েছে।

'soft' এবং 'hard' কলাম দুটি সফট ও হার্ড লিমিট থ্রেশহোল্ড নির্দেশ করে। 'used' অংশটি 'hard' লিমিটে পৌঁছালে, সিস্টেম সরাসরি নতুন ফাইল তৈরি করতে অস্বীকৃতি জানাবে।

আপনার ডিস্কে কতটা জায়গা বাকি আছে, তার থেকে এটি সম্পূর্ণ ভিন্ন একটি বিষয়।

সবশেষে, চলুন তদন্তের সূত্রগুলো মিলিয়ে দেখি।

চলুন শুরুতে সেই বন্ধুর কাছে ফিরে যাই, যে মাঝরাতে সার্ভার ক্র্যাশ করিয়েছিল।

আইনোডটি সত্যিই পূর্ণ কিনা তা নিশ্চিত করার জন্য `df -i` দিয়ে শুরু করে, তিনি আমার বর্ণিত চারটি ধাপ অনুসরণ করেছিলেন।

এরপর, ফাইন্ড মেথড ব্যবহার করে দেখা গেল যে, একটি পরিত্যক্ত পুরোনো ওয়েবসাইটের ক্যাশ ডিরেক্টরি প্রচুর পরিমাণে ছোট ছোট ফাইল তৈরি করছিল।

অবশেষে, `repquota` পরীক্ষা করে নিশ্চিত হওয়া গেল যে এটি সত্যিই নির্ধারিত সর্বোচ্চ সীমায় পৌঁছে গেছে।

জাঙ্ক ক্যাশের ওই স্তূপটি পরিষ্কার করার পর ওয়েবসাইটটি সঙ্গে সঙ্গে আবার সচল হয়ে উঠল।

তাই পরের বার যখন আপনি এই অদ্ভুত পরিস্থিতির সম্মুখীন হবেন যেখানে 'ডিস্কে পরিষ্কারভাবে জায়গা আছে কিন্তু ফাইল লেখা যাচ্ছে না,' তখন হার্ড ড্রাইভ যোগ করতে তাড়াহুড়ো করবেন না।

প্রথমে, `df -i` ব্যবহার করে আইনোডটি দেখে নিন; সত্যটি হয়তো সেই ইনডেক্স কার্ডটিতেই লুকিয়ে আছে যা আপনি আগে কখনো খেয়াল করেননি।

আমি আন্তরিকভাবে বিশ্বাস করি যে, একশটা অপটিমাইজেশন তালিকা মুখস্থ করার চেয়ে সিস্টেমের মূলে লুকিয়ে থাকা সাধারণ জ্ঞানের এই ছোট ছোট বিষয়গুলো অনেক বেশি কার্যকর।