Açık dosya tanıtıcısı sınırına ulaşılması nasıl araştırılır?

Açık dosya tanıtıcısı sınırına ulaşılması nasıl araştırılır?​

Açık dosya tanıtıcısı sınırına ulaşıldığını doğrulamak için önce hatayı üreten sürecin kullanıcı ve PID bilgilerini belirleyin; ardından o sürecin mevcut açık tanıtıcı sayısını, süreç başına yumuşak/sert sınırını ve sistem genelindeki sayaçları karşılaştırın. Linux’ta süreç sınırı aşıldığında genellikle EMFILE ("Too many open files"), sistem genelindeki dosya tablosu dolduğunda ise ENFILE görülür.

Kavram nasıl çalışır?​

Dosya tanıtıcısı (file descriptor), bir sürecin açık dosya, soket, pipe veya benzeri kaynağı gösteren küçük bir tamsayıdır. Standart giriş, çıkış ve hata akışları da tanıtıcı kullandığından sayaç yalnızca normal dosyaları kapsamaz.

Her süreç için iki sınır vardır:

• Soft limit: Sürecin normalde kullanabileceği etkin sınırdır. Bash kabuğunda ulimit -Sn bunu gösterir; bu, çalışan ayrı bir hizmetin sınırı değildir.
• Hard limit: Soft limitin yükseltilebileceği üst sınırdır. Yetkisiz süreç hard limitini yükseltemez; soft değerini mevcut hard sınırına kadar yükseltebilir. Yetkili süreçler için çekirdek üst sınırı gibi ek koşullar vardır.

Örneğin soft limit 1024 ise kullanılabilecek tanıtıcı numaraları 0–1023 aralığındadır. Bu aralık dolduğunda yeni bağlantı veya log açma işlemi başarısız olabilir. Limit teknik olarak açılabilecek en büyük tanıtıcı numarasının bir fazlasıdır; yalnızca girdi sayısını ölçmek her durumu kesin kanıtlamaz. Aynı makinede başka süreçlerin toplam kullanımı sistem genelindeki dosya tablosunu doldurursa tek bir süreç kendi sınırına ulaşmamış olsa bile ENFILE görülebilir.

Uygulanabilir araştırma adımları​

Aşağıdaki komutlar systemd kullanılan Linux içindir; hizmet adı, komut adı ve PID 1234 temsili değerlerdir. Başka kullanıcının süreç dizinini ve günlüklerini okumak yetki gerektirebilir. İzin hatasını boş veya sağlıklı bir sonuç gibi yorumlamayın.

Sonuçlara göre karar​

Aşağıdaki ayrım, hangi müdahalenin uygun olduğunu belirler:

1. Önce uygulama ve çekirdek günlüklerinde hatayı doğrulayın.
   Kod:

   journalctl -u uygulama-hizmeti --since "10 minutes ago" | grep -Ei 'too many open files|EMFILE|ENFILE|file descriptor'

   çıktısında ilgili hata görünüyorsa sorun dosya tanıtıcısı tükenmesiyle uyumludur. Hiç sonuç yoksa aynı zaman aralığındaki uygulama loglarını ve bağlantı hatasının gerçek nedenini ayrıca inceleyin.
2. Hizmetin PID’sini bulun ve gerçekten çalışan süreci seçtiğinizi kontrol edin.
   Kod:

   pgrep -a -f 'uygulama-komutu'

   birden fazla PID döndürürse her worker’ı ayrı inceleyin; ana süreçteki sayı tüm worker’ların toplamı değildir.
3. Sürecin sınırlarını okuyun.
   Kod:

   cat /proc/1234/limits | grep -i 'open files'

   çıktısında Soft Limit ve Hard Limit değerlerini karşılaştırın. Soft değer küçükse süreç bu sınıra önce ulaşabilir; her iki değer de düşükse kalıcı hizmet yapılandırması gözden geçirilmelidir.
4. Mevcut açık tanıtıcı sayısını ölçün.
   Kod:

   ls /proc/1234/fd | wc -l

   komutu tanıtıcı dizinindeki girdileri sayar. Sayı soft limite çok yakınsa limit baskısı olasıdır. Komut izin hatası veriyorsa boru hattının yazdığı 0 gerçek ölçüm değildir; önce okuma yetkisini doğrulayın. Sayı düşük olmasına rağmen hata sürüyorsa kısa süreli tepe kullanımını, başka worker’ları veya yeniden başlayan süreçleri kaçırmış olabilirsiniz.
