it-swarm-tr.com

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

Son zamanlarda uygulamamızı yük testine 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:

İşlemci: 2 x Çift Çekirdekli 2.66GHz 4MB 5150/1333FSB RAM: 8GB RAM HDD: 2 x 160GB 2.5 "SATA Sabit Diskler

Dosya tanımlayıcı sınırını kontrol ettim ve 1024 olarak ayarlandı. Uygulamamızın potansiyel olarak yaklaşık 1000 gelen bağlantıya ve 1000 giden bağlantıya sahip olabileceği düşünüldüğünde, 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ükte artırmak ve ardından testi yeniden çalıştırmaktı, ancak bu değişkeni çok yüksek ayarlamanın herhangi bir olası sonucunu bilmek istedim.

Bunu ayarlamak için, yazılımımızın teorik olarak kaç dosya tanımlayıcı açabileceğini bulmaktan başka en iyi uygulamalar var mı?

77
Kevin

Bu sınırlar, birden fazla "normal" kullanıcının (uygulama değil) sunucuyu paylaşacağı bir zamandan geldi ve onları çok fazla kaynak kullanmasını önlemek için yollara ihtiyacımız vardı.

Yüksek performanslı sunucular için çok düşüktür ve genellikle onları çok yüksek bir değere ayarlarız. (24k veya daha fazla) 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 olarak, uygulamanızda 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 komutunu kullanın. Uygulama hataları gidermek için sistem.

73
sucuri

Her zaman sadece

cat /proc/sys/fs/file-nr

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

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

15

Dosya tanımlayıcıları tcp yuvaları vb. İse, yuva arabellekleri ve diğer çekirdek nesneleri için büyük miktarda bellek kullanma riskiyle karşı karşıya kalırsınız; bu bellek değiştirilemez.

Ancak aksi halde, hayır, prensipte sorun olmamalıdır. Ne kadar çekirdek belleği kullanacağını öğrenmek ve/veya test etmek için çekirdek belgelerine bakın.

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

Ulimit ayarı işlem başınadır, ancak sistem çapında bir sınır da vardır (varsayılan olarak 32k)

6
MarkR

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

Gördüğünüz 1024'ün sistem genelinde bir sınır değil, kullanıcı başına bir sınır olduğunu unutmayın. Bu sistemde kaç uygulamayı ç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, potansiyel olarak kaçabilecek komut dosyalarını çalıştırmak ve çalıştırmak için bu hesabı kullanan kişilerin var mı?)

Kutunun sadece bir uygulamayı çalıştırdığı ve söz konusu uygulamanın sadece bu amaç için çalıştığı göz önüne alındığında, önerdiğiniz gibi limitinizi artırmakta herhangi bir zarar görmüyorum. Eğer bir şirket içi geliştirme ekibi ise, onların görüşünü isterim. Üçüncü taraf bir satıcıdan geliyorsa, belirli gereksinimleri veya önerileri olabilir.

2
Grahamux

Bu bana "geliştirme ortamında test et" ile en iyi cevaplanan sorulardan biri gibi görünüyor. Yıllar önce hatırlıyorum Güneş, bununla uğraştığınızda sinirlendi, ama o gergin değil. O zamanın sınırı da 1024'dü, bu yüzden şimdi Linux için aynı olduğunu görünce biraz şaşırdım, daha yüksek olması gerektiği gibi görünüyor.

Sorunuzun yanıtlarını aradığımda aşağıdaki bağlantıyı eğitici buldum: http://www.netadmintools.com/art295.html

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

1
Kyle Hodgson