SQL सर्वर CPU प्रदर्शन समस्याओं का निवारण

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

इस पोस्ट में मैं जिन चरणों का वर्णन करूँगा वे इस प्रकार हैं:

1. समस्या को परिभाषित करें
2. वर्तमान स्थितियों की पुष्टि करें
3. उत्तर "क्या यह SQL सर्वर है"?
4. सीपीयू उपभोक्ताओं की पहचान करें
5. पैटर्न का मिलान करें और हल करें

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

समस्या को परिभाषित करें

पहले हमें इस मुद्दे का दायरा बढ़ाने की जरूरत है। जब कोई आपके पास आता है और कहता है कि वे सीपीयू प्रदर्शन समस्या देख रहे हैं, तो इसका मतलब कई अलग-अलग चीजें हो सकता है। तो पहला काम यह समझना है कि वर्तमान में CPU प्रदर्शन समस्या की प्रकृति क्या है।

कुछ सामान्य श्रेणियों में शामिल हैं:

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

मैं शुरुआती बिंदु के रूप में इन अति-संग्रहित श्रेणियों का उल्लेख करता हूं, लेकिन मुझे पता है कि अक्सर इन मुद्दों पर भारी निर्भरता हो सकती है और एक वर्गीकरण दूसरे में मिल सकता है। इसके साथ ही, पहला कदम लक्षणों और समस्याओं को यथासंभव स्पष्ट रूप से परिभाषित करना है।

वर्तमान स्थितियों की पुष्टि करें

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

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

भौतिक सर्वर विवरण

• कितने सॉकेट और कोर?
• क्या हाइपर-थ्रेडिंग सक्षम है?
• प्रोसेसर मॉडल, आर्किटेक्चर (32-बिट/64-बिट) क्या है?

वर्चुअल सर्वर विवरण

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

रिजर्व, VMware CPU रिजर्वेशन, Hyper-V CPU रिलेटिव वेट, और VMware CPU शेयर।

• अतिथियों में कितने वीसीपीयू आवंटित किए जाते हैं?
• इस अतिथि के पास कितने vCPU हैं?
• क्या अतिथि हाल ही में समस्या से पहले एक नए होस्ट में माइग्रेट किया गया था?

SQL सर्वर इंस्टेंस कॉन्फ़िगरेशन सेटिंग्स

• समानांतरता सेटिंग की अधिकतम डिग्री
• समानता विकल्प के लिए लागत सीमा
• प्रोसेसर एफ़िनिटी सेटिंग
• प्राथमिकता बूस्ट सेटिंग
• अधिकतम कार्यकर्ता थ्रेड सेटिंग
• हल्के पूलिंग सेटिंग


पहले तीन कॉन्फ़िगरेशन के लिए और अधिक चर्चा की आवश्यकता हो सकती है। इन सेटिंग्स के बारे में शायद ही कभी निरपेक्षता होती है।

पिछली तीन सेटिंग्स के बारे में, जैसे कि "प्राथमिकता बढ़ावा", अगर मैं देखता हूं कि वे गैर-डिफ़ॉल्ट मानों पर हैं, तो मैं निश्चित रूप से अधिक पृष्ठभूमि जानकारी और इतिहास पर जोर देने जा रहा हूं।

CPU पावर-विकल्प सेटिंग

• पावर-विकल्प सेटिंग क्या है? (OS स्तर, VM होस्ट या BIOS नियंत्रित)
  • उच्च प्रदर्शन, संतुलित, बिजली की बचत?

"उच्च प्रदर्शन" के नीचे पावर-विकल्प सेटिंग्स अभी भी बहुत सामान्य हैं और SQL सर्वर इंस्टेंस को होस्ट करने वाले सर्वर के लिए इसे अनदेखा नहीं किया जाना चाहिए।

संसाधन गवर्नर कॉन्फ़िगरेशन

• क्या यह डिफ़ॉल्ट सेटिंग्स से परे कॉन्फ़िगर किया गया है?


मुझे अब भी लगता है कि इस सुविधा का उपयोग करने वाले ग्राहकों से मिलना दुर्लभ है, लेकिन यह सत्यापित करना आसान है कि क्या इसका उपयोग किया जा रहा है और यह उस समय के लिए इसके लायक होगा जब यह वास्तव में डिफ़ॉल्ट से परे कॉन्फ़िगर किया गया हो।
पी>

SQL सर्वर त्रुटि लॉग और Windows ईवेंट लॉग

• क्या आपको कोई असामान्य चेतावनियां या त्रुटियां दिखाई देती हैं?


CPU समस्या के लिए त्रुटि और ईवेंट लॉग क्यों देखें? कभी-कभी अपस्ट्रीम समस्याएँ SQL सर्वर में डाउनस्ट्रीम प्रदर्शन समस्याओं का कारण बन सकती हैं। जब आप अपस्ट्रीम मूल-कारण समस्या एक हार्डवेयर घटक अवक्रमण समस्या है, तो आप किसी क्वेरी को ट्यून करने या एक नई अनुक्रमणिका जोड़ने में समय बर्बाद नहीं करना चाहते हैं।

उत्तर "क्या यह SQL सर्वर है?"

जब मैं इसे पूछता हूं तो यह स्पष्ट लगता है, लेकिन आप वास्तव में SQL सर्वर में एक उच्च CPU समस्या का निवारण करने में महत्वपूर्ण समय व्यतीत नहीं करना चाहते हैं यदि अपराधी वास्तव में SQL सर्वर नहीं है।

इसके बजाय, यह जांचने के लिए एक त्वरित क्षण लें कि कौन सी प्रक्रिया सबसे अधिक सीपीयू की खपत कर रही है। चुनने के लिए कई विकल्प हैं, जिनमें शामिल हैं:

