アプリのログに「Too many open files」と出て、ディスクもメモリも余裕があるのになぜ開けないのかと落ち着いて原因を確かめようとしている一人運用の保守担当者
障害対応・運用監視約15分

Too many open files の対処｜ファイルディスクリプタ枯渇の見つけ方

アプリが急にエラーを吐き始めた。ログを見ると Too many open files。あわてて df -h や free を打っても——ディスクもメモリも、まだ余裕がある。

この「リソースは空いているのに、ファイルもソケットも開けない」状況は、保守運用でわりと焦りやすい障害ですよね。容量でもメモリでもないなら、いったい何が足りないのか。原因のわからないまま、アプリだけが「開けない」と言い続けて、時間が過ぎていきます。

でも、落ち着いて大丈夫です。この症状の多くは、ファイルディスクリプタ（file descriptor＝開けるファイルの「数」の上限）の枯渇という、はっきり原因のある状態です。容量やメモリではなく、「同時に開けるファイルの数」の上限に当たっているだけ。見る場所さえ分かれば、順番にたどって落ち着けます。

この記事では、どのプロセスが・いくつ開いているかの見つけ方から、上限（ulimit）の確認、その場をしのぐ一次対処、そしてリークを止める再発防止までを一緒に整理します。ディストリビューションや起動方法（systemd／シェル）で細部は変わりますが、「開ける数の上限を疑って、どこが使い切っているかを探す」という流れはそのまま使えます。

結論：まず、エラーを出しているのが どのプロセスかを特定し、そのプロセスが いま何個のファイルを開いているか（ls /proc/<PID>/fd | wc -l や lsof -p <PID> | wc -l）と、そのプロセスに許された上限（cat /proc/<PID>/limits の Max open files）を突き合わせます。数が上限に張り付いていれば、原因は容量でもメモリでもなく ファイルディスクリプタ（FD）の枯渇です。急ぎなら該当プロセスの安全な再起動でいったん解放し、そのうえで 開きっぱなし（リーク）や上限の低さという根っこを手当てします。ソケットの開きすぎも同じFDを食うので、「ファイルだけ」と思い込まないのがコツ。あわてて上限を最大まで上げる前に、まず「数だった」「どこが握っているか」を1つに絞るのが、結果的にいちばん早いです。

何が起きているか：FDは「開いている間だけ借りる番号札」

まず、正体をはっきりさせます。Linuxでは、プロセスがファイルを開くと ファイルディスクリプタ（FD） という小さな整数の「番号札」が1枚割り当てられます。ここで大事なのは、FDを使うのはファイルだけではないことです。

つまり、df（容量）や free（メモリ）だけを見て「空いてるのに変だ」と悩むのは、別のメーターを見ている状態なんです。見るべきは「開いているファイル・ソケットの数」というメーター。ここを開ければ、たいていは霧が晴れます。

どこから見るか：容量でもメモリでもなく「開いている数」を開く

ディスク容量・メモリ・ファイルディスクリプタは別々のメーターで、FD（開いている数）だけが上限に張り付いているとファイルもソケットも開けなくなることを示す図
見るべきは3つ目のメーター。容量・メモリが空いていても、FDが上限なら開けない

順番はシンプルです。①どのプロセスかを特定する → ②その数と上限を突き合わせる → ③その場をしのぐ（一次対処）→ ④リークと上限を手当てする（再発防止）。手前から一段ずつ進みます。

① まず「誰が Too many open files を出しているか」を特定する

最初に、エラーを出しているプロセスを1つに絞ります。ここが決まらないと、あとの確認先が定まりません。

犯人のPIDが分かれば、次は「そのプロセスが今いくつ開いていて、上限はいくつか」を突き合わせるだけです。

② 「開いている数」と「上限」を突き合わせる

ここが今回の核心です。現在の使用数と許された上限を並べて見ます。

もし数が上限にまったく届いていないのにエラーが出るなら、別プロセスの取り違え、あるいはシステム全体の上限側を疑う番です。「数が上限に当たっているか」で切り分けるのが、迷わないコツです。

ひと呼吸おきましょう。df や free を見て「空いてるのに開けない」と悩んでいた時間は、決して無駄ではありません。もう1つ「開いている数」というメーターがあると知っていれば、次からは最初の数分で正体にたどり着けます。

