घुटना टेककर प्रतीक्षा आंकड़े :PAGEIOLATCH_SH

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

• PAGEIOLATCH_SH - (एसएच हैं) डेटा फ़ाइल पृष्ठ को डिस्क से बफर पूल में लाए जाने की प्रतीक्षा कर रहे हैं ताकि इसकी सामग्री को पढ़ा जा सके
• PAGEIOLATCH_EX या PAGEIOLATCH_UP - (पूर्व समावेशी या यूपी date) डेटा फ़ाइल पृष्ठ को डिस्क से बफर पूल में लाए जाने की प्रतीक्षा कर रहा है ताकि इसकी सामग्री को संशोधित किया जा सके

इनमें से, अब तक का सबसे सामान्य प्रकार है PAGEIOLATCH_SH ।

जब यह प्रतीक्षा प्रकार सर्वर पर सबसे अधिक प्रचलित होता है, तो घुटने के बल चलने वाली प्रतिक्रिया यह होती है कि I/O सबसिस्टम में कोई समस्या होनी चाहिए और इसलिए जांचों पर ध्यान केंद्रित किया जाना चाहिए।

सबसे पहले आपको PAGEIOLATCH_SH . की तुलना करनी होगी आपकी आधार रेखा के विरुद्ध प्रतीक्षा संख्या और अवधि। यदि प्रतीक्षा की मात्रा कमोबेश समान है, लेकिन प्रत्येक पढ़ने की प्रतीक्षा की अवधि बहुत लंबी हो गई है, तो मुझे I/O सबसिस्टम समस्या के बारे में चिंता होगी, जैसे:

• I/O सबसिस्टम स्तर पर गलत कॉन्फ़िगरेशन/खराबी
• नेटवर्क विलंबता
• एक और I/O कार्यभार जो हमारे कार्यभार के साथ विवाद पैदा कर रहा है
• सिंक्रोनस I/O-सबसिस्टम प्रतिकृति/मिररिंग का कॉन्फ़िगरेशन

मेरे अनुभव में, पैटर्न अक्सर PAGEIOLATCH_SH . की संख्या का होता है बेसलाइन (सामान्य) राशि से प्रतीक्षा में काफी वृद्धि हुई है और प्रतीक्षा अवधि भी बढ़ गई है (यानी पढ़ने के लिए समय I/O बढ़ गया है), क्योंकि बड़ी संख्या में पढ़ने वाले I/O सबसिस्टम को अधिभारित करते हैं। यह I/O सबसिस्टम समस्या नहीं है - यह SQL सर्वर जितना होना चाहिए उससे अधिक I/O चला रहा है। अतिरिक्त I/Os के कारण की पहचान करने के लिए फोकस को अब SQL सर्वर पर स्विच करने की आवश्यकता है।

पठन I/Os की बड़ी संख्या के कारण

SQL सर्वर में दो प्रकार के रीड होते हैं:तार्किक I/Os और भौतिक I/Os। जब स्टोरेज इंजन के एक्सेस मेथड्स हिस्से को किसी पेज तक पहुंचने की आवश्यकता होती है, तो यह बफर पूल को मेमोरी में पेज पर पॉइंटर के लिए पूछता है (जिसे लॉजिकल I/O कहा जाता है) और बफर पूल अपने मेटाडेटा के माध्यम से यह देखने के लिए जांच करता है कि वह पेज है या नहीं पहले से ही स्मृति में है।

यदि पेज मेमोरी में है, तो बफर पूल एक्सेस मेथड्स को पॉइंटर देता है, और I/O एक लॉजिकल I/O बना रहता है। यदि पृष्ठ स्मृति में नहीं है, तो बफ़र पूल एक "वास्तविक" I/O जारी करता है (जिसे भौतिक I/O कहा जाता है) और थ्रेड को इसके पूरा होने तक प्रतीक्षा करनी पड़ती है - एक PAGEIOLATCH_XX रुको। एक बार जब I/O पूरा हो जाता है और पॉइंटर उपलब्ध हो जाता है, तो थ्रेड अधिसूचित हो जाता है और चलना जारी रख सकता है।

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

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

यहां कुछ संभावित मूल कारण दिए गए हैं (संपूर्ण सूची नहीं):

• SQL सर्वर पर बाहरी विंडोज़ मेमोरी दबाव के कारण मेमोरी मैनेजर बफर पूल का आकार कम कर देता है
• बफर पूल से अतिरिक्त मेमोरी उधार लेने के कारण कैशे ब्लोट की योजना बनाएं
• एक टेबल/क्लस्टर इंडेक्स स्कैन करने वाली क्वेरी प्लान (इंडेक्स सीक के बजाय):
  • कार्यभार की मात्रा में वृद्धि
  • एक पैरामीटर सूँघने की समस्या
  • एक आवश्यक गैर-संकुल अनुक्रमणिका जिसे छोड़ दिया गया या बदल दिया गया
  • एक निहित रूपांतरण

इसके लिए देखने के लिए एक पैटर्न एक टेबल/क्लस्टर इंडेक्स स्कैन का सुझाव देगा क्योंकि इसका कारण बड़ी संख्या में CXPACKET भी है। PAGEIOLATCH_SH के साथ प्रतीक्षा कर रहा है प्रतीक्षा करता है यह एक सामान्य पैटर्न है जो बड़े, समानांतर टेबल/क्लस्टर इंडेक्स स्कैन होने का संकेत देता है।

सभी मामलों में, आप देख सकते हैं कि कौन सी क्वेरी योजना PAGEIOLATCH_SH उत्पन्न कर रही है sys.dm_os_waiting_tasks . का उपयोग करके प्रतीक्षा करता है और अन्य डीएमवी, और आप मेरे ब्लॉग पोस्ट में ऐसा करने के लिए कोड प्राप्त कर सकते हैं। यदि आपके पास कोई तृतीय-पक्ष निगरानी उपकरण उपलब्ध है, तो यह आपके हाथों को गंदा किए बिना अपराधी की पहचान करने में आपकी सहायता कर सकता है।

SQL संतरी और प्लान एक्सप्लोरर के साथ वर्कफ़्लो का उदाहरण

एक सरल (स्पष्ट रूप से तैयार किए गए) उदाहरण में, मान लें कि मैं SQL संतरी के उपकरण का उपयोग कर क्लाइंट सिस्टम पर हूं और SQL संतरी के डैशबोर्ड दृश्य में I/O प्रतीक्षा में एक स्पाइक देखता हूं, जैसा कि नीचे दिखाया गया है:

I/O में स्पाइक का पता लगाना SQL संतरी में प्रतीक्षा करता है

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

समय सीमा को हाइलाइट करना और शीर्ष SQL पर नेविगेट करना उन्हें>

WHERE DATEADD (YEAR, 21, [MyTable].[BirthDate]) <= @today;

WHERE [MyTable].[BirthDate] <= DATEADD (YEAR, -21, @today);