• प्रक्रिया:% उपयोगकर्ता समय (उपयोगकर्ता मोड)
• प्रक्रिया:% विशेषाधिकार प्राप्त समय (कर्नेल मोड)
• कार्य प्रबंधक
• प्रोसेस एक्सप्लोरर
• सिस्टम पर चल रहे विशिष्ट SQL सर्वर इंस्टेंस के लिए sys.dm_os_ring_buffers या सिस्टम स्वास्थ्य सत्र के माध्यम से हाल की CPU जानकारी

यदि यह SQL सर्वर है और आपके पास चुनने के लिए कई SQL सर्वर इंस्टेंस हैं, तो सुनिश्चित करें कि आप होस्ट पर सही SQL सर्वर इंस्टेंस का समस्या निवारण कर रहे हैं। ऐसा करने के कुछ तरीके हैं, जिसमें SELECT SERVERPROPERTY('processid') का उपयोग करना शामिल है। पीआईडी ​​प्राप्त करने के लिए और फिर इसे टास्क मैनेजर या प्रोसेस एक्सप्लोरर से जोड़ना।
एक बार जब आप पुष्टि कर लेते हैं कि यह SQL सर्वर है, तो क्या आप उच्च उपयोगकर्ता समय या विशेषाधिकार प्राप्त (कर्नेल) समय देख रहे हैं? फिर से इसकी पुष्टि प्रक्रिया के माध्यम से की जा सकती है:% विशेषाधिकार प्राप्त समय (sqlservr ऑब्जेक्ट) और विंडोज टास्क मैनेजर या प्रोसेस एक्सप्लोरर भी।

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

CPU उपभोक्ताओं की पहचान करें

एक बार जब आप यह सत्यापित कर लेते हैं कि कौन सा SQL सर्वर इंस्टेंस सिस्टम पर उपयोगकर्ता-समय CPU उपयोग चला रहा है, तो वेब पर बहुत से पूर्व-डिब्बाबंद क्वेरी उदाहरण हैं जिनका आप उपयोग कर सकते हैं।

नीचे उन DMV की सूची दी गई है जिनका उपयोग लोग आमतौर पर किसी प्रदर्शन समस्या के दौरान विभिन्न रूपों में करते हैं। मैंने इसे एक प्रश्नोत्तर प्रारूप में संरचित किया है ताकि यह तय किया जा सके कि आप उन तक क्यों पहुंचना चाहते हैं।

इस समय कौन से अनुरोध निष्पादित हो रहे हैं और उनकी स्थिति क्या है?

• sys.dm_exec_requests

यह क्या क्रियान्वित कर रहा है?

• sys.dm_exec_sql_text

यह कहां से है?

• sys.dm_exec_sessions
• sys.dm_exec_connections

इसकी अनुमानित योजना क्या है? (लेकिन पहले से ही सीपीयू-बाधित सिस्टम पर एक्सएमएल को कतरने से सावधान रहें)

• sys.dm_exec_query_plan

संसाधन की प्रतीक्षा कौन कर रहा है और वे किसकी प्रतीक्षा कर रहे हैं?

• sys.dm_os_waiting_tasks

पिछली बार पुनरारंभ होने के बाद से किन प्रश्नों ने सबसे अधिक CPU समय लिया है?

• sys.dm_exec_query_stats
• total_worker_time के हिसाब से जोड़ें
• निष्पादन_गणना के साथ औसत परिभाषित करें
• यदि तदर्थ कार्यभार है, तो आप query_hash के आधार पर समूह बना सकते हैं
• योजना को हथियाने के लिए sys.dm_exec_query_plan के साथ plan_handle का उपयोग करें

क्या यह क्वेरी समानांतरवाद का उपयोग कर रही है?

• sys.dm_os_tasks
  • session_id, request_id द्वारा आदेशित
• sys.dm_exec_query_plan
  • योजना संचालकों को देखें - लेकिन ध्यान रखें कि यह केवल अनुमानित योजना है
• sys.dm_exec_query_stats
  • कुल_कार्यकर्ता_समय से कम कुल_बीता हुआ_समय फ़िल्टर करें
  • लेकिन ध्यान दें कि यह अवरुद्ध परिदृश्यों के लिए एक गलत नकारात्मक हो सकता है - जहां संसाधन पर प्रतीक्षा के कारण अवधि बढ़ जाती है

पैटर्न का मिलान करें और हल करें

आप शायद इस विशेष कदम पर हंस रहे हैं - क्योंकि यह सबसे अधिक शामिल हो सकता है (और एक और कारण है कि SQL सर्वर पेशेवर लाभप्रद रूप से कार्यरत हैं)। कई अलग-अलग पैटर्न और संबंधित संकल्प हैं - इसलिए मैं पिछले कुछ वर्षों में देखे गए अधिक सामान्य CPU प्रदर्शन समस्या ड्राइवरों की सूची के साथ इस पोस्ट को समाप्त करूंगा:

• उच्च I/O संचालन (और मेरे अनुभव में यह CPU का सबसे सामान्य चालक है)
• कार्डिनैलिटी अनुमान संबंधी समस्याएं (और संबंधित खराब क्वेरी योजना गुणवत्ता)
• अप्रत्याशित समानता
• अत्यधिक संकलन / पुनर्संकलन
• गणना-गहन यूडीएफ कॉल, कतरन संचालन
• पंक्ति-दर-पंक्ति संचालन
• समवर्ती रखरखाव गतिविधियाँ (जैसे FULLSCAN के साथ अद्यतन आँकड़े)

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

सारांश

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