چگونه می‌توانم میزان استفاده از inode را در HestiaCP بررسی کنم؟ چه چیزی باعث می‌شود که حتی با وجود فضای دیسک کافی، نتوانم فایل‌ها را بنویسم؟

چند روز پیش، یکی از دوستانم آخر شب به من پیام داد که سرورش از کار افتاده است.

علائم خاص به طور خاص عجیب بودند: وب‌سایت ناگهان شروع به نمایش خطا کرد، امکان نوشتن گزارش‌ها وجود نداشت و ایجاد فایل‌های جدید بلافاصله پیام پر شدن دیسک را نشان می‌داد.

اما وقتی با `df -h` بررسی کرد، با کمال تعجب دید که دیسک به وضوح ده‌ها گیگابایت فضای خالی دارد. چطور ممکن است پر باشد؟

همان جا به او گفتم: «داداش، فقط فضای ذخیره‌سازی‌ات پر نیست، Inode ات هم بیش از حد اشغال شده.»

او با یک علامت سوال پاسخ داد: Inode دقیقاً چیست؟

در واقع، بسیاری از مردم دقیقاً همان واکنشی را نشان می‌دهند که او هنگام اولین بار افتادن در این دام نشان داد، زیرا هیچ‌کس در مدرسه هرگز این چیزها را به آنها یاد نداده است.

بیایید ابتدا روشن کنیم که Inode چیست.

آن را مانند یک کارت فهرست کتابخانه در نظر بگیرید، و درک آن آسان خواهد بود.

فضای دیسک مانند یک قفسه کتاب است؛ اینکه چند کتاب می‌توانید روی آن قرار دهید به ظرفیت آن بستگی دارد که درک آن برای همه آسان است.

یک inode مانند یک کارت فهرست برای هر کتاب است که نام، مکان و اینکه چه کسی آن را جابجا کرده است را ثبت می‌کند.

در لینوکس ، هر فایل و هر دایرکتوری باید یک inode را اشغال کند، مهم نیست که فایل چقدر کوچک باشد.

حتی اگر فایل خالی باشد، سیستم همچنان یک کارت فهرست برای آن مصرف می‌کند.

سیستم برای تعداد کل فایل‌هایی که می‌تواند ایجاد کند محدودیت دارد؛ این محدودیت، تعداد کل گره‌های داخلی (innode) است.

پس از اتمام ظرفیت inode، حتی اگر دیسک شما هنوز صدها گیگابایت فضای خالی داشته باشد، سیستم عامل از ایجاد هرگونه فایل جدید خودداری خواهد کرد.

لاگ‌ها قابل نوشتن نیستند، حافظه پنهان ایجاد نمی‌شود و وب‌سایت کاملاً از کار می‌افتد - این صحنه عجیبی است که شاهد آن هستید.

راستش را بخواهید، این یک وضعیت واقعاً پیچیده است زیرا پیام خطا از مکانی ارسال می‌شود که شما به آن نگاه نمی‌کنید.

اولین ترفند استفاده از `df -i` برای مشاهده سریع است.

در محیط HestiaCP ، می‌توانید به سادگی با SSH وارد ترمینال شوید و این خط را تایپ کنید.

df -i

این دستور تعداد کل innodeها، تعداد استفاده شده و تعداد باقی مانده برای هر پارتیشن mount شده را فهرست می‌کند.

در خروجی، ستونی به نام IUse% وجود دارد که معیار کلیدی است که باید به آن توجه داشته باشید.

اگر درصد استفاده (IUse%) یک پارتیشن به ۱۰۰٪ برسد، حتی اگر آن پارتیشن هنوز فضای دیسک زیادی داشته باشد، دیگر قادر به ایجاد هیچ فایل یا گزارش جدیدی نخواهد بود.

به دوستم پیشنهاد دادم که اول این را اجرا کند تا بتواند در عرض یک ثانیه مشخص کند که آیا مشکل از Inode است یا خیر ، که این کار خیلی سریع‌تر از حدس زدن خواهد بود.

روش دوم استفاده از `find` برای شمارش دقیق یک کاربر خاص است.

پس از تأیید اینکه مشکل از innode است، گام بعدی این است که بفهمیم چه کسی بیش از حد از کارت فهرست استفاده می‌کند.

HestiaCP برای هر کاربر یک دایرکتوری خانگی جداگانه دارد. شما می‌توانید به سادگی تعداد کل فایل‌ها و دایرکتوری‌های موجود در یک دایرکتوری وب‌سایت خاص را بشمارید.

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

به جای "username" و "your domain name" مسیر واقعی خود را وارد کنید. عدد خالصی که توسط ترمینال برگردانده می‌شود، مجموع تمام فایل‌ها و پوشه‌های موجود در آن دایرکتوری است.

هر فایل یا دایرکتوری مربوط به یک inode است، بنابراین این عدد نشان دهنده میزان استفاده از inode است.

اگر برای بررسی تک تک موارد تنبل هستید و می‌خواهید توزیع استفاده همه کاربران در کل سایت را به طور همزمان ببینید، یک دستور حلقه‌ای نیز وجود دارد.

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

این خط تعداد کل فایل‌های موجود در هر دایرکتوری کاربر در مسیر ‎/home‎ را چاپ می‌کند و تشخیص اینکه کدام دایرکتوری کاربر تعداد فایل‌های غیرعادی زیادی دارد را آسان می‌کند.

سومین استراتژی، شناسایی زیرشاخه‌هایی است که بیشترین مصرف ید را دارند.

بعضی وقت‌ها می‌دانید که یک وب‌سایت مقادیر Inode بسیار بالایی دارد، اما هنوز نمی‌توانید بفهمید مشکل صفحه پر از فایل چیست.

در چنین مواردی، باید یک سطح پایین‌تر بروید تا زیرپوشه‌هایی را پیدا کنید که حاوی تعداد زیادی فایل کوچک هستند، مانند دایرکتوری‌های حافظه پنهان، دایرکتوری‌های جلسه و دایرکتوری‌های گزارش - اینها مشکل‌سازترین قسمت‌ها هستند.

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

این دستور 10 زیرپوشه برتر که بیشترین فایل‌ها را مصرف می‌کنند، فهرست می‌کند.

مسیری که در بالای لیست قرار دارد، جایی است که تعداد زیادی فایل کوچک در کنار هم قرار گرفته‌اند.

به دوستم گفتم که احتمالاً یک افزونه‌ی کش مخفیانه فایل‌های کوچک تولید می‌کند و اجرای این خط اساساً این موضوع را تأیید می‌کند.

نکته چهارم، بررسی محدودیت سهمیه با استفاده از repquota است.

اگر سهمیه‌بندی فایل سیستم لینوکس در سرور شما فعال باشد، می‌توانید از زاویه دیگری به مشکل نگاه کنید.

repquota -a

این دستور محدودیت حجم فایل و میزان استفاده واقعی از فایل را برای همه کاربران نمایش می‌دهد.

به بخش محدودیت‌های فایل در خروجی دقت کنید؛ ستون استفاده‌شده نشان می‌دهد که چند فایل استفاده شده است.

ستون‌های «soft» و «hard» نشان‌دهنده‌ی آستانه‌های محدودیت soft و hard هستند. به محض اینکه «used» به «hard» برسد، سیستم مستقیماً از ایجاد فایل‌های جدید خودداری می‌کند.

این یک داستان کاملاً متفاوت از میزان فضای باقی مانده روی دیسک شماست.

برای جمع‌بندی، بیایید نکات تحقیق را به هم وصل کنیم.

برگردیم به دوستی که در همان ابتدا، نیمه شب سرور را از کار انداخت.

او چهار مرحله‌ای را که توضیح دادم دنبال کرد، و با `df -i` شروع کرد تا تأیید کند که inode واقعاً پر است.

سپس، با استفاده از find، دایرکتوری کش یک وب‌سایت قدیمی متروکه را پیدا کردیم که فایل‌های کوچکی را به شدت تولید می‌کرد.

در نهایت، بررسی «repquota» تأیید کرد که واقعاً به حد نصاب رسیده است.

پس از پاک کردن آن انبوه از فایل‌های کش بی‌ارزش، وب‌سایت بلافاصله دوباره فعال شد.

بنابراین دفعه‌ی بعد که با این موقعیت عجیب مواجه شدید که «دیسک به وضوح فضای خالی دارد اما نمی‌توانید فایلی روی آن بنویسید»، برای اضافه کردن یک هارد دیسک عجله نکنید.

ابتدا، از `df -i` برای بررسی inode استفاده کنید؛ حقیقت ممکن است در آن کارت فهرست که قبلاً هرگز متوجه آن نشده‌اید، پنهان باشد.

من واقعاً معتقدم که این تکه‌های کوچک عقل سلیم که در هسته سیستم پنهان شده‌اند، مفیدتر از حفظ کردن صدها لیست بهینه‌سازی هستند.