systemd 上で Matrix Synapse の「開いているファイルが多すぎます」という問題を修正する

Matrix Synapse は正常に起動した後、接続を受け付けなくなったり、「開いているファイルが多すぎます」というログが出力されたり、負荷がかかった状態でフリーズしたりすることがあります。systemd 環境では、まず実行中の Synapse プロセスが継承するファイルディスクリプタの制限を確認してください。シェルを変更したりulimit、PAM の制限ファイルを編集したりしても、systemd が起動するサービスの制限は通常変更されません。

以下の手順は、Synapseがsystemdサービスとして実行されているLinuxホストに適用されます。ユニット名はmatrix-synapse.service、、、matrix-synapse@.serviceまたはパッケージ固有の名前になっている場合があります。コマンドをコピーする前に、実際のユニット名を確認してください。SynapseがDocker、Kubernetes、またはその他のコンテナで実行されている場合は、以下の別のセクションを参照してください。

「開いているファイルが多すぎます」とはどういう意味ですか？

Linux では、各プロセスがオープンできるファイルディスクリプタの数に制限が設けられています。ディスクリプタは、ファイル、ソケット、パイプ、その他のリソースを参照できます。そのため、ネットワーク接続もディスクリプタを消費します。プロセスがソフトリミットに達すると、別のディスクリプタを開いたり受け入れたりしようとすると、エラーで失敗することがありますEMFILE。Linux には、システム全体のファイルテーブルにも別の制限があり、そこで不足が発生するとエラーが発生しますENFILE。Synapse サービスの制限を 1 つ引き上げても、システム全体の不足は解消されません。

Synapse の公式管理 FAQ によると、接続数やフェデレーション数が多いと多くのファイル ハンドルが使用され、枯渇するとサーバーが新しい TCP 接続を受け付けなくなる可能性があるとのことです。ガイダンスでは、1,024 や 256 といった古いデフォルト値と比較して、制限値を少なくとも 4,096 に引き上げることを推奨しています。これは、上記のような状況におけるトラブルシューティングの最低限度値として捉えるべきであり、すべてのホームサーバーに共通する容量推奨値ではありません。まずは、実際の制限値と実際の使用状況を確認することから始めてください。

Linuxのgetrlimitとprlimitのドキュメントには、プロセスごとのソフトリミットとハードリミットについて記載されています。Synapseにもsoft_file_limit設定項目があり、Synapseの設定リファレンスにはデフォルト値がゼロと記載されています。これは、Synapseが使用可能なハードリミットにソフトリミットを設定するように指示するものです。

1. ユニットを確認し、故障を診断する

まず、実際のサービス名を確認してください。多くのパッケージインストールでは ですmatrix-synapse.serviceが、インストールでカスタムユニットやワーカーを使用している場合は、その名前を前提としないでください。

systemctl list-units --type=service --all | grep -i synapse
systemctl status matrix-synapse.service --no-pager
journalctl -u matrix-synapse.service --since "30 minutes ago" --no-pager

正確なエラー内容、発生時刻、トラフィックの急増時、フェデレーション活動時、または再起動時に発生したかどうかを確認してください。次に、systemd が現在報告している制限値を調べます。

systemctl show matrix-synapse.service -p LimitNOFILE -p MainPID

LimitNOFILEこれはサービスマネージャに設定されている制限値を表示するものであり、現在開いているディスクリプタの数ではありません。 のようなシェルコマンドは、ulimit -n現在のシェルの制限値のみを報告するものであり、サービスの制限値を証明するものではありません。

2. ドロップインを使用して systemd サービス制限を引き上げます

パッケージの更新時にベンダーユニットファイルを編集する必要がないように、systemd ドロップインを使用してください。以下の値は一例であり、すべてのサーバーにとって理想的な値とは限りません。観測されたピーク使用量よりも余裕のある制限値を選択し、異常に高い値を設定する前に、アプリケーションと依存関係の互換性を確認してください。

sudo systemctl edit matrix-synapse.service

エディターの新しいドロップインに以下を追加してください。

[Service]
LimitNOFILE=65536

保存して終了し、適切なメンテナンス時間内にsystemdを再読み込みしてSynapseを再起動してください。

sudo systemctl daemon-reload
sudo systemctl restart matrix-synapse.service
systemctl show matrix-synapse.service -p LimitNOFILE

systemd では、単一のLimitNOFILE値でサービスのソフトリミットとハードリミットの両方を設定できます。systemd のマニュアルsoft:hardでは、ペアの値も指定できます。ソフトリミットはハードリミットを超えることはできません。非常に高い値を選択する前に、systemd.exec のドキュメントを確認してください。このドキュメントには、1,023 を超えるディスクリプタを持つ古いselect(2)インターフェースを使用するプログラムとの互換性に関する注意点が記載されています。デプロイメント内のすべてのライブラリやプラグインが任意のリミットをサポートしていると想定しないでください。

3. Synapse の設定とワーカー サービスを確認する

Synapseの設定で明示的にsoft_file_limit低い値を設定している場合、アプリケーションの設定によってソフトリミットがsystemdの上限値よりも低く抑えられる可能性があります。アクティブな設定ファイルと含まれている設定ファイルでそのキーを検索してください。不要なオーバーライドを削除するか、意図的に設定してください。ドキュメントに記載されているデフォルト値のゼロは、Synapseにソフトリミットを使用可能なハードリミットまで引き上げるよう指示するものです。

