क्या CPU उपयोग विदेशी NUMA पहुंच की लागत को प्रभावित करता है?

Question

परिदृश्य

मान लें कि मेरे पास प्रत्येक 1 NUMA नोड के साथ 4 सॉकेट के साथ एक SQL सर्वर है। प्रत्येक सॉकेट में 4 भौतिक कोर होते हैं। कुल 512 जीबी मेमोरी है इसलिए प्रत्येक NUMA नोड में 128 जीबी रैम है।

एक कुंजी तालिका को पहले NUMA नोड में लोड किया गया है।

सवाल

मान लेते हैं कि हमारे पास उस टेबल से बहुत सारी ट्रैफ़िक रीडिंग है। यदि NUMA नोड के मालिक सॉकेट के सभी भौतिक कोर में 100 प्रतिशत CPU उपयोग होता है, तो क्या यह अन्य सॉकेट्स से आने वाले गैर-स्थानीय NUMA पहुंच की लागत को नकारात्मक रूप से प्रभावित करता है? या दूसरी तरफ गैर-स्थानीय NUMA की लागत की परवाह किए बिना कि सॉकेट कितना व्यस्त है?

मुझे उम्मीद है कि मेरा सवाल समझ में आता है। कृपया मुझे बताएं कि अगर ऐसा नहीं है तो मैं स्पष्ट करने की कोशिश करूंगा।

पृष्ठभूमि

हमारे पास पिछले सप्ताह हमारे उत्पादन सर्वर में एक डेटाबेस समस्या थी और हमारे कुछ संसाधित व्यवसाय दूसरों की तुलना में अधिक प्रभावित दिखाई दिए। हमें 1 मिनट से अधिक समय लेने वाले कुछ तार्किक रीड्स के साथ प्रश्न थे। हमने समग्र सीपीयू उपयोग को देखा जो लगभग 60 प्रतिशत था। हमने सॉकेट विशिष्ट सीपीयू मैट्रिक्स को नहीं देखा। I / O मीट्रिक औसत थे।

Comments

यदि आप ऐसा कुछ बना सकते हैं जैसे किन ने उल्लेख किया है तो यह सहायक होगा। इसके अलावा, आपने MAXDOP को क्या सेट किया है?

— user41207

Answer 1

एक भारी सवाल :-) मैं इसमें शामिल कुछ कारकों की रूपरेखा तैयार करूँगा। किसी भी संदर्भ में, ये कारक और अन्य अलग-अलग हो सकते हैं और एक दिलचस्प परिणाम उत्पन्न कर सकते हैं।

क्षमा करें, मैं इसे बहुत छोटा बनाने में सक्षम नहीं था ...

1. संचित सीपीयू एमएस बनाम तार्किक आईओ
2. भौतिक NUMA नोड्स के साथ SQL सर्वर लॉजिकल मेमोरी नोड संरेखण
3. क्वेरी कार्यस्थान मेमोरी आवंटन में स्पिनलॉक विवाद
4. अनुसूचियों को टास्क असाइनमेंट
5. बफर पूल में प्रासंगिक डेटा प्लेसमेंट
6. शारीरिक मेमोरी प्लेसमेंट

---

