> 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/roboflow/roboflow-hi/deploy/batch-processing/troubleshooting.md).
# समस्या निवारण
यह पेज Batch Processing के लिए ज्ञात समस्याएँ, सीमाएँ, और वर्कअराउंड सूचीबद्ध करता है। यदि आपको यहाँ सूचीबद्ध नहीं की गई कोई समस्या मिलती है, तो कृपया इसे हमारे माध्यम से रिपोर्ट करें [सपोर्ट चैनलों](https://github.com/roboflow/inference/issues).
## ज्ञात सीमाएँ
* कुछ Workflow blocks जिन्हें environment variables और local storage (जैसे File Sink और Environment Secret Store) तक पहुँच चाहिए, ब्लॉक कर दिए जाते हैं और निष्पादित नहीं होंगे।
* यह service केवल उन Workflows के साथ काम करती है जो एक **एकल** input image parameter परिभाषित करते हैं।
## तकनीकी विवरण
* डेटा Data Staging में एक **7-दिन की समाप्ति**.
* प्रत्येक batch processing job में कई stages होते हैं (आमतौर पर `प्रसंस्करण` और `निर्यात`)। प्रत्येक stage एक output batch बनाती है। हम उपयोग करने की अनुशंसा करते हैं `निर्यात` stage outputs, क्योंकि वे कुशल transfer के लिए संपीड़ित होते हैं।
* में चल रहा job `प्रसंस्करण` stage को UI और CLI दोनों का उपयोग करके abort किया जा सकता है।
* abort किया गया या failed job पुनः प्रारंभ किया जा सकता है।
* यह service स्वतः डेटा को shards में विभाजित करती है और उसे parallel रूप से process करती है:
* मशीनों की संख्या डेटा volume के आधार पर स्वतः scale होती है (कुछ workloads के लिए throughput 500k–1M images/hour तक पहुँच सकता है)।
* प्रत्येक मशीन डेटा के chunks process करने वाले कई workers चलाती है। यह configurable है और गति तथा लागत के संतुलन के लिए इसे tune किया जाना चाहिए।
* image jobs के लिए, यदि एक ही shard में बहुत सारी images fail हो जाती हैं, तो वह shard abort कर दिया जाता है जबकि job का बाकी हिस्सा जारी रहता है। आप इस threshold को प्रति job configure कर सकते हैं (देखें [Per-Shard Image Failure Tolerance](#per-shard-image-failure-tolerance) नीचे)।
## Job Time Out हुआ
### समस्या
Batch jobs समय से पहले समाप्त हो जाती हैं यदि **Processing Timeout Hours** job के आकार या जटिलता की तुलना में बहुत कम set किया गया हो।
UI में Processing Timeout सेटिंग
### विवरण
timeout सेटिंग (UI) या `--max-runtime-seconds` (CLI) निर्धारित करता है **सभी parallel workers के बीच अधिकतम संचयी मशीन runtime**.
* **कुल compute time:** यदि limit 2 घंटे है और job 2 machines शुरू करती है, तो प्रत्येक अधिकतम 1 घंटे तक चल सकती है (2 machines x 1 hour = 2 hours total)।
* **प्रति chunk विभाजित:** Jobs को parallelism सक्षम करने के लिए processing chunks में विभाजित किया जाता है। timeout chunks में बाँटा जाता है — कम timeout और बहुत सारे chunks होने पर प्रति chunk बहुत कम समय बच सकता है।
* **Machine type मायने रखता है:** CPU पर जटिल 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 में बाँटता है। default settings और high-resolution inputs के साथ, इसका अर्थ प्रति image दर्जनों या सैकड़ों inferences हो सकता है।
* Image Slicer block configuration जाँचें। Workflow में पहले एक Resize Image block का उपयोग करके slices कम करें या inputs का आकार घटाएँ।
**SAHI के बजाय बड़े model input size पर विचार करें:** बड़े input dimensions के साथ model को 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.
UI में FPS sub-sampling सेटिंग
## Out of Memory (OOM) त्रुटियाँ
### समस्या
जब Workflow उपलब्ध RAM या VRAM से अधिक उपयोग करता है, तब OOM त्रुटियों के कारण jobs fail हो जाती हैं।
### सामान्य कारण
* **SAHI + Instance Segmentation:** यह संयोजन अत्यधिक memory-intensive है। SAHI inference calls को बढ़ा देता है, और instance segmentation बड़े outputs (masks, scores) उत्पन्न करता है, जिससे अक्सर crashes होते हैं।
* **प्रति मशीन बहुत अधिक workers:** कई workers हल्के Workflows के लिए लागत और गति को optimize करते हैं, लेकिन भारी Workflows (कई बड़े models, जटिल post-processing) उपलब्ध memory से अधिक हो जाएंगे।
### सिफारिशें
* बड़े models, SAHI, या high-resolution inputs वाले Workflows के लिए प्रति मशीन कम workers (जैसे, 1 या 2) उपयोग करें।
* कम करें **Workers Per Machine** मान को Advanced Options के अंतर्गत।
* यदि आपके model को अधिक memory throughput चाहिए, तो CPU से GPU पर स्विच करें।
* बड़े batches चलाने से पहले अपने Workflow को छोटे dataset पर परीक्षण करें।
* input resolution कम करें या अनावश्यक blocks हटाकर Workflow को सरल करें।
UI में workers per machine सेटिंग
## Per-Shard Image Failure Tolerance
### यह कैसे काम करता है
Image batch jobs को shards में विभाजित किया जाता है जो parallel रूप से चलते हैं। प्रत्येक shard यह ट्रैक करता है कि processing के दौरान कितनी images failed हुईं। यदि एक shard के भीतर failure rate threshold से अधिक हो जाता है, तो वह shard abort कर दिया जाता है। job का बाकी हिस्सा अप्रभावित रहता है।
डिफ़ॉल्ट रूप से, platform एक fixed failure threshold लागू करता है। आप इसे प्रति job इस मान को सेट करके override कर सकते हैं `maxImageFailureRate` job creation request body में। मान के बीच एक float होता है `0.0` और `1.0`:
* `0.0` का अर्थ zero tolerance है (पहली failure पर shard abort करें)।
* `1.0` का अर्थ shard कभी abort नहीं होता, चाहे कितनी भी images fail हों।
* field को छोड़ दें या इसे set करें `null` platform default का उपयोग करने के लिए।
यह parameter केवल image jobs पर लागू होता है। Video jobs इसे support नहीं करतीं।
### API के माध्यम से सेट करना
शामिल करें `maxImageFailureRate` job creation payload में:
```json
{
"type": "simple-image-processing-v1",
"maxImageFailureRate": 0.1,
...
}
```
असफल या abort किए गए job को पुनः प्रारंभ करते समय भी, restart parameters override में इसे शामिल करके इस मान को override किया जा सकता है।
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` query parameter:
```
GET https://docs.roboflow.com/roboflow/roboflow-hi/deploy/batch-processing/troubleshooting.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.
