SQL सर्वर में I / O अनुरोधों के 15 सेकंड से अधिक समय होने की घटनाएं हुई हैं

Question

उत्पादन SQL सर्वर पर, हम निम्नलिखित विन्यास है:

3 डेल पॉवरएडज R630 सर्वर, उपलब्धता समूह सभी में संयुक्त 3 एकल डेल सैन स्टोरेज यूनिट से जुड़े हुए हैं जो एक RAID सरणी है

समय-समय पर, PRIMARY पर हम नीचे के समान संदेश देख रहे हैं:

SQL सर्वर ने डेटाबेस आईडी 8 में फ़ाइल [F: \ Data \ MyDatabase.mdf] पर पूरा करने के लिए I / O अनुरोधों के 11 घटना (15) से अधिक समय का सामना किया है
। OS फ़ाइल हैंडल 0x0000000000001FBC है।
नवीनतम आई / ओ की ऑफसेट है: 0x000004295d0000।
I / O लंबे समय की अवधि है: 37397 ms।

हम प्रदर्शन समस्या निवारण में नौसिखिया हैं

भंडारण से संबंधित इस विशेष समस्या के निवारण में सबसे सामान्य तरीके या सर्वोत्तम अभ्यास क्या हैं? ऐसे संदेशों के मूल कारण को कम करने के लिए कौन से प्रदर्शन काउंटर, टूल, मॉनीटर, ऐप आदि का उपयोग किया जाना चाहिए? हो सकता है कि कोई विस्तारित ईवेंट हो जो मदद कर सकता है, या किसी प्रकार का ऑडिट / लॉगिंग?

Comments

संबंधित: धीमी चौकी और फ्लैश स्टोरेज पर 15 सेकंड I / O चेतावनियां

— शॉन गेलार्डी

क्या SQL सर्वर उन भौतिक मशीनों पर VM में चल रहा है? यदि हां, तो आपको यह सुनिश्चित करने की आवश्यकता है कि हाइपरविजर सही ढंग से सेटअप है, और प्रत्येक वीएम ठीक से कॉन्फ़िगर किया गया है। VMware के लिए, vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/…

— Max Vernon

@MaxVernon नहीं, SQL सर्वर VM के अंदर नहीं है; हालाँकि, हाइपर- V भूमिका इन सर्वरों पर स्थापित की जाती है क्योंकि वे छोटे VM (IIS वेब सर्वर) की जोड़ी की मेजबानी कर रहे हैं ... क्या इस मामले में हाइपरवाइज़र सेटिंग्स की जाँच करने की आवश्यकता है?

— अलेक्सी विट्स्को

Answer 1

हमारे पास एक समान सेटअप है और हाल ही में लॉग में इन संदेशों का सामना करना पड़ा है। हम एक Dell सम्मिश्रण SAN का उपयोग कर रहे हैं। इन संदेशों को प्राप्त करने के लिए जाँच करने के लिए यहाँ कुछ चीजें दी गई हैं जिनसे हमें एक समाधान खोजने में मदद मिली

• अपने डिस्क के लिए अपने विंडोज़ प्रदर्शन काउंटरों की समीक्षा करें, जो चेतावनी संदेश विशेष रूप से इंगित कर रहे हैं:
  • डिस्क एवीजी। समय पढ़ें
  • डिस्क एवीजी। समय लिखो
  • डिस्क रीड बाइट्स / सेक
  • डिस्क लिख बाइट्स / सेकंड
  • डिस्क स्थानांतरण / सेकंड
  • औसत। डिस्क कतार लंबाई
