Files
SnapOtter/apps/docs/hi/guide/low-resource.md
T

104 lines
12 KiB
Markdown
Raw Normal View History

---
i18n_source_hash: f5de74aee1b9
i18n_provenance: machine
i18n_output_hash: 9e03d6f8c387
---
# कम संसाधन वाले सेटअप {#low-resource-setups}
SnapOtter छोटे हार्डवेयर पर अच्छी तरह चलता है: Raspberry Pi 4 या 5, कोई पुराना लैपटॉप, या 2 GB का VPS। यह पेज ऐसी मशीनों के लिए व्यावहारिक गाइड है: क्या अपेक्षा करें, समझदार सीमाओं के साथ एक कॉपी-पेस्ट सेटअप, और कौन से फ़ीचर छोड़ देने चाहिए। इन संख्याओं के पीछे का पूरा बेंचमार्क डेटा [Hardware Requirements](/hi/guide/deployment#hardware-requirements) में है।
शुरू में ही दो सख़्त सीमाएँ:
- **केवल 64-बिट।** इमेज `linux/amd64` और `linux/arm64` के लिए बनाई जाती है। 32-बिट ARM (`armv7`/`armhf`) समर्थित नहीं है, इसलिए पहली पीढ़ी के Pi और Pi Zero परिवार बाहर हैं।
- **2 GB मेमोरी की न्यूनतम सीमा।** 512 MB स्टैक शुरू ही नहीं कर सकता, और 1 GB बहु-फ़ाइल बैचों पर विफल हो जाता है। 2 कोर के साथ 2 GB सबसे छोटा कॉन्फ़िगरेशन है जो आराम से काम करता है।
## छोटे हार्डवेयर पर क्या अच्छा चलता है {#what-runs-well}
हर गैर-AI टूल 2 GB / 2-कोर मशीन पर काम करता है: पूरे Image और Files सेक्शन, PDF टूल, और स्ट्रीम-कॉपी वाले वीडियो व ऑडियो ऑपरेशन (ट्रिम, म्यूट, कंटेनर रीमक्स)। अधिकांश एक सेकंड से भी कम में पूरे हो जाते हैं।
दो वर्कलोड अपवाद हैं:
- **वीडियो री-एन्कोडिंग** (कोडेक के बीच रूपांतरण) CPU-बाउंड है। जो 1080p क्लिप किसी तेज़ डेस्कटॉप CPU पर ~40 सेकंड लेती है, वह Pi-श्रेणी के CPU पर कई मिनट ले सकती है। स्ट्रीम-कॉपी ऑपरेशन तब भी तुरंत ही होते हैं।
- **AI टूलों** को RAM (4 GB अनुशंसित) और डिस्क चाहिए (बड़े बंडल 4-5 GB प्रत्येक होते हैं), और भारी वाले (अपस्केलिंग, फोटो बहाली, पृष्ठभूमि हटाना) Pi-श्रेणी के CPU पर व्यावहारिक नहीं हैं। चेहरा पहचान और OCR जैसा हल्का AI उपयोग करने योग्य है, बशर्ते आपके पास उसके लिए मेमोरी हो।
जब तक आप इनका उपयोग नहीं करते, इनमें से कुछ भी इंस्टॉल या चालू नहीं होता: बिना किसी AI बंडल के ऐप लगभग 360 MB पर निष्क्रिय रहता है, और AI बंडल केवल तभी डाउनलोड होते हैं जब कोई एडमिन उन्हें सक्षम करता है।
## Raspberry Pi / पुराने लैपटॉप की वॉकथ्रू {#walkthrough}
यह [Getting Started](/hi/guide/getting-started) वाला ही स्टैंडर्ड Compose इंस्टॉल है, साथ में रिसोर्स लिमिट और सतर्क सीमाएँ। यह 64-बिट OS मानकर चलता है (Pi पर: Raspberry Pi OS 64-bit या Ubuntu Server arm64)।
```yaml
services:
snapotter:
image: snapotter/snapotter:latest
ports:
- "1349:1349"
volumes:
- ./snapotter-data:/data
environment:
- DATABASE_URL=postgres://snapotter:snapotter@db:5432/snapotter
- REDIS_URL=redis://redis:6379
# Small-box profile: see the table below for what each cap does.
- CONCURRENT_JOBS=1
- MAX_WORKER_THREADS=2
- MAX_BATCH_SIZE=5
- MAX_UPLOAD_SIZE_MB=100
- MAX_MEGAPIXELS=50
- MAX_VIDEO_DURATION_S=300
deploy:
resources:
limits:
cpus: "2"
memory: 2G
depends_on:
- db
- redis
restart: unless-stopped
db:
image: postgres:17-alpine
environment:
- POSTGRES_USER=snapotter
- POSTGRES_PASSWORD=snapotter
- POSTGRES_DB=snapotter
volumes:
- ./postgres-data:/var/lib/postgresql/data
restart: unless-stopped
redis:
image: redis:8-alpine
command: redis-server --maxmemory 256mb --maxmemory-policy noeviction
restart: unless-stopped
```
Pi-श्रेणी की मशीनों के लिए नोट्स:
- **डेटा वॉल्यूम और Postgres के लिए SD कार्ड के बजाय USB SSD चुनें।** जॉब वर्कस्पेस असली डिस्क IO करते हैं, और SD कार्ड धीमे भी होते हैं और जल्दी घिस भी जाते हैं।
- **ऑल-इन-वन एकल कंटेनर यहाँ भी काम करता है** (`DATABASE_URL`/`REDIS_URL` अनसेट होने पर एंबेडेड Postgres और Redis), और मेमोरी की तंगी वाले होस्ट पर आपको `REDIS_MAXMEMORY` से इसकी एंबेडेड Redis सीमा घटा देनी चाहिए ([Configuration](/hi/guide/configuration) देखें)। Compose हर सेवा पर बारीक नियंत्रण देता है, इसीलिए यह वॉकथ्रू उसी का उपयोग करती है।
- **2 GB डिवाइसों पर स्वैप जोड़ें।** इससे कभी-कभार का स्पाइक (कोई बड़ी PDF, कोई बैच जिस पर सीमा लगाना आप भूल गए) आउट-ऑफ़-मेमोरी किल में खत्म नहीं होता। zram SD-कार्ड के लिए अनुकूल विकल्प है।
- arm64 इमेज केवल CPU वाली है; ARM बोर्डों पर कोई CUDA नहीं है।
## ट्यूनिंग के विकल्प {#tuning-knobs}
सभी सीमाएँ एनवायरनमेंट वेरिएबल हैं, जिनका पूरा विवरण [Configuration](/hi/guide/configuration) में है। `0` का मतलब असीमित या ऑटो है। छोटे हार्डवेयर पर जो मायने रखती हैं:
| वेरिएबल | छोटी मशीन के लिए सुझाव | यह किससे बचाता है |
|---|---|---|
| `CONCURRENT_JOBS` | `1` | कितने जॉब समानांतर चलते हैं। ऑटो-डिटेक्ट CPU कोर घटा एक का उपयोग करता है, जो बड़ी मशीनों पर ठीक है लेकिन मेमोरी दबाव में 2-कोर मशीन पर ज़रूरत से ज़्यादा आक्रामक है। |
| `MAX_WORKER_THREADS` | `2` | इमेज-प्रोसेसिंग थ्रेड पूल। |
| `MAX_BATCH_SIZE` | `5` | बैच ही वह जगह है जहाँ 1-2 GB मशीनों की मेमोरी सबसे पहले खत्म होती है। |
| `MAX_UPLOAD_SIZE_MB` | `100` | एक ही विशाल फ़ाइल को पूरा वर्कस्पेस घेरने से रोकता है। |
| `MAX_MEGAPIXELS` | `50` | 100+ MP इमेज को डिकोड करने में RAM खर्च होती है, फ़ाइल आकार चाहे जो हो। |
| `MAX_VIDEO_DURATION_S` | `300` | लंबे ट्रांसकोड छोटे CPU पर मिनटों से घंटों तक कब्ज़ा कर लेते हैं। |
| `PROCESSING_TIMEOUT_S` | `600` | सख़्त ऊपरी सीमा, ताकि कोई बेकाबू जॉब अंततः मशीन को मुक्त कर दे। |
ये सीमाएँ इस पर लागू होती हैं कि सर्वर क्या स्वीकार करता है, इसलिए इन्हें जितना संभव हो उतना छोटा रखने के बजाय अपने वास्तविक उपयोग के अनुसार सेट करें। अगर आप वीडियो कभी नहीं छूते, तो `MAX_VIDEO_DURATION_S` सीमा का कोई नुकसान नहीं; अगर आप रोज़ दस्तावेज़ स्कैन करते हैं, तो `MAX_PDF_PAGES` पर सीमा न लगाएँ।
## क्या छोड़ दें {#what-to-skip}
- **भारी AI बंडल।** अपस्केलिंग, फोटो बहाली, और पृष्ठभूमि हटाने को GPU या तेज़ मल्टी-कोर CPU चाहिए, और हर बंडल 4-5 GB डिस्क लेता है। छोटी मशीन पर इन्हें बस इंस्टॉल ही न करें; जिन टूलों का बंडल मौजूद नहीं है वे चलने के बजाय इंस्टॉल का संकेत दिखाते हैं।
- **नियमित वर्कलोड के रूप में वीडियो री-एन्कोडिंग।** कभी-कभार के ट्रांसकोड ठीक हैं (वे बस धीमे होते हैं); लगातार चलने वाली ट्रांसकोड कतार को CPU कोर चाहिए, Pi नहीं।
- **सामान्य तौर पर अप्रयुक्त टूल।** एडमिन Settings में अलग-अलग टूल बंद कर सकता है, जिससे वे UI से हट जाते हैं और उनके API रूट रजिस्टर होना बंद हो जाते हैं। इससे अपने आप मेमोरी नहीं बचती, लेकिन यह साझा छोटी इंस्टेंस को उसी एक वर्कलोड में इस्तेमाल होने से बचाता है जिसे हार्डवेयर झेल नहीं सकता।
अगर बाद में आप इंस्टेंस को बड़े हार्डवेयर पर ले जाते हैं, तो सीमाएँ हटा दें (उन्हें वापस `0` पर सेट करें) और वही डेटा वॉल्यूम साथ चला जाता है।