NUMmatics, NUMerology और सिर्फ NUMA के बारे में

NUMA (नॉन-यूनिफ़ॉर्म मेमोरी एक्सेस - या नॉन-यूनिफ़ॉर्म मेमोरी आर्किटेक्चर - नॉन-यूनिफ़ॉर्म मेमोरी आर्किटेक्चर) कोई नई तकनीक नहीं है। मैं यहां तक ​​कहूंगा कि यह बहुत पुराना है। यही है, संगीत वाद्ययंत्र के संदर्भ में, यह एक बटन समझौते भी नहीं है, बल्कि एक वीणा है ।
लेकिन, इसके बावजूद, कोई समझदार लेख नहीं है जो यह समझाता हो कि यह है, और सबसे महत्वपूर्ण बात यह है कि इसके साथ प्रभावी ढंग से कैसे काम किया जाए। इस स्थिति को ठीक करने वाली यह पोस्ट मुख्य रूप से उन लोगों के लिए है जो NUMA के बारे में कुछ नहीं जानते हैं, लेकिन NUM विशेषज्ञों के लिए कुछ दिलचस्प भी है, और सबसे महत्वपूर्ण बात यह है कि यह मेरे लिए जीवन को आसान बनाता है, एक इंटेल इंजीनियर, अब से हर कोई जो NAMA में रुचि रखता है। रूसी भाषी डेवलपर्स उसे भेजेंगे।

तीन हीरोज

और उपेक्षा की शुरुआत के साथ शुरू करो। यही है, आइए यूनिफ़ॉर्म मेमोरी एक्सेस को देखें, जिसे एसएमपी (सिमेट्रिक मल्टी प्रोसेसिंग - सिमेट्रिक मल्टीप्रोसेसिंग) के रूप में भी जाना जाता है।

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



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

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

और अंत में, NUMA (नॉन-यूनिफ़ॉर्म मेमोरी एक्सेस)। यह वास्तुकला एसएमपी और एमपीपी की सकारात्मक विशेषताओं को जोड़ती है। NUMA सिस्टम को कई नोड्स में विभाजित किया गया है, जिनकी स्थानीय मेमोरी और अन्य नोड्स की मेमोरी (जिसे "रिमोट" कहा जाता है) दोनों की पहुंच है। स्वाभाविक रूप से, दूरस्थ मेमोरी तक पहुंच स्थानीय की तुलना में बहुत धीमी है । वहाँ से नाम "स्मृति के लिए विषम पहुँच" है। यह न केवल एक नाम है, बल्कि एनयूएमए वास्तुकला का एक दोष भी है, जिसे कम करने के लिए विशेष सॉफ्टवेयर अनुकूलन की आवश्यकता हो सकती है, जिसकी चर्चा बाद में की जाएगी।

यह वही है जो इंटेल Xeon डुअल-सॉकेट NUMA सिस्टम जैसा दिखता है (अर्थात्, इंटेल NUMA ने वहां डेब्यू किया) CPU में एकीकृत मेमोरी कंट्रोलर्स के साथ।


यहाँ प्रोसेसर QPI द्वारा जुड़े हुए हैं - इंटेल क्विकपैथ पॉइंट-टू-पॉइंट कनेक्शन उच्च बैंडविड्थ और कम ट्रांसमिशन देरी के साथ।

प्रोसेसर कैश को आकृति में नहीं दिखाया गया है, लेकिन मेमोरी कैश के सभी तीन स्तर, निश्चित रूप से हैं। तो, एक NUMA विशेषता है जिसका उल्लेख करना आवश्यक है : NUMA, जिसका उपयोग इंटेल सिस्टम में किया जाता है, कैश और साझा की गई मेमोरी (यानी, विभिन्न CPU के कैश के बीच डेटा पत्राचार) का समर्थन करता है, इसलिए इसे कभी-कभी NcNUMA - कैश सुसंगत NUMA भी कहा जाता है। इसका मतलब यह है कि कैश की सामग्री, साथ ही मेमोरी के मिलान के लिए एक विशेष हार्डवेयर समाधान है, जब एक से अधिक कैश उसी हिस्से को स्टोर करते हैं। बेशक, इस तरह का कैश संचार समग्र प्रणाली के प्रदर्शन को खराब करता है, लेकिन इसके बिना डेटा की अप्रत्याशित वर्तमान स्थिति के साथ सिस्टम को प्रोग्राम करना बेहद मुश्किल होगा। इस प्रभाव के प्रभाव को कम करने के लिए, आपको उन परिस्थितियों से बचना चाहिए जब कई प्रोसेसर एक बार में एक मेमोरी ब्लॉक के साथ काम करते हैं (जरूरी नहीं कि एक चर के साथ!)। ठीक यही NUMA- सक्षम उत्पाद करने की कोशिश कर रहे हैं।

