कंटेनर स्मृति सीमाओं से परे चल रहा है

Question

Hadoop v1 में, मैंने प्रत्येक 7 mapper और reducer स्लॉट को 1GB के आकार के साथ असाइन किया है, मेरे mappers और reducers ठीक चलते हैं। मेरी मशीन में 8 जी मेमोरी, 8 प्रोसेसर है। अब YARN के साथ, एक ही मशीन पर एक ही एप्लिकेशन चलाने पर, मुझे कंटेनर की त्रुटि मिली। डिफ़ॉल्ट रूप से, मेरे पास यह सेटिंग है:

  <property>
    <name>yarn.scheduler.minimum-allocation-mb</name>
    <value>1024</value>
  </property>
  <property>
    <name>yarn.scheduler.maximum-allocation-mb</name>
    <value>8192</value>
  </property>
  <property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>8192</value>
  </property>

इसने मुझे त्रुटि दी:

Container [pid=28920,containerID=container_1389136889967_0001_01_000121] is running beyond virtual memory limits. Current usage: 1.2 GB of 1 GB physical memory used; 2.2 GB of 2.1 GB virtual memory used. Killing container.

मैंने तब मेप्रेड-site.xml में मेमोरी लिमिट सेट करने की कोशिश की:

  <property>
    <name>mapreduce.map.memory.mb</name>
    <value>4096</value>
  </property>
  <property>
    <name>mapreduce.reduce.memory.mb</name>
    <value>4096</value>
  </property>

लेकिन अभी भी त्रुटि हो रही है:

Container [pid=26783,containerID=container_1389136889967_0009_01_000002] is running beyond physical memory limits. Current usage: 4.2 GB of 4 GB physical memory used; 5.2 GB of 8.4 GB virtual memory used. Killing container.

मैं उलझन में हूं कि मैप टास्क को इस मेमोरी की आवश्यकता क्यों है। मेरी समझ में, 1GB मेमोरी मेरे नक्शे / कार्य को कम करने के लिए पर्याप्त है। क्यों मैं कंटेनर को अधिक मेमोरी असाइन करता हूं, कार्य अधिक उपयोग करता है? क्या इसलिए कि प्रत्येक कार्य में अधिक विभाजन हो जाता है? मुझे लगता है कि कंटेनर के आकार को थोड़ा कम करना और अधिक कंटेनर बनाना अधिक कुशल है, ताकि अधिक कार्य समानांतर में चल रहे हों। समस्या यह है कि मैं यह कैसे सुनिश्चित कर सकता हूं कि प्रत्येक कंटेनर को अधिक से अधिक विभाजन नहीं सौंपे जा सकते हैं?

Comments

Hadoop यार्न कंटेनर

— शीना

नमस्ते ! आपका कॉन्फ़िगेशन 'यार्न.नोदीमेनेगर.वम-पीएमएम-अनुपात = 2'?

— स्प्राइट

Answer 1

आपको MapReduce के लिए अधिकतम मेमोरी आवंटन को ठीक से कॉन्फ़िगर करना चाहिए। से इस HortonWorks ट्यूटोरियल :

[...]

हमारे क्लस्टर में प्रत्येक मशीन में 48 जीबी रैम है। इस RAM में से कुछ को ऑपरेटिंग सिस्टम के उपयोग के लिए आरक्षित होना चाहिए। प्रत्येक नोड पर, हम ऑपरेटिंग सिस्टम के लिए 8 जीबी का उपयोग करने और रखने के लिए 40 जीबी रैम असाइन करेंगे

हमारे उदाहरण के क्लस्टर के लिए, हमारे पास एक कंटेनर (यार्न। Scheduler.minimum-आवंटन-एमबी) = 2 जीबी के लिए न्यूनतम रैम है। हम इस प्रकार मानचित्र कार्य कंटेनरों के लिए 4 जीबी और कम कार्यों वाले कंटेनरों के लिए 8 जीबी असाइन करेंगे।

Mapred-site.xml में:

mapreduce.map.memory.mb: 4096

mapreduce.reduce.memory.mb: 8192

प्रत्येक कंटेनर मैप और रिड्यूस कार्यों के लिए जेवीएम चलाएगा। JVM हीप का आकार मानचित्र से कम और ऊपर परिभाषित स्मृति को कम करने के लिए सेट किया जाना चाहिए, ताकि वे YARN द्वारा आवंटित कंटेनर मेमोरी की सीमा के भीतर हों।

