Database
 sql >> डेटाबेस >  >> RDS >> Database

घुटना टेककर प्रतीक्षा आंकड़े :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 पर नेविगेट करना उन्हें>

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


शीर्ष SQL में लंबे समय से चल रही क्वेरी की समीक्षा करना उन्हें>

यदि मैं SQL संतरी क्लाइंट में योजना को देखता हूँ या इसे SQL संतरी योजना एक्सप्लोरर में खोलता हूँ, तो मुझे तुरंत कई समस्याएं दिखाई देती हैं। 7 पंक्तियों को वापस करने के लिए आवश्यक रीड्स की संख्या बहुत अधिक लगती है, अनुमानित और वास्तविक पंक्तियों के बीच का डेल्टा बड़ा है, और योजना एक इंडेक्स स्कैन को दिखाती है जहां मुझे एक तलाश की उम्मीद होगी:


क्वेरी प्लान में कन्वर्ज़न चेतावनियां देखना

इन सबका कारण SELECT . पर चेतावनी में हाइलाइट किया गया है ऑपरेटर:यह एक अंतर्निहित रूपांतरण है!

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

यह प्रतीत होता है कि निर्दोष कोड में क्रॉप हो सकता है, और एक सामान्य उदाहरण दिनांक गणना का उपयोग कर रहा है। यदि आपके पास एक तालिका है जो ग्राहकों की आयु संग्रहीत करती है, और आप यह देखने के लिए गणना करना चाहते हैं कि कितने 21 वर्ष या उससे अधिक पुराने हैं, तो आप इस तरह कोड लिख सकते हैं:

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

इस कोड के साथ, गणना टेबल कॉलम पर होती है और इसलिए इंडेक्स सीक का उपयोग नहीं किया जा सकता है, जिसके परिणामस्वरूप एक अनपेक्षित एक्सप्रेशन (तकनीकी रूप से गैर-एसएआरजीबल एक्सप्रेशन के रूप में जाना जाता है) और एक टेबल/क्लस्टर इंडेक्स स्कैन होता है। यह गणना को ऑपरेटर के दूसरी तरफ ले जाकर हल किया जा सकता है:

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

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

सारांश

अत्यधिक PAGEIOLATCH_XX . के इस सोच के जाल में न पड़ें प्रतीक्षा I/O सबसिस्टम के कारण होती है। मेरे अनुभव में वे आमतौर पर SQL सर्वर के साथ कुछ करने के कारण होते हैं और यहीं से मैं समस्या निवारण शुरू करूंगा।

जहां तक ​​सामान्य प्रतीक्षा आंकड़ों का संबंध है, आप प्रदर्शन समस्या निवारण के लिए उनका उपयोग करने के बारे में अधिक जानकारी यहां प्राप्त कर सकते हैं:

  • मेरी SQLskills ब्लॉग पोस्ट श्रृंखला, प्रतीक्षा आँकड़ों से शुरू होती है, या कृपया मुझे बताएं कि यह कहाँ दर्द होता है
  • मेरे प्रतीक्षा प्रकार और कुंडी कक्षा पुस्तकालय यहां
  • मेरा प्लूरलसाइट ऑनलाइन प्रशिक्षण पाठ्यक्रम SQL सर्वर:प्रतीक्षा सांख्यिकी का उपयोग करके प्रदर्शन समस्या निवारण
  • एसक्यूएल संतरी

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


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL इंजेक्शन के विरुद्ध JDBC एप्लिकेशन की सुरक्षा कैसे करें

  2. मांग के साथ आपूर्ति का मिलान चुनौती

  3. 2013 एमवीपी शिखर सम्मेलन:एक त्वरित समीक्षा और आगे की ओर एक झलक

  4. कैसे सुनिश्चित करें कि डेटाबेस में खंडित अनुक्रमणिकाएं नहीं हैं

  5. डेटाबेस टेबल्स जानकारी प्राप्त करने के लिए संग्रहीत प्रक्रिया

© कॉपीराइट http://hi.sqldat.com सर्वाधिकार सुरक्षित