> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/deployment/hi/roboflow-cloud/batch-processing/troubleshooting.md).

# समस्या निवारण

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

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

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

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

* डेटा Data Staging में एक **7 दिनों की समाप्ति**.
* प्रत्येक batch processing job में कई stages होती हैं (आमतौर पर `processing` और `export`). प्रत्येक stage एक output batch बनाती है। हम `export` stage outputs का उपयोग करने की सलाह देते हैं, क्योंकि वे कुशल ट्रांसफर के लिए संकुचित होते हैं।
* में चल रहा job `processing` stage को UI और CLI दोनों से निरस्त किया जा सकता है।
* एक निरस्त या विफल job को पुनः प्रारंभ किया जा सकता है।
* सेवा स्वतः डेटा को shard करती है और इसे समानांतर में संसाधित करती है:
  * मशीनों की संख्या डेटा मात्रा के आधार पर स्वतः स्केल होती है (कुछ workloads के लिए throughput 500k–1M images/hour तक पहुँच सकता है)।
  * प्रत्येक मशीन डेटा के chunks को संसाधित करने वाले कई workers चलाती है। यह कॉन्फ़िगर करने योग्य है और गति तथा लागत के बीच संतुलन के लिए इसे ट्यून किया जाना चाहिए।
* Image jobs के लिए, यदि एक ही shard में बहुत अधिक images विफल हो जाती हैं, तो वह shard निरस्त कर दिया जाता है जबकि job का बाकी भाग जारी रहता है। आप इस threshold को प्रति job कॉन्फ़िगर कर सकते हैं (देखें [Per-Shard Image Failure Tolerance](#per-shard-image-failure-tolerance) नीचे)।

## Job समय समाप्त

### समस्या

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

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

### विवरण

Timeout सेटिंग (UI) या `--max-runtime-seconds` (CLI) निर्धारित करता है **सभी समानांतर workers के बीच मशीन के अधिकतम संचयी रनटाइम को**.

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

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

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

## SAHI के साथ Workflow बहुत लंबा चलता है

### समस्या

SAHI का उपयोग करने वाले jobs - विशेष रूप से उच्च-रिज़ॉल्यूशन इनपुट और instance segmentation के साथ - अपेक्षा से कहीं अधिक समय ले सकते हैं।

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

**स्लाइसों की अत्यधिक संख्या:** SAHI छवियों को detection के लिए छोटे slices में विभाजित करता है। डिफ़ॉल्ट सेटिंग्स और उच्च-रिज़ॉल्यूशन इनपुट के साथ, इसका मतलब प्रति छवि दर्जनों या सैकड़ों inferences हो सकता है।

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

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

**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 सेटिंग</p></figcaption></figure>

## मेमोरी समाप्ति (OOM) त्रुटियाँ

### समस्या

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

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

* **SAHI + Instance Segmentation:** यह संयोजन अत्यंत मेमोरी-गहन है। SAHI inference calls को कई गुना बढ़ाता है, और instance segmentation बड़े outputs (masks, scores) उत्पन्न करता है, जिससे अक्सर क्रैश हो जाता है।
* **प्रति मशीन बहुत अधिक workers:** कई workers हल्के Workflows के लिए लागत और गति को अनुकूलित करते हैं, लेकिन भारी Workflows (कई बड़े models, जटिल post-processing) उपलब्ध मेमोरी से अधिक हो जाएँगे।

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

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

<figure><img src="https://media.roboflow.com/inference/batch-processing/workers-number-adjustment.png" alt=""><figcaption><p>UI में प्रति मशीन workers सेटिंग</p></figcaption></figure>

## Per-Shard Image Failure Tolerance

### यह कैसे काम करता है

Image batch jobs को shards में विभाजित किया जाता है जो समानांतर चलते हैं। प्रत्येक shard ट्रैक करता है कि processing के दौरान कितनी images विफल हुईं। यदि किसी एक shard के भीतर failure rate एक threshold से अधिक हो जाता है, तो वह shard निरस्त कर दिया जाता है। job का बाकी भाग बिना प्रभावित हुए जारी रहता है।

डिफ़ॉल्ट रूप से, प्लेटफ़ॉर्म एक निश्चित failure threshold लागू करता है। आप job creation request body में `maxImageFailureRate` से इसे प्रति job ओवरराइड कर सकते हैं। मान एक float है, जो `0.0` और `1.0`:

* `0.0` का अर्थ शून्य सहनशीलता है (पहली विफलता पर shard निरस्त करें)।
* `1.0` का अर्थ है कि shard कभी निरस्त नहीं किया जाता, चाहे कितनी भी images विफल हों।
* फ़ील्ड को छोड़ दें या इसे `null` पर सेट करें ताकि प्लेटफ़ॉर्म का डिफ़ॉल्ट उपयोग हो सके।

यह पैरामीटर केवल image jobs पर लागू होता है। Video jobs इसका समर्थन नहीं करते।

### API के माध्यम से सेट करना

शामिल करें `maxImageFailureRate` job creation payload में:

```json
{
  "type": "simple-image-processing-v1",
  "maxImageFailureRate": 0.1,
  ...
}
```

विफल या निरस्त job को पुनः प्रारंभ करते समय भी मान को ओवरराइड किया जा सकता है, इसे restart parameters override में शामिल करके।