पिछले 18 महीनों से मैं आँकड़ों के विश्लेषण और अन्य प्रदर्शन-ट्यूनिंग से संबंधित विषयों की प्रतीक्षा करने के लिए घुटनों के बल चलने वाली प्रतिक्रियाओं पर ध्यान केंद्रित कर रहा हूँ, और इस पोस्ट में मैं इसे जारी रखने जा रहा हूँ और PAGELATCH_XX पर चर्चा करूँगा। प्रतीक्षा करता है प्रतीक्षा के अंत में XX का अर्थ है कि PAGELATCH . के कई प्रकार हैं प्रतीक्षा करें, और सबसे सामान्य उदाहरण हैं:
- PAGELATCH_SH - ( एसएच हैं) स्मृति में डेटा फ़ाइल पृष्ठ तक पहुंच की प्रतीक्षा कर रहे हैं ताकि पृष्ठ सामग्री को पढ़ा जा सके
- PAGELATCH_EX या PAGELATCH_UP - (पूर्व समावेशी या यूपी दिनांक) स्मृति में डेटा फ़ाइल पृष्ठ तक पहुंच की प्रतीक्षा कर रहा है ताकि पृष्ठ सामग्री को संशोधित किया जा सके
जब इन प्रतीक्षा प्रकारों में से एक सर्वर पर सबसे अधिक प्रचलित होता है, तो घुटने के बल चलने वाली प्रतिक्रिया यह होती है कि समस्या I/O से संबंधित है (अर्थात PAGEIOLATCH_XX के साथ भ्रम) प्रतीक्षा प्रकार, जिसे मैंने 2014 में एक पोस्ट में कवर किया था) और कोई अधिक मेमोरी जोड़ने या I/O सबसिस्टम को ट्विक करने का प्रयास करता है। इन प्रतिक्रियाओं में से किसी का भी कोई प्रभाव नहीं पड़ेगा, क्योंकि विवाद के तहत डेटा फ़ाइल पेज बफ़र पूल में पहले से ही मेमोरी में हैं!
सभी मामलों में, आप देख सकते हैं कि आपको PAGELATCH_XX . में कोई समस्या है या नहीं sys.dm_os_waiting_tasks . का उपयोग करके विवाद मेरे ब्लॉग पर स्क्रिप्ट या प्रदर्शन सलाहकार जैसे टूल का उपयोग करना, जैसा कि इस पोस्ट में दिखाया गया है (एक अलग प्रतीक्षा प्रकार के लिए)।
तो विवाद का स्रोत क्या है? पहले मैं इन प्रतीक्षा प्रकारों के पीछे की पृष्ठभूमि के बारे में बताऊंगा, और फिर मैं PAGELATCH_XX के दो सबसे सामान्य कारणों पर चर्चा करूंगा। विवाद।
पृष्ठभूमि:कुंडी
इससे पहले कि मैं PAGELATCH_XX . के कुछ कारणों में जाऊं प्रतीक्षा करता है, मैं समझाना चाहता हूं कि वे क्यों मौजूद हैं।
किसी भी मल्टी-थ्रेडेड सिस्टम में, डेटा संरचनाएं जिन्हें कई थ्रेड्स द्वारा एक्सेस और हेरफेर किया जा सकता है, को परिदृश्यों को रोकने के लिए संरक्षित करने की आवश्यकता होती है जैसे:
- एक साथ डेटा संरचना को अपडेट करने वाले दो थ्रेड, और कुछ अपडेट खो जाते हैं
- एक थ्रेड डेटा संरचना को पढ़ने वाले दूसरे थ्रेड के साथ-साथ डेटा संरचना को अपडेट करता है, इसलिए रीडिंग थ्रेड पुराने और नए डेटा का मिश्रण देखता है
यह बुनियादी कंप्यूटर विज्ञान है, और SQL सर्वर अलग नहीं है, इसलिए SQL सर्वर के अंदर सभी डेटा संरचनाओं को बहु-थ्रेडेड अभिगम नियंत्रण की आवश्यकता होती है।
ऐसा करने के लिए SQL सर्वर द्वारा उपयोग किए जाने वाले तंत्रों में से एक को लैच कहा जाता है, जहां लैच को अनन्य मोड में रखने से अन्य थ्रेड्स को डेटा संरचना तक पहुँचने से रोकता है, और लैच को शेयर मोड में रखने से अन्य थ्रेड्स को डेटा संरचना को बदलने से रोकता है। SQL सर्वर कुछ डेटा संरचनाओं के लिए स्पिनलॉक का भी उपयोग करता है और मैंने 2014 में इस पोस्ट में इन पर चर्चा की थी।
लेकिन स्मृति में डेटा फ़ाइल पृष्ठ एक कुंडी द्वारा सुरक्षित क्यों है, आपको आश्चर्य हो सकता है? खैर, एक डेटा फ़ाइल पृष्ठ केवल एक डेटा संरचना है, हालांकि एक विशेष उद्देश्य एक है, और इसलिए किसी भी अन्य डेटा संरचना के समान पहुंच नियंत्रण की आवश्यकता है। इसलिए जब एक थ्रेड को डेटा फ़ाइल पृष्ठ को संशोधित करने की आवश्यकता होती है, तो उसे पृष्ठ पर एक विशेष या अद्यतन लैच प्राप्त करने की आवश्यकता होती है, और यदि यह नहीं हो सकता है और प्रतीक्षा करने की आवश्यकता है, तो प्रतीक्षा प्रकार PAGELATCH_EX या PAGELATCH_UP परिणाम।
क्लासिक tempdb विवाद
PAGELATCH Tempdb में विवाद आम तौर पर आवंटन बिटमैप्स पर होता है और कई समवर्ती कनेक्शनों के साथ वर्कलोड के साथ होता है जो छोटे अस्थायी टेबल (जो tempdb में संग्रहीत होते हैं) बनाते और छोड़ते हैं।
जब पहली पंक्ति को अस्थायी तालिका में डाला जाता है, तो दो पृष्ठ आवंटित किए जाने चाहिए (एक डेटा पृष्ठ और एक IAM पृष्ठ, जो डेटा पृष्ठ को ट्रैक करता है)। इन पृष्ठों को एक विशेष आवंटन पृष्ठ में आवंटित के रूप में चिह्नित करने की आवश्यकता है जिसे पीएफएस पृष्ठ कहा जाता है, और डिफ़ॉल्ट रूप से विशेष डेटा विस्तार से आवंटित किए जाते हैं जिन्हें एसजीएएम पृष्ठ नामक एक अन्य आवंटन पृष्ठ द्वारा ट्रैक किया जाता है (इनका विवरण मेरे पुराने ब्लॉग पोस्ट में पाया जा सकता है) यहाँ)। जब अस्थायी तालिका को छोड़ दिया जाता है, तो इन पृष्ठों को फिर से हटाने की आवश्यकता होती है, जिससे PFS और SGAM पृष्ठों में और अधिक परिवर्तन आवश्यक हो जाते हैं।
यदि अस्थायी तालिकाएँ छोटी हैं, और सभी समवर्ती रूप से बनाई गई अस्थायी तालिकाओं का संचयी आकार 64MB से कम है, तो ये सभी आवंटन बिटमैप परिवर्तन tempdb डेटा फ़ाइल में पहले PFS और SGAM पृष्ठों पर केंद्रित होते हैं (पृष्ठ आईडी के साथ (1:1) और (1:3) क्रमशः)। इन आवंटन पृष्ठों में से किसी एक को अपडेट करने के लिए पृष्ठ को लॉक करना आवश्यक है, और एक समय में केवल एक थ्रेड पृष्ठ को बदल सकता है, इसलिए अन्य सभी थ्रेड को प्रतीक्षा प्रकार के साथ PAGELATCH_UP प्रतीक्षा करनी होगी। ।
SQL सर्वर 2005 के बाद से, अस्थायी तालिकाओं को गिराए जाने पर कैश किया जा सकता है, जब तक कि वे आकार में 8MB से कम न हों (और SQL सर्वर 2014 में एक संग्रहीत प्रक्रिया में नहीं बनाया जाता है जिसमें अस्थायी तालिका पर DDL स्टेटमेंट भी होते हैं)। इसका मतलब यह है कि अगला थ्रेड जो समान क्वेरी योजना को निष्पादित करता है, अस्थायी तालिका को कैश से बाहर ले जा सकता है और प्रारंभिक आवंटन से निपटने की आवश्यकता नहीं है। यह आवंटन बिटमैप्स पर विवाद को कम करता है, लेकिन अस्थायी टेबल कैश बहुत बड़ा नहीं है, इसलिए सैकड़ों समवर्ती अस्थायी टेबल क्रिएट/ड्रॉप्स के साथ वर्कलोड में अभी भी बहुत सारे विवाद दिखाई देंगे।
सर्वर पर प्रलेखित ट्रेस फ्लैग 1118 को सक्षम करके tempdb में SGAM पृष्ठों पर विवाद को रोकने के लिए तुच्छ है, जो मैं कहता हूं कि दुनिया भर के सभी सर्वरों पर सक्षम होना चाहिए, और वास्तव में SQL सर्वर 2016 में अपरिवर्तनीय डिफ़ॉल्ट व्यवहार है।
Tempdb में PFS पृष्ठों पर विवाद को रोकना थोड़ा अधिक कठिन है। यह मानते हुए कि प्रदर्शन के लिए अस्थायी तालिकाओं की आवश्यकता है, यह चाल है कि tempdb के लिए कई डेटा फाइलें हों ताकि आवंटन फाइलों के बीच राउंड-रॉबिन किया जा सके, विवाद कई PFS पृष्ठों पर विभाजित हो जाता है, और इसलिए समग्र विवाद नीचे चला जाता है। दुर्भाग्य से आपके पास कितनी डेटा फ़ाइलें होनी चाहिए, इसका कोई सही उत्तर नहीं है। आप इस पर आम तौर पर स्वीकृत मार्गदर्शन के बारे में KB आलेख 2154845 और इस ब्लॉग पोस्ट में अधिक पढ़ सकते हैं।
हॉटस्पॉट डालें
उपयोगकर्ता डेटाबेस में, PAGELATCH_EX . की उच्च संख्या का एक सामान्य कारण प्रतीक्षा एक सम्मिलित हॉटस्पॉट है।
यह तब हो सकता है जब किसी तालिका में एक int या bigint क्लस्टर कुंजी के साथ एक संकुल अनुक्रमणिका होती है, और एक पंक्ति का आकार इतना छोटा होता है कि कई दस या अधिक तालिका पंक्तियाँ संकुल अनुक्रमणिका के पत्ती स्तर पर एक डेटा पृष्ठ पर फ़िट हो सकें।
ऐसी तालिका के लिए, यदि कार्यभार में तालिका में सम्मिलित करने वाले कई दसियों या सैकड़ों समवर्ती धागे शामिल हैं, तो कई धागे पहचान मूल्यों (और इसलिए क्लस्टर कुंजियाँ) के साथ पंक्तियाँ उत्पन्न करेंगे जिन्हें समान पत्ती-स्तरीय डेटा पृष्ठ पर डालने की आवश्यकता होती है। ।
अब याद रखें कि मेमोरी में डेटा फ़ाइल पेज में कोई भी बदलाव करने के लिए एक विशेष लैच की आवश्यकता होती है, इसलिए एक ही पेज पर सम्मिलित करने का प्रयास करने वाले प्रत्येक थ्रेड को पेज के लैच को विशेष रूप से प्राप्त करना चाहिए। जबकि प्रत्येक थ्रेड अनन्य कुंडी धारण कर रहा है, अन्य थ्रेड PAGELATCH_EX की प्रतीक्षा कर रहे होंगे उस पृष्ठ के लिए, अनिवार्य रूप से समवर्ती सम्मिलन को एक बेहद-अड़चन वाली तुल्यकालिक प्रक्रिया में बनाना।
इस समस्या के कुछ संभावित समाधान हैं:
- अधिक यादृच्छिक कुंजी का उपयोग करें, और पहचानें कि इससे अनुक्रमणिका विखंडन हो जाएगा इसलिए पृष्ठ विभाजन को रोकने में मदद करने के लिए अनुक्रमणिका भरण कारक का भी उपयोग करें
- किसी प्रकार के कृत्रिम विभाजन तंत्र का उपयोग करके इन्सर्ट को तालिका में फैलाएं
- एक लंबी तालिका पंक्ति आकार का उपयोग करें (यह स्पष्ट रूप से कम से कम स्वादिष्ट विकल्प है)
मैंने इस फसल की तरह एक सम्मिलित हॉटस्पॉट देखा है जब किसी ने एक यादृच्छिक GUID क्लस्टर कुंजी को int या bigint पहचान क्लस्टर कुंजी में बदलकर अनुक्रमणिका विखंडन समस्याओं को दूर करने का प्रयास किया है, लेकिन उत्पादन भार के तहत नई तालिका स्कीमा का परीक्षण करने में विफल रहा है।
सारांश
अन्य प्रतीक्षा प्रकारों की तरह ही, PAGELATCH_XX . को ठीक से समझना वेट्स माध्य यह समझने की कुंजी है कि उनका निवारण कैसे किया जाए।
जहां तक सामान्य प्रतीक्षा आंकड़ों का संबंध है, आप प्रदर्शन समस्या निवारण के लिए उनका उपयोग करने के बारे में अधिक जानकारी यहां प्राप्त कर सकते हैं:
- मेरी SQLskills ब्लॉग पोस्ट श्रृंखला, प्रतीक्षा आँकड़ों से शुरू होती है, या कृपया मुझे बताएं कि यह कहाँ दर्द होता है
- मेरे प्रतीक्षा प्रकार और कुंडी कक्षा पुस्तकालय यहाँ
- मेरा प्लूरलसाइट ऑनलाइन प्रशिक्षण पाठ्यक्रम SQL सर्वर:प्रतीक्षा सांख्यिकी का उपयोग करके प्रदर्शन समस्या निवारण
- एसक्यूएल संतरी प्रदर्शन सलाहकार
अगली बार तक, समस्या निवारण के लिए शुभकामनाएँ!