• उपरोक्त औसत हैं। यदि आपके पास एक ड्राइव पर कई डेटाबेस फाइलें हैं, तो ये औसत परिणाम को तिरछा कर सकते हैं और विशिष्ट डेटाबेस फ़ाइलों पर एक बोतल गर्दन को मुखौटा कर सकते हैं। की जाँच करें इस जो DMV से प्रत्येक फ़ाइल के लिए औसत विलंबता रिटर्न पॉल एस रैंडल से क्वेरी sys.dm_io_virtual_file_stats। हमारे मामले में रिपोर्ट की गई औसत विलंबता स्वीकार्य थी, लेकिन कवर के नीचे हमारे पास> 200 एमएस औसत विलंबता वाली कई फाइलें थीं।
• समय की जाँच करें। क्या कोई पैटर्न है? क्या यह रात में निश्चित समय पर अधिक बार होता है? यदि ऐसा है तो देखें कि क्या उस समय कोई रखरखाव कार्य चल रहा है या कोई अनुसूचित गतिविधि जो डिस्क गतिविधि को बढ़ा सकती है और आपके आईआईएस सबसिस्टम में एक बोतल गर्दन को उजागर कर सकती है।
• त्रुटियों के लिए विंडोज़ इवेंट व्यूअर की जाँच करें। यदि आपके स्विच या SAN को आपके एप्लिकेशन के लिए ठीक से लोड नहीं किया जा रहा है या सेटअप नहीं किया जा रहा है, तो आपको इस लॉग में कुछ संदेश मिल सकते हैं, और यह जानकारी आपके SAN व्यवस्थापक को लेना अच्छा है। हमारे मामले में हम पूरे दिन अक्सर iSCSI कनेक्शन त्रुटियों को प्राप्त कर रहे थे, समस्या पर इशारा कर रहे थे।
• अपने SQL सर्वर कोड की समीक्षा करें। जब आप इन संदेशों को प्राप्त करते हैं तो आपको तुरंत यह नहीं सोचना चाहिए कि यह एक IO सबसिस्टम समस्या है और इसे अपने SAN व्यवस्थापक को पास करें। आपको अपना हिस्सा करने और डेटाबेस की समीक्षा करने की आवश्यकता है। क्या आपके पास वास्तव में खराब प्रश्न हैं जो अक्सर टन डेटा के माध्यम से मंथन किए जा रहे हैं? खराब अनुक्रमण? अत्यधिक लेनदेन लॉग लिखता है? आप अपने डेटाबेस पर स्वास्थ्य जांच प्राप्त करने के लिए कुछ ओपन सोर्स क्वेश्चन का उपयोग कर सकते हैं, यह जांचने के लिए एक उदाहरण है कि आपकी क्वेरी योजना कैसी दिखती है
• इन पर ध्यान न दें। आज आप उन्हें दिन में कई बार प्राप्त कर सकते हैं ... फिर कई महीनों बाद जब आपका कार्यभार बढ़ जाता है और आप उन्हें मॉनिटर करना भूल जाते हैं तो वे बढ़ना शुरू कर देते हैं। इनमें से बहुत सारे संदेश प्राप्त करने से SQL सर्वर को एक निश्चित फ़ाइल तक पहुंचने से रोका जा सकता है, और यदि यह अस्थायी है , तो यह अच्छा नहीं है। हमारे मामले में यह इतना खराब हो गया कि SQL सर्वर खुद बंद हो गया।

हमारा समाधान हमारे स्विच को SAN स्विच में अपग्रेड कर रहा था। हाँ, ये सभी बिंदुएँ SQL सर्वर के भीतर हैं। हमें यह पता लगाने के लिए प्रेरित किया गया कि यह स्विच था कि हम हर दिन SQL सर्वर पर विंडोज एप्लिकेशन इवेंट व्यूअर में लगभग 1500 iSCSI pdu डिस्कनेक्ट त्रुटियों को प्राप्त कर रहे थे। इसने हमारे SAN द्वारा जांच को स्विच में प्रवेश करने के लिए प्रेरित किया।

अपग्रेड करने के तुरंत बाद, iSCSI त्रुटियाँ हो गईं और सभी फ़ाइलों के लिए औसत विलंबता लगभग 50 ms तक कम हो गई, और यह कि आवेदन में बेहतर प्रदर्शन के लिए सहसंबद्ध हो गया। इन बिंदुओं को ध्यान में रखते हुए उम्मीद है कि आप अपना समाधान पा सकते हैं।

