【Linux】ファイルディスクリプタとは？上限の変更方法を解説！

Amazonのアソシエイトとして、ITナレッジライフは適格販売により収入を得ています。

記事の文字数：4,600 ／総アクセス数：641 views

Linuxシステムにおいて「ファイルディスクリプタの上限」は、高負荷アプリケーションや大量の同時接続を扱うサービスのパフォーマンスに大きく影響します。本記事では、/etc/security/limits.conf での基本的な設定から、systemd を利用した永続的な上限変更方法まで、実践的かつ分かりやすく解説しています。

2025/6/14 2025/6/14 更新

LinuxやUnix系統の環境でサーバやアプリケーションを運用する際、ファイルディスクリプタ (FD：File Descriptor) の上限に抵触することが問題となることがあります。特に大量の同時接続を扱うサーバアプリケーションでは、デフォルトの上限では足りないケースが多く見られます。本記事では、ファイルディスクリプタの基本から、上限の確認方法、具体的な変更手順、そして運用時の注意点まで、詳細に解説します。

ファイルディスクリプタはリソースにアクセスする識別子

🎯 基本概念

プロセス
(PID: 1234)

→

FDテーブル

stdin (標準入力)

stdout (標準出力)

stderr (エラー出力)

ファイル.txt

ソケット

整数値でI/Oリソースを識別する仕組み

ファイルディスクリプタ (FD) は、プロセスがファイルやソケット、パイプ、デバイスなどのリソースにアクセスする際に使用する識別子です。ファイルディスクリプタは、整数値で管理され、オペレーティングシステムがリソースを効率的に制御するための仕組みの一つです。プロセスごとに管理され、プロセスが開くことのできるファイルやソケットの数に上限があります。

標準ファイルディスクリプタシステムは、プログラムが起動する際に自動的に3つのファイルディスクリプタを開き、特定の番号を割り当てます。

0: 標準入力（stdin）- キーボードからの入力など。
1: 標準出力（stdout）- 画面への出力など。
2: 標準エラー出力（stderr）- エラーメッセージの出力など。

これらは固定されており、プログラムが新しくファイルを開く際には「3」以降の未使用の整数値が順番に割り当てられます。

FDの上限に達すると、Too many open filesというエラーが発生し、アプリケーションが新たな接続を受け付けられなくなったり、ログファイルの書き込みに失敗したりと、深刻なトラブルを引き起こすことがあります。

Too many open files エラーとは

❌ "Too many open files" エラー

FD上限を超えると発生する深刻なエラー

🚫 新しいネットワーク接続が確立できない
📝 ファイルの読み書きが失敗
📋 ログ記録が停止
💥 アプリケーションが異常終了

Too many open files は、プロセスがオープンできるファイルディスクリプタ数の上限を超えた場合に発生する代表的なエラーです。このエラーが発生すると、以下のような具体的な問題が生じます。

新しいネットワーク接続が確立できなくなる。
ファイルの書き込みや読み込み処理が失敗する。
ログ記録やファイルオープン操作がすべて停止する。
アプリケーションやシステムサービスが異常終了することがある。

FD上限の確認方法

🔍 現在の上限確認

現在のFD上限

ulimit -n

→ 現在のセッションの上限値を表示

システム全体の上限

cat /proc/sys/fs/file-max

→ システム全体の最大値を表示

ファイルディスクリプタの上限は一時的に変更することも、永続的に変更することも可能です。それぞれの方法について詳しく解説します。

現在のログインユーザのFD上限確認方法（ulimit）

ファイルディスクリプタの現在の上限は、ulimit コマンドを使って簡単に確認できます。以下のコマンドを実行してください。

1
ulimit -n

このコマンドにより、現在のセッションで許可されている最大ファイルディスクリプタ数が表示されます。例えば、次のような結果が返されます。

1
1024

これは、このシェル内で開くことができるファイルやソケットの上限が1024であることを示しています。多くのLinuxディストリビューションでは、この値がデフォルト設定になっている場合がありますが、大量の接続を処理する場合は、これでは不十分です。

特定プロセスのFD上限を確認する

cat /proc/{プロセスID}/limits コマンドを使用します。
まず、目的のプロセスのプロセスID (PID) を特定する必要があります。例えば、Java プロセスの場合は ps -eaf | grep java で PID を特定できます。
このコマンドの出力には「Max open files」という項目があり、そのプロセスのソフトリミット（通常の動作時に適用される上限）とハードリミット（絶対的な上限）が表示されます。

現在のファイルディスクリプタ上限の確認方法

現在のシステム全体のファイルディスクリプタ上限は、以下のコマンドで確認できます。

1
cat /proc/sys/fs/file-max

FD上限の変更方法

📁 主要な設定ファイル

limits.conf

ユーザー単位の制限

/etc/security/limits.conf

system.conf

systemdサービス制限

/etc/systemd/system.conf

sysctl.conf

システム全体制限

/etc/sysctl.conf

一時的に上限を変更（ulimit）

一時的に上限を引き上げるには、以下のコマンドを現在のターミナルで実行します。

1
ulimit -n 65535

この設定は、現在のターミナルセッション内でのみ有効です。ターミナルを閉じたり、サーバを再起動した場合には元の値に戻ってしまいます。開発環境や一時的な検証にはこの方法が便利ですが、本番環境での恒久的な運用には適していません。

永続的に上限を変更（/etc/security/limits.conf）

ファイルディスクリプタの上限を恒久的に変更する場合は、いくつかの設定ファイルを編集する必要があります。以下は代表的な設定箇所です。

/etc/security/limits.conf は、PAM認証モジュールの一つである pam_limits の設定ファイルです。このファイルに設定を記述することで、ユーザーごとの永続的なファイルディスクリプタ数の変更が可能になります。

例えば次のように追記してください。

1
* soft nofile 65535
2
* hard nofile 65535

設定内容の説明

*：全ユーザーが対象です。特定のユーザーにだけ適用したい場合は、ここにユーザー名を指定してください。
soft nofile：ソフトリミット（通常の動作時に適用される上限）。一般ユーザーが変更可能です。
hard nofile：ハードリミット（絶対的な上限）。rootユーザーのみが変更できます。

✅ 反映方法：マシンを再起動するか、対象ユーザーでログアウト・再ログインすると設定が有効になります。

PAM認証経由でのみ有効

limits.confの設定は PAM（Pluggable Authentication Module）認証を経由して起動されるプロセスにのみ適用されます。 PAM認証とは、システムへのログインやプログラムの実行などの際に使用される認証モジュールの一つです。

✅ 有効：SSHログイン、sudo経由で起動したプロセス
❌ 無効：OS起動時に systemd から直接立ち上がるデーモン（例：nginx、Apache など）

limits.conf を変更後、手動で sudo systemctl restart nginx などを実行すると、一時的に上限が反映されることがあります。これは、sudo 実行時に PAM 認証が適用されるためです。しかし注意点としてOS を再起動すると、systemd が直接サービスを起動するため、PAM が介在せず、上限がリセットされてしまいます。

永続的に上限を変更（systemd）

systemd を使用してファイルディスクリプタの上限を設定する方法には、サービスごとまたは全体の2つのアプローチがあります。これらは、PAM 認証を介さないデーモン系のプロセスに対してファイルディスクリプタ上限を設定するのに適切な方法です。

サービスごとに `LimitNOFILE` を設定する（推奨）

特定のデーモンプロセス単位で上限を設定する方法です。
一般的に最も安全で適切な設定方法です。

設定手順は以下の通りです。

対象サービスのユニットファイルを編集
例：nginx の場合
/etc/systemd/system/multi-user.target.wants/nginx.service など
以下を [Service] セクションに追記
```
1
LimitNOFILE=60000
```

設定の反映

1
sudo systemctl daemon-reload
2
sudo systemctl restart <サービス名>  # 例: sudo systemctl restart nginx

設定確認
実行コマンド
```
1
cat /proc/<PID>/limits | grep "Max open files"
```
→ ファイルディスクリプタ上限が正しく変更されていることを確認できます。

