大容量システムの実用的な最大オープンファイル記述子（ulimit -n）

最近、アプリケーションの負荷テストを開始し、約24時間後にファイル記述子が不足することに気付きました。

Dell 1955でRHEL 5を実行しています。

CPU：デュアルコア2.66GHz 4MB 5150 / 1333FSB x 2 RAM：8GB RAM HDD：160GB 2.5 "SATAハードドライブx 2

ファイル記述子の制限を確認し、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ソケットなどである場合、ソケットバッファおよびその他のカーネルオブジェクト用に大量のメモリを使い果たす危険があります。このメモリはスワップ可能ではありません。

しかし、そうでなければ、いいえ、原則として問題はないはずです。カーネルのドキュメントを参照して、使用するカーネルメモリの量を確認し、テストします。

データベースサーバーは、大きな問題なしで（ほとんどが実際のディスクファイルで）〜10kファイル記述子を開いて実行しますが、64ビットであり、RAMの負荷があります。

ulimit設定はプロセスごとですが、システム全体にも制限があります（デフォルトでは32kと思います）

個人的にベストプラクティスを認識していません。システム機能によって多少主観的です。

表示されている1024はユーザーごとの制限であり、システム全体の制限ではないことに注意してください。このシステムで実行するアプリケーションの数を検討してください。これだけですか？このアプリケーションを実行しているユーザーは他に何かをしていますか？（つまり、このアカウントを使用して、逃げる可能性のあるスクリプトにログインして実行する人間がいますか？）

ボックスがこの1つのアプリケーションのみを実行しており、そのアプリケーションを実行しているアカウントがその目的のみに使用されていることを考えると、制限を増やしても問題はないと思います。社内の開発チームの場合は、意見を求めます。サードパーティベンダーからのものである場合、特定の要件または推奨事項がある場合があります。

これは、「開発環境でテストする」と最もよく答えられる質問の1つです。何年も前に、これを台無しにしたときに太陽が緊張したのを覚えていますが、それほど緊張していません。当時の制限も1024だったので、Linuxで同じになったのを見て驚いたのですが、もっと高いはずです。

あなたの質問への回答をグーグルで検索したとき、次のリンクを見つけました：http : //www.netadmintools.com/art295.html

そしてこれも：https : //stackoverflow.com/questions/1212925/on-linux-set-maximum-open-files-to-unlimited-possible