Comments

तो सिस्टम ईवेंट, SQL सर्वर में नहीं, आपको रिज़ॉल्यूशन पर ले जाता है, सही? यदि समस्या SQL सर्वर, OS स्तर, फ़ाइल सिस्टम स्तर, या संग्रहण क्षेत्र नेटवर्किंग स्तर पर कुछ आंतरिक है, तो क्या आप किसी अन्य समस्या निवारण समस्या को कम करने में मदद कर सकते हैं?

— सीन गेलार्डी

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

— केविनहाट

Answer 2

यह एक डिस्क समस्या है, और कहीं अधिक अक्सर एक नेटवर्किंग समस्या है। तुम्हें पता है, सैन में एन?

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

इसके बजाय, उन्हें SAN के नेटवर्क पथ के बारे में पूछें। गति प्राप्त करें, यदि यह बहुपथित है, आदि उन से उन संख्याओं के बारे में प्राप्त करें जिन्हें आप देख रहे हैं। पूछें कि क्या सर्वर के सेट होने पर उनके पास बेंचमार्क हैं।

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

आपको उन संदेशों के लिए भी अपनी त्रुटि लॉग की खोज करनी चाहिए जिनमें "फ्लशचेच" और "संतृप्ति" शामिल हैं, क्योंकि वे नेटवर्क नोटेशन के संकेत भी हो सकते हैं।

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

आप अधिक सुझावों के लिए यहां उत्तरों की जांच करना भी चाह सकते हैं: धीमी जांच और फ्लैश स्टोरेज पर 15 सेकंड I / O चेतावनी

मैंने यहां एक समान विषय के बारे में ब्लॉग किया है: सर्वर से सैन के लिए

Answer 3

क्यों एक पर डेटा भंडारण SAN? क्या बात है? सभी डेटाबेस प्रदर्शन डिस्क I / O से बंधा है और आप उनके पीछे I / O के लिए केवल एक डिवाइस के साथ 3 सर्वर का उपयोग कर रहे हैं। इसका कोई मतलब नहीं है ... और दुर्भाग्य से इतना आम है।

मैं अपना जीवन खराब तरीके से डिजाइन किए गए हार्डवेयर प्लेटफ़ॉर्मों पर गुजारता हूं, जहां लोग बस बड़े पैमाने पर कंप्यूटर डिजाइन करने की कोशिश करते हैं। सभी सीपीयू पावर यहां, सभी डिस्क वहां ... उम्मीद है कि रिमोट रैम जैसी कोई चीज नहीं होगी। और सबसे दुख की बात यह है कि वे इस डिज़ाइन की दक्षता की कमी की भरपाई विशाल सर्वरों से करते हैं जिनकी लागत उनकी तुलना में दस गुना अधिक है। मैंने $ 1k लैपटॉप की तुलना में $ 400k इन्फ्रा स्लोअर देखा।

एसक्यूएल सर्वर सॉफ्टवेयर एक बहुत ही उन्नत सॉफ्टवेयर है, यह किसी भी बिट हार्डवेयर, सीपीयू कोर, सीपीयू कैश, टीएलबी, रैम, डिस्क कंट्रोलर, हार्ड ड्राइव कैश का लाभ लेने के लिए बनाया गया है ... वे लगभग सभी फाइल सिस्टम लॉजिक को शामिल करते हैं। वे नियमित कंप्यूटर पर विकसित किए जाते हैं और उच्च अंत प्रणालियों पर बेंचमार्क किए जाते हैं। SQL सर्वर के पास अपने स्वयं के डिस्क होने चाहिए। एक SAN पर उन्हें स्थापित करना एक कंप्यूटर का "अनुकरण" करने जैसा है, आप सभी प्रदर्शन अनुकूलन खो देते हैं। सैन बैकअप, अपरिवर्तनीय फ़ाइलों को संग्रहीत करने के लिए हैं, और आप फ़ाइलों को केवल (लॉग) डेटा संलग्न करते हैं।

