हमारे पास VMware वर्चुअल मशीन में चल रहे SQL Server 2016 SP1 का एक ही उदाहरण है। इसमें 4 डेटाबेस हैं, प्रत्येक एक अलग एप्लिकेशन के लिए है। वे एप्लिकेशन सभी अलग-अलग वर्चुअल सर्वर पर हैं। उनमें से कोई भी अभी तक उत्पादन उपयोग में नहीं है। अनुप्रयोगों का परीक्षण करने वाले लोग प्रदर्शन के मुद्दों की रिपोर्ट कर रहे हैं, हालांकि।
ये सर्वर के आँकड़े हैं:
- 128 जीबी रैम (110 जीबी मैक्स मेमोरी SQL सर्वर के लिए)
- 4 करोड़ @ 4.6 गीगाहर्ट्ज़
- 10 GBit नेटवर्क कनेक्शन
- सभी भंडारण एसएसडी आधारित है
- प्रोग्राम फाइल, लॉग फाइल, डेटाबेस फाइल और टेम्पर्डब सर्वर के अलग-अलग विभाजन पर हैं
- asd
उपयोगकर्ता C ++ आधारित ERP एप्लिकेशन के माध्यम से सिंगल स्क्रीन एक्सेस कर रहे हैं।
जब मैं Microsoft के ostressकई छोटे प्रश्नों या बड़ी क्वेरी का उपयोग करके SQL सर्वर का परीक्षण करता हूं, तो मुझे अधिकतम प्रदर्शन मिलता है। केवल थ्रॉटलिंग ही क्लाइंट है, क्योंकि वह तेजी से पर्याप्त उत्तर नहीं दे सकता है।
लेकिन जब बमुश्किल कोई उपयोगकर्ता होता है, तो SQL सर्वर मुश्किल से कुछ भी कर रहा है। फिर भी लोगों को आवेदन में कुछ भी बचाने के लिए हमेशा इंतजार करना पड़ता है।
पॉल रैंडल के अनुसार " मुझे बताओ कि यह कहाँ दर्द होता है " क्वेरी के अनुसार, सभी प्रतीक्षा घटनाओं के 50% हैं ASYNC_NETWORK_IO।
यह या तो नेटवर्क समस्या, या अनुप्रयोग सर्वर या क्लाइंट के साथ प्रदर्शन समस्या का अर्थ हो सकता है। अधिकतम क्षमता पर अपने संसाधनों का उपयोग करने में न तो दूरस्थ रूप से शामिल हैं। अधिकांश समय CPU सभी मशीनों (क्लाइंट, एपरसेवर, डीबी सर्वर) पर लगभग 26% है।
नेटवर्क कनेक्शन की विलंबता लगभग 1-3ms है। Db सर्वर का IO अनुप्रयोग के साथ सामान्य उपयोग के दौरान अधिकतम 20MB / s लिखने की गति पर है (औसत 7-9MB / s है)। जब मैं तनाव परीक्षण करता हूं, तो मुझे अधिकतम 5GB / s मिलता है।
हमारे ERP प्रणाली के DB के लिए बफर कैश का आकार 60GB, हमारे वित्तपोषण सॉफ्टवेयर के लिए 20GB, गुणवत्ता आश्वासन सॉफ़्टवेयर के लिए 1GB, दस्तावेज़ संग्रह प्रणाली के लिए 3GB है।
मैंने SQL सर्वर खाते को इंस्टेंट फ़ाइल इनिशियलाइज़ेशन का उपयोग करने का अधिकार दिया । यह प्रदर्शन में मामूली वृद्धि नहीं हुई।
सामान्य उपयोग के दौरान पृष्ठ जीवन प्रत्याशा लगभग 15k + है। भारी तनाव परीक्षण की समाप्ति के दौरान लगभग .05k तक गिर जाता है, जिसकी उम्मीद की जानी है। कार्यभार के आधार पर बैच / सेकंड लगभग 2-8k पर है।
मैं कहूंगा कि ईआरपी ऐप सिर्फ बुरी तरह से लिखा गया है, लेकिन मैं नहीं कर सकता क्योंकि सभी एप्लिकेशन प्रभावित हैं। यहां तक कि न्यूनतम कार्यभार पर भी।
फिर भी मैं यह क्या कारण है पर इंगित नहीं कर सकता। क्या इस समस्या के बारे में आपके पास कोई सुझाव, संकेत ट्यूटोरियल, एप्लिकेशन, सर्वोत्तम / सबसे खराब अभ्यास दस्तावेज या कुछ और हैं जो आप लोगों के दिमाग में हैं?
ये sp_BlitzFirstनिम्न परिणाम हैं :
मैंने इसे 600 सेकंड चलाया। मैंने इसे ऐप के उच्च वर्कलोड के दौरान शुरू किया था। 1/3 समय है ASYNC_NETWORK_IO। मैं भी साथ नेटवर्क कनेक्शन का परीक्षण किया NTttcp, PsPing, ipferf3, और pathping। कुछ भी असाधारण नहीं। प्रतिक्रिया समय अधिकतम 3ms, avg 0.3ms है। थ्रूपुट लगभग 1000 एमबी / एस पर है।
मेरी जांच में हमेशा ASYNC_NETWORK_IOनंबर एक वाट्सएप होने का परिणाम है ।
हमने Large-Receive-OffloadVMware में सुविधा को अक्षम करने के परिणाम की जांच की । हम अभी भी परीक्षण कर रहे हैं, लेकिन परिणाम असंगत लगते हैं। हमारा पहला 'बेंचमार्क' 19 मिनट की अवधि का था (शीर्ष परिणाम 13 मिनट का है जो केवल तभी प्राप्त होता है जब ऐप वीएम पर SQL सर्वर के साथ ही चल रहा हो)। दूसरा परिणाम 28 मिनट का है, जो वास्तव में खराब है।
हमारे 'बेंचमार्क' का पहला परिणाम 19 मिनट था। कौन सा अच्छा है। क्योंकि शीर्ष परिणाम 13 मिनट था (जो कि केवल तभी प्राप्त होता है जब एप्लिकेशन SQL सर्वर के साथ VM पर बेंचमार्क करता है)। यह कुछ नेटवर्क से संबंधित मुद्दे पर दृढ़ता से संकेत देता है। या VMware कॉन्फ़िगरेशन के साथ कोई समस्या।
मैं वर्तमान में किस तरीके का उपयोग करने के लिए खो गया हूं, इसे अड़चन में डालने के लिए।
एप्लिकेशन के साथ अधिकतम प्रदर्शन केवल तभी प्राप्त होता है जब एप्लिकेशन SQL सर्वर के साथ VM पर चल रहा हो। यदि एप्लिकेशन को किसी अन्य वीएम या वर्चुअल डेस्कटॉप पर निष्पादित किया जाता है, तो हमारे बेंचमार्क की अवधि तीन गुना हो जाती है (13 मिनट की अवधि से 40 मिनट या उससे अधिक)। सभी एंडपॉइंट (वीएम ऑफ़ SQL सर्वर, ऐप सर्वर का वीएम और वर्चुअल डेस्कटॉप) एक ही भौतिक हार्डवेयर का उपयोग कर रहे हैं। हमने अन्य सभी समापन बिंदुओं को अन्य हार्डवेयर में स्थानांतरित कर दिया है।
संपादित करें: लगता है जैसे समस्या वापस आ गई है। ऊर्जा बचत मोड को उच्च प्रदर्शन से संतुलित करने के बाद, हमने वास्तव में नाटकीय रूप से प्रतिक्रिया समय में सुधार किया। लेकिन आज मैं 300 सेकंड के नमूने के साथ फिर से sp_BlitzFirst चला गया। यह परिणाम है:
यह ASYNC_NETWORK_IO के लिए प्रतीक्षा समय के सेकंड सेकंड से अधिक चलता है जबकि sp_blitzfirst चला गया है।