یکی از خطاهایی که تقریبا هر مهندس بک‌اند یا DevOps حداقل یک‌بار در production با آن روبه‌رو شده، این پیام است:
Too many open files
در نگاه اول ساده به نظر می‌رسد، اما وقتی در ساعت اوج ترافیک ظاهر می‌شود، می‌تواند کل سرویس را از دسترس خارج کند. بسیاری از تیم‌ها سریع limit را بالا می‌برند و مشکل را موقتاً حل‌شده فرض می‌کنند. اما علت اصلی معمولاً جای دیگری است.
هر process در لینوکس تعداد مشخصی file descriptor می‌تواند باز کند. این فقط شامل فایل‌های معمولی نیست. socketها، connectionهای دیتابیس، فایل‌های لاگ، pipeها و حتی برخی resourceهای داخلی همگی از همین سهمیه استفاده می‌کنند. وقتی تعداد connectionهای همزمان یا فایل‌های باز از حد مجاز بیشتر شود، سیستم‌عامل دیگر اجازه باز کردن resource جدید نمی‌دهد و سرویس شروع به fail کردن درخواست‌ها می‌کند.
مشکل از آنجا پیچیده‌تر می‌شود که limit پیش‌فرض در بسیاری از سرورها (مخصوصا containerها) نسبتا پایین است. در Kubernetes یا Docker، اگر صریحا تنظیم نکنید، ممکن است با محدودیت‌های سخت‌گیرانه‌تری روبه‌رو شوید.
راه‌حل اصولی فقط افزایش عدد ulimit -n نیست. باید سه لایه را بررسی کنید:
Limit سیستم‌عامل و process
مقدار ulimit -n و تنظیمات /etc/security/limits.conf یا LimitNOFILE در systemd را چک کنید. در containerها این مقدار را از طریق ulimits در Docker یا securityContext در Kubernetes تنظیم کنید.نشت resource در خود اپلیکیشن
شایع‌ترین علت واقعی، بستن‌نشدن connectionها یا فایل‌هاست. connection pool دیتابیس، HTTP client، یا باز کردن فایل بدون close مناسب می‌تواند به‌مرور descriptorها را مصرف کند. ابزارهایی مثل lsof -p <pid> به شما نشان می‌دهند دقیقاً چه چیزهایی باز مانده‌اند.ظرفیت واقعی سرویس
اگر سرویس شما به‌طور طبیعی هزاران connection همزمان نیاز دارد، باید هم limit را بالا ببرید و هم معماری را بررسی کنید (مثلاً استفاده بهتر از connection pooling یا asynchronous I/O).
توصیه عملی:
قبل از اینکه فقط عدد را بالا ببرید، یک‌بار با lsof و مانیتورینگ تعداد open files را در زمان اوج ترافیک بررسی کنید. اگر عدد مدام در حال افزایش است و پایین نمی‌آید، با یک memory leak یا connection leak طرف هستید، نه فقط کمبود limit.
این خطا در ظاهر ساده است، اما معمولاً نشانه‌ای از یک مشکل عمیق‌تر در مدیریت resource است. تیم‌هایی که آن را جدی می‌گیرند، هم پایداری بیشتری دارند و هم از surpriseهای ناگهانی در production جلوگیری می‌کنند.