1. संचित सीपीयू एमएस बनाम तार्किक आईओ

   मैं सीपीयू के उपयोग के खिलाफ तार्किक आईओ (या परफॉमेंस शब्दावली "बफर पूल पेज लुक्स") के ग्राफ का उपयोग बहुत बार करता हूं, ताकि वर्कलोड की सीपीयू दक्षता को नापा जा सके और स्पिनलॉक प्रवण मामलों की तलाश की जा सके।

   लेकिन SQL सर्वर पृष्ठ लुकअप और स्पिनलॉक के अलावा बहुत सी गतिविधि के साथ सीपीयू समय जमा करता है:

   • योजनाएँ संकलित और पुन: संकलित हैं।
   • सीएलआर कोड निष्पादित किया जाता है।
   • कार्य किए जाते हैं।

   पृष्ठ लुकअप में परिलक्षित किए बिना कई अन्य गतिविधियाँ महत्वपूर्ण सीपीयू समय को चबाएंगी।

   मेरे द्वारा देखे जाने वाले वर्कलोड में, इन "गैर तार्किक IO गहन लेकिन CPU-gobbling" गतिविधियों में से प्रमुख / छंटनी गतिविधि है।

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

   कार्यक्षेत्र मेमोरी के बारे में और इन पोस्ट में कार्यक्षेत्र का कितना उपयोग किया गया है:

   • http://sql-sasquatch.blogspot.com/2015/08/sql-server-grantedreservedstolen_4.html

   • http://sql-sasquatch.blogspot.com/2015/08/sql-server-workspace-memory-with-twist.html

   • http://sql-sasquatch.blogspot.com/2015/03/resource-governor-to-restrict-max-query.html

---

2. भौतिक NUMA नोड्स के साथ SQL सर्वर लॉजिकल मेमोरी नोड संरेखण

   SQL सर्वर (डिफ़ॉल्ट रूप से अपनी NUMA- जागरूक रणनीतियों को शामिल करने के बाद से) सर्वर पर प्रत्येक NUMA नोड के लिए SQLOS मेमोरी नोड बनाता है। जैसे-जैसे मेमोरी आवंटन बढ़ता है, प्रत्येक आवंटन को SQLOS मेमोरी नोड्स में से एक द्वारा नियंत्रित किया जाता है।

   आदर्श रूप से, SQLOS मेमोरी नोड्स पूरी तरह से भौतिक NUMA नोड्स के साथ संरेखित हैं। यह कहना है, प्रत्येक SQLOS मेमोरी नोड में एक एकल NUMA नोड से मेमोरी होती है, साथ ही कोई अन्य SQLOS मेमोरी नोड भी उसी NUMA नोड से मेमोरी नहीं होती है।

   हालाँकि, आदर्श स्थिति हमेशा ऐसी नहीं होती है।

   निम्नलिखित सीएसएस SQL ​​सर्वर इंजीनियर्स ब्लॉग पोस्ट (परिजनों की प्रतिक्रिया में भी शामिल है) विवरण व्यवहार जो SQLOS मेमोरी नोड्स के लिए पार-NUMA नोड मेमोरी आवंटन को जारी रख सकता है। जब ऐसा होता है, तो प्रदर्शन प्रभाव विनाशकारी हो सकता है।

   • http://blogs.msdn.com/b/psssql/archive/2012/12/13/how-it-works-sql-server-numa-local-foreign-and-away-memory-blocks.aspx

   निरंतर क्रॉस-नुमा नोड संदर्भ के विशेष रूप से दर्दनाक मामले के लिए कुछ सुधार किए गए हैं। इन दोनों के अतिरिक्त संभवतः अन्य:

   • FIX: प्रदर्शन समस्याएँ NUMA वातावरण में SQL Server 2012 या SQL Server 2014 में विदेशी पृष्ठ प्रसंस्करण के दौरान होती हैं

   • FIX: SQL सर्वर प्रदर्शन NUMA वातावरण में समस्याएँ

---