डाटासेंटर प्रशासक वे सभी को सैन पर रख सकते हैं क्योंकि इस तरह से उनके पास प्रबंधन करने के लिए भंडारण का केवल एक पूल है, प्रत्येक सर्वर पर भंडारण की देखभाल करने की तुलना में यह अधिक आसान है। यह एक "मैं अपनी नौकरी नहीं करना चाहता" पसंद है, और एक बहुत बुरा है, क्योंकि तब उन्हें प्रदर्शन की समस्याओं से निपटना पड़ता है और सभी कंपनी इससे पीड़ित होती हैं। बस उस हार्डवेयर पर सॉफ़्टवेयर स्थापित करें जिसके लिए इसे डिज़ाइन किया गया है। इसे सरल रखें। आई / ओ बैंडविड्थ, कैश और संदर्भ स्विच ओवरहेड के लिए देखभाल, रीसोर्स जिटर (जब रिसोर्स साझा किया जाता है तब होता है)। आप एक ही कच्चे आउटपुट पावर के लिए 1/10 वीं डिवाइस को बनाए रखेंगे, अपनी ऑप्स टीम को बहुत अधिक सिरदर्द से बचाएंगे, प्रदर्शन हासिल करेंगे जो आपके अंतिम उपयोगकर्ताओं को खुश और अधिक उत्पादक बनाते हैं, आपकी कंपनी को काम करने के लिए एक बेहतर जगह बनाते हैं, और बहुत सारी ऊर्जा बचाएं (ग्रह आपको धन्यवाद देगा)।

आपने टिप्पणियों में कहा, आप SSD को अपने सर्वर में रखने पर विचार कर रहे हैं। आप समर्पित SSDs के साथ अपने सेटअप को नहीं पहचानेंगे, SAN की तुलना में आपको एक ही ड्राइव पर डेटा और ट्रांजेक्शन लॉग फ़ाइलों के साथ भी 500x सुधार जैसा कुछ मिलेगा। कला SQL सर्वर के एक राज्य में अलग हार्डवेयर नियंत्रक चैनलों पर डेटा और लेनदेन लॉग के लिए तेजी से अलग एसएसडी होगा (अधिकांश सर्वर मदरबोर्ड में कई हैं)। लेकिन आपके वर्तमान सेटअप की तुलना में हम वहां विज्ञान-फाई की बात कर रहे हैं। बस SSD को आज़माएँ।

Comments

यह मुझे एक ही SAN का उपयोग करने वाले सभी 3 के बजाय प्रत्येक प्रतिकृति (डेटा फ़ाइलों के लिए, शायद लॉग फ़ाइलों के लिए) के लिए समर्पित SSD ड्राइव खरीदने के बारे में फिर से सोचता है। मैं धीरे-धीरे ऊपर पोस्ट किए गए सभी आइटमों की दोहरी जांच कर रहा हूं, साथ ही बेशक

— अलेक्सी विट्स्को

Answer 4

ठीक है, रुचि रखने वाले किसी के लिए,

हमने प्रत्येक दो सर्वरों में सीधे संलग्न SSD ड्राइव स्थापित करके, और DB डेटा को लॉग इन करके और उन SSD ड्राइव्स से SAN में लॉग फाइल करके, प्रश्न युगल में कुछ महीने पहले हल किया था।

यहाँ पर मैंने इस मुद्दे पर शोध करने के लिए क्या किया, इस पर एसएसडी स्थापित करने का निर्णय लेने से पहले हमने इस मुद्दे पर सभी सिफारिशों (इस सवाल से सभी सिफारिशों का उपयोग करके) का सारांश प्रस्तुत किया:

1) सभी 3 सर्वरों पर निम्नलिखित ड्राइव के लिए PerfMon काउंटर इकट्ठा करना शुरू किया:

