लिनक्स: बड़े int सरणी: mmap बनाम फ़ाइल खोजना?

Question

मान लीजिए मैं एक डाटासेट 1e12 32-बिट ints (4 टीबी) एक 4tb HDD ext4 फाइलसिस्टम पर एक फ़ाइल में संग्रहीत की एक सरणी है कि ..

पर विचार करें कि डेटा सबसे अधिक संभावना यादृच्छिक है (या कम से कम लगता है यादृच्छिक)।

// pseudo-code 
for (long long i = 0; i < (1LL << 40); i++) 
    SetFileIntAt(i) = GetRandInt(); 

इसके अलावा, विचार है कि मैं एक अप्रत्याशित क्रम में और कलन विधि अनिश्चित काल चलाता है (यह चालू है) कि व्यक्ति पूर्णांक तत्वों को पढ़ने के लिए चाहते हैं।

// pseudo-code 
while (true) 
    UseInt(GetFileInt(GetRand(1<<40))); 

हम लिनक्स x86_64, gcc पर हैं। आप सिस्टम मान सकते हैं रैम 4 जीबी है (यानी 1000x कम डाटासेट से)

निम्नलिखित वास्तुकार का उपयोग करने के दो तरीके होते हैं:

(ए) स्मृति का एक 4 टीबी ब्लॉक करने के लिए फ़ाइल mmap, और एक के रूप में यह पहुँच int array

(बी) फ़ाइल खोलें और 2 (2) का उपयोग करें और इन्हें पढ़ने के लिए (2) पढ़ें।

ए और बी के बाहर बेहतर प्रदर्शन होगा ?, और क्यों?

क्या कोई अन्य डिज़ाइन है जो या तो ए या बी से बेहतर प्रदर्शन करेगा?

Answer 1

मैं कहूंगा कि प्रदर्शन वास्तव में यादृच्छिक है तो प्रदर्शन समान होना चाहिए। ओएस एक समान कैशिंग रणनीति का उपयोग करेगा चाहे डेटा पेज को फ़ाइल से मैप किया गया हो या फ़ाइल डेटा को रैम के साथ किसी भी सहयोग के बिना कैश किया गया हो।

मान लिया जाये कि कैश अप्रभावी है:

• आप fadvise उपयोग कर सकते हैं अग्रिम और अक्षम Readahead में अपनी पहुंच पद्धति घोषित करने के लिए।
• पता स्थान लेआउट यादृच्छिकरण के कारण, आपके वर्चुअल एड्रेस स्पेस में 4 टीबी का एक संगत ब्लॉक नहीं हो सकता है।
• यदि आपका डेटा सेट कभी विस्तारित करता है, तो पता स्थान समस्या अधिक दबाने लग सकती है।

तो मैं स्पष्ट रूप से पढ़ता हूं।

Answer 2

एक ओर, आप स्मृति स्वैप नाबालिग pagefaults, अनुप्रयोगी के लिए पारदर्शी है, जिसके परिणामस्वरूप का व्यापक उपयोग किया है। दूसरी तरफ, आपके पास ज्ञात ओवरहेड के साथ सिस्टम सिस्टम कॉल करता है। विकिपीडिया पेज memory-mapped file मेरे लिए काफी स्पष्ट प्रतीत होता है, यह एक व्यापक तरीके से पेशेवरों और विपक्ष में ब्राउज़ करता है।

मुझे लगता है कि 64 बिट आर्किटेक्चर + मेमोरी-मैप किए गए फ़ाइल दृष्टिकोण के लिए बड़ी फ़ाइल कॉल, कम से कम आवेदक को जटिल बनाने से रोकने के लिए; मुझे बताया गया है कि जटिलता अक्सर खराब प्रदर्शन की ओर ले जाती है। हालांकि mmap() अनुक्रमिक पहुंच के लिए सामान्य है, जो यहां उद्देश्य नहीं है।

क्योंकि यह शुद्ध यादृच्छिक पहुंच है, इसलिए कुछ मौका है कि दो एक्सेस एक ही रैम-लोड पृष्ठ में होंगे। एक पूर्ण 4 केबी पेज एचडीडी से रैम में बदल दिया जाएगा, केवल 4 बाइट डेटा के लिए ... यह बसों की बेकार लोडिंग है और शायद खराब प्रदर्शन में परिणाम देगा।

इस सहायता की आशा करें।

Answer 3

शायद 4TB रैखिक डेटासेट के लिए आपको फ़ाइल सिस्टम की आवश्यकता नहीं है। मुझे लगता है कि एक कच्चे डिवाइस का उपयोग कुछ प्रदर्शन लाभ ला सकता है।

शायद प्रश्नों या डेटा संरचना को अनुकूलित करने का एक तरीका भी है, ताकि कैशिंग को अधिक कुशलता से उपयोग किया जा सके?

Answer 4

प्रदर्शन की खोज अत्यधिक आपके फ़ाइल सिस्टम कार्यान्वयन पर निर्भर करती है। Ext4 एक अच्छा विकल्प होना चाहिए क्योंकि यह extent trees का उपयोग करता है। इसके अलावा यदि आपकी फ़ाइल में रैखिक संगत आवंटन है तो हद के पेड़ में एक ही प्रविष्टि होगी, जो कि छोटे से कुशलता से खोज लेती है।