Deskriptor file terbuka maksimum praktis (ulimit -n) untuk sistem volume tinggi

Kami baru-baru ini mulai menguji aplikasi kami dan menyadari bahwa itu kehabisan file deskriptor setelah sekitar 24 jam.

Kami menjalankan RHEL 5 pada Dell 1955:

CPU: 2 x Dual Core 2.66GHz 4MB 5150 / 1333FSB RAM: 8GB RAM HDD: 2 x 160GB 2,5 "SATA Hard Drives

Saya memeriksa batas deskriptor file dan ditetapkan pada 1024. Mengingat aplikasi kita berpotensi memiliki sekitar 1000 koneksi masuk serta 1000 koneksi keluar, ini tampaknya cukup rendah. Belum lagi file aktual yang perlu dibuka.

Pikiran pertama saya adalah hanya meningkatkan parameter ulimit -n dengan beberapa urutan besarnya dan kemudian menjalankan kembali tes tetapi saya ingin mengetahui kemungkinan konsekuensi pengaturan variabel ini terlalu tinggi.

Adakah praktik terbaik untuk menetapkan ini selain mencari tahu berapa banyak deskriptor file yang secara teoritis dapat dibuka oleh perangkat lunak Anda?

Batas ini berasal dari waktu di mana beberapa pengguna "normal" (bukan aplikasi) akan berbagi server, dan kami membutuhkan cara untuk melindungi mereka dari menggunakan terlalu banyak sumber daya.

Mereka sangat rendah untuk server berkinerja tinggi dan kami biasanya mengaturnya ke jumlah yang sangat tinggi. (24k atau lebih) Jika Anda membutuhkan angka yang lebih tinggi, Anda juga perlu mengubah opsi file sysctl-max (umumnya terbatas pada 40k di ubuntu dan 70k pada rhel).

Pengaturan ulimit:

# ulimit -n 99999

File maks sysctl:

#sysctl -w fs.file-max=100000

Juga, dan sangat penting, Anda mungkin perlu memeriksa apakah aplikasi Anda memiliki kebocoran deskriptor memori / file. Gunakan lsof untuk melihat semua yang terbuka untuk melihat apakah valid atau tidak. Jangan mencoba mengubah sistem Anda untuk mengatasi bug aplikasi.

Anda selalu bisa saja

cat /proc/sys/fs/file-nr

Selama situasi 'beban tinggi' untuk melihat berapa banyak deskriptor file yang digunakan.

Untuk maksimum - itu hanya tergantung pada apa yang Anda lakukan.

Jika deskriptor file adalah soket tcp, dll, maka Anda berisiko menghabiskan banyak memori untuk buffer soket dan objek kernel lainnya; memori ini tidak akan bisa ditukar.

Tetapi sebaliknya, tidak, pada prinsipnya seharusnya tidak ada masalah. Konsultasikan dokumentasi kernel untuk mencoba mencari tahu berapa banyak memori kernel yang akan digunakan, dan / atau mengujinya.

Kami menjalankan server database dengan ~ 10k file deskriptor terbuka (kebanyakan pada file disc nyata) tanpa masalah besar, tetapi mereka 64-bit dan memiliki banyak ram.

Pengaturan ulimit adalah per-proses, tetapi ada batas sistem juga (32 k saya pikir secara default)

Saya pribadi tidak mengetahui adanya praktik terbaik. Ini agak subjektif tergantung pada fungsi sistem.

Ingat bahwa 1024 yang Anda lihat adalah batas per pengguna dan bukan batas seluruh sistem. Pertimbangkan berapa banyak aplikasi yang Anda jalankan di sistem ini. Apakah ini satu-satunya? Apakah pengguna yang menjalankan aplikasi ini melakukan hal lain? (Yaitu apakah Anda memiliki manusia yang menggunakan akun ini untuk masuk dan menjalankan skrip yang berpotensi melarikan diri?)

Mengingat kotak hanya menjalankan aplikasi yang satu ini dan akun yang menjalankan aplikasi tersebut hanya untuk tujuan itu, saya tidak melihat ada salahnya meningkatkan batas Anda seperti yang Anda sarankan. Jika itu adalah tim pengembang in-house, saya akan meminta pendapat mereka. Jika berasal dari vendor pihak ketiga, mereka mungkin memiliki persyaratan atau rekomendasi khusus.

Ini menurut saya salah satu pertanyaan yang paling baik dijawab dengan "mengujinya di lingkungan pengembangan". Saya ingat bertahun-tahun yang lalu Sun gugup ketika Anda mengacaukan ini, tetapi tidak segugup itu. Batasnya pada waktu itu juga 1024, jadi saya sedikit terkejut melihat bahwa itu sama untuk Linux sekarang, sepertinya itu harus lebih tinggi.

Saya menemukan tautan berikut mendidik ketika saya mencari jawaban untuk pertanyaan Anda di Google: http://www.netadmintools.com/art295.html

Dan yang ini juga: https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible