# Troubleshooting

यह पृष्ठ Batch Processing के लिए ज्ञात समस्याएँ, सीमाएँ, और workarounds सूचीबद्ध करता है। यदि आपको यहाँ सूचीबद्ध नहीं की गई कोई समस्या मिलती है, तो कृपया इसे हमारे [support channels](https://github.com/roboflow/inference/issues).

## ज्ञात सीमाएँ

* environment variables और local storage तक पहुँच की आवश्यकता वाले कुछ Workflow blocks (जैसे File Sink और Environment Secret Store) ब्लॉक कर दिए जाते हैं और निष्पादित नहीं होंगे।
* यह सेवा केवल उन Workflows के साथ काम करती है जो एक **single** input image parameter परिभाषित करते हैं।

## तकनीकी विवरण

* Data को Data Staging में एक **7-day expiry**.
* के साथ संग्रहीत किया जाता है। प्रत्येक batch processing job में कई stages होती हैं (आमतौर पर `processing` और `export`)। प्रत्येक stage एक output batch बनाती है। हम `export` stage outputs
* में चल रहे job को `processing` stage का उपयोग करने की अनुशंसा करते हैं, क्योंकि वे कुशल transfer के लिए compressed होते हैं। UI और CLI दोनों का उपयोग करके
* रद्द (abort) किए गए या विफल job को पुनः प्रारंभ किया जा सकता है।
* यह सेवा स्वचालित रूप से data को shard करती है और उसे parallel में process करती है:
  * machines की संख्या data volume के आधार पर स्वचालित रूप से scale होती है (कुछ workloads के लिए throughput 500k–1M images/hour तक पहुँच सकता है)।
  * प्रत्येक machine data chunks को process करने वाले multiple workers चलाती है। यह configurable है और speed तथा cost के बीच संतुलन के लिए tune किया जाना चाहिए।

## Job का समय समाप्त हो गया

### समस्या

Batch jobs समय से पहले समाप्त हो जाते हैं यदि **Processing Timeout Hours** job के size या complexity की तुलना में बहुत कम सेट किया गया हो।

<figure><img src="https://media.roboflow.com/inference/batch-processing/batch-processing-timeout.png" alt=""><figcaption><p>UI में Processing Timeout setting</p></figcaption></figure>

### विवरण

timeout setting (UI) या `--max-runtime-seconds` (CLI) परिभाषित करता है **सभी parallel workers में अधिकतम संचयी machine runtime**.

* **कुल compute time:** यदि सीमा 2 घंटे है और job 2 machines शुरू करती है, तो प्रत्येक अधिकतम 1 घंटे तक चल सकती है (2 machines x 1 hour = 2 hours total)।
* **प्रति chunk विभाजित:** Parallelism सक्षम करने के लिए jobs को processing chunks में विभाजित किया जाता है। Timeout chunks में विभाजित होता है — कई chunks के साथ छोटा timeout प्रति chunk बहुत कम समय छोड़ सकता है।
* **Machine का type मायने रखता है:** CPU पर complex Workflows चलाने से processing time काफी बढ़ जाता है। जहाँ उपयुक्त हो, GPU का उपयोग करें।

### सिफारिशें

* बड़े datasets या multi-stage Workflows के लिए एक उदार timeout (जैसे 4–6 घंटे) से शुरुआत करें।
* भविष्य की timeout settings को सूचित करने के लिए job के वास्तविक runtimes की निगरानी करें।
* तेज़ processing के लिए chunk count कम करने या video frame sub-sampling का उपयोग करने पर विचार करें।

## SAHI वाला Workflow बहुत लंबा चलता है

### समस्या

SAHI का उपयोग करने वाले jobs — विशेष रूप से high-resolution inputs और instance segmentation के साथ — अपेक्षा से कहीं अधिक समय ले सकते हैं।

### कारण और सिफारिशें

**slices की अत्यधिक संख्या:** SAHI detection के लिए images को छोटे slices में विभाजित करता है। डिफ़ॉल्ट settings और high-resolution inputs के साथ, इसका अर्थ प्रति image दर्जनों या सैकड़ों inferences हो सकता है।

* Image Slicer block configuration जाँचें। Workflow में पहले एक Resize Image block का उपयोग करके slices कम करें या inputs का आकार घटाएँ।

**SAHI के बजाय बड़ा model input size विचार करें:** बड़े input dimensions के साथ model train करने से SAHI की आवश्यकता पूरी तरह समाप्त हो सकती है। पहले छोटे sample पर test करें।

**Instance segmentation bottleneck:** जब SAHI का उपयोग instance segmentation के साथ किया जाता है, तो Detections Stitch block (विशेषकर NMS के साथ) एक प्रमुख bottleneck बन सकता है — एक single frame को stitch करने में दसियों सेकंड लग सकते हैं।

**SAHI वाले video jobs:** frames को छोड़ने के लिए FPS sub-sampling का उपयोग करें:

* UI में, उपयोग करें **Video FPS sub-sampling** dropdown.
* CLI में, उपयोग करें `--max-video-fps` flag का उपयोग करें।

<figure><img src="https://media.roboflow.com/inference/batch-processing/limiting-video-fps.png" alt=""><figcaption><p>UI में FPS sub-sampling setting</p></figcaption></figure>

## Out of Memory (OOM) Errors

### समस्या

जब Workflow उपलब्ध RAM या VRAM से अधिक memory उपयोग करता है, तो jobs OOM errors के कारण विफल हो जाते हैं।

### सामान्य कारण

* **SAHI + Instance Segmentation:** यह संयोजन अत्यधिक memory-intensive है। SAHI inference calls को गुणा करता है, और instance segmentation बड़े outputs (masks, scores) उत्पन्न करता है, जिससे अक्सर crashes हो जाते हैं।
* **प्रति machine बहुत अधिक workers:** Multiple workers हल्के Workflows के लिए cost और speed को optimize करते हैं, लेकिन भारी Workflows (multiple large models, complex post-processing) उपलब्ध memory से अधिक हो जाएंगे।

### सिफारिशें

* Large models, SAHI, या high-resolution inputs वाले Workflows के लिए प्रति machine कम workers (जैसे 1 या 2) का उपयोग करें।
* कम करें **Workers Per Machine** मान को Advanced Options के अंतर्गत।
* यदि आपके model को अधिक memory throughput की आवश्यकता है, तो CPU से GPU पर स्विच करें।
* बड़े batches चलाने से पहले अपने Workflow को छोटे dataset पर test करें।
* input resolution कम करें या अनावश्यक blocks हटाकर Workflow को सरल बनाएं।

<figure><img src="https://media.roboflow.com/inference/batch-processing/workers-number-adjustment.png" alt=""><figcaption><p>UI में workers per machine setting</p></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.roboflow.com/roboflow/roboflow-hi/deploy/batch-processing/troubleshooting.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.