وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

رفع ENOSPC در پایش فایل لینوکس؛ وقتی فضا هست اما محدودیت inotify پر شده

تشخیص خطای ENOSPC در inotify و تنظیم حساب‌شده max_user_watches بدون اشتباه گرفتن آن با پر شدن دیسک.

انتشار:
توسط تیم فنی نت‌آرام
۵ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله رفع ENOSPC در پایش فایل لینوکس؛ وقتی فضا هست اما محدودیت inotify پر شده در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
ابزاری که تغییر فایل‌ها را دنبال می‌کند متوقف می‌شود و پیام ENOSPC: System limit for number of file watchers reached نشان می‌دهد. در این حالت ممکن است دیسک هنوز فضای خالی داشته باشد. بسیاری از ابزارهای توسعه و بعضی سرویس‌ها از inotify لینوکس برای دریافت خبر تغییر فایل استفاده می‌کنند؛ تعداد watchهای مجاز برای هر شناسه کاربر واقعی محدود است.
البته ENOSPC در کار با فایل می‌تواند واقعاً به فضای دیسک یا inode نیز مربوط باشد. اول محل خطا را مشخص می‌کنیم، بعد سراغ محدودکردن فایل‌های پایش‌شده یا تغییر حساب‌شده سقف می‌رویم. تغییر سراسری سیستم را روی هاست اشتراکی انجام ندهید.

۱. تفاوت فضای دیسک و watch را تشخیص دهید

گزارش برنامه را در زمان خطا بخوانید. اگر نام inotify_add_watch، watchers یا max_user_watches کنار ENOSPC آمده، محدودیت پایش یک احتمال جدی است. اگر برنامه هنگام نوشتن فایل خطا می‌دهد، وضعیت فایل‌سیستم همان مسیر را هم بررسی کنید:
کد / دستورdf -h . df -i .
دستور اول فضای قابل استفاده و دومی inodeهای فایل‌سیستم پوشه جاری را نشان می‌دهد. پر شدن هر کدام می‌تواند نوشتن را متوقف کند. اگر هر دو ظرفیت دارند و گزارش مشخصاً از watch می‌گوید، مراحل بعد را دنبال کنید. در هاست اشتراکی محدودیت سهمیه حساب نیز مستقل از فضای کل دیسک است.

۲. سقف فعلی و برنامه مسئول را ببینید

در ترمینال سرور لینوکس اجرا کنید:
کد / دستورcat /proc/sys/fs/inotify/max_user_watches cat /proc/sys/fs/inotify/max_user_instances cat /proc/sys/fs/inotify/max_queued_events
اولی سقف تعداد watch و دومی سقف instance برای هر شناسه کاربر واقعی است. سومی اندازه صف رویداد برای هر instance را تعیین می‌کند؛ این سه عدد یک چیز نیستند. خطای ایجاد watch را با پرشدن صف رویداد اشتباه نگیرید. تغییر max_user_watches لزوماً خطای مربوط به تعداد instance یا فضای واقعی دیسک را حل نمی‌کند.
از گزارش، نام و شناسه پردازش مربوط را پیدا کنید. اگر سرویس systemd است:
کد / دستورsystemctl status example.service journalctl -u example.service -n 100 --no-pager
example.service را با نام واقعی عوض کنید. ابزارهای مختلف ممکن است چند پردازش با یک کاربر داشته باشند و watchها را با هم در سهمیه همان کاربر مصرف کنند. تعداد فایل‌های باز و تعداد watch یکی نیست. اگر دسترسی مناسب دارید، برای یک PID مشخص می‌توانید فایل‌های /proc/PID/fdinfo را بررسی کنید؛ اطلاعات این بخش در همه محیط‌ها یا با هر مجوزی در دسترس نیست. از پیمایش بی‌حساب تمام پردازش‌های سرور شلوغ خودداری کنید.

۳. ابتدا پوشه‌های اضافی را از پایش خارج کنید