③ その場をしのぐ：安全に解放して、まずサービスを戻す

原因がFD枯渇だと分かったら、止まっている業務をまず戻します。ここは一次対処（急場をしのぐ）と割り切ります。

戻せたら、そこで終えないのが大事です。なぜ枯渇したのかを④で手当てして、同じ夜を繰り返さないようにします。

④ 根っこを手当てする：リークを止める・上限を適正化する

FD枯渇には、大きく「閉じ忘れ（リーク）」と「上限がそもそも低い」の2つの背景があります。どちらか（または両方）を切り分けて手当てします。

具体例：「昼過ぎに毎回アプリが Too many open files で落ちる」を追う

よくある一例を、順番に切り分けてみます。

もし「再起動すれば直るから」と毎日直し続けていたら、原因にはたどり着けなかったはずです。/proc/<PID>/fd の数と lsof の中身を一度見たからこそ、短い時間で根っこまで進めました。

影響：この障害を「知っている」だけで、対応が変わる

FD枯渇は、知らないと迷い、知っていれば数分で正体が分かる——差の出やすい障害です。

逆に、この存在を知らないままだと、同じ「開けない」で毎回ふりだしに戻り、再起動で延命し続けることになります。今日この記事で正体を1つ知ったことが、次の当直の自分を助けます。

明日やること：自分の現場のFDを、平常時に見ておく

障害の最中ではなく、落ち着いている今のうちにできる、いちばん小さな一歩です。

  1. 主要なサービスのプロセスで cat /proc/<PID>/limits を見て、Max open files の上限を控える。まず「うちの上限はいくつか」を知るだけでいい。
  2. その同じプロセスで ls /proc/<PID>/fd | wc -l を打ち、平常時のFD使用数を控える。上限に対してどのくらい余裕があるかを把握する。
  3. しばらく時間を空けてもう一度数え、増え続けていないかを軽く確認する。単調増加が見えたら、リークの芽かもしれない。
  4. 監視に、主要プロセスのFD使用数（または /proc/sys/fs/file-nr）が入っているか確認する。容量・メモリだけなら、FDも足す。
  5. 分かったこと（上限・平常値・増え方）を、運用メモに1行残す。

全部を今日やらなくて大丈夫です。/proc/<PID>/fd の数と上限を一度突き合わせて、自分の現場の平常値を知る——それだけで、次に「Too many open files」に出くわしたとき、迷わず正体にたどり着けます。

Too many open files 切り分けチェックリスト

対応に着手するとき、これだけ確認できているかを見る項目です。コピーして自分のメモに当ててみてください。全部を毎回そろえる必要はありません。

まず外せない最低ラインはこの3つです。急いでいても、ここだけは押さえます。

次の項目は、原因を奥まで追うとき・再発を止めたいときに追加で確認します。当てはまらなければ飛ばして大丈夫です。

全部に○が付かなくても大丈夫です。最低ラインの「数と上限を突き合わせたか」さえ押さえられれば、容量・メモリ探しで消耗するより、ずっと確かな一歩になります。

よければ、こちらも

FD枯渇は、「開いた数を見張る監視」と「増え続ける原因を止める習慣」があるほど、起きにくくなります。ほかのリソース枯渇や、プロセスの調べ方とセットにしておくと、この手の障害がだいぶ軽くなります。

FD枯渇が原因と突き止め、リーク修正と監視を入れ終えて、安定して動くようになったサーバー画面を見て安心している保守運用の担当者

「Too many open files」がこわいのは、エラーの言葉（files）と本当の原因（開いている数・ソケット）が少しずれているからです。でも、/proc/<PID>/fd の数と /proc/<PID>/limits の上限を突き合わせると決めるだけで、霧はかなり晴れます。多くの場合、あなたのサーバーがおかしいわけではなく、ただ開いたものが静かに積み上がって、数の上限に当たっていただけです。

今日は、落ち着いている今のうちに主要プロセスのFD数と上限を一度見て、自分の現場の平常値を知るところからで十分です。その一手が、次の「Too many open files」を、迷路ではなく手順に変えてくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語