अपलोड के दौरान ब्राउज़र क्रैश? स्टेबल ट्रांसफर के लिए फ़िक्स
अपलोड के दौरान ब्राउज़र क्रैश या फ़्रीज़? बड़े ट्रांसफर के लिए मेमोरी समस्या और अस्थिरता को सिद्ध स्टेप्स से ठीक करें।
अगर अपलोड के बीच में ब्राउज़र क्रैश हो, तो कारण लगभग हमेशा टैब पर मेमोरी प्रेशर होता है। Chrome उन टैब को kill करता है जो लगभग 2 से 4 GB प्राइवेट मेमोरी पार कर जाएं, और एक ट्रांसफर सर्विस जो 10 GB फ़ाइल एक ही Blob ऑब्जेक्ट में लोड करती हो वह उस सीलिंग के पार चली जाएगी। फ़िक्स: ऐसी सर्विस इस्तेमाल करें जो File API के slice() मेथड से फ़ाइल को चंक में स्ट्रीम करे (ज़्यादातर आधुनिक सर्विसेज़ करती हैं), अपलोड से पहले बाकी सभी टैब बंद करें, fetch/XHR में हुक करने वाले एक्सटेंशन डिसेबल करें, और बैटरी पर चल रहे लैपटॉप की जगह डेस्कटॉप पर अपलोड करें। Firefox आमतौर पर Chromium की तुलना में कम मेमोरी ओवरहेड से बड़ी File API स्ट्रीम संभालता है।
ब्राउज़र अपलोड पर क्रैश क्यों होता है
दो आर्किटेक्चरल हकीकतें टकराती हैं। पहली: हर ब्राउज़र टैब एक अलग प्रोसेस है जिसकी अपनी मेमोरी सीलिंग है। Chrome 64-बिट सिस्टम पर प्रत्येक renderer प्रोसेस को लगभग 4 GB पर OOM killer से पहले कैप करता है। दूसरी: JavaScript में फ़ाइल अपलोड करने का सीधा तरीका पूरे File ऑब्जेक्ट को fetch बॉडी में पास करना है, जिसे ब्राउज़र अक्सर भेजने से पहले मेमोरी में बफर करने की कोशिश करते हैं।
अच्छी तरह बनी ट्रांसफर सर्विस ऐसा कभी नहीं करती। वह हर 5 से 20 MB चंक के लिए Blob बनाने को File.slice(start, end) से फ़ाइल पढ़ती है, वह चंक अपलोड करती है, फिर release करती है। फ़ाइल के साइज़ की परवाह किए बिना मेमोरी लगभग chunkSize × concurrency बाइट पर bounded रहती है।
अगर आपका अपलोड 500 MB प्रोग्रेस पर ठीक शुरू हो और टैब 2 GB पर ग्रे हो जाए, तो सर्विस भेजने से पहले पूरा लोड कर रही है। कोई और सर्विस या तरीका चुनें।
दूसरे टैब आक्रामक रूप से बंद करें
Chrome Site Isolation के साथ भी सिस्टम लेवल पर मेमोरी प्रेशर शेयर होता है। 4K में YouTube चला रहा दूसरा टैब, Figma लोड किया तीसरा, Notion लेकर बैठा चौथा — 8 GB RAM वाले लैपटॉप पर 12 टैब के साथ 10 GB अपलोड खतरनाक है।
बड़ा अपलोड शुरू करने से पहले Chrome पूरा बंद करें और सिर्फ ट्रांसफर सर्विस के टैब के साथ दोबारा खोलें। Activity Monitor (macOS) या Task Manager (Windows) में ब्राउज़र उस एकल टैब पर 2 GB से काफी कम दिखना चाहिए।
एक्सटेंशन डिसेबल करें
Ad ब्लॉकर, प्राइवेसी एक्सटेंशन, पासवर्ड मैनेजर और नेटवर्क एनालाइज़र — uBlock Origin, Privacy Badger, LastPass, HTTP Toolkit — सभी नेटवर्क रिक्वेस्ट में inject करते हैं। ज़्यादातर से कोई समस्या नहीं। कुछ, खासकर पुराने कोड वाले, रिक्वेस्ट बॉडी इंस्पेक्ट करने के लिए बफर करते हैं, जो स्ट्रीमिंग अपलोड बर्बाद करके मेमोरी उड़ाता है।
incognito विंडो में टेस्ट करें (एक्सटेंशन डिफ़ॉल्ट से बंद होते हैं)। incognito में अपलोड सफलतापूर्वक पूरा हो तो एक्सटेंशन दोषी हैं। एक-एक करके चालू करें दोषी ढूंढने के लिए।
कमज़ोर GPU पर हार्डवेयर एक्सेलेरेशन बंद करें
पुराने लैपटॉप जिनमें integrated Intel UHD 620 या ऐसा ही GPU हो, कभी-कभी progress bar अपडेट और file read buffer एक साथ रेंडर करते समय क्रैश होते हैं। Chrome की Settings > System > "Use hardware acceleration when available" को टॉगल ऑफ किया जा सकता है। इससे बाकी सब कुछ थोड़ा कम smooth होगा लेकिन मेमोरी-कंस्ट्रेंड सिस्टम पर बड़े अपलोड स्थिर होंगे।
इसी तरह, Chrome का "Memory Saver" मोड अपलोड टैब के लिए बंद करें — यह प्रेशर में टैब बाहर कर देता है जिससे अपलोड बीच में टूट सकता है। टैब पिन करें या उसे explicitly exclude करें।
बहुत बड़ी फ़ाइलों के लिए Firefox पर स्विच करें
Firefox ऐतिहासिक रूप से Chromium की तुलना में कम मेमोरी बजट से File API संभालता है। Chrome पर बार-बार क्रैश होने वाला 10 GB अपलोड Firefox पर अक्सर बिना नाटक के पूरा होता है। अंतर अच्छी तरह बनी सर्विस पर बड़ा नहीं है, लेकिन कम-आदर्श इम्प्लीमेंटेशन वाली सर्विसेज़ पर Firefox का रूढ़िवादी मेमोरी मॉडल ज़्यादा माफ़ करने वाला है।
macOS पर Safari बड़े अपलोड के लिए भरोसेमंद है, लेकिन iOS Safari बैकग्राउंड टैब आक्रामक रूप से बंद करता है।
टैब को फोरग्राउंड में रखें और पिन करें
बैकग्राउंड टैब मेमोरी प्रेशर में सबसे पहले निकाले जाते हैं। अपलोड टैब फोरग्राउंड में रखें। 30 मिनट के लिए दूसरी विंडो पर न जाएं वरना टैब रीलोड मिलेगा। Chrome का "discarded" टैब वापस आने पर ग्रे placeholder दिखाता है, और progress में चल रहा कोई भी अपलोड खत्म हो चुका होता है।
macOS पर caffeinate -s या अपलोड के दौरान Windows की पावर-सेविंग sleep बंद करें। सोया हुआ लैपटॉप WebSocket और XHR कनेक्शन बंद कर देता है, और हर सर्विस बाद में साफ़ resume नहीं कर पाती।
बैटरी पर नहीं, डेस्कटॉप या प्लग-इन लैपटॉप से अपलोड करें
बैटरी पर चलने वाले लैपटॉप CPU और RAM आक्रामक रूप से थ्रॉटल करते हैं। macOS का "Low Power Mode" और Windows का "Battery Saver" दोनों बैकग्राउंड टास्क प्राथमिकता घटाते हैं — ब्राउज़र टैब के लिए जो AES एन्क्रिप्शन और नेटवर्क राइट कर रहा हो, इसका मतलब है रुकाव।
प्लग लगाएं। बैटरी-सेवर मोड बंद करें। अगर लैपटॉप CPU परफॉर्मेंस प्रोफाइल चुनने का विकल्प दे — Dell Power Manager, Lenovo Vantage — तो duration के लिए "Performance" सेट करें।
अपलोड से पहले ब्राउज़र रीस्टार्ट करें
Chrome, Firefox और Edge सभी लंबे सेशन में धीरे-धीरे मेमोरी लीक करते हैं। दो दिन से खुला 40 टैब वाला ब्राउज़र अपलोड पेज खोलने से पहले ही 2 GB zombie मेमोरी ले सकता है। पूरी तरह quit करें — macOS पर Cmd+Q, सिर्फ विंडो बंद नहीं; Windows पर taskbar राइट-क्लिक > Quit — और दोबारा खोलें।
हार्डवेयर के हिसाब से चंक साइज़ मैच करें
जो सर्विसेज़ चंक साइज़ कॉन्फ़िगर करने देती हैं — ज़्यादातर नहीं, लेकिन rclone जैसे कुछ CLI टूल देते हैं — उन पर छोटे चंक कम मेमोरी लेते हैं। 4 concurrent workers के साथ 5 MB चंक किसी भी समय 20 MB buffer है। 4 workers के साथ 100 MB चंक 400 MB है। 4 GB मशीन पर फर्क पड़ता है।
वेब-आधारित सर्विसेज़ आपके लिए डिफ़ॉल्ट चुनती हैं, आमतौर पर 5 से 20 MB प्रति चंक, जो समझदारी है। लेकिन कस्टम स्क्रिप्ट कभी-कभी "तेज़ जाने" के लिए बड़े चंक डिफ़ॉल्ट करती हैं और छोटी मशीन पर फेल होती हैं।
अपलोड के दौरान Activity Monitor से RAM चेक करें
अपलोड के दौरान ब्राउज़र प्रोसेस की मेमोरी देखें। macOS Activity Monitor: Memory टैब, ब्राउज़र के नाम से फ़िल्टर। Windows Task Manager: Details टैब, "Memory (private working set)" से सॉर्ट।
स्वस्थ chunked अपलोड प्रोग्रेस की परवाह किए बिना ब्राउज़र मेमोरी को कुछ सौ MB पर स्थिर रखता है। अगर मेमोरी अपलोड प्रोग्रेस के साथ रैखिक रूप से बढ़े — 10 GB फ़ाइल के 50% पर 5 GB पहुँचे — तो सर्विस सब कुछ बफर कर रही है। यह बग है। कोई और सर्विस ढूंढें।
बड़े ब्राउज़र अपलोड के लिए सही इंजीनियरिंग वाली सर्विस चुनें
अच्छी तरह इंजीनियर ट्रांसफर सर्विस एन्क्रिप्शन के लिए Web Worker pool के साथ chunked अपलोड, bounded मेमोरी, और फेल चंक पर explicit retry इस्तेमाल करती है। HexaTransfer Web Workers में File.slice() से फ़ाइलें पढ़ता है, प्रति चंक AES-256-GCM से एन्क्रिप्ट करता है, और ब्राउज़र मेमोरी को कुछ सौ MB से ज़्यादा नहीं जाने देता — चाहे आप 50 MB भेजें या पूरे 10 GB प्रति-ट्रांसफर सीलिंग तक। DPDP Act 2023 के तहत डेटा सुरक्षा की ज़िम्मेदारी के साथ काम करने वाले भारतीय यूज़र के लिए यह क्लाइंट-साइड एन्क्रिप्शन खास मायने रखता है।
hexatransfer.com पर आज़माएं — मुफ्त, बिना अकाउंट, 10 GB तक।
एंड-टू-एंड एन्क्रिप्शन के साथ बड़ी फ़ाइलें सुरक्षित रूप से भेजें
एंड-टू-एंड एन्क्रिप्शन के साथ 10 GB तक की फ़ाइलें मुफ़्त में ट्रांसफ़र करें। अकाउंट की आवश्यकता नहीं। अपलोड से पहले आपकी फ़ाइलें ब्राउज़र में एन्क्रिप्ट की जाती हैं — कोई और उन्हें पढ़ नहीं सकता।
फ़ाइल भेजें