Yüksek hacimli bir sistem için pratik maksimum açık dosya tanımlayıcıları (ulimit -n)

Kısa süre önce uygulamamızı yüklemeye başladık ve yaklaşık 24 saat sonra dosya tanımlayıcılarının bittiğini fark ettik.

Dell 1955'te RHEL 5 kullanıyoruz:

CPU: 2 x Çift Çekirdekli 2.66GHz 4MB 5150 / 1333FSB RAM: 8GB RAM HDD: 2 x 160GB 2,5 "SATA Sabit Sürücüler

Dosya tanımlayıcı sınırını kontrol ettim ve 1024 olarak ayarlandı. Uygulamamızın yaklaşık 1000 gelen bağlantıya ve 1000 giden bağlantıya sahip olabileceği göz önüne alındığında, bu oldukça düşük görünüyor. Açılması gereken gerçek dosyalardan bahsetmiyorum bile.

İlk düşüncem, ulimit -n parametresini birkaç büyüklük sırasına göre arttırmak ve daha sonra testi yeniden yapmaktı, ancak bu değişkeni çok fazla ayarlamanın olası sonuçlarını bilmek istedim.

Yazılımımızın teorik olarak kaç tane dosya tanıtıcısını açabileceğini bulmaktan başka, bunu ayarlamaya yönelik en iyi yöntemler var mı?

Bu sınırlamalar, birden fazla "normal" kullanıcının (uygulamaları değil) sunucuyu paylaşacağı bir zamandan geldi ve onları çok fazla kaynak kullanmasını engellemek için gerekli yöntemlere ihtiyacımız vardı.

Yüksek performanslı sunucular için çok düşükler ve genellikle onları çok yüksek bir sayıya ayarladık. (24k ya da öylesine) Daha yüksek sayılara ihtiyacınız varsa, sysctl file-max seçeneğini de değiştirmeniz gerekir (genellikle ubuntu'da 40k ve rhel'de 70k ile sınırlıdır).

Ulimit ayarı:

# ulimit -n 99999

Sysctl max dosyaları:

#sysctl -w fs.file-max=100000

Ayrıca ve çok önemli, uygulamanızın bellek / dosya tanımlayıcı sızıntısı olup olmadığını kontrol etmeniz gerekebilir. Geçerli olup olmadığını görmek için açık olan her şeyi görmek için lsof kullanın. Sisteminizi uygulama hataları etrafında çalışacak şekilde değiştirmeye çalışmayın.

Her zaman sadece olabilir

cat /proc/sys/fs/file-nr

'Yüksek yük' durumu sırasında kaç tane dosya tanımlayıcısının kullanıldığını görmek için.

Bir maksimum olarak - sadece ne yaptığınıza bağlıdır.

Dosya tanımlayıcıları tcp soketleri, vb. İse, soket arabellekleri ve diğer çekirdek nesneleri için büyük miktarda bellek kullanma riskiniz vardır; bu hafıza değiştirilemez.

Fakat aksi takdirde, hayır, prensipte hiçbir sorun olmamalıdır. Ne kadar çekirdek bellek kullanacağına karar vermek için çekirdek belgelerine bakın ve / veya test edin.

Veri tabanı sunucularını ~ 10k dosya tanımlayıcıları açık (çoğunlukla gerçek disk dosyalarında) büyük bir sorun olmadan çalıştırıyoruz, ancak 64 bit ve ram'ları var.

Ulimit ayarı işlem başına, ancak sistem genelinde bir sınır da var (32k varsayılan olarak düşünüyorum)

Kişisel olarak en iyi uygulamaların farkında değilim. Sistem fonksiyonuna bağlı olarak biraz öznel.

Gördüğünüz 1024'ün kullanıcı başına bir limit olduğunu ve sistem genelinde bir limit olmadığını unutmayın. Bu sistemde kaç tane uygulama çalıştırdığınızı düşünün. Sadece bu mu? Bu uygulamayı çalıştıran kullanıcı başka bir şey yapıyor mu? (IE, bu hesabı kullanarak potansiyel olarak kaçabilecek komut dosyalarını çalıştırmak ve çalıştırmak için kullanan insanlar var mı?)

Kutu yalnızca bu uygulamayı çalıştırıyorsa ve bahsi geçen uygulamayı çalıştıran hesap yalnızca bu amaç için çalışıyorsa, önerdiğiniz şekilde limitinizi artırmada hiçbir zarar görmüyorum. Eğer bir şirket içi dev ekip ise, onların fikrini rica ediyorum. Üçüncü taraf bir satıcıdan geliyorsa, belirli gereksinimleri veya önerileri olabilir.

Bu bana "kalkınma ortamında test etmek" ile en iyi cevaplanan sorulardan biri gibi geliyor. Yıllar önce hatırlıyorum ki, bununla uğraşırken Sun tedirgin oldu, ama bu tedirgin değil O zamanın limiti de 1024 idi, bu yüzden şimdi Linux için aynı olduğunu görmek biraz şaşırdım, daha yüksek olması gerektiği gibi görünüyor.

Sorunuza cevap vermem için Google'a giderken aşağıdaki bağlantı eğitimini buldum: http://www.netadmintools.com/art295.html

Ve bu da: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible