プロセスごとの最大ファイル記述子の制限を設定すると、どのようなリスクがありますか?

プロセスごとの最大ファイル記述子の制限を設定すると、どのようなリスクがありますか?

私は古いレガシーアプリケーションに取り組んでいますが、誰も説明しないいくつかの設定に直面しています。

明らかに、ある時点で、アプリケーションの一部のプロセスがプロセスごとに許可される最大ファイル記述子の数に達し、チームはシェルの初期化ファイル(.kshrc)に以下を追加して制限を増やすことにしました。

((nfd=16#$(/etc/sysdef | grep "file descriptor" | awk '{ print $1 }' | cut -f3 -d "x")))

ulimit -n $nfd

これにより、ulimit -n出力が256から65536に増加します。私たちのマシンのほとんどすべてのプロセスは、この高いソフト制限の下で実行されます。

この粗雑なアプローチには危険がありますか?正しい校正方法は何ですかulimit

追加の質問:現在実行中のプロセスで使用されているFDの数をどのように知ることができますか?


環境

  • オペレーティングシステム:SunOS .... 5.10 Generic_120011-14 sun4u sparc SUNW、Sun-Fire-V215
  • ハウジング:KsHバージョンM-11/16/88

ベストアンサー1

実行中のプロセスで使用されているファイル記述子の数を表示するには、次のようにします。pfilesプロセスIDに。

プロセスで使用可能なfdの数を増やすと、ソフトウェアと作成方法によってはパフォーマンスに影響を与える可能性があります。プログラムがデータ構造のサイズを変更するために使用できるfdの最大数。select(3c)ビットマスク配列を使用するか、すべてのfdに対してループを閉じるなどの操作を実行します(Solaris用に作成されたソフトウェアは次のものを使用できます)。fdwalk(3c)この関数は、可能な最大値ではなく開いたfdに対してのみこれを行います。

おすすめ記事