マルチプロセス構成の場合、各ワーカーは個別のプロセスであり、個別のユニットまたはテンプレートインスタンスによって起動される可能性があります。メインサービスの制限値を引き上げても、すべてのワーカーが意図した制限値を持つとは限りません。実際のワーカーユニット名を検査しsystemctl list-units、必要な各サービスに適切なドロップインを適用して検証してください。

同様に、設定ファイル/etc/security/limits.confやログインシェルの設定ulimitは、通常、systemd によって直接起動されるシステムサービスには影響しません。この設定を行うには、ユニットのリソース制限を変更し、systemd が実際に起動したプロセスでその変更を確認してください。

4. Synapseがコンテナ内で実行されている場合

別のサービスに対するホストレベルの systemd オーバーライドは、コンテナのファイルディスクリプタ制限を自動的に変更しません。コンテナのランタイムまたはオーケストレーションレイヤーを設定してください。Docker Compose の場合、サービス定義はコンテナごとにサポートされていますulimits。例は次のとおりです。

services:
  synapse:
    ulimits:
      nofile:
        soft: 65536
        hard: 65536

この数値は例示です。使用状況とホストの制限に基づいてサイズを決定してください。Docker のCompose サービスリファレンスでこのulimits設定について説明しています。Docker Engine 29 以降、Docker のリリース ノートでは containerd 2.1.5 に関連付けられたデフォルトの nofile 制限の変更について説明しています。コンテナは以前のデフォルト値 1,048,576 ではなく 1,024 を受け取る可能性があります。この問題が Engine のアップグレード後に発生した場合は、コンテナの実効制限を確認し、デプロイメント構成で必要な ulimit を明示的に設定してください。Docker Engine 29 のリリース ノートとdocker run リファレンスを参照してください。

5. 実行中のSynapseプロセスの制限を確認する

再起動後、systemdの設定だけでなく、プロセスレベルの制限も確認してください。メインのPIDを取得し、カーネルが報告する制限を調べます。

PID=$(systemctl show --property=MainPID --value matrix-synapse.service)
grep "Max open files" "/proc/$PID/limits"
find "/proc/$PID/fd" -mindepth 1 -maxdepth 1 | wc -l

メインの PID がゼロであるか、Synapse ではなくラッパーに属している場合は、サービスの cgroup 内で Synapse プロセスを特定し、その PID を調べます。ディスクリプタの数はスナップショットです。代表的な負荷がかかったときに再度測定してください。「最大オープンファイル数」が意図したソフトリミットとハードリミットを反映していること、カウントがソフトリミットを十分に下回っていること、ジャーナルにエラーが報告されなくなったことを確認してください。

カウントが新しい上限に達するまで増加し続ける場合、制限は単に障害を先延ばしにしているだけかもしれません。Synapse の FAQ では、ファイルハンドルの枯渇を調査する際に、リクエストが停止したり、処理が遅くなったりすることが関連する可能性があると指摘しています。上限を闇雲に引き上げ続けるのではなく、周囲のログとリクエスト処理を確認し、時間の経過に伴うディスクリプタ数を比較し、メモリリークや予期せず持続する接続の可能性を調査してください。

サービスごとの上限を引き上げるだけでは不十分な場合

ログにシステム全体のファイルテーブル枯渇エラー（例：）が報告された場合はENFILE、ホスト全体の使用状況と他のサービスを調べてください。サービスごとのLimitNOFILE変更では、カーネルのシステム全体の容量は増加しません。エラーを確認し、ホスト全体への影響を理解するまでは、グローバルなカーネル制限を変更しないでください。ドロップイン後もサービスの報告された制限が低いままの場合は、を実行してsystemctl cat matrix-synapse.serviceドロップインがロードされていることを確認し、ユニット名を確認し、systemd をリロードして、正しいユニットを再起動してください。

簡単な自己チェック

• エラーをログに記録している正確なSynapseユニットまたはコンテナを特定できましたか？
• systemctl showそのユニットの想定される制限値を報告しますか？
• /proc/<Synapse-PID>/limits再起動後、意図したソフトリミットとハードリミットが表示されますか？
• 通常のピーク負荷時において、記述子の数はソフトリミットを下回っていますか？
• 該当する場合、作業ユニットとコンテナの設定は個別にチェックされますか？
• エラーは解消されましたか？それとも、使用量は新しい上限に向かって増加し続けていますか？

プロセスレベルのチェックがすべてパスし、代表的なトラフィック処理中にエラーが停止した場合は、systemd の制限値の変更は正しく機能しています。ディスクリプタが蓄積され続ける場合、またはシステムがグローバルな不足を報告する場合は、制限値を大きくするだけで解決するとは考えず、原因の調査を続けてください。

情報源

• Synapse管理に関するFAQ：ファイルハンドルの枯渇
• Synapse設定リファレンス：soft_file_limit
• systemd.exec マニュアル: サービスリソースの制限
• Linuxマニュアル：getrlimitとprlimit
• Docker Engine 29 リリースノート