मेरी कंपनी एक ऐसे एप्लिकेशन का उपयोग करती है जिसमें बहुत बड़ी प्रदर्शन समस्याएं हैं। डेटाबेस के साथ कई समस्याएं हैं, जिनके माध्यम से मैं काम करने की प्रक्रिया में हूं, लेकिन कई समस्याएं विशुद्ध रूप से अनुप्रयोग से संबंधित हैं।
अपनी जांच में मैंने पाया कि SQL सर्वर डेटाबेस पर लाखों क्वेरीज़ हैं जो खाली तालिकाओं को क्वेरी करती हैं। हमारे पास लगभग 300 खाली टेबल हैं और उनमें से कुछ टेबल प्रति मिनट 100-200 बार तक बोली जाती हैं। तालिकाओं का हमारे व्यावसायिक क्षेत्र से कोई लेना-देना नहीं है और मूल रूप से मूल एप्लिकेशन के कुछ भाग हैं जो विक्रेता ने तब नहीं निकाले जब उन्हें हमारी कंपनी द्वारा हमारे लिए एक सॉफ्टवेयर समाधान तैयार करने के लिए अनुबंधित किया गया था।
इस तथ्य के अलावा कि हमें संदेह है कि हमारी एप्लिकेशन त्रुटि लॉग इस समस्या से संबंधित त्रुटियों से भरी हुई है, विक्रेता हमें आश्वासन देता है कि आवेदन या डेटाबेस सर्वर के लिए कोई प्रदर्शन या स्थिरता प्रभाव नहीं है। त्रुटि लॉग उस सीमा तक भर गया है कि हम निदान करने के लिए त्रुटियों के 2 मिनट से अधिक मूल्य नहीं देख सकते हैं।
इन प्रश्नों की वास्तविक लागत स्पष्ट रूप से CPU चक्र आदि के संदर्भ में कम होने वाली है, लेकिन क्या कोई सुझाव दे सकता है कि SQL सर्वर और अनुप्रयोग पर क्या प्रभाव होगा? मुझे संदेह होगा कि एक अनुरोध भेजने, इसकी पुष्टि करने, इसे संसाधित करने, इसे वापस करने और आवेदन द्वारा रसीद स्वीकार करने का वास्तविक यांत्रिकी खुद प्रदर्शन पर असर पड़ेगा।
हम एप्लिकेशन के लिए SQL Server 2008 R2, Oracle Weblogic 11g का उपयोग करते हैं।
@ फ्रिसबी- लंबी कहानी संक्षेप में, मैंने एक तालिका बनाई थी जिसमें क्वेरीटेक्स्ट था जो ऐप के डेटाबेस में खाली तालिकाओं को हिट करता था, फिर इसे उन सभी टैबलेम्स के लिए क्वेर करता था जिन्हें मैं जानता हूं कि वे खाली हैं और बहुत लंबी सूची मिली है। शीर्ष हिट 30 दिनों के अपटाइम में 2.7 मिलियन निष्पादन पर था, ऐप को ध्यान में रखते हुए आमतौर पर 8 am-6pm का उपयोग किया जाता है, इसलिए वे संख्या परिचालन घंटों के लिए अधिक केंद्रित होती हैं। कई तालिकाओं, कई प्रश्नों, शायद कुछ जोड़ के माध्यम से relavent, कुछ नहीं। शीर्ष हिट (उस समय 2.7 मिलियन) एक खाली तालिका से एक सरल चयन था जहां एक खंड, कोई जोड़ नहीं है। मुझे उम्मीद है कि रिक्त तालिकाओं में जुड़ने से बड़े प्रश्नों को लिंक किए गए तालिकाओं में अपडेट शामिल हो सकता है, लेकिन मैं इस प्रश्न की जांच करूँगा और इस प्रश्न को अपडेट करूँगा।
अद्यतन: १०४३ - ४६२२६१४ (२.५ महीने से अधिक) के बीच की गणना के साथ १००० प्रश्न हैं। कैश्ड प्लान की उत्पत्ति कब होगी, यह जानने के लिए मुझे और खुदाई करनी होगी। यह आपको केवल प्रश्नों की सीमा का अंदाजा लगाने के लिए है। अधिकांश 20 से अधिक जोड़ के साथ यथोचित रूप से जटिल हैं।
@ srutzky- हाँ, मेरा मानना है कि जब योजना संकलित की गई थी, उस समय से संबंधित एक तारीख का कॉलम है, जो ब्याज का होगा, इसलिए मैं इसकी जांच करूंगा। मुझे आश्चर्य है कि जब SQL सर्वर एक VMware क्लस्टर पर बैठता है तो सीमाएं एक कारक होगी? जल्द ही एक समर्पित डेल पीई 730xD शुक्र है।
@ फ्रिसबी - देर से प्रतिक्रिया के लिए क्षमा करें। जैसा कि आपने सुझाव दिया, मैंने SQLQueryStress (इसलिए वास्तव में 240,000 पुनरावृत्तियों) का उपयोग करते हुए 24 थ्रेड्स पर 10,000 बार खाली टेबल से एक चयन * किया और तुरंत 10,000 बैच अनुरोध / सेकंड मारा। तब मैं 24 थ्रेड्स से 1000 गुना कम हो गया और 4,000 बैच अनुरोध / सेकंड के तहत हिट किया। मैंने केवल 12 थ्रेड्स (इसलिए 120000 कुल पुनरावृत्तियों) पर 10,000 पुनरावृत्तियों की कोशिश की और यह एक निरंतर 6,505 बैच / सेकंड का उत्पादन किया। सीपीयू पर प्रभाव वास्तव में ध्यान देने योग्य था, प्रत्येक परीक्षण चलाने के दौरान कुल CPU उपयोग का लगभग 5-10%। नेटवर्क वेट नगण्य थे (जैसे मेरे वर्कस्टेशन पर क्लाइंट के साथ 3ms) लेकिन सीपीयू प्रभाव वहाँ सुनिश्चित करने के लिए था, जो कि जहां तक मेरा संबंध है, काफी निर्णायक है। यह CPU उपयोग और थोड़े अनावश्यक डेटाबेस फ़ाइल IO को उबालने लगता है। कुल निष्पादन / दूसरा काम 3000 साल से कम उम्र में हो जाता है। जो उत्पादन से अधिक है, हालांकि मैं इस तरह के दर्जनों प्रश्नों में से केवल एक का परीक्षण कर रहा हूं। सीपीयू के समय की बात करें तो 300-4000 बार प्रति मिनट के बीच खाली टेबल पर बैठे सैकड़ों प्रश्नों का शुद्ध प्रभाव नगण्य होगा। दोहरी फ्लैश सरणी और 256 जीबी रैम, 12 आधुनिक कोर के साथ एक निष्क्रिय पीई 730xD के खिलाफ किए गए सभी परीक्षण।
@ srutzky- अच्छी सोच। SQLQueryStress डिफ़ॉल्ट रूप से कनेक्शन पूलिंग का उपयोग करने लगता है, लेकिन मुझे वैसे भी एक नज़र मिला और पाया कि हाँ, कनेक्शन पूलिंग के लिए बॉक्स की जाँच की जाती है। का पालन करने के लिए अद्यतन
@ srutzky- कनेक्शन पूलिंग जाहिरा तौर पर आवेदन पर सक्षम नहीं है - या यदि यह है, तो यह काम नहीं कर रहा है। मैंने एक प्रोफाइलर ट्रेस किया और पाया कि ऑडिट लॉग इवेंट्स के लिए कनेक्शन में EventSubClass "1 - Nonpooled" है।
पुन: कनेक्शन पूलिंग- वेबलॉग की जाँच की और कनेक्शन पूलिंग सक्षम पाया। जीवित रहने के खिलाफ और अधिक निशान पाए गए और पूलिंग के संकेत सही ढंग से / बिल्कुल नहीं हो रहे हैं:
और यहाँ पर ऐसा लगता है कि जब मैं एक एकल क्वेरी को बिना किसी जोड़ के एक आबादी वाले टेबल के साथ चलाता हूं; अपवाद पढ़ा "SQL सर्वर से कनेक्शन स्थापित करते समय एक नेटवर्क-संबंधित या आवृत्ति-विशिष्ट त्रुटि उत्पन्न हुई। सर्वर पाया नहीं गया था और पहुँच योग्य नहीं था। सत्यापित करें कि उदाहरण का नाम सही है और दूरस्थ कनेक्शन की अनुमति देने के लिए SQL सर्वर कॉन्फ़िगर किया गया है। (प्रदाता: नामित पाइप प्रदाता, त्रुटि: 40 - SQL सर्वर से कोई कनेक्शन नहीं खोल सकता) "बैच अनुरोध काउंटर पर ध्यान दें। समय के दौरान सर्वर को पिंग करना एक सफल पिंग प्रतिक्रिया में परिणाम उत्पन्न करता है।
अपडेट- लगातार दो टेस्ट रन, एक ही वर्कलोड (चयन * fromEmptyTable), पूलिंग सक्षम / सक्षम नहीं। थोड़ा अधिक CPU उपयोग और बहुत सी विफलताएं और कभी भी 500 बैच अनुरोधों / सेकंड से ऊपर नहीं जाता है। परीक्षण 10,000 बैच / सेकंड और पूलिंग ऑन के साथ कोई विफलता नहीं दिखाते हैं, और लगभग 400 बैच / सेकंड तब पूलिंग अक्षम होने के कारण बहुत सारी विफलताएं होती हैं। मुझे आश्चर्य है कि क्या ये विफलता कनेक्शन उपलब्धता की कमी से संबंधित हैं?
@ srutzky- sysinos_exec_connections से काउंट (*) चुनें;
पूलिंग सक्षम: 37 लगातार, लोड टेस्ट रुकने के बाद भी
पूलिंग अक्षम: 11-37 यह निर्भर करता है कि SQLQueryStress पर अपवाद हो रहे हैं या नहीं,
यानी: जब ये कुंड Batches
/ सेकंड ग्राफ पर दिखाई देते हैं , तो अपवाद SQLQueryStress पर होते हैं, और
कनेक्शन की संख्या 11 हो जाती है, फिर धीरे-धीरे 37 तक वापस आ जाती है जब चमगादड़ चरम पर होने लगते हैं और अपवाद नहीं होते हैं। बहुत, बहुत दिलचस्प।
0 के डिफ़ॉल्ट पर सेट किए गए दोनों परीक्षण / लाइव इंस्टेंसेस पर अधिकतम कनेक्शन।
हालांकि, एप्लिकेशन लॉग की जाँच की है और कनेक्टिविटी मुद्दों को नहीं पा सकते हैं, बड़ी संख्या में त्रुटियों के कारण उपलब्ध लॉगिंग के लायक केवल कुछ मिनट हैं: अर्थात ढेर सारी ट्रेस ट्रेस त्रुटियाँ। एप्लिकेशन समर्थन पर एक सहयोगी सलाह देता है कि कनेक्टिविटी से संबंधित HTTP त्रुटियों की एक बड़ी संख्या होती है। यह इस पर आधारित होगा, कि किसी कारण से एप्लिकेशन सही ढंग से कनेक्शन को पूल नहीं कर रहा है और परिणामस्वरूप, सर्वर बार-बार कनेक्शन से बाहर चल रहा है। मैं ऐप लॉग में अधिक देखूंगा। मुझे आश्चर्य है कि यह साबित करने का एक तरीका है कि SQL सर्वर की ओर से उत्पादन में क्या हो रहा है?
@ srutzky- धन्यवाद। मैं कल वेबलॉग कॉन्फिग पर जांच करूंगा और अपडेट करूंगा। मैं केवल 37 कनेक्शनों के बारे में सोच रहा था - अगर SQL®Stress 10,000 पुनरावृत्तियों पर 12 थ्रेड्स कर रहा है = 120,000 चयन न किए गए कथनों का, तो इसका मतलब यह नहीं है कि प्रत्येक चयन sql उदाहरण के लिए एक अलग कनेक्शन बनाता है?
@ srutzky- वेबलॉग को पूल कनेक्शन से कॉन्फ़िगर किया गया है, इसलिए इसे ठीक काम करना चाहिए। कनेक्शन पूलिंग को इस तरह से कॉन्फ़िगर किया गया है, प्रत्येक 4 लोड-संतुलित वेबलिक्स पर:
- प्रारंभिक क्षमता: 10
- अधिकतम क्षमता: 50
- न्यूनतम क्षमता: 5
जब मैं रिक्त तालिका क्वेरी से चयन निष्पादित करने वाले थ्रेड्स की संख्या बढ़ाता हूं, तो कनेक्शन की संख्या 47 के आसपास होती है। कनेक्शन पूलिंग अक्षम होने के साथ, मैं लगातार कम से कम अधिकतम बैच अनुरोध / सेकंड (10,000 से नीचे लगभग 400) देखता हूं। हर बार क्या होगा कि SQLQueryStress पर 'अपवाद' कुछ ही समय बाद बैचों / सेकंड एक गर्त में चले जाते हैं। यह कनेक्टिविटी से संबंधित है लेकिन मैं वास्तव में समझ नहीं पा रहा हूं कि ऐसा क्यों हो रहा है। जब कोई परीक्षण नहीं चल रहा है, तो # कनेक्शन लगभग 12 हो जाते हैं।
कनेक्शन पूलिंग अक्षम होने के साथ, मुझे यह समझने में परेशानी हो रही है कि अपवाद क्यों होते हैं, लेकिन हो सकता है कि यह एडम मैकैनिक के लिए एक पूरी तरह से अन्य स्टैक एक्सचेंज प्रश्न / प्रश्न हो?
@srutzky मुझे आश्चर्य है कि जब SQL सर्वर कनेक्शन से बाहर नहीं चल रहा है, तब भी सक्षम किए बिना अपवाद क्यों होते हैं?
SELECT COUNT(*) FROM sys.dm_exec_connections;यह देखने के लिए कि क्या पूलिंग सक्षम होने के बीच मान बहुत भिन्न है या नहीं नहीं। उन त्रुटियों के आधार पर, मुझे लगता है कि पूलिंग अक्षम होने पर कई और कनेक्शन होंगे।
Pooling=falseया Max Pool Size?