मैं वर्तमान में बड़ी फ़ाइलों की प्रतिलिपि बनाने के लिए प्रति मेमोरी ब्लॉक 100 मेगाबाइट का उपयोग कर रहा हूं।कॉपी करते समय उपयोग करने के लिए आदर्श मेमोरी ब्लॉक आकार क्या है?
क्या वहां "अच्छी" राशि है जो लोग आम तौर पर उपयोग करते हैं?
संपादित
सभी महान प्रतिक्रिया के लिए धन्यवाद।
मैं अभी भी इन अवधारणाओं के लिए काफी नया हूं इसलिए मैं उन लोगों में से कई को समझने की कोशिश करूंगा (उदा। वापस कैश लिखें)। मैं नई चीजें सीख रहा हूं :)
4096 और 32 केबी के बीच एक ब्लॉक ठेठ विकल्प है। 100 एमबी का उपयोग काउंटर-उत्पादक है। आप बफर के साथ रैम पर कब्जा कर रहे हैं जिसे पर फ़ाइल सिस्टम लेखन कैश के रूप में बेहतर उपयोग किया जा सकता है।
फ़ाइलों को कॉपी करना बहुत तेज़ है जब फ़ाइल कैश में पूरी तरह फिट बैठती है, WriteFile() कॉल एक साधारण मेमोरी-टू-मेमोरी प्रति है। कैश मैनेजर तब आलसी से डिस्क पर लिखता है। लेकिन जब कैश में कोई और कमरा नहीं है, तो कॉपी की गति एक चट्टान से गिर जाती है जब WriteFile() को अंतरिक्ष उपलब्ध कराने के लिए इंतजार करना पड़ता है। यह अब डिस्क लिखने की गति पर चला जाता है।
मुझे लगता है कि यह आपके पास मुफ्त मेमोरी के आकार पर निर्भर करता है।
यदि आप मशीन पर प्रतिलिपि बनाने के लिए 100 एम ब्लॉक का उपयोग करते हैं, उदाहरण के लिए 30 एमबी खाली मेमोरी है तो छोटे (20 एम) ब्लॉक का उपयोग करने की तुलना में कॉपी करने में अधिक समय लगेगा।
यदि प्रतिलिपि बनाने के लिए आपका बफर उपलब्ध मुफ्त मेमोरी के आकार से बड़ा है तो वर्चुअल मेमोरी स्वैपिंग के कारण आपकी प्रतिलिपि अपेक्षा से धीमी हो जाएगी।
मुझे नहीं पता कि यह आपका क्या मतलब है, लेकिन मैं जांचता हूं कि फ़ाइल का आकार 100 मेगाबाइट से बड़ा है, और यदि नहीं, तो मैं सिर्फ एक ब्लॉक का उपयोग करता हूं जो सटीक फ़ाइल आकार है। –
यह एक बहुत अधिक राशि है। ध्यान दें कि आप 100 एमबी पढ़ने से पहले डेटा लिखना भी शुरू नहीं करते हैं, इसलिए फाइल सिस्टम ड्राइवर को पढ़ने के दौरान किसी भी गंतव्य फ़ाइल को लिखने का मौका भी नहीं मिलता है। डिस्क उस फ़ाइल के कुछ हिस्सों को लिख सकती है जो सिर के नीचे गुजरती हैं क्योंकि यह स्रोत फ़ाइल पढ़ रही है (उदाहरण के लिए elevator seek देखें)।
बड़े पैमाने पर ब्लॉक का उपयोग करने में आमतौर पर थोड़ा सा लाभ होता है।
मान लीजिए कि आपका ऑपरेटिंग सिस्टम सुपर-बेवकूफ है और प्रत्येक पढ़ने या लिखने के ऑपरेशन में हार्ड डिस्क की तलाश होती है (प्रैक्टिस में आप अक्सर पाएंगे कि लिखते हैं कतारबद्ध हो जाते हैं और पढ़ते हैं, आगे बढ़ते हैं, बड़े बफर का उपयोग करने के लाभ को कम करते हैं आपके आवेदन कोड में)।
फिर प्रत्येक ब्लॉक आपको दो कहने के लिए 2x10ms खर्च करता है (एक पढ़ने के लिए और एक लिखने के लिए) और वास्तविक पढ़ने और लेखन के समय के बाद आपके ब्लॉक आकार में थोड़ा सा बिंदु बढ़ रहा है। एक वास्तव में तेज़ एचडी 150 एमबी/एस पर पढ़ और लिख सकता है, इस मामले में 10 एमएमएस 1.5 एमबी पढ़ने/लिखने के अनुरूप होगा, और आप 15 एमबी से अधिक ब्लॉकों के लिए थोड़ा सा प्राप्त करेंगे।
प्रैक्टिस में, (1) आपका खोज समय शायद कम होगा, (2) आपकी पढ़ाई और लिखने वाली बैंडविड्थ शायद अधिक होगी, और (3) आपका ओएस और ड्राइव हार्डवेयर शायद आपके लिए चीजें कैशिंग और क्यूइंग करेगा; आपको शायद लगभग 100 केबी से ऊपर ब्लॉक करने से बहुत कम या कोई लाभ दिखाई देगा।
(आप शायद बेंचमार्क blocksizes की एक किस्म है और देखना चाहिए कि क्या आप अपने खुद के सिस्टम पर मिलता है।)
मैं आपको बेंचमार्क करने की सलाह दूंगा, और अधिक छोटे ब्लॉक आकारों को शामिल करना याद रखें। इस पर अपने स्वयं के परीक्षणों में, मुझे काफी प्रतिद्वंद्वी परिणाम मिल गए।
हार्ड ड्राइव से पढ़ने और लिखने पर, 512 बाइट और 512 केबी के बीच सभी ब्लॉक (ब्लॉक की शक्ति) एक ही गति प्रदान करते हैं। 512 केबी से 1 एमबी से ब्लॉक आकार में वृद्धि प्रतिलिपि की गति लगभग 60% तक कम हो गई। ब्लॉक आकार में वृद्धि ने गति को फिर से बढ़ाया, लेकिन छोटे ब्लॉक का उपयोग करने की गति पर कभी भी वापस नहीं।
जब सभी प्रतिलिपि डेटा कैश मेमोरी में था, तो (बहुत तेजी से) प्रतिलिपि गति में वृद्धि हुई, आकार के ब्लॉक आकार के साथ सुधार हुआ, 32 केबी ब्लॉक तक पहुंचने के आसपास बाहर निकल रहा था, और अचानक 256 से जाने पर अचानक पिछली गति के करीब आ गया केबी से 512 केबी ब्लॉक, पिछली गति पर वापस नहीं लौटना।
इस परीक्षण के बाद, मैंने अपने कई कार्यक्रमों में लगभग 1 एमबी से 32 केबी तक पढ़ने/लिखने के ब्लॉक आकार को छोड़ दिया।
एक अवसर पर (कुछ साल पहले) जब मैंने फ्लैश फाइल सिस्टम के साथ मोबाइल उपकरणों पर परीक्षणों का एक गुच्छा चलाया, तो लिखने की गति लगभग 256K तक बढ़ रही थी, हालांकि 64 के पिछले बहुत कम रिटर्न के साथ। लेकिन आईआईआरसी मैं सिर्फ स्मृति से फ़ाइल में लिखने का परीक्षण कर रहा था, फाइल फ़ाइल प्रति नहीं। और हम वास्तव में कभी नहीं समझ पाएंगे कि उन आकारों के बारे में क्या विशेष था। –
यह देखते हुए कि ड्राइव को ट्रैक करने पर ड्राइव की तलाश करनी चाहिए, क्या 63 x 512 = 32256 का ब्लॉक आकार इष्टतम परिणाम नहीं दे सकता है?
भौतिक डिस्क और प्रोग्राम के बीच ऑपरेटिंग सिस्टम और हार्डवेयर की कुछ परतें हैं, इसलिए डिस्क ट्रैक आकार शायद महत्वपूर्ण नहीं है। हालांकि, SO :-) में आपका स्वागत है। – thiton
शायद आपके निष्पादन योग्य विंडोज-कॉपियर की तुलना में एक उच्च प्राथमिकता है। – BenjaminB
यदि आपका ओएस 'statfs' प्रदान करता है तो आप उस अवरोध को देख सकते हैं जो यह सुझाता है ('f_bsize'), हालांकि मुझे नहीं पता कि आप कितना दूर विश्वास कर सकते हैं कि यह वास्तव में" इष्टतम "है। जब तक आप वास्तव में चिंतित नहीं होते हैं कि विभिन्न प्लेटफॉर्म और फाइल सिस्टम पर क्या होता है, तो विभिन्न मशीनों के साथ बहुत छोटे से बहुत बड़े आकार के साथ अपनी मशीन पर कुछ परीक्षण चलाएं। उस बिंदु से परे अधिक स्मृति का उपयोग करने का कोई मतलब नहीं है जहां यह तेजी से हो रहा है। –
विंडोज़ पर 'कॉपीफाइल' जैसे मूल संचालन का उपयोग करने पर भी विचार करें। – MSalters