2^21、Ubuntu 16.04を超えると、Openfilesの制限が自動的に減少します。

2^21、Ubuntu 16.04を超えると、Openfilesの制限が自動的に減少します。

nofile私のユーザー(もちろん、権限を含む)に対してハード制限とソフト制限を設定しようとしたときに、sudo奇妙な動作が見つかりました。

私のシステム全体の制限は2 ^ 22で、2 ^ 23に設定した後も次のことを試しました。

問題なくソフト制限とハード制限を2^20に完全に設定しました。 (これは、これを使用してサンプリングした後にulimit -Sn,and -Hn設定した値を取得することを意味します。)

2 ^ 21以上に設定すると、ユーザーが再ログインした後(変更を適用するため)、ハード制限とソフト制限がそれぞれ4096と1024に減少します。

オンラインでこれに関する情報が見つからず、これらの値を保存するために使用される変数の種類に関連していると思われます。 (個人的には約2^32またはさらに2^33であると予想しています。定義されていますが、uint確かにこの状況ではありません)。

ベストアンサー1

システム全体に2つの制限があるようです。ドキュメント/sysctl/fs.txt

  • fs.file-maxシステム全体で開かれたファイル(ファイルハンドル)の最大数。
  • fs.nr_openプロセスごとに開かれたファイル数のグローバル上限であり、設定された値を制限しRLIMIT_NOFILEますulimit -n。予想通り、デフォルトは1024 * 1024、つまり2 ^ 20です。

だから:

# sysctl fs.nr_open
fs.nr_open = 1048576
# ulimit -Hn 1048577
-su: ulimit: open files: cannot modify limit: Operation not permitted
# sysctl fs.nr_open=$[ 2**22 ] 
fs.nr_open = 4194304
# ulimit -Hn 4000000            # now it can be set

しかし、file-maxこれはプロセス固有の制限設定を妨げないようです。私はいつも次のように設定しました。

# sysctl fs.file-max
fs.file-max = 262144

したがって、どの制限が設定されていても(pam_limits.so?)sysctlで設定された制限が原因で、システムコールでエラーを選択して無視できます。または、どこかにエラーが記録されることがあります。ログを確認してください。

おすすめ記事