साझा मेमोरी IPC के लिए फ़ाइलों का उपयोग करना, क्या मेमोरी एक आवश्यकता की मैपिंग है?

वोट
19

वहाँ कुछ परियोजनाएँ हैं जो जावा के FileChannel.map () द्वारा JDMs के बीच एक ही होस्ट पर साझा मेमोरी IPC (जो क्रॉनिकल क्यू, एयरोस्पेस IPC, आदि देखें) के रूप में साझा करने के तरीके से MappedByteBuffers का उपयोग करती हैं। जहां तक मैं बता सकता हूं, यह एपीआई सिर्फ एमएमएपी कॉल के ऊपर बैठता है। हालांकि, जावा का कार्यान्वयन अनाम (गैर-फ़ाइल समर्थित) मैपिंग की अनुमति नहीं देता है।

मेरा सवाल है, जावा (1.8) और लिनक्स (3.10) पर, क्या मैपेडबाइटबफर्स वास्तव में साझा मेमोरी आईपीसी को लागू करने के लिए आवश्यक हैं, या क्या किसी आम फ़ाइल तक पहुंच समान कार्यक्षमता प्रदान करेगी? (यह प्रश्न MappedByteBuffer या नहीं का उपयोग करने के प्रदर्शन निहितार्थ से संबंधित नहीं है।)

यहाँ मेरी समझ है:

  1. जब लिनक्स एक फाइल को डिस्क से लोड करता है, तो यह उस फाइल के कंटेंट को मेमोरी में पेजों पर कॉपी कर देता है। मेमोरी के उस क्षेत्र को पेज कैश कहा जाता है। जहाँ तक मैं बता सकता हूँ, यह इस बात की परवाह किए बिना करता है कि जावा विधि (FileInputStream.read (), RandomAccessFile.read (), FileChannel.read (), FileChannel.map ()) या देशी विधि का उपयोग फ़ाइल को पढ़ने के लिए किया जाता है ( "मुक्त" और "कैश" मान की निगरानी) के साथ माना जाता है।
  2. यदि कोई अन्य प्रक्रिया उसी फ़ाइल को लोड करने का प्रयास करती है (जबकि यह अभी भी कैश में निवासी है) तो कर्नेल यह पता लगाता है और फ़ाइल को पुनः लोड करने की आवश्यकता नहीं है। यदि पेज कैश भरा हुआ है, तो पेज बेदखल हो जाएंगे - गंदे लोगों को डिस्क पर वापस लिखा जा रहा है। (यदि डिस्क पर स्पष्ट फ्लश है, और समय-समय पर, कर्नेल थ्रेड के साथ पृष्ठ भी लिखे जाते हैं)।
  3. कैश में पहले से ही एक बड़ी (बड़ी) फ़ाइल होने से एक महत्वपूर्ण प्रदर्शन को बढ़ावा मिलता है, यह उन अंतरों की तुलना में बहुत अधिक है जिनके आधार पर हम उस फ़ाइल को खोलने / पढ़ने के लिए जावा विधियों का उपयोग करते हैं।
  4. Mmap सिस्टम कॉल करने वाला AC प्रोग्राम एक ANONYMOUS मैपिंग कर सकता है, जो अनिवार्य रूप से कैश में ऐसे पेज आवंटित करता है जो वास्तविक फ़ाइल द्वारा समर्थित नहीं हैं (इसलिए डिस्क पर वास्तविक राइट्स जारी करने की कोई आवश्यकता नहीं है), लेकिन जावा नहीं लगता यह बताने के लिए कि ( tmpfs में फाइल मैप करना एक ही बात को पूरा करेगा?)
  5. यदि कोई फ़ाइल mmap सिस्टम कॉल (C) या FileChannel.map () (जावा) के माध्यम से लोड की जाती है, तो अनिवार्य रूप से फ़ाइल के पृष्ठ (कैश में) प्रक्रिया के पते के स्थान में सीधे लोड होते हैं। किसी फ़ाइल को खोलने के लिए अन्य तरीकों का उपयोग करते हुए, फ़ाइल को पृष्ठों में लोड किया जाता है, प्रक्रिया के पते के स्थान में नहीं, और फिर उस फ़ाइल को पढ़ने / लिखने के विभिन्न तरीके / उन पृष्ठों से / प्रक्रिया के पते के स्थान में बफर में उन पृष्ठों को कॉपी करते हैं। । उस प्रतिलिपि से बचने के लिए एक स्पष्ट प्रदर्शन लाभ है, लेकिन मेरा प्रश्न प्रदर्शन से चिंतित नहीं है।

इसलिए सारांश में, अगर मैं सही ढंग से समझता हूं - मैपिंग एक प्रदर्शन लाभ प्रदान करता है, तो ऐसा नहीं लगता है कि यह किसी भी "साझा स्मृति" कार्यक्षमता प्रदान करता है जो हमें पहले से ही लिनक्स और पेज कैश की प्रकृति से नहीं मिलता है।

इसलिए, कृपया मुझे बताएं कि मेरी समझ कहां है।

धन्यवाद।

22/05/2020 को 21:20
का स्रोत उपयोगकर्ता
अन्य भाषाओं में...                            


2 जवाब

वोट
0

प्रदर्शन, और समवर्ती परिवर्तन और स्मृति उपयोग: वर्थ तीन बिंदुओं का उल्लेख करता है।

आप आकलन में सही हैं कि एमएमएपी-आधारित आमतौर पर फ़ाइल आधारित आईओ पर प्रदर्शन लाभ प्रदान करेगा। विशेष रूप से, प्रदर्शन लाभ महत्वपूर्ण है अगर कोड फ़ाइल के आर्टिवर्थ प्वाइंट पर बहुत छोटे आईओ का प्रदर्शन करता है।

एन-वें बाइट को बदलने पर विचार करें: एमएमएपी के साथ buffer[N] = buffer[N] + 1 , और फ़ाइल आधारित पहुँच के साथ आपको (कम से कम) 4 सिस्टम कॉल त्रुटि जाँच की आवश्यकता होती है:

   seek() + error check
   read() + error check
   update value
   seek() + error check
   write + error check

यह सच है कि वास्तविक IO की संख्या (डिस्क के लिए) सबसे अधिक समान है।

समवर्ती पहुंच को ध्यान में रखते हुए दूसरा बिंदु। फ़ाइल आधारित IO के साथ, आपको संभावित समवर्ती पहुँच के बारे में चिंता करनी होगी। आपको एक ही समय में गलत तरीके से एक्सेस करने के लिए दो प्रक्रियाओं को रोकने के लिए, स्पष्ट लॉकिंग (पढ़ने से पहले), और अनलॉक (लिखने के बाद) जारी करने की आवश्यकता होगी। साझा मेमोरी के साथ, परमाणु संचालन अतिरिक्त लॉक की आवश्यकता को समाप्त कर सकता है।

तीसरा बिंदु वास्तविक मेमोरी उपयोग है। उन मामलों के लिए जहां साझा किए गए ऑब्जेक्ट का आकार महत्वपूर्ण है, साझा मेमोरी का उपयोग करके बड़ी संख्या में प्रक्रियाओं को अतिरिक्त मेमोरी आवंटित किए बिना डेटा तक पहुंचने की अनुमति मिल सकती है। यदि सिस्टम स्मृति द्वारा विवश है, या ऐसी प्रणाली जिसे वास्तविक समय में प्रदर्शन प्रदान करने की आवश्यकता है, तो यह डेटा तक पहुंचने का एकमात्र तरीका हो सकता है।

29/05/2020 को 10:35
का स्रोत उपयोगकर्ता

वोट
0

मेरा सवाल है, जावा (1.8) और लिनक्स (3.10) पर, क्या मैपेडबाइटबफर्स वास्तव में साझा मेमोरी आईपीसी को लागू करने के लिए आवश्यक हैं, या क्या किसी आम फ़ाइल तक पहुंच समान कार्यक्षमता प्रदान करेगी?

यह इस बात पर निर्भर करता है कि आप साझा मेमोरी आईपीसी को क्यों लागू करना चाहते हैं।

आप साझा मेमोरी के बिना स्पष्ट रूप से आईपीसी को लागू कर सकते हैं; जैसे सॉकेट्स पर। इसलिए, यदि आप इसे प्रदर्शन कारणों से नहीं कर रहे हैं, तो साझा मेमोरी आईपीसी करना बिल्कुल भी आवश्यक नहीं है!

इसलिए प्रदर्शन किसी भी चर्चा के मूल में होना चाहिए।

जावा क्लासिक io या nio एपीआई के माध्यम से फ़ाइलों का उपयोग करके साझा मेमोरी कार्यक्षमता या प्रदर्शन प्रदान नहीं करता है।

नियमित फ़ाइल I / O या सॉकेट I / O बनाम साझा मेमोरी IPC के बीच मुख्य अंतर यह है कि पूर्व में स्पष्ट रूप से आवेदन करने की आवश्यकता होती है read तथा write संदेश भेजने और प्राप्त करने के लिए syscalls। यह अतिरिक्त syscalls पर जोर देता है, और कर्नेल कॉपी करने वाले डेटा को जोड़ता है। इसके अलावा, अगर वहाँ कई धागे आप या तो एक अलग "चैनल" प्रत्येक धागा जोड़ी के बीच की जरूरत है या एक साझा चैनल पर कई "बातचीत" गुणा करने के लिए कुछ है। उत्तरार्द्ध साझा चैनल को कंसीडर टोंटी बन सकता है।

ध्यान दें कि ये ओवरहेड लिनक्स पेज कैश में ऑर्थोगोनल हैं।

इसके विपरीत, साझा स्मृति का उपयोग करते हुए आईपीसी लागू करने के साथ, वहाँ नहीं हैं read तथा write syscalls, और कोई अतिरिक्त प्रतिलिपि चरण नहीं है। प्रत्येक "चैनल" केवल मैप किए गए बफर के एक अलग क्षेत्र का उपयोग कर सकता है। एक प्रक्रिया में एक धागा साझा स्मृति में डेटा लिखता है और यह लगभग तुरंत दूसरी प्रक्रिया के लिए दिखाई देता है।

चेतावनी यह है कि प्रक्रियाओं को 1) सिंक्रनाइज़ करने की आवश्यकता है, और 2) यह सुनिश्चित करने के लिए मेमोरी अवरोधों को लागू करें कि पाठक बासी डेटा नहीं देखता है। लेकिन इन दोनों को बिना सिस्कॉल के लागू किया जा सकता है।

वॉश-अप में, मेमोरी मैप्ड फ़ाइलों का उपयोग करके साझा की गई मेमोरी IPC >> << पारंपरिक फ़ाइलों या सॉकेट्स का उपयोग करने की तुलना में तेज़ है, और यही कारण है कि लोग ऐसा करते हैं।


आपसे यह भी स्पष्ट रूप से पूछा गया है कि क्या साझा मेमोरी IPC को मेमोरी मैप की गई फ़ाइलों के बिना लागू किया जा सकता है।

  • एक मेमोरी-फाइल फ़ाइल सिस्टम में रहने वाले फ़ाइल के लिए एक मेमोरी-मैप्ड फ़ाइल बनाने का एक व्यावहारिक तरीका होगा; लिनक्स में एक "tmpfs" की तरह।

    तकनीकी रूप से, यह अभी भी एक मेमोरी-मैप की गई फ़ाइल है। हालाँकि, आप डिस्क में फ्लशिंग डेटा के ओवरहेड्स को लाइक नहीं करते हैं, और आप निजी आईपीसी डेटा की संभावित सुरक्षा चिंता को डिस्क पर समाप्त करने से बचते हैं।

  • आप सिद्धांत में निम्नलिखित कार्य करके दो प्रक्रियाओं के बीच एक साझा खंड को लागू कर सकते हैं:

    • मूल प्रक्रिया में, सेगमेंट बनाने के लिए mmap का उपयोग करें MAP_ANONYMOUS | MAP_SHARED
    • कांटा बच्चे की प्रक्रिया। ये सभी खंडों को एक-दूसरे और मूल प्रक्रिया के साथ साझा करेंगे।

    हालाँकि, जावा प्रक्रिया के लिए इसे लागू करना ... चुनौतीपूर्ण होगा। AFAIK, Java इसका समर्थन नहीं करता है।

संदर्भ:

31/05/2020 को 06:17
का स्रोत उपयोगकर्ता

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more