3. कार्यक्षेत्र मेमोरी के आवंटन के दौरान स्पिनलॉक विवाद

   यह वह जगह है जहाँ यह मज़ा करने के लिए शुरू होता है। मैंने पहले ही वर्णन किया है कि कार्यक्षेत्र मेमोरी में सॉर्ट और हैश काम सीपीयू की खपत करता है, लेकिन बम्पर लुकअप संख्या में परिलक्षित नहीं होता है।

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

   ट्रेस ध्वज 8048 कोर स्तर पर संसाधन को और अधिक विभाजित करके इस विवाद को दूर करने का एक बड़ा काम करता है।

   माइक्रोसॉफ्ट का कहना है कि "ट्रेस फ्लैग 8048 पर विचार करें यदि प्रति सॉकेट 8 या अधिक कोर"। लेकिन ... यह वास्तव में नहीं है कि कितने सॉकेट प्रति सॉकेट (जब तक कि कई हैं), बल्कि एक ही NUMA नोड पर किए जा रहे काम में विवाद के लिए कितने अवसर हैं।

   सरेस से जोड़ा हुआ AMD प्रोसेसर (12 कोर प्रति सॉकेट, 2 NUMA नोड प्रति सॉकेट) पर 6 कोर प्रति NUMA नोड था। मैंने उन सीपीयू में से 4 (इसलिए आठ एनयूएमए नोड्स, 6 कोर प्रत्येक) के साथ एक प्रणाली देखी जो स्पिनक काफिले में जाम हो गई थी जब तक कि ट्रेस ध्वज 8048 सक्षम नहीं था।

   मैंने इस स्पिनलॉक विवाद को 4 वीसीपीयू के रूप में वीएम पर प्रदर्शन को नीचे खींचें। ट्रेस फ्लैग 8048 ने उन सिस्टमों पर सक्षम होने के समय क्या करना चाहिए था।

   यह देखते हुए कि वहाँ अभी भी कुछ 4 कोर आवृत्ति अनुकूलित CPU हैं, सही कार्यभार के साथ, उन्हें ट्रेस फ्लैग 8048 से भी लाभ होगा।

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

   • यह कैसे काम करता है: CMemThread और डीबगिंग उन्हें

---

4. अनुसूचियों को टास्क असाइनमेंट

   NUMA सिस्टम पर, NUMA नोड्स को कनेक्शन वितरित किए जाते हैं (अच्छी तरह से - वास्तव में SQLOS अनुसूचक समूह उनसे जुड़े हुए हैं) राउंड-रॉबिन, यह मानते हुए कि विशेष NUMA नोड्स से जुड़े कनेक्शन अंत बिंदु नहीं हैं। यदि कोई सत्र समानांतर क्वेरी निष्पादित करता है, तो एक एकल NUMA नोड से श्रमिकों का उपयोग करने के लिए एक मजबूत प्राथमिकता है। हम्म् ... एक 4 NUMA नोड सर्वर पर विचार करें, जिसमें जटिल क्वेरी 4 रास्तों में टूटी हुई है, और डिफ़ॉल्ट 0 MAXDOP। यहां तक ​​कि अगर क्वेरी केवल MAXDOP कार्यकर्ता थ्रेड्स का उपयोग करती है, तो NUMA नोड पर प्रत्येक तार्किक CPU के लिए 4 वर्कर थ्रेड होंगे। लेकिन जटिल योजना में 4 रास्ते हैं - इसलिए NUMA नोड पर प्रत्येक तार्किक CPU पर 16 श्रमिक हो सकते हैं - सभी एक क्वेरी के लिए!

   यही कारण है कि कभी-कभी आप एक NUMA नोड को कठिन परिश्रम करते हुए देखेंगे, जबकि अन्य लोफिंग कर रहे हैं।

   कार्य असाइनमेंट के लिए कुछ अन्य बारीकियां हैं। लेकिन मुख्य रास्ता यह है कि सीपीयू व्यस्त जरूरी NUMA नोड्स में समान रूप से वितरित नहीं किया जाएगा। (यह भी महसूस करने के लिए अच्छा है कि बम्प पेज इन्सर्ट (रीड या फर्स्ट-पेज-राइट्स) वर्कर के साथ जुड़े SQLOS मेमोरी नोड में बापल में जाएगा, वर्कर चालू है। और चुराए गए पेज अधिमानतः "लोकल" SQLOS मेमोरी से आएंगे। नोड, भी।

   मैंने पाया है कि 0 से अधिकतम 8 तक लाने में मददगार है। वर्कलोड प्रोफाइल के आधार पर (मुख्य रूप से समवर्ती अपेक्षित संभावित लंबे समय तक चलने वाले प्रश्नों की संख्या पर imo), MAXDOP = 2 के लिए सभी तरह से वारंट किया जा सकता है।

   समानता के लिए लागत सीमा को समायोजित करना भी सहायक हो सकता है। जिन प्रणालियों पर मैं काम करता हूं, वे उच्च लागत वाले प्रश्नों के साथ उपभोग करते हैं और शायद ही कभी 50 या 100 से नीचे की योजना का सामना करते हैं, इसलिए मैंने लागत सीमा को समायोजित करने की तुलना में मैक्सडॉप (कार्यभार समूह स्तर पर ओटेन) को समायोजित करके अधिक कर्षण किया है।

   • SQL सर्वर PLE 8 NUMA नोड्स के साथ

     इस पोस्ट में, कार्यक्षेत्र मेमोरी और असमान कार्य वितरण के आसपास स्पिनलॉक विवाद के संयोजन पर चर्चा की गई है। देखें - ये चीजें वास्तव में सभी एक साथ बुनाई करते हैं :-)

   • 40 समवर्ती SQL सर्वर समानांतर क्वेरी + (2 सॉकेट * 10 कोर प्रति सॉकेट) = spinlock काफिला

