अपाचे स्पार्क: कोर की संख्या बनाम निष्पादकों की संख्या

194

मैं YARN पर स्पार्क की नौकरी चलाते समय कोर की संख्या और निष्पादनकर्ताओं की संख्या के संबंध को समझने की कोशिश कर रहा हूं।

परीक्षण वातावरण इस प्रकार है:

  • डेटा नोड्स की संख्या: 3
  • डेटा नोड मशीन कल्पना:
    • सीपीयू: कोर i7-4790 (कोर का #: 4, # धागे का: 8)
    • RAM: 32GB (8GB x 4)
    • HDD: 8TB (2TB x 4)

  • नेटवर्क: 1 जीबी

  • स्पार्क संस्करण: 1.0.0

  • Hadoop संस्करण: 2.4.0 (होर्टनवर्क्स HDP 2.1)

  • स्पार्क नौकरी का प्रवाह: sc.textFile -> फ़िल्टर -> मानचित्र -> फ़िल्टर -> mapToPair -> कम करेंबायके -> मानचित्र -> saveAsTextFile

  • इनपुट डेटा

    • प्रकार: एकल पाठ फ़ाइल
    • आकार: 165GB
    • लाइनों की संख्या: 454,568,833

  • उत्पादन

    • दूसरे फिल्टर के बाद लाइनों की संख्या: 310,640,717
    • परिणाम फ़ाइल की पंक्तियों की संख्या: 99,848,268
    • परिणाम फ़ाइल का आकार: 41 जीबी

निम्नलिखित कॉन्फ़िगरेशन के साथ काम चलाया गया था:

  1. --master yarn-client --executor-memory 19G --executor-cores 7 --num-executors 3 (डेटा नोड के अनुसार निष्पादक, कोर जितना उपयोग करें)

  2. --master yarn-client --executor-memory 19G --executor-cores 4 --num-executors 3 (# कोर की कमी)

  3. --master yarn-client --executor-memory 4G --executor-cores 2 --num-executors 12 (कम कोर, अधिक निष्पादक)

बीता हुआ समय:

  1. 50 मिनट 15 सेकंड

  2. 55 मिनट 48 सेकेंड

  3. 31 मिनट 23 सेकंड

मेरे आश्चर्य करने के लिए, (3) बहुत तेज था।
मैंने सोचा था कि (1) तेजी से होगा, क्योंकि फेरबदल करते समय कम अंतर-निष्पादक संचार होगा।
हालाँकि (#) कोर का # (3) से कम है, #of कोर 2 से महत्वपूर्ण कारक नहीं है) ने अच्छा प्रदर्शन किया।

(Pwilmot के जवाब के बाद फॉलोवर्स जोड़े गए।)

जानकारी के लिए, प्रदर्शन मॉनिटर स्क्रीन कैप्चर इस प्रकार है:

  • (1) के लिए गंगालिया डेटा नोड सारांश - नौकरी 04:37 पर शुरू हुई।

(1) के लिए गंगालिया डेटा नोड सारांश

  • (3) के लिए गंगालिया डेटा नोड सारांश - नौकरी 19:47 पर शुरू हुई। कृपया उस समय से पहले ग्राफ़ को अनदेखा करें।

(3) के लिए गंगालिया डेटा नोड सारांश

ग्राफ लगभग 2 वर्गों में विभाजित है:

  • पहला: शुरू से घटाना शुरू करें: CPU गहन, कोई नेटवर्क गतिविधि नहीं
  • दूसरा: कम करने के बादबायके: सीपीयू कम, नेटवर्क I / O किया जाता है।

जैसा कि ग्राफ से पता चलता है, (1) सीपीयू शक्ति का उतना ही उपयोग कर सकते हैं जितना कि दिया गया था। तो, यह थ्रेड्स की संख्या की समस्या नहीं हो सकती है।

इस परिणाम की व्याख्या कैसे करें?

hadoop  apache-spark  yarn 
— zeodtr
स्रोत
2
अब मुझे GC पर संदेह हो रहा है ... वास्तव में, स्पार्क UI पर GC के लिए बिताया गया कुल समय 2 की तुलना में 1) लंबा है।
— मार्च को zeodtr
आपने 19G के साथ 3) की कोशिश क्यों नहीं की? क्या ऐसा हो सकता है कि 4 जी पर श्रमिकों को भ्रमित करने से एनयूएमए प्रभाव कम हो जाए जो कुछ पीपीएल में हो? यानी आपका 4 जी आपके वर्कफ़्लो को आवंटित 2 कोर में से एक पर स्थित है और इस प्रकार कम i / o मंदी है, जिससे बेहतर समग्र प्रदर्शन हो सकता है। अन्यथा मुझे लगता है कि एक मुख्य सवाल यह है: एक कार्यकर्ता पर कितने कोर / थ्रेड एक एकल निष्पादक का उपयोग कर सकते हैं? (एक कार्यकर्ता के लिए केवल कोर की कुल संख्या निर्दिष्ट कर सकता है, निष्पादनकर्ता की विशिष्टता पर नहीं)
— बेकन
4
Btw मैंने अभी कोर / src / main / scala / org / apache / spark / तैनात / कार्यकर्ता / ExecutorRunner.scala पर कोड की जाँच की और ऐसा लगता है कि 1 निष्पादक = 1 कार्यकर्ता का धागा।
— बेकन
थोड़ा देर से लेकिन यहाँ इस विषय पर क्लाउडडेरा पर एक पोस्ट है: blog.cloudera.com/blog/2015/03/…
— Orelus
1
वैसे, मैं एक क्लाउडेरा स्लाइड डेक में यह जानकारी पाया slideshare.net/cloudera/... , कि executors, कोर में निर्णय लेने और स्मृति के बारे में थोड़ा बताते हैं
— मनीष साहनी

जवाबों:

58

उम्मीद है कि यह सब थोड़ा और अधिक ठोस बनाने के लिए, यहाँ एक स्पार्क ऐप को यथासंभव क्लस्टर के रूप में उपयोग करने के लिए कॉन्फ़िगर करने का एक काम किया गया उदाहरण है: NodeManagers चलाने वाले छह नोड्स के साथ एक क्लस्टर की कल्पना करें , प्रत्येक 16 कोर और 64 जीबी मेमोरी से सुसज्जित है। । NodeManager की क्षमताएं, यार्न। Nodemanager.resource.memory-mb और यार्न .nodemanager.resource.cpu-vcores, संभवतः 63 * 1024 = 64512 (मेगाबाइट) और 15 पर सेट होने चाहिए। हम YARN कंटेनरों को 100% संसाधन आवंटित करने से बचते हैं क्योंकि नोड को OS और Hadoop डेमॉन चलाने के लिए कुछ संसाधनों की आवश्यकता होती है। इस मामले में, हम इन सिस्टम प्रक्रियाओं के लिए एक गीगाबाइट और एक कोर छोड़ते हैं। क्लाउड प्रबंधक इन के लिए लेखांकन और इन YARN गुणों को स्वचालित रूप से कॉन्फ़िगर करने में मदद करता है।

संभावना सबसे पहले आवेग का उपयोग करने के लिए किया जाएगा --num- निष्पादक 6 --executor-cores 15 --executor-memory 63G । हालाँकि, यह गलत तरीका है क्योंकि:

63GB + निष्पादक मेमोरी ओवरहेड NodeManagers की 63GB क्षमता के भीतर फिट नहीं होगी। एप्लिकेशन मास्टर नोड्स में से एक पर एक कोर ले जाएगा, जिसका अर्थ है कि उस नोड पर 15-कोर निष्पादक के लिए जगह नहीं होगी। प्रति निष्पादित 15 कोर खराब एचडीएफएस I / O थ्रूपुट का कारण बन सकता है।

एक बेहतर विकल्प का उपयोग करने के लिए होगा - एनम-एक्ज़ीक्यूटर्स 17 - एक्सीलेटर-कोर 5 - एक्सील्यूटर-मेमोरी 19 जी । क्यों?

यह कॉन्फ़िगरेशन AM के साथ वाले को छोड़कर सभी नोड्स पर तीन निष्पादकों का परिणाम है, जिसमें दो निष्पादक होंगे। --exexor-memory को (63/3 निष्पादक प्रति नोड) = 21. 21 * 0.07 = 1.47 के रूप में प्राप्त किया गया था। 21 - 1.47 ~ 19।

क्लूडेरा के ब्लॉग, हाउ-टू: ट्यून योर अपाचे स्पार्क जॉब्स (भाग 2) में एक लेख में स्पष्टीकरण दिया गया था ।

— DzOrdre
स्रोत
1
"यह एएम के साथ वाले को छोड़कर सभी नोड्स पर तीन निष्पादकों में परिणाम करता है, जिसमें दो निष्पादक होंगे।" इसका क्या अर्थ है "--exexor-cores 5" के साथ?
— derek
इसका मतलब है कि प्रत्येक निष्पादक 5 कोर का उपयोग करता है। प्रत्येक नोड में 3 निष्पादक होते हैं, इसलिए 15 कोर का उपयोग करते हुए, नोड्स में से एक को छोड़कर नौकरी के लिए एप्लिकेशन मास्टर भी चल रहा होगा, इसलिए केवल 2 निष्पादक अर्थात 10 कोर को निष्पादक के रूप में उपयोग कर सकते हैं।
— दावोस १
अच्छी तरह से समझाया - कृपया ध्यान दें कि यह yarn.scheduler.capacity.resource-calculatorअक्षम पर लागू होता है , जो कि डिफ़ॉल्ट है। ऐसा इसलिए है क्योंकि डिफ़ॉल्ट रूप से यह मेमोरी द्वारा शेड्यूल करता है और सीपीयू द्वारा नहीं।
— योयो
1
अधिक निष्पादक खराब एचडीएफएस I / O थ्रूपुट का नेतृत्व कर सकते हैं। तो अगर मैं एचडीएफएस का उपयोग बिल्कुल नहीं कर रहा हूं, तो उस स्थिति में मैं 5 कोर प्रति निष्पादन का उपयोग कर सकता हूं?
— दर्शन
हालांकि मैं अनुप्रयोग मास्टर प्रत्येक नोड पर चलाता हूं। प्रति से ऊपर, जिसका अर्थ है कि नौकरी चलाने के लिए केवल 1 आवेदन मास्टर होगा। क्या वो सही है?
— रोशन फर्नांडो
15

जैसा कि आप अपने स्पार्क ऐप को HDFS के शीर्ष पर चलाते हैं, सैंडी रियाज़ के अनुसार

मैंने देखा है कि HDFS क्लाइंट को समवर्ती धागे के टन से परेशानी होती है। एक मोटा अनुमान यह है कि प्रति निष्पादक अधिकतम पांच कार्य पूर्ण लेखन थ्रूपुट को प्राप्त कर सकता है, इसलिए उस संख्या के नीचे प्रति निष्पादन कोर की संख्या को रखना अच्छा है।

इसलिए मेरा मानना ​​है कि आपका पहला कॉन्फ़िगरेशन तीसरे की तुलना में धीमा है क्योंकि खराब HDFS I / O थ्रूपुट है

— tgbaggio
स्रोत
11

मैंने स्वयं इन सेटिंग्स के साथ नहीं खेला है, इसलिए यह सिर्फ अटकलें हैं लेकिन अगर हम इस मुद्दे के बारे में एक वितरित प्रणाली में सामान्य कोर और धागे के रूप में सोचते हैं तो अपने क्लस्टर में आप 12 कोर (4 * 3 मशीन) और 24 धागे का उपयोग कर सकते हैं (8 * 3 मशीनें)। आपके पहले दो उदाहरणों में आप अपनी नौकरी को उचित संख्या में कोर (संभावित गणना स्थान) दे रहे हैं, लेकिन उन कोर पर चलने वाले थ्रेड्स (नौकरियों) की संख्या इतनी सीमित है कि आप आवंटित प्रसंस्करण शक्ति का अधिक उपयोग करने में सक्षम नहीं हैं और इस तरह नौकरी धीमी होने के बावजूद अधिक संगणना संसाधन आवंटित किए जाते हैं।

आप उल्लेख करते हैं कि आपकी चिंता फेरबदल कदम में थी - जबकि फेरबदल कदम में ओवरहेड को सीमित करना अच्छा है, यह आमतौर पर क्लस्टर के समानांतर उपयोग के लिए बहुत अधिक महत्वपूर्ण है। चरम मामले के बारे में सोचो - शून्य फेरबदल के साथ एक एकल पिरोया कार्यक्रम।

— pwilmot
स्रोत
आपके उत्तर के लिए धन्यवाद। लेकिन मुझे संदेह है कि थ्रेड्स की संख्या मुख्य समस्या नहीं है। मैंने मॉनिटरिंग स्क्रीन कैप्चर जोड़ा है। जैसा कि ग्राफ़ दिखाता है, 1) सीपीयू की उतनी ही शक्ति का उपयोग कर सकता है जितना दिया गया था।
— मार्च को zeodtr
1
@zeodtr pwilmot सही है - आपको अपने कोर की पूरी क्षमता का उपयोग करने के लिए 2-4 कार्यों की आवश्यकता है। यह रखो यह था - मैं आमतौर पर अपने 80 कोर क्लस्टर के लिए कम से कम 1000 विभाजन का उपयोग करता हूं।
— samthebest
@samthebest मैं जो जानना चाहता हूं वह 1) और 3) के बीच के अंतर का कारण है। जब मैं स्पार्क यूआई देखता हूं, तो दोनों धारा 2 में समानांतर में 21 कार्य चलाते हैं (3 के मामले में 24 के बजाय 21 क्यों) अब अज्ञात है) लेकिन, 3 के लिए कार्य) बस तेजी से चलता है।
— जियोट्रेट
10

