Linuxサーバーで突然アプリケーションが不安定になったり、 「ファイルが開けない」「接続できない」といったエラーが多発する場合、 ファイルディスクリプタ（FD）枯渇が原因であることが少なくありません。
本記事では、ファイルディスクリプタ枯渇時に現れる典型的な症状、 即座に行うべき確認手順、 そして恒久対策まで含めた実務的な対処方法を解説します。
ファイルディスクリプタとは
ファイルディスクリプタとは、 Linuxにおいてプロセスがファイルやソケットを扱うための識別子です。
以下はすべてファイルディスクリプタを消費します。
- 通常のファイル
- ログファイル
- TCP / UDP ソケット
- パイプ
つまりネットワークアプリケーションほどFDを大量消費します。
ファイルディスクリプタ枯渇時の典型的な症状
① アプリケーションエラーが多発する
Too many open files
EMFILE (Too many open files)Java、nginx、Apache、DBなど多くのミドルウェアで見られる代表的なエラーです。
② 新規接続ができない
- Webアクセスが急に通らなくなる
- DB接続が張れない
- SSH接続が失敗する
既存接続は生きているが、新規接続だけ失敗する場合は要注意です。
③ ログが出力されなくなる
ログファイルを開けなくなり、 障害が起きているのにログが増えないという状態になります。
④ systemd サービスが起動しない
Failed to open file descriptor
Resource temporarily unavailableFD不足によりサービス起動自体が失敗するケースもあります。
現在のファイルディスクリプタ使用状況を確認する
システム全体の上限
cat /proc/sys/fs/file-maxシステム全体で使用可能なFDの最大数です。
現在の使用数
cat /proc/sys/fs/file-nr出力例：
12345 0 200000- 使用中FD数
- 未使用（通常0）
- 最大値
プロセスごとのFD使用数
ls /proc/<PID>/fd | wc -lFDを異常に消費しているプロセスを特定できます。
ulimit による制限を確認する
現在の制限値
ulimit -nこれは1プロセスあたりのFD上限です。
よくある問題例
- システム全体は余裕がある
- プロセスの ulimit が低すぎる
この場合、特定アプリだけがFD枯渇を起こします。
一時的な対処（緊急対応）
① 不要なプロセス・接続を減らす
- アプリケーション再起動
- 異常な接続元の遮断
※ 根本解決ではありませんが、サービス復旧を最優先します。
② ulimit を一時的に引き上げる
ulimit -n 65535※ セッション単位なので再ログインで戻ります。
恒久対策①：ulimit の設定変更
/etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535systemd管理サービスの場合は次も重要です。
systemd の制限確認
systemctl show <service> | grep LimitNOFILE設定例：
[Service]
LimitNOFILE=65535恒久対策②：アプリケーション側の問題を疑う
FDリークの典型パターン
- ソケットをcloseしていない
- ファイルを開きっぱなし
- 例外処理でclose漏れ
時間経過とともにFDが増え続ける場合はほぼFDリークです。
lsofで調査
lsof -p <PID>どのファイル・ソケットが大量に開かれているか確認します。
よくある勘違い
- メモリが足りない → ×
- ディスクがいっぱい → ×
FD枯渇はリソース不足でもディスク不足でもありません。 独立した制限です。
設計・運用時のベストプラクティス
- 高負荷サーバーは初期から nofile を引き上げる
- systemd の LimitNOFILE を必ず明示
- FD使用数を監視項目に入れる
- 接続数が多いアプリは定期的に lsof で確認
まとめ
ファイルディスクリプタ枯渇は、 事前に知っていれば確実に防げる障害です。
「突然つながらない」「ログが出ない」といった症状が出たら、 まずFDを疑うことが重要です。
正しい制限設定と監視で、 FD枯渇は“事故”ではなく“管理可能な事象”になります。
