ルートが使用している開いているファイル記述子の数がulimit -nを超える(またはその方法)のはなぜですか?
私たちのサーバーは最近ファイル記述子を使い果たしました。それに関していくつか質問があります。ulimit -n開いているファイル記述子の最大数を提供することになっています。その数は1024です。実行して開いているファイル記述子の数を確認し、lsof -u root |wc -l2500 fdsを取得しました。これは1024をはるかに超えているので、1024の数値は、ユーザーごとではなく、プロセスごとであることを意味すると思います。さて、私は走っlsof -p$PidOfGlassfish|wc -lて1300を得ました。これは私が得られない部分です。ulimit -nユーザーごとまたはプロセスごとのプロセスの最大数ではない場合、それは何に適していますか?rootユーザーには適用されませんか?もしそうなら、どのようにしてファイル記述子の不足に関するエラーメッセージを取得できますか? 編集:私が理解できる唯一の方法ulimit -nは、ファイルハンドルの数ではなく開いているファイルの数(bashマニュアルに記載されているように)を適用する場合です(異なるプロセスが同じファイルを開くことができます)。この場合、開いているファイルの数を一覧表示するだけで(「/」を削除して、メモリにマップされたファイルを除外する)だけでは不十分です。 lsof -u root |grep /|sort -k9 |wc -l #prints '1738' 実際に開いているファイルの数を確認するには、一意のエントリのみを印刷するために名前列でフィルタリングする必要があります。したがって、おそらく次の方がより正確です。 lsof -u root |grep /|sort -k9 -u |wc -l #prints '604' 上記のコマンドは、lsofからの次の形式での出力を想定しています。 java 32008 root mem REG 8,2 11942368 72721 /usr/lib64/locale/locale-archive vmtoolsd 4764 root mem REG 8,2 …