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

timeouts, SAHI performance, और OOM errors सहित Batch Processing की सामान्य समस्याओं का समस्या निवारण करें।

यह पृष्ठ Batch Processing के लिए ज्ञात समस्याएँ, सीमाएँ, और workarounds सूचीबद्ध करता है। यदि आपको यहाँ सूचीबद्ध नहीं की गई कोई समस्या मिलती है, तो कृपया इसे हमारे माध्यम से रिपोर्ट करें support channelsarrow-up-right.

ज्ञात सीमाएँ

  • Environment variables और local storage (जैसे File Sink और Environment Secret Store) तक पहुँच की आवश्यकता वाले कुछ Workflow blocks blocked हैं और execute नहीं होंगे।

  • यह service केवल ऐसे Workflows के साथ काम करता है जो एक single input image parameter परिभाषित करते हैं।

तकनीकी विवरण

  • Data को Data Staging में एक 7-day expiry.

  • के साथ संग्रहीत किया जाता है। प्रत्येक batch processing job में कई stages होते हैं (आमतौर पर processing और export). प्रत्येक stage एक output batch बनाता है। हम export stage outputs

  • का उपयोग करने की अनुशंसा करते हैं, क्योंकि वे कुशल transfer के लिए compressed होते हैं। एक चल रहा job processing stage में UI और CLI दोनों का उपयोग करके abort किया जा सकता है।

  • एक aborted या failed job को restart किया जा सकता है।

  • यह service स्वचालित रूप से 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 Timed Out

समस्या

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

UI में Processing Timeout setting

विवरण

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

  • कुल compute time: यदि limit 2 hours है और job 2 machines spawn करता है, तो प्रत्येक अधिकतम 1 hour तक चल सकता है (2 machines x 1 hour = 2 hours total)।

  • प्रति chunk विभाजित: Parallelism सक्षम करने के लिए jobs को processing chunks में split किया जाता है। timeout chunks में विभाजित होता है — बहुत सारे chunks के साथ छोटा timeout प्रति chunk बहुत कम समय छोड़ सकता है।

  • Machine type मायने रखता है: CPU पर complex Workflows चलाने से processing time काफी बढ़ जाता है। जहाँ उपयुक्त हो, GPU का उपयोग करें।

सिफारिशें

  • बड़े datasets या multi-stage Workflows के लिए उदार timeout (जैसे, 4–6 hours) से शुरू करें।

  • भविष्य के timeout settings को बेहतर बनाने के लिए actual job runtimes की निगरानी करें।

  • तेज़ processing के लिए chunk count कम करने या video frame sub-sampling का उपयोग करने पर विचार करें।

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

समस्या

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

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

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

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

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 को skip करने के लिए FPS sub-sampling का उपयोग करें:

  • UI में, Video FPS sub-sampling dropdown का उपयोग करें।

  • CLI में, --max-video-fps flag का उपयोग करें।

UI में FPS sub-sampling setting

Out of Memory (OOM) Errors

समस्या

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

सामान्य कारण

  • SAHI + Instance Segmentation: यह संयोजन अत्यंत memory-intensive है। SAHI inference calls को गुणा करता है, और instance segmentation बड़े outputs (masks, scores) उत्पन्न करता है, जिससे अक्सर crashes होते हैं।

  • प्रति machine बहुत अधिक workers: Multiple workers हल्के Workflows के लिए cost और speed को optimize करते हैं, लेकिन heavy Workflows (multiple large models, complex post-processing) उपलब्ध memory से अधिक हो जाएँगे।

सिफारिशें

  • Large models, SAHI, या high-resolution inputs वाले Workflows के लिए प्रति machine कम workers (जैसे, 1 या 2) का उपयोग करें।

  • कम करें Workers Per Machine Advanced Options के अंतर्गत value।

  • यदि आपके model को अधिक memory throughput की आवश्यकता है, तो CPU से GPU पर स्विच करें।

  • बड़े batches चलाने से पहले अपने Workflow को छोटे dataset पर test करें।

  • Input resolution कम करें या अनावश्यक blocks हटाकर Workflow को सरल बनाएँ।

UI में workers per machine setting

Last updated

Was this helpful?