संक्षिप्त उत्तर : मुझे लगता है कि tgbaggio सही है। आपने अपने निष्पादकों पर HDFS थ्रूपुट सीमाएं मार दीं।

मुझे लगता है कि यहां का जवाब यहां की कुछ सिफारिशों से थोड़ा सरल हो सकता है।

मेरे लिए सुराग क्लस्टर नेटवर्क ग्राफ में है। रन 1 के लिए उपयोग ~ 50 M बाइट्स / s पर स्थिर है। रन 3 के लिए स्थिर उपयोग दोगुना हो गया है, लगभग 100 एम बाइट्स / एस।

से क्लाउडेरा ब्लॉग पोस्ट द्वारा साझा DzOrd , तो आप इस महत्वपूर्ण उद्धरण देख सकते हैं:

मैंने देखा है कि HDFS क्लाइंट को समवर्ती धागे के टन से परेशानी होती है। एक मोटा अनुमान यह है कि प्रति निष्पादक अधिकतम पाँच कार्य पूर्ण लेखन थ्रूपुट को प्राप्त कर सकता है, इसलिए उस संख्या के नीचे प्रति निष्पादनकर्ता कोर की संख्या रखना अच्छा है।

तो, चलिए कुछ गणना करते हैं कि क्या प्रदर्शन की उम्मीद है अगर हम सच है।

रन 1: 19 जीबी, 7 कोर, 3 निष्पादक

  • 3 निष्पादक x 7 सूत्र = 21 सूत्र
  • 7 कोर प्रति निष्पादक के साथ, हम HDO तक सीमित IO की उम्मीद करते हैं (अधिकतम 5 कोर पर)
  • प्रभावी थ्रूपुट ~ = 3 निष्पादक x 5 थ्रेड = 15 थ्रेड

रन 3: 4 जीबी, 2 कोर, 12 निष्पादक

  • 2 निष्पादक x 12 सूत्र = 24 सूत्र
  • 2 कोरस प्रति निष्पादक, इसलिए hdfs थ्रूपुट ठीक है
  • प्रभावी थ्रूपुट ~ = 12 निष्पादक x 2 थ्रेड = 24 थ्रेड

यदि कार्य समवर्ती (थ्रेड्स की संख्या) 100% सीमित है। हम उम्मीद करेंगे कि थ्रेड्स की संख्या के साथ रनटाइम पूरी तरह से परस्पर संबंधित होगा।

ratio_num_threads = nthread_job1 / nthread_job3 = 15/24 = 0.625
inv_ratio_runtime = 1/(duration_job1 / duration_job3) = 1/(50/31) = 31/50 = 0.62

इसलिए ratio_num_threads ~= inv_ratio_runtime, और ऐसा लगता है कि हम नेटवर्क सीमित हैं।

यही प्रभाव रन 1 और रन 2 के बीच के अंतर को बताता है।

रन 2: 19 जीबी, 4 कोर, 3 निष्पादक

  • 3 निष्पादक x 4 सूत्र = 12 सूत्र
  • प्रति एग्जीक्यूटिव के साथ 4 कोर, एचडीएफ के लिए ओके आईओ
  • प्रभावी थ्रूपुट ~ = 3 निष्पादक x 4 थ्रेड = 12 थ्रेड

प्रभावी थ्रेड्स और रनटाइम की संख्या की तुलना:

ratio_num_threads = nthread_job2 / nthread_job1 = 12/15 = 0.8
inv_ratio_runtime = 1/(duration_job2 / duration_job1) = 1/(55/50) = 50/55 = 0.91

यह पिछली तुलना की तरह बिल्कुल सही नहीं है, लेकिन हम अभी भी प्रदर्शन में एक समान गिरावट देखते हैं जब हम धागे खो देते हैं।

अब अंतिम बिट के लिए: ऐसा क्यों है कि हम अधिक थ्रेड, एस्प के साथ बेहतर प्रदर्शन प्राप्त करते हैं। सीपीयू की संख्या से अधिक धागे?

समानता (अंतर जो हम कई सीपीयू पर डेटा को विभाजित करके प्राप्त करते हैं) और संगामिति के बीच अंतर का एक अच्छा विवरण (हम एक ही सीपीयू पर काम करने के लिए कई थ्रेड का उपयोग करते समय क्या प्राप्त करते हैं) इस महान पोस्ट में रोब पाइक द्वारा प्रदान किया गया है: Concurrency समानता नहीं है ।

संक्षिप्त व्याख्या यह है कि यदि स्पार्क नौकरी एक फाइल सिस्टम या नेटवर्क के साथ बातचीत कर रही है, तो सीपीयू उन इंटरफेस के साथ संचार पर इंतजार करने में बहुत समय व्यतीत करता है और वास्तव में "काम" करने में बहुत समय खर्च नहीं करता है। उन सीपीयू को एक बार में काम करने के लिए 1 से अधिक कार्य देकर, वे कम समय प्रतीक्षा और अधिक समय काम करने में बिता रहे हैं, और आप बेहतर प्रदर्शन देखते हैं।

— turtlemonvh
स्रोत
1
दिलचस्प और आश्वस्त व्याख्या, मुझे आश्चर्य है कि अगर आप कैसे अपना अनुमान लगाते हैं कि निष्पादक के पास अधिकतम थ्रूपुट प्राप्त करने के लिए 5 कार्य सीमाएं हैं।
— दत्त गुयेन
इसलिए नंबर 5 कुछ ऐसा नहीं है जिसके साथ मैं आया हूं: मैंने सिर्फ IO की अड़चनों के संकेत देखे हैं और उन अड़चनों की तलाश में चला गया है जहां से यह अड़चनें आ सकती हैं।
— turtlemonvh
8

से उत्कृष्ट पर उपलब्ध संसाधनों RStudio के Sparklyr पैकेज पेज :

स्पार्क परिभाषाएँ :

स्पार्क नामकरण के लिए कुछ सरल परिभाषाएँ प्रदान करना उपयोगी हो सकता है:

नोड : एक सर्वर

वर्कर नोड : एक सर्वर जो क्लस्टर का हिस्सा है और स्पार्क जॉब्स को चलाने के लिए उपलब्ध है

मास्टर नोड : सर्वर जो कार्यकर्ता नोड्स का समन्वय करता है।

निष्पादक : नोड के अंदर एक प्रकार की आभासी मशीन। एक नोड में कई एक्जिक्यूटर्स हो सकते हैं।

चालक नोड : नोड जो स्पार्क सत्र आरंभ करता है। आमतौर पर, यह सर्वर होगा जहां स्पार्कलीर स्थित है।

ड्राइवर (एक्ज़िक्यूटर) : एग्ज़ेकटर लिस्ट में ड्राइवर नोड भी दिखाई देगा।

— d8aninja
स्रोत
1

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

नीचे पढ़ें उसी पर:

http://spark.apache.org/docs/latest/configuration.html#dynamic-allocation

— हरिकृष्णन सी.के.
स्रोत
1

मेरे विचार से पहले दो विन्यासों में एक छोटी सी समस्या है। धागे और कोर की अवधारणाएं इस प्रकार हैं। थ्रेडिंग की अवधारणा यह है कि यदि कोर आदर्श हैं तो डेटा को संसाधित करने के लिए उस कोर का उपयोग करें। इसलिए मेमोरी पहले दो मामलों में पूरी तरह से उपयोग नहीं की गई है। यदि आप बेंच मार्क करना चाहते हैं, तो यह उदाहरण उन मशीनों को चुनें, जिनमें प्रत्येक मशीन पर 10 से अधिक कोर हैं । फिर बेंच मार्क करें।

लेकिन प्रति निष्पादक 5 से अधिक कोर न दें, आई / ओ प्रदर्शन पर बोतल गर्दन होगी।

तो इस बेंच मार्किंग के लिए सबसे अच्छी मशीनें डेटा नोड्स हो सकती हैं जिनमें 10 कोर होते हैं।

डेटा नोड मशीन युक्ति: CPU: कोर i7-4790 (# कोर का: 10, # धागे का: 20) RAM: 32GB (8GB x 4) HDD: 8TB (2TB x 4)

— अकेला स्टार
स्रोत
0

मुझे लगता है कि इसका एक बड़ा कारण स्थानीयता है। आपकी इनपुट फ़ाइल का आकार 165G है, फ़ाइल के संबंधित ब्लॉक निश्चित रूप से कई DataNodes पर वितरित किए जाते हैं, अधिक निष्पादक नेटवर्क कॉपी से बच सकते हैं।

निष्पादक संख्या बराबर ब्लॉकों की संख्या निर्धारित करने का प्रयास करें, मुझे लगता है कि यह तेज हो सकता है।

— zwb
स्रोत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.