1000個のパーティションを持つトピックを使用してKafkaインスタンスを実行できないため、java.io.IOException: Too many open filesec2 VMのファイル記述子の制限を調べ始めました。次のコマンドはすべて異なる結果を生成するため、Centos 7システムでファイルを開くときの正確な制限を理解するのが困難です。コマンドは次のとおりです。
ulimit -a: ファイル1024を開くlsof | wc -l:298280cat /proc/sys/fs/file-max：758881（と一致する/proc/sys/fs/file-nr）
実際の制限が最後のコマンドによって生成された制限である場合、それよりはるかに低くなります（lsof | wc -l：298280）。しかし、この場合、ulimit開いているファイルが1024個よりはるかに多いため、コマンドの出力は非常に不明です。
公式文書によると、Centosでファイル記述子をチェックする最良の方法は/proc/sys/fs/file-maxfileしかし、これらの命令の間に「不一致」のように見えるものはすべてありますか？
答え1
file-maxシステム全体で開くことができるファイルの最大数。これはカーネルレベルで行われます。マニュアルページには次のように記載されています
lsof。
オプションがない場合、lsof はすべてのアクティブ・プロセスに属するすべてのオープン・ファイルをリストします。
報告されたファイルの数が設定lsofよりはるかに少ないため、これは観察内容と一致します。file-max
- 最後に、
ulimitユーザーレベルでリソース制限を適用するために使用されます。 「オープンファイル数」パラメータはユーザーレベルで設定されますが、そのユーザーが開始したすべてのプロセスに適用されます。この場合、単一のKafkaプロセスは最大1024のファイルハンドルを開くことができます（ソフトリミット）。
この制限を4096というハード制限に直接増やすことができます。ハード制限を増やすには、ルートアクセスが必要です。
Kafkaが単一のプロセスとして実行されている場合lsof -p [PID]。
問題が解決することを願っています。
答え2
これは一般的な間違いです。lsof元の呼び出しの結果を仮定された制限と比較することです。
グローバル制限（/proc/sys/fs/file-max）の場合、/proc/sys/fs/file-nr最初の値は使用された値を表し、最後の値は制限を表します。
OpenFileの制限はプロセスごとに適用されますが、ユーザーに対して定義できます。ユーザーの制限については、ulimit -Hnコマンドと定義を参照してください。/etc/security/limits.conf通常は「アプリユーザー」と一緒に適用されます。例: "tomcat": ユーザー tomcat の制限を 65000 に設定すると、この制限は実行される Java プロセスに適用されます。
プロセスに適用される制限を確認するには、対応するPIDを取得し、次の手順を実行します。
cat /proc/${PID}/limits
特定のプロセスで開いているファイルの数を確認するには、適切なPIDをインポートして次の手順を実行します。
ls -1 /proc/${PID}/fd | wc -l(lsは「minus 1」を意味するので、「minus el」と混同しないでください.)
lsofの詳細を知りたいのですが、制限に含まれるファイルハンドルだけを知りたい場合は、次のことを試してください。
lsof -p ${PID} | grep -P "^(\w+\s+){3}\d+\D+"
lsof -p ${PID} -d '^cwd,^err,^ltx,^mem,^mmap,^pd,^rtd,^txt' -a
注：「ファイル」は、ファイル/パイプ/tcp接続/などです。
場合によっては、権限なしでコマンドで正しい結果を得るためにrootまたはsudoを使用する必要があり、時にはエラーが表示されず、少ない結果しか得られません。
最後に、プロセスがアクセスするファイルシステムのファイルを知りたい場合は、次の点を見てください。
lsof -p ${PID} | grep / | awk '{print $9}' | sort | uniq