2011-11-05 11 views
9

के साथ मेमोरी सीमा निर्दिष्ट करना मैं एक हडोप क्लस्टर (0.20.203) पर एक उच्च-स्मृति नौकरी चलाने की कोशिश कर रहा हूं। मैंने कुछ स्मृति सीमाओं को लागू करने के लिए mapred-site.xml को संशोधित किया।हडूप

<property> 
    <name>mapred.cluster.max.map.memory.mb</name> 
    <value>4096</value> 
    </property> 
    <property> 
    <name>mapred.cluster.max.reduce.memory.mb</name> 
    <value>4096</value> 
    </property> 
    <property> 
    <name>mapred.cluster.map.memory.mb</name> 
    <value>2048</value> 
    </property> 
    <property> 
    <name>mapred.cluster.reduce.memory.mb</name> 
    <value>2048</value> 
    </property> 

मेरी नौकरी में, मैं यह निर्दिष्ट कर रहा हूं कि मुझे कितनी मेमोरी चाहिए। दुर्भाग्यवश, भले ही मैं -Xmx2g के साथ अपनी प्रक्रिया चला रहा हूं (जॉब कंसोल एप्लिकेशन के रूप में इस स्मृति के साथ ठीक से चल रहा है) मुझे अपने मैपर के लिए और अधिक मेमोरी का अनुरोध करने की आवश्यकता है (एक सबक्वेस्टियन के रूप में, यह क्यों है?) या यह है मारे गए।

val conf = new Configuration() 
conf.set("mapred.child.java.opts", "-Xms256m -Xmx2g -XX:+UseSerialGC"); 
conf.set("mapred.job.map.memory.mb", "4096"); 
conf.set("mapred.job.reduce.memory.mb", "1024"); 

रेड्यूसर को किसी भी स्मृति की आवश्यकता नहीं है क्योंकि मैं पहचान reducer कर रहा हूँ।

class IdentityReducer[K, V] extends Reducer[K, V, K, V] { 
    override def reduce(key: K, 
     values: java.lang.Iterable[V], 
     context:Reducer[K,V,K,V]#Context) { 
     for (v <- values) { 
     context write (key, v) 
     } 
    } 
    } 

हालांकि, रेड्यूसर अभी भी बहुत सारी मेमोरी का उपयोग कर रहा है। क्या मैपर से रेड्यूसर अलग जेवीएम तर्क देना संभव है? हैडोप रेड्यूसर को मारता है और दावा करता है कि यह 3 9 60 एमबी मेमोरी का उपयोग कर रहा है! और reducers नौकरी में विफल होने के अंत में समाप्त होता है। यह कैसे संभव है?

TaskTree [pid=10282,tipID=attempt_201111041418_0005_r_000000_0] is running beyond memory-limits. 
Current usage : 4152717312bytes. 
Limit : 1073741824bytes. 
Killing task. 

अद्यतन: यहां तक ​​कि जब मैं cat नक्शाकार के रूप में और uniq कम करने के रूप में और -Xms512M -Xmx1g -XX:+UseSerialGC अपने कार्यों आभासी स्मृति के 2 जी अपने हाथ में लेने के साथ एक स्ट्रीमिंग का काम निर्दिष्ट! यह अधिकतम ढेर आकार 4x पर असाधारण लगता है।

TaskTree [pid=3101,tipID=attempt_201111041418_0112_m_000000_0] is running beyond memory-limits. 
Current usage : 2186784768bytes. 
Limit : 2147483648bytes. 
Killing task. 

अद्यतन: original JIRA स्मृति के उपयोग के लिए विन्यास प्रारूप को बदलने के लिए विशेष रूप से कहा गया है कि जावा उन ज्यादातर ताड़ना को रोकने के लिए भौतिक स्मृति में रुचि रखते हैं। मुझे लगता है कि यह वही है जो मैं चाहता हूं: यदि कोई अपर्याप्त भौतिक स्मृति उपलब्ध नहीं है तो मैं एक नोड को मैपर को स्पिन करना नहीं चाहता हूं। हालांकि, इन विकल्पों को वर्चुअल मेमोरी बाधाओं के रूप में लागू किया गया प्रतीत होता है, जिन्हें प्रबंधित करना मुश्किल होता है।

+0

बस उत्सुक - mapred.child.java.opts/-Xmx और mapred.job.map.memory.mb/mapred.job.reduce.memory.mb का उपयोग कर अधिकतम मेमोरी सेट करने के बीच क्या अंतर है? मैंने SO (http://goo.gl/aIBLr) में एक प्रश्न उठाया है, लेकिन कोई प्रतिक्रिया नहीं है। –

उत्तर

6

अपने उलिमिट की जांच करें। Cloudera, संस्करण 0.20.2 पर है, लेकिन से वही समस्या शायद बाद के संस्करणों के लिए लागू होता है:

... यदि आप mapred.child.ulimit निर्धारित करते हैं, यह महत्वपूर्ण है कि इसे और अधिक दो बार से ढेर होना चाहिए mapred.child.java.opts में आकार मान सेट करें। उदाहरण के लिए, यदि आप 1 जी ढेर सेट करते हैं, तो mapred.child.ulimit को 2.5GB पर सेट करें। चाइल्ड प्रक्रियाओं को अब कम से कम एक बार कांटा की गारंटी दी जाती है, और कांटा को आभासी स्मृति में दो बार ओवरहेड की आवश्यकता होती है।

यह भी संभव है कि mapred.child.java.opts को प्रोग्रामेटिक रूप से सेट करना "बहुत देर हो चुकी है"; हो सकता है कि आप इसे सत्यापित करना चाहें कि वास्तव में प्रभाव में जा रहा है, और यदि इसे नहीं, तो इसे अपने mapred-site.xml में डाल दें।

+1

ऐसा लगता है कि 'ulimit' 'mapred.job.reduce.memory.mb' की तुलना में एक कठोर बाधा है और यह मेरी स्थापना में सेट नहीं है। हालांकि यह एक सहायक संदर्भ है कि वीएम को कितना अनुमति है ... – schmmd

संबंधित मुद्दे