Linux'ta izin verilen en fazla açık dosya sayısı

Linux'ta maksimum açık dosya sayısını ne kadar yapılandırabileceğiniz konusunda (teknik veya pratik) bir sınır var mı? Çok fazla sayıda (örneğin 1-100M) yapılandırırsanız bazı olumsuz etkiler var mı?

Burada sunucu kullanımını düşünüyorum, gömülü sistemleri değil. Çok miktarda açık dosya kullanan programlar elbette hafızayı yiyebilir ve yavaş olabilir, ancak sınır gerekenden çok daha büyük yapılandırılmışsa (örneğin sadece yapılandırma tarafından tüketilen hafıza) olumsuz etkilerle ilgileniyorum.

Sınırın ana nedeninin aşırı bellek tüketiminden kaçınmak olduğundan şüpheleniyorum (her bir açık dosya tanımlayıcısı çekirdek belleği kullanıyor). Ayrıca, dosya tanımlayıcılarını sızdıran ve sistem kaynaklarını tüketen buggy uygulamalarına karşı bir koruma görevi görür.

Ancak modern sistemlerin 10 yıl önceki sistemlerle karşılaştırıldığında ne kadar saçma bir RAM olduğunu düşünürsek, bugünkü varsayılanların oldukça düşük olduğunu düşünüyorum.

2011'de Linux'ta dosya tanımlayıcıları için varsayılan sabit sınır 1024'ten 4096'ya yükseltildi .

Bazı yazılımlar (örn. MongoDB), varsayılan sınırdan çok daha fazla dosya tanımlayıcı kullanır. MongoDB halkı bu sınırı 64.000'e çıkarmanızı tavsiye ediyor . rlimit_nofileBelirli uygulamalar için 300.000’i kullandım .

Yumuşak sınırı varsayılan (1024) konumunda tuttuğunuz sürece, sabit sınırı artırmak muhtemelen oldukça güvenlidir. Programlar setrlimit()sınırlarını yumuşak sınırın üzerine çıkarmak için çağırmalıdır ve yine de sınırlama ile sınırlıdır.

Ayrıca ilgili bazı sorulara bakın:

• /server/356962/where-are-the-default-ulimit-values-set-linux-centos
• /server/773609/how-do-ulimit-settings-impact-linux

Etki normalde gözlemlenebilir olmaz, ancak çekirdeğin IO modülü tüm bu açık dosya tanımlayıcılarıyla ilgilenmek zorunda kalacak ve ayrıca önbellek verimliliği üzerinde de etkisi olabilir.

Bu sınırlar, kullanıcıyı kendi (veya üçüncü tarafların) hatalarından koruma avantajına sahiptir. Örneğin, süresiz olarak çatallanan küçük bir program veya komut dosyası çalıştırırsanız, en sonunda ulimits'den birini engeller ve bu nedenle daha yoğun (muhtemelen kurtarılamaz) bir bilgisayarın donmasını önler.

Bu sınırlardan herhangi birini artırmak için kesin nedenleriniz olmadıkça, bundan kaçınmalı ve daha iyi uymalısınız.

Teknik olarak imzasız uzun (C Lang) maksimum değeri ile sınırlıdır, yani 4,294,967,295

Referans: fs.hdosya

/* And dynamically-tunable limits and defaults: */
struct files_stat_struct {
  unsigned long nr_files;   /* read only */
  unsigned long nr_free_files;  /* read only */
  unsigned long max_files;    /* tunable THIS IS OUR VALUE */
};

Endişenizin anlaşılabilir olduğunu düşünüyorum, ancak büyük olasılıkla Linux yapılandırılmış (ancak kullanılan dosya tanımlayıcıları değil) için çok fazla bellek tüketmeyecek :)

Son 10 yıldır mesleki kariyerimde böyle bir problemi hatırlayamıyorum.

Saygılarımızla.

Sessiz geç ama bu herkesin bu sorunun cevabını almasına yardımcı olmalı. Linux'ta açık dosya sayısı için pratik sınır, bir işlemin açabileceği maksimum dosya tanımlayıcı sayısı kullanılarak da sayılabilir.

Limitlerin sistemden sisteme değiştiğini gördüm. Gönderen getlimit adam sayfasında bunu görebilirsiniz RLIMIT_NOFILE-1dahili belirtir sınırları.

RLIMIT_NOFILE değerini kontrol etmek için aşağıdaki ifadeyi kullanarak bir demet alabilirsiniz

python -c "import resource; print(resource.getrlimit(resource.RLIMIT_NOFILE))"

Tuple sonuçları (Soflimit, hardlimit) olarak döndürür. Benim için birden fazla sistemde çalışan sonuçlar aşağıdaki gibidir

(1024, 1048576) # on UBUNTU linux 
(65536, 65536)  # on amazon linux 
(1024, 9223372036854775807) # on macos 

Not: 9223372036854775807 bu sayı sadece sonsuzluk anlamına gelir. Buna çarpmadan önce her zaman diğer kaynak sınırlarına ulaşacaksınız. Bir sistemdeki donanım sınırını olduğundan daha fazla değiştirdiyseniz, çekirdek parametrelerini değiştirmeniz gerekir.