Disk F:सैन के आधार पर लॉजिकल डिस्क है, जिसमें एमडीएफ डेटा फाइलें हैं,
Disk I:यह सैन के आधार पर लॉजिकल डिस्क है, जिसमें एलडीएफ लॉग फाइलें हैं,
Disk T:जो सीधे एसएसडी से जुड़ी होती है, जो केवल अस्थायी रूप से समर्पित है।

नीचे दी गई तस्वीर 2 सप्ताह की अवधि के लिए एकत्रित औसत मूल्य है

Disk I: (LDF)इस तरह की एक छोटी आईओ और लेटेंसी बहुत कम है, इसलिए डिस्क I: को अनदेखा किया जा सकता है
आप देख सकते हैं कि Disk T: (TempDB)इसकी तुलना में बड़ा IO है Disk F: (MDF), और यह एक ही समय में बेहतर लेटेंसी है - 0 ms

स्पष्ट रूप से डिस्क एफ के साथ कुछ गलत है: जहां डेटा फाइलें निवास करती हैं, इसमें उच्च I और कम डिस्क के बावजूद डिस्क डिस्क लिखें क्यू है।

2) इस वेबसाइट से क्वेरी का उपयोग करते हुए व्यक्तिगत डेटाबेस के लिए जाँच की विलंबता

https://www.brentozar.com/blitz/slow-storage-reads-writes/

प्राथमिक सर्वर पर कुछ सक्रिय डेटाबेसों में 150-250 एमएस रीड लेटेंसी और 150-450 एमएस लेटेंसी लिखते हैं
दिलचस्प क्या है, मास्टर और एमएसडीबी डेटाबेस फ़ाइलों ने 90 एमएस तक विलंबता पढ़ी थी जो संदिग्ध है उनके डेटा के छोटे आकार और निम्न IO - एक और संकेत कुछ गलत है SAN

3) कोई विशिष्ट समय नहीं था

जिसके दौरान "SQL सर्वर में घटनाएं
हुईं ..." संदेश दिखाई दिए कि उन संदेशों को लॉग किए जाने पर कोई रखरखाव या डिस्क हेवी ईटीएल नहीं चल रहा था

4) विंडोज इवेंट व्यूअर

"SQL सर्वर में हुई घटनाओं को छोड़कर ..." समस्या को संकेत देने वाली कोई अन्य प्रविष्टि नहीं दिखाई गई थी ...

5) शीर्ष 10 प्रश्नों की जाँच शुरू

Sp_BlitzCache (cpu, पढ़ता है, आदि) से, और जहाँ संभव
नहीं है, वहाँ कोई भी सुपर IO भारी क्वेरी जो डेटा का भारी मंथन करेगी और भंडारण को भारी रूप से प्रभावित करेगी, हालाँकि
डेटाबेस में अनुक्रमण ठीक है, मैं इसे बनाए रखता हूँ

6) हमारे पास सैन टीम नहीं है

हमारे पास केवल 1 sysadmin है जो
SAN को दूषण नेटवर्क पथ पर मदद करता है - यह बहुपथित है, 3 सर्वरों में से प्रत्येक में 2 नेटवर्क केबल हैं जो स्विच करने के लिए और फिर SAN के लिए अग्रणी हैं, और इसका 1 गीगाबाइट / सेकंड होना चाहिए

7) कोई क्रिस्टलडिमार्क परिणाम नहीं थे

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

8) विचाराधीन डेटाबेस के लिए चेकपॉइंट इवेंट पर विस्तारित ईवेंट सत्र सेटअप करें

एक्सई सत्र ने यह पता लगाने में मदद की कि "एसक्यूएल सर्वर में घटनाएं हुई हैं ..." संदेश, चेकपॉइंट वास्तव में धीमा हुआ (90 सेकंड तक)

9) SQL सर्वर त्रुटि लॉग

शामिल "फ्लशचेच" "संतृप्ति" प्रविष्टियाँ,
ये तब दिखाना चाहिए जब दिए गए डेटाबेस के लिए चेकपॉइंट समय पुनर्प्राप्ति अंतराल सेटिंग्स से अधिक हो