5. Tanıtıcıların ne için kullanıldığını sınıflandırın.
   Kod:

   ls -l /proc/1234/fd | head -40

   ile normal dosya, socket, pipe ve silinmiş dosya göstergelerini görün. Çok sayıda socket bağlantı havuzuna; sürekli artan pipe veya dosya girdileri ise kapatılmayan kaynaklara işaret edebilir.
6. Sistem genelindeki durumu kontrol edin.
   Kod:

   cat /proc/sys/fs/file-nr

   çıktısı sırasıyla ayrılmış açık dosya tanımı (file handle) sayısını, boş tanım sayısını ve üst sınırı gösterir. Modern Linux’ta ikinci değer 0’dır. Bu sistem sayacı, süreçlerdeki tanıtıcı sayılarının basit toplamı değildir; birden fazla tanıtıcı aynı açık dosya tanımını paylaşabilir. Ayrıca
   Kod:

   cat /proc/sys/fs/file-max

   sistem genelindeki açık dosya tanımı üst sınırını verir. Toplam kullanım sınıra yaklaşıyorsa yalnızca uygulamanın limitini artırmak kalıcı çözüm değildir.
7. Hizmetin nasıl başlatıldığını kontrol edin. systemd ile çalışan bir hizmette
   Kod:

   systemctl show uygulama-hizmeti -p LimitNOFILE -p LimitNOFILESoft

   komutunu kullanın. Elle kabuktan çalıştırılan süreçte görülen ulimit değeriyle systemd servisinin değeri aynı olmayabilir.
8. Aynı PID için ölçümü birkaç saniye arayla birkaç kez tekrarlayıp zamanıyla kaydedin. Artış tek başına sızıntıyı kanıtlamaz; eşzamanlı trafik ve tamamlanan işlerle karşılaştırın. Süreç yeniden başlarsa yeni PID’yi seçin. Hata çıktısını gizleyerek kaybolmuş PID’yi sıfır kullanım gibi kaydetmeyin.

Başarılı bir kontrolde günlükteki hata, ilgili PID, o PID’nin soft limiti ve aynı anda ölçülen tanıtıcı sayısı birlikte kaydedilmiş olur. Örneğin sayı 1020, soft limit 1024 ise tanıtıcı aralığı neredeyse doludur; sayı 150, limit 4096 ise bu anda limit doluluğu kanıtlanmış değildir ve geçmişteki tepe değer veya farklı worker incelenmelidir.

Linux’ta select() kullanan uygulamalar 1023 üzerindeki tanıtıcılarla çalışamayabilir; soft limiti yükseltmeden önce uygulamanın uyumluluğunu doğrulayın. Limit artırmak yalnızca uygulamanın gerçekten daha fazla eşzamanlı dosya ve sokete ihtiyaç duyduğu, kaynakların düzgün kapatıldığı ve bellek/işletim sistemi kapasitesinin değerlendirildiği durumda yapılmalıdır. systemd hizmetinde LimitNOFILE ayarı, kabukta ulimit değiştirmekten bağımsız olabilir; ayarı değiştirdikten sonra hizmeti yeniden başlatıp systemctl show ve /proc/PID/limits ile doğrulayın.

Sık yapılan hatalar​

• Yalnızca ulimit -n çalıştırmak: Bu değer mevcut kabuğu gösterir, çalışan hizmetin sınırını göstermeyebilir.
• Yalnızca toplam dosya sayısına bakmak: Toplam sayı normal görünürken tek bir worker kendi soft limitine ulaşabilir.
• PID değişimini yok saymak: Yeniden başlayan hizmette eski PID’nin ölçümü güncel süreci temsil etmez.
• Limit artırmayı kök neden sanmak: Artış, açık kalan socket veya dosyaların uygulamadaki nedenini düzeltmez.
• Sadece normal dosyaları saymak: Socket, pipe, event ve log tanıtıcıları da aynı süreç sınırını tüketebilir.

Sık sorulan sorular​

Bir dosya silindiği halde neden disk alanı geri gelmez?​

Dosya adı dizinden silinse bile bir süreç dosyayı açık tutuyorsa disk alanı süreç kapanana veya tanıtıcıyı bırakana kadar kullanılabilir. lsof +L1 ile silinmiş ama açık dosyaları araştırabilirsiniz.