---

5. बम्पर में प्रासंगिक डेटा प्लेसमेंट

   यह वह स्थिति है जो मुझे लगता है कि NUMA सर्वर के साथ काम करते समय सबसे सहज है। यह भी, सबसे आम तौर पर, कार्यभार प्रदर्शन के लिए अत्यंत महत्वपूर्ण नहीं है।

   यदि NUMA नोड 3 पर तालिका को चपेट में पढ़ा जाता है, और बाद में NUMA नोड 4 पर एक क्वेरी NUMA नोड्स में सभी बम्पर लुकअप को प्रदर्शित करने वाली तालिका को स्कैन करती है तो क्या होता है?

   लिंची शीया के इस प्रदर्शन प्रभाव पर एक शानदार पोस्ट है:

   • http://sqlblog.com/blogs/linchi_shea/archive/2012/01/30/performance-impact-the-cost-of-numa-remote-memory-access.aspx

   NUMA नोड्स में मेमोरी एक्सेस करने से अतिरिक्त मेमोरी लेटेंसी की थोड़ी मात्रा हो जाती है। मुझे यकीन है कि कुछ वर्कलोड हैं जिन्हें इष्टतम प्रदर्शन के लिए उस अतिरिक्त बेस मेमोरी विलंबता को खत्म करने की आवश्यकता है - इसके साथ काम करने वाले सिस्टम पर कोई समस्या नहीं है।

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

   फिर - मुझे यकीन है कि वर्कलोड ऐसे हैं कि मेमोरी बैंडविड्थ एक महत्वपूर्ण विचार है। मेरे सिस्टम के लिए, हालांकि, अन्य विचार जो मैं सूचीबद्ध कर रहा हूं, वे अधिक महत्वपूर्ण हैं।

---

6. शारीरिक मेमोरी प्लेसमेंट

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

---

बड़ा खत्म!

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

इसके बजाय, यदि आपके द्वारा देखी गई स्थिति NUMA- संबंधित है, तो मैं यह उम्मीद करूंगा कि यह ऊपर वर्णित कारकों का एक संयोजन हो;

1. कार्यक्षेत्र मेमोरी का उपयोग (जो तार्किक IO काउंट में नहीं दिखाई देगा)

2. जो लगातार विदेशी मेमोरी स्थिति के कारण क्रॉस-नुमा नोड हो सकता है (यदि यह मामला है, तो संबंधित सुधार देखें)

3. और जो एनयूएमए नोड के भीतर हर बार आवंटन को रोक सकता है, जब कोई आवंटन अनुदान के खिलाफ किया जाता है (T8048 के साथ ठीक करें)

