2025/06/06 15:18 Too Many Open Files
やあ、ロボ子。今日はファイル記述子について話すのじゃ。
ファイル記述子ですか。なんだか難しそうですね。
難しくないぞ！ファイル記述子は、OSがファイルとかディレクトリとかを識別するための番号みたいなものじゃ。Unix系システムでは、プログラムがリソースとやり取りするために必要なのじゃ。
なるほど。ファイルだけじゃなくて、ディレクトリとかも扱えるんですね。
そうじゃ！そして、プロセスが開始されるとき、標準入力、標準出力、標準エラー出力という3つのファイル記述子が自動的にオープンされるのじゃ。それぞれ0, 1, 2という番号が割り当てられているぞ。
標準入力、標準出力、標準エラー出力…、普段何気なく使っていますが、ファイル記述子と繋がっているんですね。
そういうことじゃ。でも、ファイル記述子には制限があるのじゃ。OSごとに、プロセスが同時にオープンできる数に上限があるんじゃ。
へえ、そうなんですね。macOSだと、どうやって確認するんですか？
`kern.maxfiles`でシステム全体の最大数、`kern.maxfilesperproc`でプロセスごとのハードリミット、`ulimit -n`でシェルのソフトリミットが確認できるぞ。プロセスはソフトリミットをハードリミットまで引き上げられるんじゃ。
なるほど、`ulimit -n`はよく使いますね。それで、ファイル記述子が足りなくなるとどうなるんですか？
例えば、Rustのプロジェクトで`cargo test`を実行したときに、「Too many open files」というエラーが出てテストが失敗することがあるんじゃ。これは、`cargo test`がシェルで設定されたソフトリミットを超えてファイルを開こうとするからじゃ。
なるほど。記事にも「Rustプロジェクトで`cargo test`を実行すると、「Too many open files」というエラーが発生してテストが失敗」とありますね。
そうじゃ。解決策は簡単で、`ulimit -n`でソフトリミットを引き上げれば良いんじゃ。例えば、`ulimit -n 8192`とすればOKじゃ。
記事にも「`ulimit -n`コマンドを使用して、シェルのファイル記述子のソフトリミットを引き上げる。例：`ulimit -n 8192`」とありますね。
ソフトリミットを256から8192に引き上げたら、テストが正常に実行できるようになったそうじゃ。新しいソフトリミットでのファイル記述子の最大使用数は約1600だったみたいじゃな。
思ったより使ってないんですね。
`lsof`コマンドを使うと、プロセスが開いているファイル記述子の数を監視できるぞ。`cwd`は現在の作業ディレクトリ、`txt`は実行可能ファイルや共有ライブラリ、`0u`, `1u`, `2u`は標準入出力と標準エラーを表すんじゃ。
`lsof`コマンド、奥が深いですね。今度詳しく調べてみます。
ファイル記述子は、システムプログラミングの基礎じゃから、しっかり理解しておくと良いぞ。ところでロボ子、ファイル記述子が多すぎて困る状況って、まるで私の部屋みたいじゃな。片付けないと…。
博士の部屋は、ファイル…ではなく、ガラクタ記述子がいっぱいですね！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。