Bagaimana perbedaan ulimit -n dan / proc / sys / fs / file-max?


32

Saya perhatikan bahwa pada gambar CentOS baru yang baru saja saya boot dari EC2 bahwa default ulimit adalah 1024 file terbuka, tetapi / proc / sys / fs / file-max ditetapkan pada 761.408 dan saya bertanya-tanya bagaimana dua batasan ini bekerja bersama. Saya menduga bahwa ulimit -n adalah batas per-pengguna jumlah deskriptor file sementara / proc / sys / fs / file-max luas sistem? Jika itu masalahnya, katakan saya telah login dua kali sebagai pengguna yang sama - apakah setiap pengguna yang login memiliki batas 1024 pada jumlah file yang terbuka, atau apakah itu adalah batas 1024 gabungan file terbuka antara masing-masing yang login di pengguna?

Dan apakah ada banyak dampak kinerja untuk mengatur deskriptor file maks Anda ke angka yang sangat tinggi, jika sistem Anda tidak pernah membuka file yang sangat banyak?


Tag yang ditambahkan: bash linux kernel-resource sistem
Warner

Jawaban:


28

file-maxadalah Penjelasan File (FD) maksimum yang diberlakukan pada tingkat kernel, yang tidak dapat dilampaui oleh semua proses tanpa meningkatkan. The ulimitdiberlakukan pada tingkat proses, yang bisa kurang dari itu file-max.

Tidak ada risiko dampak kinerja dengan meningkatkan file-max. Distribusi modern memiliki set FD maksimum yang cukup tinggi, sedangkan di masa lalu diperlukan kompilasi ulang kernel dan modifikasi untuk meningkat melewati 1024. Saya tidak akan meningkatkan seluruh sistem kecuali Anda memiliki kebutuhan teknis.

Konfigurasi per-proses sering kali perlu disetel untuk melayani daemon tertentu, baik itu database atau server Web. Jika Anda menghapus batas seluruhnya, daemon itu berpotensi menghabiskan semua sumber daya sistem yang tersedia; artinya Anda tidak akan dapat memperbaiki masalah kecuali dengan menekan tombol reset atau power cycle. Tentu saja, salah satu dari itu cenderung mengakibatkan korupsi pada semua file terbuka.


Apakah pemahaman saya benar, bahwa batas per pengguna yang ditetapkan menggunakan ulimit sama untuk semua pengguna? Apakah ada cara untuk menggunakan nilai yang berbeda per pengguna atau tidak?
Oliver

Ya, pengaturan dapat diatur secara global dan per pengguna.
Warner

Jika saya mendapatkan posting Anda dengan benar, ini tidak benar. Itu adalah per proses yang dihasilkan oleh pengguna xy, dan ini dibatasi oleh maksimum filesystem yang ditentukan di /etc/sysctl.conf
Jeredepp

3
The ulimitbatas tidak per pengguna, tapi per proses! Lihat unix.stackexchange.com/questions/55319/…
Tonin

@Tonin - Ya, jawaban ini salah.
Nemo

11

Batasan ulimit adalah per pengguna unik. Jadi user1, terlepas dari berapa kali login atau proses berjalan, akan dibatasi hingga 1024. Ini digabungkan.

Saya tidak yakin apakah saya benar-benar mengerti arti kalimat itu (Bahasa Inggris bukan bahasa ibu saya) Jika kalimat itu berarti konfigurasi ulimit untuk deskriptor file bukan batasan per proses, jawaban yang diterima (AFAIK) salah.

Yang saya maksud adalah, jika beberapa pengguna telah meluncurkan 4 proses dan konfigurasi ulimit untuk FD adalah 1024, setiap proses dapat membuka 1024 FD. Pengguna tidak akan terbatas pada 1024 FD tetapi proses yang diluncurkan oleh pengguna tersebut.

Sebagai contoh:

me@superme:~$ ulimit -n
1024
me@superme:~$ lsof | grep $USER | wc -l
8145

Berikut contoh perl tempat kami mencapai batas (ini adalah batas per proses):

#!/usr/bin/perl

$count = 0;
@filedescriptors;

while ($count <= 1024) {
    $FILE = ${count};
    open $FILE, ">", "/tmp/example$count" or die "\n\n FDs: $count $!";
    push(@filedescriptors, $FILE);
    $count ++;
}

Hasil:

FDs: 1021 Too many open files at ./test.pl line 8.

1021 karena ada 3 deskriptor file terbuka sebelum mencapai loop sementara (stdout, stdin dan stderr)

Maaf jika saya benar-benar salah atau saya salah paham jawabannya.


Jadi kamu benar. Tanggapan @ Warner salah dalam pengertian ini karena batasnya adalah pada basis per-proses dan bukan per-pengguna
filipenf
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.