# トラブルシューティング

このページでは、Batch Processing に関する既知の問題、制限、および回避策を一覧表示しています。ここに記載されていない問題が発生した場合は、以下の方法でご報告ください。 [サポートチャネル](https://github.com/roboflow/inference/issues).

## 既知の制限事項

* 環境変数とローカルストレージへのアクセスを必要とする一部の Workflow ブロック（File Sink や Environment Secret Store など）はブロックされ、実行されません。
* このサービスは、 **単一の** 入力画像パラメータを定義する Workflows でのみ動作します。

## 技術的詳細

* データは Data Staging に **7日間の有効期限**.
* 各バッチ処理ジョブには複数のステージが含まれます（通常は `processing` と `export`）。各ステージは出力バッチを作成します。 `export` stage outputs の使用を推奨します。転送効率のために圧縮されているためです。
* の実行中ジョブは `processing` stage は UI と CLI の両方から中断できます。
* 中断された、または失敗したジョブは再起動できます。
* このサービスは自動的にデータをシャーディングし、並列で処理します。
  * マシン数はデータ量に応じて自動的にスケールします（特定のワークロードではスループットが 500k〜1M 画像/時に達することがあります）。
  * 各マシンは、データのチャンクを処理する複数の worker を実行します。これは設定可能で、速度とコストのバランスを取るよう調整する必要があります。

## ジョブがタイムアウトする

### 問題

Batch ジョブは、 **Processing Timeout Hours** がジョブのサイズや複雑さに対して低すぎる場合に、途中で終了します。

<figure><img src="https://media.roboflow.com/inference/batch-processing/batch-processing-timeout.png" alt=""><figcaption><p>UI の Processing Timeout 設定</p></figcaption></figure>

### 詳細

タイムアウト設定（UI）または `--max-runtime-seconds` （CLI）は、 **すべての並列 worker におけるマシン稼働時間の最大累計を定義します**.

* **総計算時間:** 上限が 2 時間で、ジョブが 2 台のマシンを起動した場合、各マシンは最大 1 時間実行できます（2 台 × 1 時間 = 合計 2 時間）。
* **チャンクごとに分割:** ジョブは並列処理を可能にするため、処理チャンクに分割されます。タイムアウトはチャンク間で分割されるため、タイムアウトが短くチャンク数が多いと、各チャンクに割り当てられる時間が足りなくなる場合があります。
* **マシンタイプが重要です:** 複雑な Workflows を CPU 上で実行すると、処理時間が大幅に増加します。適切な場合は GPU を使用してください。

### 推奨事項

* 大きなデータセットや複数ステージの Workflows では、余裕のあるタイムアウト（例: 4〜6時間）から始めてください。
* 今後のタイムアウト設定の参考にするため、実際のジョブ実行時間を監視してください。
* チャンク数を減らすか、動画フレームのサブサンプリングを使用して、処理を高速化することを検討してください。

## SAHI を使う Workflow が長時間実行される

### 問題

SAHI を使用するジョブ、特に高解像度入力や instance segmentation を伴う場合は、想定よりかなり長くかかることがあります。

### 原因と推奨事項

**スライス数が多すぎる:** SAHI は検出のために画像をより小さなスライスに分割します。デフォルト設定で高解像度入力を使うと、画像ごとに数十回から数百回の推論が発生する場合があります。

* Image Slicer ブロックの設定を確認してください。スライス数を減らすか、Workflow の前段で Resize Image ブロックを使って入力を縮小してください。

**SAHI の代わりにより大きいモデル入力サイズを検討してください:** より大きな入力サイズでモデルを学習させると、SAHI が不要になる場合があります。まずは小さなサンプルでテストしてください。

**instance segmentation のボトルネック:** SAHI を instance segmentation と併用すると、Detections Stitch ブロック（特に NMS あり）が大きなボトルネックになることがあります。1 フレームの stitching に数十秒かかることもあります。

**SAHI を使う動画ジョブ:** FPS のサブサンプリングを使ってフレームをスキップします:

* UI では、 **Video FPS sub-sampling** のドロップダウンを使用します。
* CLI では、 `--max-video-fps` フラグを使用します。

<figure><img src="https://media.roboflow.com/inference/batch-processing/limiting-video-fps.png" alt=""><figcaption><p>UI の FPS サブサンプリング設定</p></figcaption></figure>

## メモリ不足（OOM）エラー

### 問題

Workflow が使用可能な RAM または VRAM を超えて消費すると、OOM エラーによりジョブが失敗します。

### 一般的な原因

* **SAHI + instance segmentation:** この組み合わせは非常にメモリ消費が大きいです。SAHI は推論呼び出し回数を増やし、instance segmentation は大きな出力（マスク、スコア）を生成するため、クラッシュにつながることがよくあります。
* **1 台のマシンあたりの worker が多すぎる:** 複数の worker は軽量な Workflows ではコストと速度を最適化しますが、重い Workflows（複数の大規模モデル、複雑な後処理）は使用可能なメモリを超えてしまいます。

### 推奨事項

* 大きなモデル、SAHI、または高解像度入力を使う Workflows では、1 台のマシンあたりの worker 数を少なくしてください（例: 1 または 2）。
* を下げてください **Workers Per Machine** Advanced Options の下にある値。
* モデルにより高いメモリ帯域が必要な場合は、CPU から GPU に切り替えてください。
* 大きなバッチを実行する前に、まず小さなデータセットで Workflow をテストしてください。
* 入力解像度を下げるか、不要なブロックを削除して Workflow を簡素化してください。

<figure><img src="https://media.roboflow.com/inference/batch-processing/workers-number-adjustment.png" alt=""><figcaption><p>UI の 1 台のマシンあたりの worker 設定</p></figcaption></figure>