同時実行コンテナ向けにJellyfinのデータベース接続を最適化する方法
同時稼働するコンテナからの Jellyfin データベースアクセスを最適化するには、まずデータベースの所有者を1つに統一し、そのうえでロック待ち時間、書き込みの集中、ストレージレイテンシ、ワークロードの重なりを測定します。
複数のコンテナが同じ Jellyfin データベースを開いているのでしょうか。それとも、スキャンやユーザー操作中に1つの Jellyfin コンテナが遅くなっているのでしょうか。接続数を闇雲に増やしてはいけません。バックエンドの種類、アクティブな書き込み元、マウント先、バックアップ方法、そして待機が発生している正確な処理を確認してから、バックエンドや接続プールを変更してください。
制限要因がロックかストレージかを確認する
データベースがビジーまたはロックされているというメッセージ、トランザクションの所要時間、I/Oレイテンシ、CPU待機時間、同時に実行されているタスクを記録します。SQLiteは同時読み取りに対応していますが、書き込みは直列化されるため、多数の書き込み元があると、短時間で終わるメタデータ更新でも待ち行列が発生します（SQLiteのロック動作）。
データベースを高速なローカルストレージへ移すのは、制御されたテストとしてのみ行ってください。ストレージレイテンシが低下してもロック待ちが残る場合、問題はディスクだけではなく、書き込み元の重複やデータベース設計にあります。
同じスキャン中に、ロック待ち時間とストレージレイテンシを比較します。データベース自体は高速なのに書き込み元が待機している場合、次に調整すべきなのは接続数ではなく、スケジュールと所有権です。
データベースの所有者を決め、書き込み処理をスケジュールする
対応しているバックエンドとデプロイ構成が明示的に複数インスタンスの調整を提供していない限り、1つのアプリケーションデータベースを所有する Jellyfin インスタンスは1つだけにしてください。スキャン、メタデータ更新、インポート、バックアップ、メンテナンスが同時に開始されないようにします。1つのコンテナIDと1つの永続パスを使用し、再起動によって2つ目のデータベースが作成されないようにしてください。
1回のスキャン、次に1つのユーザーワークロード、その後に通常の同時実行構成を順番に実行して検証します。書き込み元を1つずつ追加した後、ロック待ち時間と完了時間を比較してください。
まず書き込み元を1つにしてテストし、その後、通常の同時実行コンテナ構成を追加します。これにより、書き込み元を追加するたびに待ち行列の時間が増えるのか、それとも問題のない読み取りが増えるだけなのかを確認できます。
別のバックエンドが必要になるタイミングを把握する
複数のアプリケーション書き込み元、大規模な同時アクティビティ、または SQLite では提供できない運用ツールが実際に必要な場合は、PostgreSQL などのより大規模なバックエンドを検討する価値があります。ただし、移行、認証情報、バックアップ、ネットワーク障害、復旧が必要な別サービスも追加されます。あるプロジェクトディスカッションでは、商用規模の同時実行は Jellyfin の通常のホームサーバー向け対象範囲外と説明されているため、家庭用デプロイにエンタープライズ向けの接続数の前提をそのまま適用しないでください（対象範囲を限定した同時実行の議論）。
バックエンドの変更をテストする場合は、元のデータベースとデプロイ定義を利用できる状態に保ち、アプリケーションの状態を変更せずに比較をロールバックできるようにしてください。
同じスキャン中に、ロック待ち時間とストレージレイテンシを比較します。データベース自体は高速なのに書き込み元が待機している場合、次に調整すべきなのは接続数ではなく、スケジュールと所有権です。
選択した構成を検証する
すべてのコンテナを再起動し、元の同時実行ワークロードを実行して、ロック待ち時間、レイテンシ、ユーザー操作、バックアップが許容範囲内に収まっていることを確認します。明確な所有者を1つにし、復元手順をテストした状態でデータベースがワークロードを完了できたら、調整を終了してください。可逆的なスケジュール変更とストレージの確認を行っても、破損、繰り返し発生するロック失敗、サポート対象外の複数インスタンスからの書き込みが残る場合は、エスカレーションしてください。
まず書き込み元を1つにしてテストし、その後、通常の同時実行コンテナ構成を追加します。これにより、書き込み元を追加するたびに待ち行列の時間が増えるのか、それとも問題のない読み取りが増えるだけなのかを確認できます。
バックエンドの変更をテストする場合は、元のデータベースとデプロイ定義を利用できる状態に保ち、アプリケーションの状態を変更せずに比較をロールバックできるようにしてください。
おすすめ商品
サポートとヒント
もっと読む
Jellyfinでジョブやインポートの重複を防ぐ方法
重複作業は通常、スケジューラーの重複や複数の書き込み担当者によって発生します。担当者を1人、経路を1つ、完了確認を1つに決めてください。
データベースボリュームがいっぱいになった後にJellyfinを修復する方法
書き込みを停止し、データベースとWALファイルを保持したまま、状態を無闇に削除せずに空き容量を確保し、その後、整合性と元のワークロードを検証します。
Jellyfinは、見つからないファイルをなぜ間違った所有者で再作成するのですか？
所有者が誤っている場合、通常はユーザーIDの不一致か、異なるインポートパスが原因です。権限を変更する前に、アクティブなコンテナユーザーを確認してください。
