大容量システムの実用的な最大オープンファイル記述子（ulimit -n）
最近、アプリケーションの負荷テストを開始し、約24時間後にファイル記述子が不足することに気付きました。
Dell 1955でRHEL 5を実行しています。
CPU：2 xデュアルコア2.66GHz 4MB 5150/1333FSB RAM：8GB RAM HDD：2 x 160GB 2.5 "SATAハードドライブ
ファイル記述子の制限を確認したところ、1024に設定されていました。アプリケーションには、約1000の着信接続と1000の発信接続が潜在的に存在する可能性があることを考えると、これはかなり低いようです。開く必要がある実際のファイルは言うまでもありません。
私の最初の考えは、ulimit -nパラメーターを数桁増やしてからテストを再実行することでしたが、この変数を高く設定しすぎると発生する可能性のある影響について知りたかったのです。
私たちのソフトウェアが理論的に開くことができるファイル記述子の数を把握する以外に、これを設定するためのベストプラクティスはありますか？
これらの制限は、複数の「通常の」ユーザー（アプリではない）がサーバーを共有する時代から来たものであり、あまりにも多くのリソースを使用しないように保護する方法が必要でした。
高性能サーバーの場合は非常に低く、通常は非常に高い値に設定します。 （24k程度）より大きな数値が必要な場合は、sysctl file-maxオプションも変更する必要があります（通常、ubuntuでは40k、rhelでは70kに制限されています）。
Ulimitの設定：
# ulimit -n 99999
Sysctl maxファイル：
#sysctl -w fs.file-max=100000
また、非常に重要なことですが、アプリケーションにメモリ/ファイル記述子のリークがあるかどうかを確認する必要がある場合があります。lsofを使用して、開いているすべてを確認し、アプリケーションが有効かどうかを確認します。変更しないでください。アプリケーションのバグを回避するシステム。
あなたはいつでも
cat /proc/sys/fs/file-nr
「高負荷」の状況で、使用されているファイル記述子の数を確認します。
最大に関しては-それはあなたが何をしているかに依存します。
ファイル記述子がtcpソケットなどである場合、ソケットバッファやその他のカーネルオブジェクトに大量のメモリを消費する危険があります。このメモリはスワップ可能ではありません。
しかし、それ以外の場合、原則として問題はありません。カーネルのドキュメントを参照して、カーネルメモリの使用量を調べたり、テストしたりしてください。
私たちはデータベースサーバーを実行し、大きな問題なく（大部分は実際のディスクファイルで）10,000までのファイル記述子を開いていますが、64ビットであり、RAMの負荷があります。
Ulimit設定はプロセスごとですが、システム全体の制限もあります（デフォルトでは32kと思います）。
私は個人的にベストプラクティスを知りません。システムの機能によっては主観的です。
表示される1024はユーザーごとの制限であり、システム全体の制限ではないことに注意してください。このシステムで実行するアプリケーションの数を検討してください。これだけですか？このアプリケーションを実行するユーザーは他に何かをしていますか？ （つまり、このアカウントを使用して、暴走する可能性のあるスクリプトにログインして実行する人間がいますか？）
ボックスがこの1つのアプリケーションのみを実行しており、そのアプリケーションを実行するアカウントがその目的のためだけであるとすれば、提案どおりに制限を増やしても害はありません。社内の開発チームの場合は、意見を求めます。サードパーティベンダーからの場合は、特定の要件や推奨事項がある可能性があります。
これは、「開発環境でテストする」で最もよく答えられる質問の1つに思えます。何年か前に、Sunがこれをいじったときに緊張しましたが、それほど緊張していませんでした。当時の制限も1024だったので、Linuxでも同じであることに少し驚いて、もっと高いはずです。
私はあなたの質問への回答をグーグル検索したときに、次のリンクがわかりました： http://www.netadmintools.com/art295.html
そしてこれも： https://stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible