समानांतर क्वेरी निष्पादन त्रुटि को समझने की आवश्यकता है

आज हमने अपने उत्पादन एसक्यूएल सर्वर पर प्रदर्शन में गिरावट का अनुभव किया। इस समय के घटने के बाद हमने कई "The query processor could not start the necessary thread resources for parallel query execution"त्रुटियां दर्ज कीं। मैंने जो रीडिंग की है, उससे पता चलता है कि जटिल क्वेरी को निष्पादित करते समय कितने सीपीयू का उपयोग करना है। हालाँकि जब मैंने आउटेज के दौरान जाँच की CPU Utilization was only at 7%। वहाँ कुछ और है यह भी हो सकता है कि मैं अभी तक भर नहीं आया है? क्या यह प्रदर्शन में गिरावट की संभावना है या मैं एक लाल हेरिंग का पीछा कर रहा हूं?

इसके लिए मेरे sp_configure मान इस प्रकार हैं:

name                                minimum maximum config_value run_value
cost threshold for parallelism      0       32767   5            5

sql-server sql-server-2008-r2 parallelism

— ढेलेदार
स्रोत

max degree of parallelismNUMA कॉन्फ़िगरेशन के साथ-साथ आपके पास सर्वर पर वर्तमान में कॉन्फ़िगर किए गए और कितने प्रोसेसर हैं? प्रोसेसर और NUMA कॉन्फ़िगरेशन की संख्या जानने के लिए आप sysinternalscoreinfo.exe से उपयोग कर सकते हैं ।

— परिजन शाह

समानांतरवाद की मैक्स डिग्री 0

— लुम्पी

यही कारण है कि sql सर्वर थ्रेड संसाधनों के लिए भूखा क्यों होगा।

— परिजन शाह

@ क्या मेरे पास 12 प्रोसेसर (0 - 11) प्रोसेसर हैं तो NUMA नोड मैप के लिए दो लॉजिकल प्रोसेसर हैं: प्रविष्टियां नोड 0, नोड 1

— लुम्पी

@ मुझे लगा कि 0 उल्लेख है कि SQL सर्वर प्रबंधित करता है कि इसे कितने थ्रेड का उपयोग करना चाहिए। यह थ्रेड संसाधनों के लिए SQL सर्वर को भूखा करने में क्यों होगा?

— लुम्पी

जवाबों:

कुछ महीने पहले, मुझे ऐसी ही स्थिति का सामना करना पड़ा जिसमें MAXDOP सेटिंग डिफ़ॉल्ट थी और एक रन दूर क्वेरी ने सभी कार्यकर्ता थ्रेड्स को समाप्त कर दिया।

जैसा कि रेमस ने बताया है कि इसे श्रमिक सूत्र भुखमरी कहा जाता है ।

यह स्थिति उत्पन्न होने पर आपके सर्वर पर एक मेमोरी डंप होगा।

यदि आप 2008R2 + SP1 पर हैं और फिर sys.dm_server_memory_dumpsआपको डंप फ़ाइल स्थान भी देंगे।

अब समस्या पर वापस:

NUMA नोड के अनुसार 1 शेड्यूलर मॉनीटर थ्रेड है और चूंकि आपके पास 2 NUMA नोड्स हैं, इसलिए 2 शेड्यूलर मॉनीटर थ्रेड होंगे, जो सभी शेड्यूलर के स्वास्थ्य की जाँच के लिए ज़िम्मेदार होते हैं, हर 60 सेकंड में उस विशेष NUMA नोड के लिए जाँच करते हुए कि शेड्यूलर अटक गया है या नहीं नहीं।

हर बार जब शेड्यूलर्स वर्कर कतार से एक नया कार्य अनुरोध निकाला जाता है, तो कार्य प्रक्रियाओं का काउंटर बढ़ जाता है। यदि शेड्यूलर के पास कार्य अनुरोध कतारबद्ध है और 60 सेकंड में कार्य अनुरोधों में से एक को संसाधित नहीं करता है, तो शेड्यूलर को माना जाता है।

एक रन-वे क्वेरी या व्यापक समानता के कारण, श्रमिक थ्रेड्स की एक स्थिति उत्पन्न होती है, क्योंकि सभी थ्रेड्स उस एकल-रन क्वेरी या अत्यधिक लंबे अवरुद्ध द्वारा कब्जा कर लिए जाते हैं और जब तक कि अपमानजनक प्रक्रिया को मार नहीं दिया जाता है तब तक कोई काम नहीं किया जा सकता है।

आपकी सबसे अच्छी शर्त है कि आप अपने मैक्स डिग्री ऑफ़ पैरेललिज्म सेटिंग को ट्यून करें । डिफ़ॉल्ट का 0 मतलब है कि SQL सर्वर सभी उपलब्ध सीपीयू का समानांतर प्रसंस्करण के लिए उपयोग कर सकता है और सभी वर्कर थ्रेड्स को समाप्त करके।

कई कारण हैं जो श्रमिक सूत्र की थकावट का कारण बन सकते हैं:

व्यापक लंबी अवरोधक जंजीरों के कारण SQL सर्वर वर्कर थ्रेड से बाहर निकल जाता है
व्यापक समानता भी कार्यकर्ता सूत्र की थकावट के लिए अग्रणी
किसी भी प्रकार के "लॉक" के लिए व्यापक प्रतीक्षा करें - स्पिनलॉक, लैच। एक अनाथ पालक एक उदाहरण है।

यहां मेरे जवाब का संदर्भ लें जो आपको दिखाएगा कि आप अपने सर्वर उदाहरण के लिए MAXDOP मान की गणना कैसे कर सकते हैं।

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

— परिजन शाह
स्रोत

वहाँ कुछ भी है जो एक रनवे क्वेरी का संकेत होगा? कुछ भी मैं उन प्रश्नों की पहचान करने का प्रयास कर सकता हूं जो इसके जोखिम में हैं?

— Lumpy

आपको यह पता लगाने के लिए प्रतीक्षा आँकड़े जानकारी देखने के लिए सुझाव दें कि यह कहाँ दर्द होता है । इसके अलावा, देखें sys.dm_os_schedulers-> current_tasks_count, runnable_tasks_count, current_workers_count और active_workers_count साथ ही sys.dm_os_wait_statsऔरsys.dm_os_waiting_tasks

— Kin Shah

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

आप जो लक्षण देखते हैं वह समस्या का शिकार है, कारण नहीं। हम कारण जानने के लिए समाधान w / o की अनुशंसा नहीं कर सकते। आपको अधिक जानकारी के लिए पूर्ण काउंटर, DMVs एकत्र करने और ERRORLOG की जांच करने की आवश्यकता है।

— रेमस रुसानु
स्रोत

अधिकतम वर्कर थ्रेड मिन = 128, अधिकतम = 32767, कॉन्फिग = 0, रन = 0

— लुम्पी

@ लम्बी यह आपकी कॉन्फ़िगरेशन अधिकतम है, लेकिन यह वास्तविक अधिकतम श्रमिकों के पास कहीं नहीं है। हमें यह जानना होगा कि आपकी मशीन को कितने प्रोसेसर की गणना करनी है।

— स्ट्रिंग में थॉमस स्ट्रिंगर