SQL सर्वर - कोई भी SUMA, ट्रेस ध्वज 8048, या ट्रेस ध्वज 8015 का उपयोग करता है?

SQL Server 2008 ट्रेस फ़्लैट 8048 में SQL Server 2008 R2 सिस्टम में एक गंभीर स्पिनलॉक विवाद समस्या को हल करने के लिए शामिल किया गया था।

उन लोगों से सुनने के इच्छुक हैं, जिन्होंने उपयोग के मामले पाए हैं, जहां प्रदर्शन मूल्य का पता लगाने वाले ध्वज 8048 (प्रति-एनयूएमए नोड से प्रति-कोर को क्वेरी मेमोरी अनुदान रणनीति को बढ़ावा देने), ट्रेस फ्लैग 8015 (एसक्यूएल सर्वर भौतिक एनयूएमए को अनदेखा करता है), या यूएमए ( interleaved पर्याप्त रूप से वर्दी स्मृति का उपयोग, कुछ NUMA मशीनों पर एक BIOS विकल्प)।

ट्रेस ध्वज 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -presented-प्रति-नुमा नोड-मई-जरूरत का पता लगाने-झंडा 8048.aspx

ट्रेस झंडा 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

सिस्टम कार्यभार का विवरण, परेशान प्रणाली से मैट्रिक्स एकत्र किया, और हस्तक्षेप के बाद सिस्टम से मैट्रिक्स एकत्र किया।

ट्रेस ध्वज 8048 एक 'फिक्स' था, लेकिन क्या यह सबसे अच्छा फिक्स था? क्या SQL सर्वर ट्रेस फ्लैग 8015 की वजह से भौतिक NUMA की अनदेखी कर रहा है? मेमोरी को इंटरमीडिएट करने के लिए BIOS को सेट करने के बारे में क्या है, सर्वर को NUMA व्यवहार के बजाय SMP-imitating SUMA व्यवहार के साथ छोड़ रहा है?

शांति! tw: @sql_handle

सिस्टम के बारे में: - 4 हेक्स कोर एक्सॉन E7540 @ 2.00GHz, हाइपरथ्रेडेड - 128 जीबी रैम - WS2008R2 - MSSQL 2008 R2 SP2 - मैक्सडोप 6

कार्यभार के बारे में: 2 रिपोर्ट एप्लिकेशन सर्वर से संचालित बैच की निर्धारित / कतारबद्ध रिपोर्ट का अधिकतम स्तर। - बैचों के 3 जायके: दैनिक, साप्ताहिक, मासिक - सभी रिपोर्ट अनुप्रयोग सर्वर कनेक्शन SQL सर्वर के लिए एक एकल सेवा खाते के रूप में किए जाते हैं - अधिकतम रिपोर्ट संक्षिप्तता = 90

परेशान प्रणाली पर मुख्य निष्कर्ष: - पर्फोमन से, 15 सेकंड का अंतराल - - सिस्टम 95% -100% सीपीयू में व्यस्त रहता है - - SQL सर्वर बफर पेज लुकअप <10000 प्रति / सेकंड

प्रतीक्षा और स्पिनलॉक डीएमवी से, 5 मिनट के अंतराल
- उच्च CMEMTHREAD वेटर्स और प्रतीक्षा समय
- उच्च SOS_SUSPEND_QUEUE स्पिन और बैकऑफ़

ट्रेस ध्वज 8048 पर बॉब डोर का सीएसएस इंजीनियर ब्लॉग पोस्ट बताता है कि क्वेरी मेमोरी अनुदान में अड़चन के कारण NUMA नोड प्रति 8 से अधिक कोर वाले सिस्टम समान लक्षणों में चल सकते हैं। ट्रेस फ्लैग 8048 प्रति-नूमा नोड के बजाय रणनीति को प्रति-कोर में बदल देगा।

हस्तक्षेप

MSSQL को -8080 के साथ फिर से शुरू किया गया था। यह अंतर तुरंत स्पष्ट हो गया था: बफर पेज लुकअप दर 1 मिलियन और स्पाइक 8 मिलियन प्रति सेकंड से अधिक हो गई। परेशान बैच कार्यभार, जो पहले 24 घंटे में पूरा नहीं कर सकता था, 4 घंटे से कम समय में पूरा हुआ। एक और बैच वर्कलोड जो जांच या हस्तक्षेप का फोकस नहीं था, ट्रेस फ्लैग 8048 के सुधारात्मक मूल्य को सत्यापित करने के हिस्से के रूप में प्रस्तुत किया गया था (और यह सुनिश्चित करना कि इसके अवांछित दुष्प्रभाव कम से कम थे)। यह रिपोर्ट बैच पहले 2 घंटे में पूरी होती है; ट्रेस फ्लैग 8048 के साथ रिपोर्ट बैच लगभग 20 मिनट में पूरा हुआ।

रात्रिकालीन ईटीएल को भी लाभ मिला। ETL का समय लगभग 60 मिनट से घटकर 40 मिनट हो गया।

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

क्वेरी मेमोरी अनुदान के लिए अधिक लेन खोलने से अड़चन दूर हो गई। लेकिन, मुझे यकीन नहीं है कि लागत। बॉब डोरर की सीएसएस पोस्ट यह स्पष्ट करती है कि ट्रेस फ्लैग 8048 के साथ अतिरिक्त मेमोरी ओवरहेड है। क्या MSSQL 2008 R2 अधिकतम सर्वर मेमोरी द्वारा शासित सिंगल-पेज एलोकेटर क्षेत्र के भीतर ओवरहेड है? यदि ऐसा है, तो मुझे लगता है कि सिस्टम में बफर पूल कैश में कुछ कम डेटाबेस पेज होंगे। यदि नहीं, तो क्या अधिकतम सर्वर मेमोरी को समायोजित करने के लिए कम किया जाना चाहिए?

— sql_handle
स्रोत

यह कमाल का पोस्ट है।

आपके अंतिम प्रश्न का उत्तर देने के लिए, मैं अनुमान लगाता हूँ कि आपका उत्तर "हाँ" है।

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

एक अलग विचार पर, मैं मजबूर परिमाणीकरण को देखूंगा - यह तथ्य कि आपका लोड आपके सीपीयू को इतना ऊंचा चला रहा है, यह बहुत दिलचस्प है और यह देखने लायक हो सकता है।

अंत में, मल्टी-नमा नोड सिस्टम पर, मेरे पास आमतौर पर निम्न प्रश्नों का आउटपुट होता है जो प्रत्येक N सेकंड में एक टेबल पर डंप होता है। कार्यभार में परिवर्तन या ट्रेस झंडे लागू होने पर कुछ दिलचस्प विश्लेषण के लिए बनाता है:

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

तथा

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC

— जेरेमी लोवेल
स्रोत

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

— sql_handle

एक और दिलचस्प काउंटर देखने के लिए एकदम सही है: SQLServer: बफर नोड:। ब्याज के उस परिवार में काउंटर विदेशी पृष्ठ, मुफ्त पृष्ठ, पृष्ठ जीवन प्रत्याशा, कुल पृष्ठ, लक्ष्य पृष्ठ और चोरी पृष्ठ हैं। मैं अनुमान लगा रहा हूं, इससे पहले कि आप ट्रेस ध्वज लागू करते, कि आपके पास बहुत अधिक मात्रा में विदेशी पृष्ठ थे - क्या आपके पास TF 834 सक्षम है? यदि ऐसा है, तो मैंने पाया है कि यह संतुलित फैशन में प्रत्येक सुरा नोड को स्मृति आवंटित नहीं करता है, जो बहुत अधिक मात्रा में महंगे रिमोट सुमा नोड मेमोरी लुकअप की ओर जाता है। सिस्टम मैं इस मुद्दे पर 1TB राम के समय में था।

— जेरेमी लोवेल

अच्छे अंक। मैं बफ़र नोड मैट्रिक्स देख रहा हूँ। सबसे उत्सुक यह था कि शुरू में, नोड 00 में कोई विदेशी पृष्ठ नहीं था, जबकि अन्य नोड्स में बड़े पैमाने पर संख्या थी। मुझे लगता है कि हमारे ETL बफर नोड / NUMA नोड 00 पर पूरी तरह से फिट होने के लिए कम पर्याप्त थ्रेड काउंट के साथ बफर रैंप का प्रदर्शन करने के कारण था। हमारे पास ध्वज 834 सक्षम नहीं है, लेकिन जल्द ही इसके साथ परीक्षण शुरू हो जाएगा। लिनक्स ओरेकल 11 जीआर 2 पर हमारे वर्कलोड परीक्षण ने बड़े पृष्ठों की मेमोरी को बहुत लाभ दिखाया, मुझे लगता है कि हम SQL सर्वर के साथ विंडोज में भी लाभ देखेंगे।

— sql_handle

@ माइक मुलायम नुमा टीएफ 8048 बनाम। मुझे लगता है कि मुलायम एनयूएमए मुझे NUMA नोड्स के भीतर 'मेमोरी नोड्स' बनाने की अनुमति देगा। इसलिए अगर मैंने प्रत्येक कोर के लिए नरम NUMA बनाया, तो क्वेरी मेमोरी अनुदान अनुरोधों के लिए (शायद) 24 लेन होगा। लेकिन शायद 24 मेमोरी नोड भी? मैं ओवरहेड के बारे में थोड़ा चिंतित होऊंगा, जो प्रत्येक कोर पेज 'विदेशी' पेज संदर्भों के साथ 24 मेमोरी नोड्स का प्रबंधन करता है, जब भी यह एक नरम एनयूएमए सीमा पार करता है, और वास्तव में विदेशी संदर्भ जब यह एक पेज को संदर्भित करने के लिए सीमा पार करता है जो दोनों अलग है मुलायम NUMA और कठोर NUMA। मैं टिंकर करूंगा और देखूंगा कि क्या मैं कुछ भी समझ सकता हूं।

— sql_handle