विवरण से पता चला है कि चेकपॉइंट को फ्लश करने के लिए डेटा की मात्रा छोटी है और इसे पूरा होने में लंबा समय लग रहा है, और समग्र गति लगभग 0.25 एमबी / सेकंड है ... अजीब

10) अंत में, यह चित्र संग्रहण समस्या निवारण चार्ट दिखाता है:

ऐसा प्रतीत होता है कि हमारे पास "हार्डवेयर प्रॉब्लम: - SAN, पुराने / दोषपूर्ण ड्राइवरों, नियंत्रकों, फर्मवेयर, आदि के किसी भी गलत धारणा को ठीक करने के लिए सिस्टम एडमिन / हार्डवेयर विक्रेता के साथ काम करना है"

एक अन्य प्रश्न में "धीमी जांच चौकी ..." धीमी चौकी और 15 सेकंड I / O फ्लैश स्टोरेज पर चेतावनियों की बहुत अच्छी सूची थी कि समस्या के निवारण के लिए हार्डवेयर और सॉफ्टवेयर स्तर पर किन वस्तुओं की जाँच की जानी है

हमारा sysadmin सूची से सभी चीजों की जांच नहीं कर सकता है, इसलिए हम बस इस मुद्दे पर कुछ हार्डवेयर फेंकना चुनते हैं - यह बिल्कुल महंगा नहीं था

संकल्प:

हमने 1 टीबी एसएसडी ड्राइव का आदेश दिया और सीधे सर्वर में स्थापित किया

चूंकि हमारे पास उपलब्धता समूह हैं, इसलिए सैकेंडरी रेप्लस पर SAN से SSD तक की DB डेटा फाइलें माइग्रेट की गईं, फिर फेल हो गईं, और पूर्व प्राथमिक पर माइग्रेट की गई फाइलें न्यूनतम कुल डाउनटाइम के लिए अनुमत हैं - 1 मिनट से कम

अब प्रत्येक सर्वर में डीबी डेटा की स्थानीय प्रतिलिपि होती है, और पूर्ण SAN / पूर्ण / लॉग बैकअप उल्लिखित SAN के लिए किया जाता है
"SQL सर्वर में घटनाएं हुई हैं ..." संदेश Windows इवेंट व्यूअर लॉग्स में, और बैकअप का प्रदर्शन, अखंडता की जाँच करता है, इंडेक्स रिबोर, क्वेरी आदि में काफी वृद्धि हुई है

IO विलंबता के संदर्भ में कितना प्रदर्शन बेहतर हुआ है क्योंकि हमने DB फाइल को SSD में स्थानांतरित कर दिया है?

प्रभाव का मूल्यांकन करने के लिए, प्रयुक्त प्रदर्शन Windows प्रदर्शन मॉनिटर लॉग से 2 सप्ताह पहले और माइग्रेशन के 4 सप्ताह बाद लॉग करता है:

नीचे डीबी स्तर की विलंबता आँकड़े तुलना (उपयोग किए जाने से पहले और बाद में SQL सर्वर की कैप्चर की गई वर्चुअल फ़ाइल आँकड़े का उपयोग किया जाता है)

सारांश

सैन से माइग्रेशन सीधे स्थानीय एसएसडी से जुड़ा हुआ था, यह अच्छी तरह से लायक
था, इसका भंडारण की विलंबता पर बहुत प्रभाव पड़ा और औसतन 90% से अधिक सुधार हुआ (विशेष रूप से राइट ऑपरेशन), और हमारे पास अब IO में 20-50 सेकंड स्पाइक्स नहीं हैं।

स्थानीय एसएसडी में जाने से न केवल भंडारण प्रदर्शन के मुद्दों का समाधान हुआ, बल्कि डेटा सुरक्षा भी थी, जिसके बारे में मैं चिंतित था (यदि SAN विफल रहता है, तो सभी 3 सर्वर एक ही समय में अपना डेटा खो देते हैं)