Mapred-site.xml में:

mapreduce.map.java.opts: -Xmx3072m

mapreduce.reduce.java.opts: -Xmx6144m

उपर्युक्त सेटिंग्स भौतिक रैम की ऊपरी सीमा को कॉन्फ़िगर करती हैं जो मानचित्र और कटौती कार्यों का उपयोग करेगी ।

इसका सारांश प्रस्तुत करना:

1. यार्न में, आपको mapreduceकॉन्फ़िगरेशन का उपयोग करना चाहिए , न कि mapredलोगों को। संपादित करें: यह टिप्पणी अब लागू नहीं होती है कि आपने अपना प्रश्न संपादित किया है।
2. आप जो कॉन्फ़िगर कर रहे हैं वह वास्तव में आप कितना अनुरोध करना चाहते हैं, न कि आवंटित करने के लिए अधिकतम क्या है।
3. अधिकतम सीमाएं java.optsऊपर सूचीबद्ध सेटिंग्स के साथ कॉन्फ़िगर की गई हैं ।

अंत में, आप इस अन्य SO प्रश्न की जाँच कर सकते हैं जो एक समान समस्या (और समाधान) का वर्णन करता है।

Comments

हाँ। मेरी समस्या का समाधान mapreduce.map.java.optsऔर mapreduce.reduce.java.optsसमाधान करके । क्या आपको पता है कि कार्य को सौंपी गई वास्तविक स्मृति केवल द्वारा परिभाषित की गई है mapreduce.map/reduce.memory.mb? yarn.scheduler.minimum-allocation-mbवास्तविक मेमोरी असाइनमेंट को कैसे प्रभावित करता है ?

— लिशु

@lishu, अगर इससे मदद मिली, तो कृपया जवाब स्वीकार करें। आपके अंतिम प्रश्न के बारे में, क्लस्टर में किसी भी कंटेनर आवंटन पर यार्न सेटिंग लागू होती है; इसमें मानचित्र और कार्य कम करना शामिल है, लेकिन अन्य प्रकार के एप्लिकेशन से अन्य कार्य भी शामिल हैं। Mapreduce सेटिंग्स केवल mapreduce नौकरियों के लिए लागू होते हैं।

— कबड्डी

@ कबाड़, मैं एक लिब का विकास करता हूं जो लिशु उपयोग कर रहा है। मैं सोच रहा था कि क्या आप अपने जवाब में कुछ भी बदलेंगे, यह जानकर कि एमआर कार्य एक ऐसी प्रक्रिया को जन्म दे रहा है जो वास्तव में अधिकांश मेमोरी (हडूप स्ट्रीमिंग) आवंटित कर रहा है। निश्चित रूप से एक्सएमएक्स सेटिंग बाहरी प्रक्रिया को प्रभावित नहीं करती है, क्योंकि यह एक जावा प्रोग्राम नहीं है। आपकी सहायता के लिए धन्यवाद।

— piccolbo

अनुशंसित मूल्यों को प्राप्त करने के लिए एचडीपीआर-कॉन्फ़िगरेशन-बर्तनों नामक हॉर्टोनवर्क्स से अब एक उपयोगी उपकरण है। इसे github.com/hortonworks/hdp-configuration-utils

— selle

यदि उचित मेमोरी कॉन्फ़िगरेशन लागू करने से समस्या ठीक नहीं हुई (जैसे कि मेरे मामले में, वास्तव में इसने ubuntu पर नहीं बल्कि CentOS पर काम किया है) पर vmem चेक को अक्षम करने का प्रयास करें: blog.cloudera.com/blog/2014/04/…

— बख्शी

Answer 2

वर्चुअल और भौतिक मेमोरी उपयोग अनुपात के लिए यार्न के स्तर पर एक चेक रखा गया है। समस्या केवल यह नहीं है कि VM के पास पर्याप्त भौतिक मेमोरी नहीं है। लेकिन यह इसलिए है क्योंकि वर्चुअल मेमोरी का उपयोग दी गई भौतिक मेमोरी के लिए अपेक्षा से अधिक है।

नोट : यह वर्चुअल मेमोरी के आक्रामक आवंटन के कारण सेंटोस / आरएचईएल 6 पर हो रहा है।

इसे या तो हल किया जा सकता है:

1. स्थापना करके आभासी स्मृति के उपयोग की जांच अक्षम yarn.nodemanager.vmem की जांच-सक्षम करने के लिए झूठी ;

2. VM को बढ़ाएं: यार्न को निर्धारित करके पीएम अनुपात। nodemanager.vmem-pmem- अनुपात कुछ उच्च मूल्य पर।

संदर्भ :

https://issues.apache.org/jira/browse/HADOOP-11364

http://blog.cloudera.com/blog/2014/04/apache-hadoop-yarn-avoiding-6-time-consuming-gotchas/

यार्न- site.xml में निम्नलिखित संपत्ति जोड़ें

 <property>
   <name>yarn.nodemanager.vmem-check-enabled</name>
    <value>false</value>
    <description>Whether virtual memory limits will be enforced for containers</description>
  </property>
 <property>
   <name>yarn.nodemanager.vmem-pmem-ratio</name>
    <value>4</value>
    <description>Ratio between virtual memory to physical memory when setting memory limits for containers</description>
  </property>

Answer 3

मैं वास्तव में EMR में HIVE का उपयोग करने के समान मुद्दा था। मेरे लिए कोई भी अतिरिक्त समाधान काम नहीं किया - अर्थात, मेरे लिए किसी भी मानचित्रण विन्यास ने काम नहीं किया; और न ही yarn.nodemanager.vmem-check-enabledझूठी करने के लिए सेटिंग ।

हालाँकि, काम करना समाप्त हो गया था tez.am.resource.memory.mb, उदाहरण के लिए:

hive -hiveconf tez.am.resource.memory.mb=4096

ट्विकिंग पर विचार करने के लिए एक और सेटिंग है yarn.app.mapreduce.am.resource.mb

Comments

उम @ अहिंसाविद्यावादी, क्या आपको पता है कि यार्न के शुरू होने से पहले यार्न पैरामीटर को "ट्विक करना" होता है या यदि यह केवल आवेदन के समय उपयोग किया जाता है (और इसे एक नौकरी से दूसरी में बदला जा सकता है)?

— जज मेंटल

मैं आवेदन समय पर सेट करने में सक्षम हूं। विशेष रूप से, हाइव इंटरएक्टिव कंसोल के भीतर।

— हिरोपोट्रॉनिगिस्ट

Answer 4

कम प्रतिष्ठा के कारण मैं स्वीकृत उत्तर पर टिप्पणी नहीं कर सकता। हालांकि, मैं जोड़ना चाहूंगा, यह व्यवहार डिजाइन द्वारा है। NodeManager आपके कंटेनर को मार रहा है। ऐसा लगता है कि आप हडूप स्ट्रीमिंग का उपयोग करने की कोशिश कर रहे हैं, जो कि नक्शे को कम करने वाले कार्य की एक बाल प्रक्रिया के रूप में चल रही है। NodeManager कार्य की पूरी प्रक्रिया के पेड़ की निगरानी करता है और यदि वह क्रमशः mapreduce.map.memory.mb या mapreduce.reduce.memory.mb में अधिकतम सेट की तुलना में अधिक मेमोरी खाता है, तो हम Nodagager से कार्य को मारने की अपेक्षा करेंगे, अन्यथा आपका कार्य अन्य कंटेनरों से संबंधित मेमोरी को चुरा रहा है, जो आप नहीं चाहते हैं।

Answer 5

ईएमआर में स्पार्क के साथ काम करते समय मुझे एक ही समस्या थी और सेटिंग maximizeResourceAllocation=trueने चाल चली; आशा है कि यह किसी की मदद करता है। क्लस्टर बनाते समय आपको इसे सेट करना होगा। से ईएमआर डॉक्स:

aws emr create-cluster --release-label emr-5.4.0 --applications Name=Spark \
--instance-type m3.xlarge --instance-count 2 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --configurations https://s3.amazonaws.com/mybucket/myfolder/myConfig.json

MyConfig.json को कहां कहना चाहिए:

[
  {
    "Classification": "spark",
    "Properties": {
      "maximizeResourceAllocation": "true"
    }
  }
]

Answer 6

हमने हाल ही में इस मुद्दे का भी सामना किया। यदि समस्या मैपर मेमोरी से संबंधित है, तो कुछ चीजें जो मैं सुझाव देना चाहूंगा कि जाँच की जानी चाहिए।

• जांच लें कि कंबाइन सक्षम है या नहीं ? यदि हाँ, तो इसका मतलब है कि लॉजिक को कम करना सभी रिकॉर्ड (मैपर के आउटपुट) पर चलना है। स्मृति में ऐसा होता है। आपके आवेदन के आधार पर आपको यह जांचने की आवश्यकता है कि कंबाइन को सक्षम करने में मदद मिलती है या नहीं। रिकॉर्ड ऑफ के 'X' नंबर पर लॉजिक को कम करने के लिए नेटवर्क ट्रांसफर बाइट्स और लिया गया समय / मेमोरी / CPU के बीच व्यापार बंद है।
  • यदि आपको लगता है कि कॉम्बिनर बहुत अधिक मूल्य का नहीं है, तो इसे अक्षम करें।
  • यदि आपको कॉम्बिनर की आवश्यकता है और 'X' एक बड़ी संख्या है (लाखों रिकॉर्ड कहिए) तो अपने विभाजित तर्क को बदलने पर विचार करें (डिफ़ॉल्ट इनपुट स्वरूपों में कम ब्लॉक आकार, सामान्य रूप से 1 ब्लॉक आकार = 1 विभाजन) का उपयोग करके रिकॉर्ड की कम संख्या दर्ज करें। सिंगल मैपर।
• एकल मैपर में संसाधित होने वाले रिकॉर्ड की संख्या। याद रखें कि इन सभी रिकॉर्ड्स को मेमोरी में सॉर्ट किया जाना चाहिए (मैपर का आउटपुट सॉर्ट किया गया है)। यदि आवश्यक हो तो mapreduce.task.io.sort.mb (डिफ़ॉल्ट 200 एमबी) को उच्च मान पर सेट करने पर विचार करें । mapred-configs.xml
• यदि उपर्युक्त में से किसी ने भी मदद नहीं की, तो मैपर लॉजिक को एक स्टैंडअलोन एप्लिकेशन के रूप में चलाने का प्रयास करें और एक प्रोफाइलर (जैसे JProfiler) का उपयोग करके एप्लिकेशन को प्रोफ़ाइल करें और देखें कि मेमोरी कहाँ उपयोग की जा रही है। यह आपको बहुत अच्छी अंतर्दृष्टि दे सकता है।

Answer 7

Ubunto OS के साथ विंडोज लिनक्स सबसिस्टम पर रनिंग यार्न, "वर्चुअल मेमोरी सीमाओं से परे चल रहा है, किलिंग कंटेनर" मैंने फ़ाइल यार्न-site.xml में वर्चुअल मेमोरी चेक को अक्षम करके इसे हल किया

<property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property> 

Comments

डब्लूएसएल पर, त्रुटि संदेश में बेतुके नंबर हैं (कम से कम मेरे लिए): "... आभासी स्मृति सीमाओं से परे चल रहा है। वर्तमान उपयोग: 338.8 एमबी 2 जीबी भौतिक मेमोरी का उपयोग किया गया; 481.1 जीबी 4.2 जीबी वर्चुअल मेमोरी का उपयोग किया। किलिंग कंटेनर। । "

— सामिक आर

@SamikR हां, मेरी भी ऐसी ही स्थिति है, मुझे लगता है कि यह हडूप मुद्दे नहीं हैं, यह डब्ल्यूएसएल मुद्दे हैं। शायद मुझे डेमो को एक वास्तविक लिनक्स ओएस कंप्यूटर पर स्थानांतरित करने की आवश्यकता है

— बिंगोआबस

Answer 8

मैंने व्यक्तिगत रूप से जाँच नहीं की है, लेकिन हडूप-यार्न-कंटेनर-वर्चुअल-मेमोरी-समझ-और-सॉल्विंग-कंटेनर-रनिंग-परे-वर्चुअल-मेमोरी-लिमिटेशंस-एरर्स बहुत उचित लगता है

मैंने yarn.nodemanager.vmem-pmem-ratioउच्च मूल्य में बदलकर समस्या हल की , और मैं इस बात से सहमत होऊंगा:

एक और कम अनुशंसित समाधान यार्न को स्थापित करके वर्चुअल मेमोरी चेक को अक्षम करना है।