Linux üzerinde performans testi – File Descriptor limit problemi

Herkese selamlar. Yaptığım bir performans testi sırasında yaşadığım bir linux deneyimini sizlerle paylaşmak istiyorum. Testi yaptığım uygulama, yapısı itibarıyla birçok yere socket bağlantısı yapıyor ve birçok dosya okuma-yazma işlemi yapıyordu. Test sırasında, bir çeşit “File not open” hatası aldım ve loglarda birçeşit dosya açma limitinden bahsediyordu. Biraz Google araştırması sonucu sorunun kaynağını bulduk.
Unix/linux kullanıcılarının bildiği üzere, işlem yapılan hemen hemen herşey düz metin dosyadır.(compile edilmiş binary dosyalar haricinde). Bu dosyalar, çeşitli işlemlerle çalıştırılabilir şekle geliyor. Ama her zaman özünde metin dosyasıdır. Mesela, bir bağlantı açılacaksa bir socket dosyası açılır/yazılır. Örneğin, mysql bağlantısı için /tmp/mysql.sock dosyası açılır.
İşte tam bu noktada ortaya şöyle bir durum çıkıyor. Linux’te bir processin işleyebileceği dosya sayısı (teknik tanımıyla: File Descriptors) konfigure edilebilir bir şekilde ayarlanıyor.
Öncelikle, bir processin o an işlediği dosyaları görmek için pfiles komutu kullanılır.
pfiles <pid>
pid olarak, işlem yapılan processin pid numarası bulunur.(basitçe, ps –ef | grep <process_ismi> ile bulunabilir).
Sistemde tanımlı limitler bulmak için ulimit komutu kullanılır.

ulimit -a
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) unlimited
-n: file descriptors 256
-v: virtual memory size (kb) unlimited

Genelde, varsayılan tanımlı sayı olarak 256 gelmektedir.( -n: file descriptors 256)
Bunu değiştirmek için:
ulimit –n <yeni_sayi>
komutu kullanılır. Sadece o oturum için değil, devamlı kullanılacaksa, bu komut ilgili kullanıcı profil dosyasına eklenir. (.xxxenv veya .xxx_profile).

Performansı yüksek, memory leak düşük, bottleneck olmayan günler dileğiyle 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

*