プロセスごとの最大ファイル記述子に上限を設定することの危険性は何ですか？
私は古いレガシーアプリケーションに取り組んでいますが、カムの周りの誰も説明していない特定の設定によく遭遇します。
どうやらある時点で、アプリケーションの一部のプロセスがプロセスごとに許可されるファイル記述子の最大数に達していたため、チームはシェルのinitファイル（.kshrc）に以下を追加して制限を増やすことにしました。
((nfd=16#$(/etc/sysdef | grep "file descriptor" | awk '{ print $1 }' | cut -f3 -d "x")))
ulimit -n $nfd
これにより、ulimit -nの出力が256から65536に増加します。マシン上のほぼすべてのプロセスは、この高いソフト制限で実行されます。
この野蛮なアプローチをとることにリスクはありますか？ ulimitを調整する適切な方法は何ですか？
副次的な質問：実行中のプロセスで現在使用されているFDの数を知るにはどうすればよいですか？
環境
- OS：SunOS .... 5.10 Generic_120011-14 Sun4u sparc SUNW、Sun-Fire-V215
- シェル：KsHバージョンM-11/16/88 i
実行中のプロセスで使用されているファイル記述子の数を確認するには、プロセスIDで pfiles を実行します。
ソフトウェアとその記述方法によっては、プロセスで使用可能なfdの数を増やすとパフォーマンスに影響が出る可能性があります。プログラムは、最大数のfdを使用して、 select(3c) ビットマスク配列などのデータ構造のサイズを設定したり、すべてのfdに対してループで閉じるなどの操作を実行したりできます（ただし、Solaris用に作成されたソフトウェアでは可能です） fdwalk(3c) 関数を使用して、可能な最大値ではなく、開いているfdに対してのみこれを実行します。
restrictアプリケーションのシェルで256個のファイル記述子しか使用できないようにする必要がある問題が発生しました。アプリケーションは非常に古く、明らかに最大数のfdを使用しており、その数を整数256までしか保持できないタイプ 'unsigned char'の変数に入れようとしました（コアダンプが発生しました）。したがって、この特定のアプリケーションでは、256fdのみを使用できるように制限する必要がありました。
Alancとは異なり、これを非常に高く設定すると、パフォーマンスに測定可能な影響が生じる可能性があるとは思いません。そうしない理由は、不正なプロセスがあまりにも多くのリソースを消費するのを防ぐためです。
最後に、alancは、pfilesコマンドが特定のプロセスで現在使用されているfdの数を通知するのは正しいことです。ただし、pfilesコマンドは、プロセスを検査するためにプロセスを一時的に停止することに注意してください。 pfilesコマンドがプロセスに対して実行された結果としてプロセスがクラッシュするのを見てきました...しかし、アプリケーションで遭遇することのないコーナーケースであった可能性があることを認めます。申し訳ありませんが、プロセスで使用されているfdの現在の数を調べる安全な方法がわかりません。私の推奨事項：プロセスに対してpfilesコマンドを実行した後も、プロセスがまだ存在することを常に監視してください。