systemd全体のデフォルト値を変更する

systemd が起動するすべてのサービスに対して、共通のデフォルト上限を設定する方法です。
よほど特別な理由がない限り、サービス単位での設定のほうが推奨されます。

/etc/systemd/system.conf を編集
実行コマンド
```
1
sudo vi /etc/systemd/system.conf
```
以下の設定を有効化（コメントアウトを解除）
```
1
DefaultLimitNOFILE=60000:524288
```
- softLimit:hardLimit の形式で記述します。
必要に応じて /etc/systemd/user.conf も同様に設定
（ユーザーユニットを使用している場合）

設定の反映

1
sudo systemctl daemon-reload
2
sudo systemctl restart <サービス名>  # またはOS再起動

設定確認

1
cat /proc/<PID>/limits | grep "Max open files"

この方法は、すべてのサービスに影響するため、不要に上限を緩めすぎるとリソースを消費しすぎるリスクがあります。
原則として、個別のサービスに必要な分だけ設定する方が安全です。

systemdのFD設定まとめ

方法	適用範囲	推奨度
サービスごとの `LimitNOFILE` 設定	特定のデーモンプロセス	★★★（推奨）
systemd全体のデフォルト設定	全サービス	★☆☆（慎重に）

永続的にシステム全体の上限を変更（/etc/sysctl.confの設定）

ファイルディスクリプタのシステム全体のハードリミットは、/etc/sysctl.conf で以下のように設定することもできます。

1
fs.file-max = 2097152

この設定は、システム全体で同時に開くことができるファイルディスクリプタの最大数を指定するものです。変更後は、以下のコマンドで即時反映が可能です。

1
sudo sysctl -p

FD上限変更時の注意点・デメリット

⚠️ メリット・デメリット

👍 メリット

大量の同時接続が可能
サーバの処理能力向上
エラー発生の防止
サービス安定性の確保

👎 デメリット

カーネルリソース圧迫
メモリ消費量増加
デバッグ難易度上昇
ログ量の増加

FD上限変更時の注意点

ファイルディスクリプタの上限を引き上げる際には、以下の点に注意が必要です。ファイルディスクリプタの上限をむやみに引き上げることは、場合によってはシステム全体のパフォーマンスや安定性に悪影響を与えることがあります。以下の点に注意しましょう。

必要最小限の値を設定すること。
大規模変更の前には、必ずシステム設定ファイルのバックアップを取ること。
サービスごとに適切なリミットが設定されているか確認すること。
systemd 経由で起動するサービスには、個別の Unit ファイルに LimitNOFILE を設定するとより確実です。

FD上限変更時のデメリット

ファイルディスクリプタの上限を引き上げることは便利ですが、いくつかのデメリットも存在します。これらを理解した上で、慎重に設定を行うことが重要です。

カーネルリソースの圧迫: ファイルディスクリプタはカーネルがメモリ内で管理しているリソースの一つです。上限を極端に増やすと、カーネルの管理テーブルが大きくなり、メモリの消費が増加します。特に大量のファイルディスクリプタが同時に使用される場合、パフォーマンスに影響を与えることがあります。
スケーラビリティの限界: 上限を上げても、アプリケーション自体が適切に大量の接続を処理できる設計になっていない場合、アプリケーション側でボトルネックが発生する可能性があります。単純に上限を増やすだけでは、真のスケーラビリティは確保できないことに注意しましょう。
デバッグの難易度上昇: 上限が高い環境では、リソースリーク（ファイルディスクリプタを閉じ忘れるバグ）が表面化しにくくなり、問題の早期発見が困難になることがあります。潜在的な不具合の発見を遅らせるリスクがあります。
ログや監視設定の見直しが必要: 大量の同時接続やファイルアクセスが可能になるため、ログ出力の量が増えることがあります。これにより、ディスク容量やログローテーションの設計も見直す必要が生じる可能性があります。

上記のように、ファイルディスクリプタの上限を上げることには利点だけでなく、運用上の課題やシステム設計への影響もあるため、総合的な視点で検討することが重要です。