मुझे लगता है कि परियोजना टंगस्टन के एकीकरण के साथ, स्पार्क स्वचालित रूप से हीप मेमोरी का उपयोग करेगा।ढेर मेमोरी कॉन्फ़िगरेशन और टंगस्टन
spark.memory.offheap.size और spark.memory.offheap.enabled के लिए क्या हैं? क्या मुझे मैन्युअल रूप से टंगस्टन के लिए ऑफ हेप मेमोरी की मात्रा निर्दिष्ट करने की आवश्यकता है?
स्पार्क/टंगस्टन जेवीएम ऑब्जेक्ट्स को अत्यधिक विशिष्ट स्पार्क एसक्यूएल प्रकार ऑब्जेक्ट्स के रूप में प्रस्तुत करने के लिए एन्कोडर्स/डिकोडर्स का उपयोग करते हैं, जिन्हें अत्यधिक उच्चतम तरीके से क्रमबद्ध और संचालित किया जा सकता है। आंतरिक प्रारूप प्रतिनिधित्व जीसी स्मृति उपयोग के लिए बेहद कुशल और मैत्रीपूर्ण है।
इस प्रकार, डिफ़ॉल्ट ऑन-हीप मोड में भी ऑपरेटिंग टंगस्टन जेवीएम ऑब्जेक्ट्स मेमोरी लेआउट और जीसी ऑपरेटिंग समय के महान ओवरहेड को कम करता है। उस मोड में टंगस्टन अपने आंतरिक उद्देश्यों के लिए ढेर पर ऑब्जेक्ट आवंटित करता है और आवंटन मेमोरी भाग बहुत बड़ा हो सकता है लेकिन यह बहुत कम होता है और जीसी पीढ़ी के संक्रमण को आसानी से बचाता है। यह लगभग इस आंतरिक संरचना को बंद करने पर विचार करने की आवश्यकता को समाप्त करता है।
इस मोड के साथ हमारे प्रयोगों में हमें और बंद में काफी समय के सुधार में सुधार नहीं हुआ। लेकिन आप ऑफ-हेप मोड के साथ क्या प्राप्त करते हैं, यह है कि आपको JVM प्रक्रिया के बाहर मेमोरी आवंटन के लिए ध्यान से डिजाइन करने की आवश्यकता है। यह YARN, Mesos इत्यादि जैसे कंटेनर प्रबंधकों के भीतर कुछ कठिनाइयों को लागू कर सकता है जब आपको अपनी जेवीएम प्रक्रिया कॉन्फ़िगरेशन के अलावा अतिरिक्त मेमोरी हिस्सों की अनुमति और योजना बनाने की आवश्यकता होगी।
इसके अलावा ऑफ-हीप मोड में टंगस्टन सूर्य का उपयोग करता है। Misc.Unsafe जो आपके तैनाती परिदृश्यों में वांछित या यहां तक कि संभव नहीं है (उदाहरण के लिए प्रतिबंधित जावा सुरक्षा प्रबंधक कॉन्फ़िगरेशन के साथ)।
मैं जोश रोजेन से एक समय टैग किए गए वीडियो कॉन्फ़्रेंस talk को साझा कर रहा हूं, जब उसे इसी तरह के प्रश्न से पूछा जा रहा है।