私は古いレガシーアプリケーションに取り組んでいますが、誰も説明しないいくつかの設定に直面しています。
明らかに、ある時点で、アプリケーションの一部のプロセスがプロセスごとに許可される最大ファイル記述子の数に達し、チームはシェルの初期化ファイル（.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に対してのみこれを行います。
答え2
解決する必要がある問題を確認してください限界アプリケーションのシェルには256個の利用可能なファイル記述子しかありません。アプリケーションは非常に古く、fdの最大数を使用し、その番号を「unsigned char」型の変数に入れようとします。この変数は最大256の整数しか保持できません（コアダンプが発生します）。したがって、この特定のアプリケーションでは、利用可能なfdを256に制限する必要があります。
Alancとは異なり、提案されているように非常に高く設定すると、パフォーマンスに測定可能な影響があるとは思われません。そうしない理由は、悪意のあるプロセスがあまりにも多くのリソースを消費するのを防ぐためです。
最後に、アランが正しいです。このpfilesコマンドは、特定のプロセスで現在使用されているfdの数を示します。ただし、このpfilesコマンドは検査プロセスを一時的に停止することを覚えておいてください。コマンドの実行によってプロセスがクラッシュするのを見たことがありますが、pfilesこれはおそらくアプリケーションで決して発生しない極端なケースです。申し訳ありません。現在のプロセスで使用されているfdの数を見つける安全な方法がわかりません。私のアドバイス：pfilesプロセスに対してコマンドを実行したら、常にプロセスがまだ存在していることを監視してください。