解決策 1:
file-max は、カーネル レベルで適用される最大のファイル記述子 (FD) であり、増加せずにすべてのプロセスが超えることはできません。 ulimit file-max 未満のプロセス レベルで適用されます。 .
file-max を増やすことによるパフォーマンスへの影響のリスクはありません .最新のディストリビューションでは最大 FD がかなり高く設定されていますが、以前は 1024 を超えるまでカーネルの再コンパイルと変更が必要でした。技術的な必要がない限り、システム全体で増やすことはありません。
プロセスごとの構成は、多くの場合、データベースまたは Web サーバーのいずれかである特定のデーモンを提供するために調整する必要があります。制限を完全に削除すると、そのデーモンは利用可能なすべてのシステム リソースを使い果たす可能性があります。つまり、リセット ボタンを押すか、電源を入れ直さない限り、問題を解決することはできません。もちろん、これらのいずれかによって、開いているファイルが破損する可能性があります。
解決策 2:
<ブロック引用>ulimit の制限は、一意のユーザーごとです。そのため、user1 は、ログイン回数やプロセスの実行回数に関係なく、1024 に制限されます。これは結合されます。
その文の意味を完全に理解しているかどうかはわかりません (英語は私の母国語ではありません) その文が、ファイル記述子の ulimit 構成がプロセスごとの制限ではないことを意味する場合、受け入れられた回答 (AFAIK) は間違っています。
つまり、あるユーザーが 4 つのプロセスを起動し、FD の ulimit 構成が 1024 の場合、各プロセスは 1024 の FD を開く可能性があります。ユーザーは 1024 個の FD に制限されるのではなく、そのユーザーによって起動されるプロセスに制限されます。
例:
[email protected]:~$ ulimit -n
1024
[email protected]:~$ lsof | grep $USER | wc -l
8145
これは、制限に達した perl の例です (プロセスごとの制限です):
#!/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 ++;
}
結果:
FDs: 1021 Too many open files at ./test.pl line 8.
1021 (while ループ (stdout、stdin、および stderr) に到達する前に 3 つの開いているファイル記述子があったため)
完全に間違っていたり、答えを誤解していたらごめんなさい。