इस प्रकार, हमने सुगमतापूर्वक हार्डवेयर से सॉफ्टवेयर और NUMA सिस्टम के प्रदर्शन पर स्विच किया।

तो, NUMA निम्नलिखित OS द्वारा समर्थित है:

विंडोज सर्वर 2003 , विंडोज एक्सपी 64-बिट और विंडोज विस्टा - 64 तार्किक प्रोसेसर तक,
विंडोज 7 , विंडोज सर्वर 2008 आर 2 - पूर्ण समर्थन।
Linux OS कर्नेल: 2.6 और उच्चतर; UNIX OS - सोलारिस और HP-Unix ।

डेटाबेस के संदर्भ में, NUMA Oracle8i, Oracle9i, Oracle10g और Oracle11g , साथ ही SQL Server 2005 और SQL Server 2008 द्वारा समर्थित है।

Windows के उपरोक्त संस्करणों पर जावा SE 6u2 , JVM 1.6 , और .NET रनटाइम में NUMA समर्थन भी लागू किया गया है।
पूरी तरह से इंटेल के NUMA गणित पुस्तकालय - MKL का समर्थन करता है।
" NUMA समर्थन " का अर्थ है निम्नलिखित - उत्पाद उस मशीन के NUMA टोपोलॉजी के बारे में जानता है जिस पर वह चल रहा है, और इसे यथासंभव कुशलता से उपयोग करने की कोशिश करता है, अर्थात, थ्रेड के काम को व्यवस्थित करने के लिए ताकि वे पूरी तरह से अपने नोड की स्मृति का उपयोग करें (जिस पर यह थ्रेड चल रहा है) ) और न्यूनतम रूप से - अजनबी। यहाँ मुख्य शब्द "कोशिश कर रहा है", क्योंकि आमतौर पर ऐसा करना हमेशा संभव नहीं होता है।
इसलिए, ऐसा हो सकता है कि कोई ऐसा उत्पाद जो NUMA का समर्थन नहीं करता है, अर्थात, बस इसके बारे में नहीं जानता है, जो इसे NUMA सिस्टम पर चलने और चलने से नहीं रोकता है, आधिकारिक रूप से NUMA का समर्थन करने से बुरा प्रदर्शन नहीं होगा। इस तरह के उत्पाद का एक उदाहरण प्रसिद्ध इंटेल थ्रेडिंग बिल्डिंग ब्लॉक्स लाइब्रेरी है।

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

यदि BIOS NUMA को अनुमति देता है, तो ऑपरेटिंग सिस्टम NUMA नोड्स के कॉन्फ़िगरेशन के बारे में सिस्टम संसाधन Affinity Table (SRAT) से उन्नत कॉन्फ़िगरेशन और पावर इंटरफ़ेस (ACPI) में सीख सकता है। एप्लिकेशन लिनक्स पर लिबनुमा लाइब्रेरी का उपयोग करके यह जानकारी प्राप्त कर सकते हैं, और आप स्वयं समझ सकते हैं कि कौन से सिस्टम विंडोज एनयूएमए इंटरफ़ेस का उपयोग करते हैं।
यह जानकारी आपके आवेदन के लिए NUMA समर्थन की शुरुआत है। इसे सीधे NUMA के उपयोग को अधिकतम करने के प्रयास के साथ होना चाहिए। इस विषय पर सामान्य शब्द पहले ही कहे जा चुके हैं, आगे की व्याख्या के लिए मैं एक विशेष उदाहरण की ओर मुड़ूंगा।

मान लीजिए कि आप मॉलॉक का उपयोग करके मेमोरी आवंटित करते हैं। यदि यह लिनक्स पर है, तो मॉलोक केवल मेमोरी को आरक्षित करता है, और इसका भौतिक आवंटन केवल तब होता है जब वास्तविक मेमोरी एक्सेस की जाती है। इस स्थिति में, मेमोरी स्वचालित रूप से इसका उपयोग करने वाले नोड पर आवंटित की जाएगी, जो NUMA के लिए बहुत अच्छा है। विंडोज पर, मॉलॉक अलग तरीके से काम करता है, यह आवंटित करते समय भौतिक मेमोरी को सीधे आवंटित करता है, अर्थात, नोड को मेमोरी स्ट्रीम आवंटित करता है। इसलिए, इसका उपयोग करने वाले अन्य थ्रेड्स के लिए इसे अच्छी तरह से हटाया जा सकता है। लेकिन विंडोज पर NUMA- फ्रेंडली मेमोरी एलोकेशन भी है। यह VirtualAlloc है , जो लिनक्स पर मॉलॉक की तरह ही काम कर सकता है। Windows NUMA API से एक अधिक उन्नत विकल्प VirtualAllocExNuma है।

OpenMP का उपयोग करते हुए निम्नलिखित सरल उदाहरण,

main() { … #pragma omp parallel { //Parallelized TRIAD loop… #pragma omp parallel for private(j) for (j=0; j<N; j++) a[j] = b[j]+scalar*c[j]; } //end omp parallel … } //end main 

आप NUMA के साथ दोस्ती कर सकते हैं, प्रत्येक थ्रेड द्वारा डेटा की इनिशियलाइज़ेशन सुनिश्चित कर सकते हैं, जिससे फिजिकल मेमोरी के नोड के लिए इसी बंधन का उपयोग किया जा सकता है:

 KMP_AFFINITY=compact,0,verbose main() { … a* = (char *) VirtualAlloc(NULL, //same for b* and c* N*(sizeof(double))+1024, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); … #pragma omp parallel { #pragma omp for private(i) for(i=0;i<N;i++) { a[i] = 10.0; b[i] = 10.0; c[i] = 10.0;} … //OpenMP on TRIAD loop… #pragma omp parallel for private(j) for (j=0; j<N; j++) a[j] = b[j]+scalar*c[j]; } //end omp parallel … } //end main 

यहां एक अलग बिंदु का उल्लेख किया जाना चाहिए आत्मीयता - विशिष्ट प्रोसेसर के लिए थ्रेड्स को बाध्य करना, प्रोसेसर के बीच थ्रेड्स के ऑपरेटिंग सिस्टम द्वारा संभावित हस्तांतरण को रोकना और जो इसके उपयोग की गई स्थानीय मेमोरी से थ्रेड्स के संभावित "अलगाव" का कारण बन सकता है।
लिनक्स और विंडोज (मानक विंडोज एपीआई, और एनयूएमए विनएपीआई ) दोनों पर एफिनिटी स्थापित करने के लिए उपयुक्त एपीआई हैं। इसके अलावा, बाइंडिंग स्थापित करने के लिए कार्यक्षमता कई समानांतर पुस्तकालयों में मौजूद है (उदाहरण के लिए, ऊपर दिखाए गए ओपनएमपी उदाहरण में, KMP_AFFINITY पर्यावरण चर इसके लिए जिम्मेदार है)।
लेकिन आपको यह समझने की आवश्यकता है कि, सबसे पहले, आत्मीयता हमेशा काम नहीं करती है (एक प्रणाली के लिए यह एक आदेश की तुलना में अधिक संभावना है), और दूसरी बात, Affinity को स्थापित करने का सकारात्मक प्रभाव केवल तब होगा जब आप सिस्टम के पूर्ण नियंत्रण में हों, अर्थात्। , आपका आवेदन इस पर विशेष रूप से चलता है, और ओएस स्वयं सिस्टम को अधिक लोड नहीं करता है। यदि, जैसा कि यह सबसे अधिक बार होता है, तो कई अनुप्रयोग हैं, इसके अलावा, वे सीपीयू और मेमोरी का गहनता से उपयोग करते हैं, जबकि एक प्रोसेसर से जुड़े होने की कोशिश करते हैं, एक दूसरे के बारे में कुछ भी नहीं जानते हैं, और ओएस समान संसाधनों के लिए प्रतिस्पर्धा कर रहा है, फिर एफिनिटी का उपयोग कर सकते हैं। अच्छे से अधिक नुकसान हो

प्रदर्शन।

और अब मज़ेदार हिस्से के लिए। आइए यह जानने की कोशिश करें कि NUMA में मेमोरी की पहुंच कितनी वास्तविक है, और क्रमशः वास्तविक अनुप्रयोगों का प्रदर्शन, इस विविधता पर निर्भर करता है।
सबसे पहले, आइए सैद्धांतिक डेटा देखें। इंटेल प्रस्तुतियों के अनुसार, "दूरस्थ मेमोरी तक पहुंचने में देरी ~ स्थानीय मेमोरी तक 1.7x पहुंच है, और स्थानीय मेमोरी की बैंडविड्थ रिमोट की तुलना में दो गुना अधिक हो सकती है"
Xeon 5500 पर वास्तविक सर्वर डेटा डेल तकनीकी विवरण में दिया गया है - " स्थानीय मेमोरी तक पहुंचने में देरी रिमोट के लिए 70 नैनोसेकंड है, - 100 नैनोसेकंड (यानी ~ 1.4 गुना), स्थानीय सर्वर की बैंडविड्थ रिमोट द्वारा 40% से अधिक है ।"

आपके वास्तविक सिस्टम पर, यह अनुमानित डेटा मुफ्त Microsoft Sysinternals उपयोगिता - CoreInfo का उपयोग करके प्राप्त किया जा सकता है, जो विभिन्न NUMA नोड्स की मेमोरी तक पहुंचने के सापेक्ष "लागत" का अनुमान लगाता है। परिणाम, निश्चित रूप से, बहुत अनुमानित है, लेकिन कुछ निष्कर्ष उत्साहजनक हैं।
Coreinfo परिणाम उदाहरण:

 Calculating Cross-NUMA Node Access Cost... Approximate Cross-NUMA Node Access Cost (relative to fastest): 00 01 00: 1.0 1.3 01: 1.2 1.0 

लेकिन मुख्य सवाल यह है कि NUMA मेमोरी तक पहुंच की "लागत" में कितना अंतर है, समग्र रूप से वास्तविक एप्लिकेशन के प्रदर्शन को प्रभावित करेगा। इस लेख को तैयार करने में, मैं SQL स्पेशलिस्ट लिनची शीया के एक बहुत ही दिलचस्प पोस्ट पर आया, जो एसक्यूएल विशेषज्ञ के प्रदर्शन पर NUMA के प्रभाव का मूल्यांकन करता है।
एचपी प्रोलिएंट 360 G7 पर दो इंटेल Xeon X5690 के साथ माप किए गए थे, कुल 12 प्रोसेसर (24 तार्किक सीपीयू) दे रहे थे और Microsoft SQL Server 2008 R2 एंटरप्राइज़ X64 के दो परिदृश्यों की तुलना थी:

1. विशेष रूप से स्थानीय मेमोरी का उपयोग करना (सभी अनुरोधों को पहले NUMA नोड पर संसाधित किया जाता है, जिसकी स्मृति में परीक्षण तालिका निहित है)
2. विशेष रूप से दूरस्थ मेमोरी (सभी अनुरोधों को दूसरे एनयूएमए नोड पर संसाधित किया जाता है, पहले नोड की मेमोरी में उसी तालिका का उपयोग करके।

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


जैसा कि आप देख सकते हैं, अंतर केवल 5% से थोड़ा अधिक है! परिणाम सुखद आश्चर्यजनक है। और यह अनुरोधों के साथ एक साथ चल रहे थ्रेड्स के 32 के साथ प्राप्त अधिकतम अंतर का मामला है (थ्रेड्स की एक अलग संख्या के साथ, अंतर और भी छोटा है)।

तो क्या मुझे NUMA के लिए अनुकूलन करने की आवश्यकता है? मैं दूर से जाऊंगा हालाँकि मेरे पास घर पर सफाई करने का समय नहीं है, मेरे पास सफाई के टिप्स पढ़ने का समय है :) और मेरे द्वारा देखे गए उपयोगी सुझावों में से एक यह है कि कम बाहर निकलने के लिए, आपको संभावित गड़बड़ी से बचने की आवश्यकता है, जिसके लिए सभी चीजों को यथासंभव उनके उपयोग के स्थान के करीब रखने की कोशिश करें।

अब "चीजों" को "डेटा" और "अपार्टमेंट" को "प्रोग्राम" से बदलें और आप अपने कार्यक्रमों में ऑर्डर प्राप्त करने के तरीकों में से एक देखेंगे। लेकिन यह बिल्कुल NUMA ऑप्टिमाइज़ेशन होगा, जिसके बारे में आपने अभी पढ़ा है।