در تنظیمات ابزار، مسیرهایی مانند پوشه خروجی build، فایل‌های موقت یا وابستگی‌های حجیم را که واقعاً نیازی به پایش ندارند شناسایی کنید. نام گزینه استثنا در هر ابزار متفاوت است؛ مستندات همان نسخه را بخوانید. مثلاً حذف node_modules از watch برای بعضی ابزارهای توسعه مناسب است، اما اگر پروژه عمداً تغییرهای آن را نیاز دارد، این کار رفتار مورد انتظار را عوض می‌کند.
تغییر را در نسخه آزمایشی ذخیره کنید، ابزار را با روش خودش دوباره اجرا کنید و یک فایل واقعاً مورد نیاز را تغییر دهید. اگر رویداد آن دیده شد و خطا تکرار نشد، این راه بدون افزایش سقف سیستم مشکل را حل کرده است. مراقب باشید پوشه خروجی که مدام بازتولید می‌شود باعث ایجاد حلقه بازسازی نشده باشد.

۴. در صورت نیاز سقف را حساب‌شده بالا ببرید

این مرحله فقط برای مدیر سرور مستقل است. مقدار فعلی، مصرف منابع و تغییرات دیگر را ثبت کنید. افزایش سقف اجازه استفاده بیشتر می‌دهد و watchهای فعال از منابع کرنل استفاده می‌کنند؛ عدد بسیار بزرگ و یکسان برای همه سرورها مناسب نیست. روی سرور چندکاربره، مدیر باید اثر آن را برای کاربران همان میزبان ارزیابی کند.
برای نمونه، فقط اگر مقدار قبلی کمتر از 16384 بوده و این عدد برای محیط شما تأیید شده است، تغییر موقت زیر تا راه‌اندازی مجدد اعمال می‌شود:
کد / دستورsudo sysctl -w fs.inotify.max_user_watches=16384 cat /proc/sys/fs/inotify/max_user_watches
خروجی دوم باید مقدار جدید را نشان دهد. این تغییر سراسری است، نه محدود به یک پروژه. برای بازگشت، همان فرمان را با عدد قبلی ثبت‌شده روی سرور خودتان اجرا کنید. اگر مقدار قبلی بیشتر از مثال است، اجرای مثال آن را پایین می‌آورد؛ پس آن را کورکورانه کپی نکنید.
اگر آزمایش موفق بود و مدیر تصمیم به ماندگاری گرفت، ابتدا فایل‌های تنظیم /etc/sysctl.d/ و سیاست توزیع را بررسی کنید تا تنظیم موجود را رونویسی نکنید. می‌توان در یک فایل اختصاصی جدید، مقدار تأییدشده را به شکل fs.inotify.max_user_watches = 16384 ثبت کرد. پیش از ذخیره و اعمال، مسیر، تقدم فایل‌های تنظیم و امکان بازگشت را بررسی کنید. راه‌اندازی مجدد یا بازخوانی تنظیمات ممکن است سایر مقادیر سیستم را نیز تحت تأثیر قرار دهد.

۵. مطمئن شوید پایش واقعاً کار می‌کند

برنامه را با روش پشتیبانی‌شده خودش دوباره اجرا کنید. یک فایل داخل پوشه موردنظر را تغییر دهید و ببینید برنامه رویداد یا بازسازی مورد انتظار را دریافت می‌کند. چند دقیقه گزارش را در شرایط واقعی دنبال کنید. اگر پیام IN_Q_OVERFLOW می‌بینید، رویدادهای صف از دست رفته‌اند و بررسی عملکرد مصرف‌کننده و صف، مسئله جداگانه‌ای است.
برای خطای متفاوتِ فایل‌های باز، راهنمای Too many open files را بخوانید. خدمات مدیریت سرور نت‌آرام و شرح فنی inotify در لینوکس نیز در دسترس است.
اشتراک‌گذاری:
لینکدینتلگرامایکس

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام