2008-09-30 15 views
7

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

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

उत्तर

19

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

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

0

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

0

एमपीआई सॉकेट का उपयोग करता है, और यदि आप जानते हैं कि आप क्या कर रहे हैं तो आप शायद अधिक बैंडविड्थ सॉकेट से प्राप्त कर सकते हैं क्योंकि आपको जितना मेटा डेटा नहीं भेजना चाहिए।

लेकिन आपको यह जानना है कि आप क्या कर रहे हैं और यह अधिक त्रुटि प्रवण होने की संभावना है। अनिवार्य रूप से आप एमपीआई को अपने मैसेजिंग प्रोटोकॉल के साथ बदल देंगे।

11

मैं आपकी खुद की रोलिंग के बजाय एमपीआई का उपयोग करने की सलाह दूंगा, जब तक कि आप उस तरह की चीज़ पर बहुत अच्छे न हों। अपने स्वयं के प्रोटोकॉल का उपयोग करके कुछ वितरित कंप्यूटिंग-एस्क्यू अनुप्रयोगों को लिखने के बाद, मैं हमेशा एमपीआई के भीतर मिली सुविधाओं को पुन: उत्पन्न (और खराब पुनरुत्पादन) ढूंढता हूं।

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

0
उच्च मात्रा के लिए

, कम भूमि के ऊपर व्यापार मैसेजिंग आप कई उत्पादों के साथ OAMQ की जाँच कर सकते हैं। ओपन सोर्स संस्करण OpenAMQ माना जाता है कि जेपी मॉर्गन में व्यापार चलाता है, इसलिए यह विश्वसनीय होना चाहिए, है ना?

1

मैंने एमपीआई का उपयोग नहीं किया है, लेकिन मैंने सॉकेट का थोड़ा सा उपयोग किया है। उच्च प्रदर्शन सॉकेट पर विचार करने के लिए कुछ चीजें हैं। क्या आप कई छोटे पैकेट, या बड़े पैकेट कर रहे हैं? यदि आप बहुत छोटे पैकेट कर रहे हैं तो तेजी से प्रतिक्रिया के लिए नागल एल्गोरिदम को बंद करने पर विचार करें:

सेटॉकॉप (m_socket, IPPROTO_TCP, TCP_NODELAY, ...);

इसके अलावा, डेटा का उच्च मात्रा प्राप्त करने का प्रयास करते समय सिग्नल का उपयोग वास्तव में बहुत धीमा हो सकता है। बहुत पहले मैंने एक टेस्ट प्रोग्राम बनाया था जहां पाठक सिग्नल की प्रतीक्षा करेगा, और एक पैकेट पढ़ेगा - इसे 100 पैकेट/सेकेंड मिलेगा। तब मैंने सिर्फ पढ़ने को अवरुद्ध कर दिया, और 10000 पढ़े/सेकंड मिला।

बिंदु इन सभी विकल्पों को देखता है, और वास्तव में उन्हें परीक्षण करता है। अलग-अलग स्थितियां अलग-अलग तकनीकों को तेज/धीमी बनाती हैं। न केवल राय प्राप्त करना महत्वपूर्ण है, बल्कि उन्हें परीक्षा में रखना महत्वपूर्ण है। स्टीव Maguire इस बारे में "लेखन ठोस कोड" में बात करते हैं। वह कई उदाहरणों का उपयोग करता है जो प्रति-सहज हैं, और यह पता लगाने के लिए परीक्षण करते हैं कि बेहतर/तेज़ कोड क्या बनाता है।

2

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

वहां बड़ी संख्या में समस्याएं हैं जिन्हें आपको संबोधित करने की आवश्यकता है जो केवल डेटा भेजने से परे है। कनेक्शन सेटअप और रखरखाव सभी आपकी ज़िम्मेदारी बन जाएंगे। यदि एमपीआई सटीक अमूर्त है (ऐसा लगता है कि यह है) तो आपको इसकी आवश्यकता है।

कम से कम, एमपीआई का उपयोग करके और बाद में इसे अपने सिस्टम के साथ रीफैक्टर करना एक अच्छा दृष्टिकोण है जो एमपीआई की स्थापना और निर्भरता की लागत है।

मुझे विशेष रूप से ओल्डमैन के बिंदु की तरह लगता है कि एमपीआई आपको सरल सॉकेट संचार से कहीं अधिक प्रदान करता है। आपको एक पारदर्शी अमूर्तता के साथ समानांतर और वितरित कंप्यूटिंग कार्यान्वयन मिलता है।

2

संदेश पासिंग एक प्रतिमान एक तकनीक नहीं है। सबसे सामान्य स्थापना में, एमपीआई संचार करने के लिए सॉकेट का उपयोग करेगा। आप एमपीआई में स्विच करके एक गति देख सकते हैं, लेकिन केवल तब तक जब आपने अपना सॉकेट संचार अनुकूलित नहीं किया है।

आपका आवेदन I/O कैसे बाध्य है? क्या यह डेटा ब्लॉक को कार्य नोड्स में स्थानांतरित करने पर बाध्य है, या यह गणना के दौरान संचार के कारण बाध्य है?

यदि उत्तर "संचार की वजह से" है तो समस्या यह है कि आप एक कसकर युग्मित अनुप्रयोग लिख रहे हैं और इसे कम से कम युग्मित कार्यों के लिए डिज़ाइन किए गए क्लस्टर पर चलाने की कोशिश कर रहे हैं। प्रदर्शन हासिल करने का एकमात्र तरीका बेहतर हार्डवेयर (तेज स्विच, infiniband, आदि) प्राप्त करना होगा ... शायद आप किसी और के एचपीसी पर समय उधार ले सकते हैं?

यदि उत्तर "डेटा ब्लॉक" स्थानान्तरण है तो श्रमिकों को एकाधिक डेटा ब्लॉक असाइन करने पर विचार करें (इसलिए वे लंबे समय तक व्यस्त रहें) & स्थानांतरण से पहले डेटा ब्लॉक को संपीड़ित करें। यह एक रणनीति है जो एक कमजोर युग्मित अनुप्रयोग में मदद कर सकती है।

+0

आई/ओ रन से पहले नौकरी डेटा भेज रहा है, और बाद में परिणाम भेज रहा है। –

4

प्रदर्शन इस मामले में उच्च प्रदर्शन क्लस्टर पर भी एकमात्र विचार नहीं है। एमपीआई एक मानक एपीआई प्रदान करता है, और "पोर्टेबल" है। एमपीआई के विभिन्न संस्करणों के बीच एक आवेदन स्विच करने के लिए अपेक्षाकृत मामूली है।

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

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

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

+0

मुझे उत्सुकता है कि आप "पोर्टेबल" का उपयोग एक वीज़ल शब्द (प्रकार के रूप में) के रूप में करते हैं, बस यह कहने के बजाय कि एमपीआई पोर्टेबल है। – Jeff

+0

मैंने उद्धरणों में "पोर्टेबल" रखा क्योंकि एमपीआई सक्षम अनुप्रयोग अधिकांश सामान्य एकल होस्ट अनुप्रयोगों की तुलना में बड़े पारिस्थितिक तंत्र पर निर्भर करते हैं। पारिस्थितिकी तंत्र पर निर्भरता एमपीआई सक्षम अनुप्रयोगों को पोर्ट करते समय मुद्दों का कारण बनती है। कई मामलों में, एक एमपीआई आवेदन "बस चलाता नहीं है", लेकिन गलती एमपीआई और आवेदन के दायरे से बाहर है। एमपीआई कार्यान्वयन में विशिष्ट पुस्तकालयों, ड्राइवरों, फर्मवेयर, नेटवर्क सेटअप, उपयोगकर्ता प्रमाणीकरण नीतियों, डेमन या सेवाओं के संस्करण, नेटवर्क फ़ाइल सिस्टम आदि पर निर्भरता हो सकती है। –

3

एमपीआई का लाभ है कि आप सामूहिक संचार कर सकते हैं। ओ (लॉग पी)/* पी में प्रसारण/कटौती करना आपके प्रोसेसर की संख्या */ओ (पी) के बजाय एक बड़ा फायदा है।

+0

क्या यूडीपी मल्टीकास्ट लॉग (पी) कार्यान्वयन के लिए अनुमति देता है? – Jeff

+0

यूडीपी परिवहन परत पर है, एमपीआई आवेदन परत पर है। यदि आप चाहते थे तो आप यूडीपी के शीर्ष पर एमपीआई लागू कर सकते हैं। –

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