4. और अन्य समानांतर क्वेरी श्रमिकों द्वारा अधिभारित तार्किक सीपीयू पर श्रमिकों द्वारा प्रदर्शन किया जा सकता है (अधिकतम के रूप में समायोजित करें और आवश्यक रूप से समानता का मूल्य सीमा)

Answer 2

( कृपया coreinfo -vअपने सीपीयू / सॉकेट और एनयूएमए वितरण का बेहतर संदर्भ प्राप्त करने के लिए अपने प्रश्न को (सिनसिनिटी यूटिलिटी) आउटपुट से अपडेट करें )

हमने समग्र सीपीयू उपयोग को देखा जो लगभग 60 प्रतिशत था। हमने सॉकेट विशिष्ट सीपीयू मैट्रिक्स को नहीं देखा। I / O मीट्रिक औसत थे।

मुझे लगता है कि आप गलत पेड़ पर भौंक रहे हैं। SQL सर्वर NUMAअवगत है। नहीं है पार NUMA स्मृति पहुँच करने के लिए बहुत छोटे प्रदर्शन जुर्माना । आप इस क्वेरी का उपयोग यह देखने के लिए कर सकते हैं कि NUMAआपके पास कितने नोड हैं और कौन सा CPU और कोर किसको असाइन किए गए हैं NUMA:

SELECT parent_node_id, scheduler_id, cpu_id
FROM sys.dm_os_schedulers WITH (NOLOCK) 
WHERE [status] = N'VISIBLE ONLINE';

या सिर्फ कितने NUMA:

select COUNT(distinct Parent_node_id)
from sys.dm_os_schedulers
where [STATUS] = 'VISIBLE ONLINE'
    and Parent_node_ID < 64

हमें 1 मिनट से अधिक समय लेने वाले कुछ तार्किक रीड्स के साथ प्रश्न थे।

यह आमतौर पर तब होता है जब आपके पास पुराने आंकड़ों के कारण खराब क्वेरी प्लान उत्पन्न होते हैं। सुनिश्चित करें कि आपके पास अपने आँकड़े अपडेट हैं और आपके सूचकांक ठीक से डीफ़्रैग्मेन्ट हैं ।

इसके अलावा, आपको वर्कर थ्रेड भुखमरी से बचने के लिए MAXDOP को अधिक समझदार मूल्य पर सेट करने की आवश्यकता है ।

cost threshold of parallelism5 के डिफ़ॉल्ट से अपने सेट को 45 की तरह एक अच्छे शुरुआती मूल्य पर सेट करें और फिर उस मूल्य की निगरानी करें और इसे अपने वातावरण के अनुसार समायोजित करें।

यदि आप बहुत सारे एडहॉक क्वेरीज़ चला रहे हैं, तो optimize for ad hoc workloadsप्लान कैश को रोकने के लिए (1 पर सेट) चालू करें।

सावधानी के साथ उपयोग करें: आप T8048 का उपयोग कर सकते हैं यदि आप SQL Server 2008/2008 R2 को नई मशीनों पर चला रहे हैं, जिसमें NUMA नोड प्रति 8 से अधिक CPU प्रस्तुत हैं और यदि आप SQL सर्वर 2012 या 2014 में हैं, तो एक हॉटफ़िक्स है ।

अत्यधिक आपको अपने डेटाबेस सर्वर उदाहरण के बारे में प्रतीक्षा आँकड़े जानकारी एकत्र करना शुरू करने की सलाह देते हैं ।

संदर्भ: यह कैसे काम करता है: SQL सर्वर (NUMA स्थानीय, विदेशी और दूर मेमोरी ब्लॉक)

Answer 3

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

आपको यह लिंक उपयोगी लग सकता है:

http://cs.nyu.edu/~lerner/spring10/projects/NUMA.pdf

क्रिस