लंबे समय तक "क्लाइंट प्रोसेसिंग टाइम" के कारण सुदूर रिमोट सेलेक्ट स्टेटमेंट, लेकिन स्थानीय स्तर पर तेजी से

Question

हमारे उत्पादन सर्वर (SQL Server 2008, बहुत शक्तिशाली मशीन) से जुड़े रहते हुए, इस SELECT स्टेटमेंट में 2 सेकंड लगते हैं , सभी क्षेत्रों को पीछे छोड़ते हुए (कुल 4 एमबी डेटा)।

SELECT TOP (30000) *
FROM person
WITH(NOLOCK);

एक ही नेटवर्क पर किसी अन्य बॉक्स से (SQL प्रमाणीकरण या विंडोज प्रमाणीकरण का उपयोग करके), उसी क्वेरी में 1 मिनट, 8 सेकंड लगते हैं ।

मैं यह बताने के लिए बहुत ही सरल कथन के साथ परीक्षण कर रहा हूं कि यह अनुक्रमण समस्या या क्वेरी से संबंधित समस्या नहीं है। (हमारे पास इस समय सभी प्रश्नों के साथ प्रदर्शन के मुद्दे हैं ...)

पंक्तियाँ चंक्स में आती हैं, और एक बार में नहीं। मुझे अपनी पहली पंक्तियाँ तुरन्त मिल जाती हैं, और फिर पंक्तियों के जत्थों के आने के लिए 1 मिनट तक इंतजार करना पड़ता है।

यहां क्वेरी के क्लाइंट आंकड़े हैं, जब इसे रिमोट बॉक्स से चलाया जाता है:

Query Profile Statistics
  Number of INSERT, DELETE and UPDATE statements 0
  Rows affected by INSERT, DELETE, or UPDATE statements 0
  Number of SELECT statements  2
  Rows returned by SELECT statements 30001
  Number of transactions 0

Network Statistics
  Number of server roundtrips 3
  TDS packets sent from client        3
  TDS packets received from server 1216
  Bytes sent from client         266
  Bytes received from server 4019800

Time Statistics
  Client processing time 72441 ms (72 seconds)
  Total execution time   72441 ms
  Wait time on server replies 0

हम देख सकते हैं कि "क्लाइंट प्रोसेसिंग टाइम" कुल निष्पादन समय के बराबर है।

क्या किसी को पता है कि मैं निदान करने के लिए क्या कदम उठा सकता हूं, वास्तविक डेटा के हस्तांतरण में लंबा समय क्यों लग रहा है?

क्या कोई SQL कॉन्फ़िगरेशन पैरामीटर है जो मशीनों के बीच डेटा ट्रांसफर गति को प्रतिबंधित या सीमित करता है?

Comments

वैसे, हमने डीबी सर्वर और एक अन्य बॉक्स के बीच एक ही आकार (4 एमबी) की फाइल को कॉपी करने की कोशिश की, और इसमें एक सेकंड का समय लगा। तो एक नेटवर्क समस्या की तरह प्रतीत नहीं होता है।

— 20

क्लाइंट एप्लिकेशन क्या है? एंड-यूज़र वर्कस्टेशन पर SSMS?

— थॉमस स्ट्रिंगर 20

हाँ Microsoft SQL सर्वर प्रबंधन स्टूडियो 10.50.1600.1। 2008 R2

— FranticRock

यह समस्या तब से शुरू हुई जब हमने डेटासेंटर को स्थानांतरित किया, और पूरी मशीन को फिर से स्थापित किया गया (एसक्यूएल सहित सब कुछ)। हम एक बहुत सम्मानित होस्टिंग प्रदाता के साथ हैं।

— FranticRock

Answer 1

आपकी समस्या निश्चित रूप से नेटवर्क से संबंधित है, आपकी जानकारी के आधार पर। जैसे, इसे नेटवर्क पेशेवरों के साथ निपटा जाना चाहिए (मैं एक नहीं हूं)।

चीजें जो मदद कर सकती हैं:

• तेज़ एनआईसी कार्ड (SQL सर्वर पर)।
• सर्वर (वेब-सर्वर और एसक्यूएल सर्वर) के बीच आवंटित / विशिष्ट एनआईसी कार्ड / सबनेट जोड़ना।

क्या वेब-सर्वर SQL सर्वर के समान उप-नेट में है?

क्या उनके बीच राउटर / पुल आदि हैं?

SQL सर्वर पर कई संभावित परिवर्तन नहीं:

• आउटपुट डेटा SQL सर्वर द्वारा मालिकाना एमएस "टीडीएस प्रोटोकॉल" के साथ भेजा जा रहा है।
• टीडीएस बफर का डिफ़ॉल्ट आकार 4 केबी है। MSDB में देखें: "नेटवर्क पैकेट आकार विकल्प"
• डेटा को संपीड़ित करना (SQL सर्वर या बाहरी अनुप्रयोग के साथ) - डेटा की प्रकृति पर निर्भर करता है।

आप एक डिफ़ॉल्ट आकार का उपयोग कर रहे हैं: अपने आँकड़े देखें: "सर्वर से प्राप्त TDS पैकेट 1216" (4MB / 1K = 4KB)। हां, टीडीएस बफर का आकार बदला जा सकता है: Google में देखें: "टीडीएस प्रोटोकॉल बैच आकार"

विषय पर अच्छी चर्चा: "क्या एसक्यूएल के नेटवर्क पैकेट का आकार वास्तव में गोल यात्रा यातायात को निर्धारित करता है?"

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

वास्तुकला में बदलाव या मिड-टियर पर डेटा की कैशिंग शुरू करने से भी मदद मिलेगी।

Answer 2

इस मुद्दे का अब समाधान कर दिया गया है।

यह एक नेटवर्क समस्या थी, और SQL बॉक्स 10 जीबी / एस एनआईसी के बजाय 100 एमबी / एस एनआईसी कार्ड का उपयोग कर रहा था ...

सही नेटवर्क कार्ड का उपयोग करने के लिए एक नेटवर्क कॉन्फ़िगरेशन परिवर्तन ने समस्या को ठीक कर दिया है। अब हम उत्पादन SQL बॉक्स से और नेटवर्क पर अन्य बॉक्स से सभी प्रश्नों के लिए समान प्रदर्शन प्राप्त कर रहे हैं।

आपकी मदद के लिए सभी को शुक्रिया।

Comments

मेरे पास आपके जैसा ही मुद्दा है और मैं यह जांचना चाहता हूं कि मेरा SQL सर्वर किस NIC कार्ड का उपयोग करता है। मैं उसे कहां देख सकता हूं?

— मीशा ज़स्लावस्की

Answer 3

प्रारंभिक पढ़ने पर ऐसा लगता है कि आप कुछ नेटवर्क विलंबता समस्याओं का सामना कर रहे हैं। क्या आपने नेटवर्क परफ़ॉर्मर काउंटरों में से कुछ को देखा है? वे आपको कुछ संकेत दे सकते हैं कि नेटवर्क के साथ क्या हो रहा है।

क्या परफ़ॉर्मर काउंटर से उद्धरण मुझे मॉनिटर करना चाहिए और उनमें से प्रत्येक का क्या मतलब है?

नेटवर्क IO

नेटवर्क I / O को मापने के लिए, आप निम्नलिखित काउंटरों का उपयोग कर सकते हैं:

नेटवर्क इंटरफ़ेस कुल / सेकंड

थ्रेसहोल्ड: नेटवर्क बैंडविड्थ के 80 प्रतिशत से अधिक के निरंतर मूल्य।

महत्व: यह काउंटर उस दर को इंगित करता है जिस पर प्रत्येक नेटवर्क एडेप्टर पर बाइट्स भेजे और प्राप्त किए जाते हैं। यह काउंटर आपको यह जानने में मदद करता है कि क्या आपके नेटवर्क एडेप्टर पर ट्रैफ़िक संतृप्त है और यदि आपको किसी अन्य नेटवर्क एडेप्टर को जोड़ने की आवश्यकता है। किसी समस्या की पहचान आप कितनी जल्दी कर सकते हैं यह इस बात पर निर्भर करता है कि आपके पास किस प्रकार का नेटवर्क है और क्या आप अन्य अनुप्रयोगों के साथ बैंडविड्थ साझा करते हैं।

नेटवर्क इंटरफ़ेस प्राप्त / सेकंड

यह काउंटर उस दर को इंगित करता है जिस पर प्रत्येक नेटवर्क एडेप्टर पर बाइट्स प्राप्त होते हैं। आप कुल बैंडविड्थ के एक हिस्से के रूप में आने वाले डेटा की दर की गणना कर सकते हैं। यह आपको यह जानने में मदद करेगा कि आपको क्लाइंट से आने वाले डेटा को ऑप्टिमाइज़ करने की ज़रूरत है या आपको आने वाले ट्रैफ़िक को संभालने के लिए दूसरे नेटवर्क एडेप्टर को जोड़ने की आवश्यकता है।

नेटवर्क इंटरफ़ेस भेजे गए / सेकंड

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

ServerBytes कुल / सेकंड

यह मान नेटवर्क की क्षमता के 50 प्रतिशत से अधिक नहीं होना चाहिए।

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

प्रोसेसर% इंटरप्ट टाइम

यह काउंटर उस समय के प्रतिशत को इंगित करता है, जब प्रोसेसर हार्डवेयर प्राप्त करने और सर्विस करने में खर्च करता है। यह मान डिवाइस की गतिविधि का एक अप्रत्यक्ष संकेतक है जो नेटवर्क एडेप्टर जैसे अवरोध उत्पन्न करता है।

नेटवर्क इंटरफ़ेस (*) आउटपुट कतार लंबाई

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

आउटपुट कतार की लंबाई आउटपुट पैकेट कतार (पैकेट में) की लंबाई है। यदि यह दो से अधिक है, तो देरी हो रही है और यदि संभव हो तो अड़चन को ढूंढना चाहिए और समाप्त करना चाहिए। चूंकि इस कार्यान्वयन में नेटवर्क ड्राइवर इंटरफ़ेस विनिर्देश (NDIS) द्वारा अनुरोधों को कतारबद्ध किया गया है, यह हमेशा 0 होगा।

Comments

परफ़ॉर्मन में इन आँकड़ों की निगरानी के बाद, मैंने कुछ चीजों पर ध्यान दिया। किसी भी नेटवर्क कार्ड पर कुल बाइट्स / सेकंड कभी भी 700K / s से अधिक नहीं होता है। यहां तक ​​कि अगर मैं एक क्वेरी चला रहा हूं जो मेगाबाइट डेटा का अनुरोध करता है, तो यह संख्या लगभग 500K / सेकंड पर रहती है। हमारा बैंडविड्थ 100 एमबीपीएस है, और हमें इसका 1% उपयोग भी नहीं मिल रहा है। मैं सोच रहा हूं कि कहीं एक सीमा कॉन्फ़िगर होनी चाहिए जो पैकेटों के आकार को कम कर रही हो, या ट्रांसफर दर को सीमित कर रही हो। हार्डवेयर व्यवधान / सेकंड 700-2000 पर हैं। आउटपुट कतार खाली है। नेटवर्क कार्ड का उपयोग सबसे अधिक लगभग 4% है।

— फ्रान्टिकरॉक

नेटवर्क कार्ड की गति और स्विच पोर्ट के बीच एक बेमेल हो सकता है। क्या आपने स्विच साइड से इसे देखने के लिए अपनी नेटवर्क टीम से सगाई की है?

— jgardner04

Answer 4

कुछ प्रारंभिक प्रश्न: 1) सर्वर में प्रोडक्ट पर SQL क्लाइंट है। सर्वर मशीन की स्थापना, सही? तो अगर आप उसी मशीन पर स्थित क्लाइंट से समान क्वेरी बनाते हैं तो यह 2 सेकंड में पूरी हो जाएगी? क्या आपने ऐसा करने की कोशिश की? क्या यह वास्तव में 2 सेकंड है? 2) आपने उल्लेख किया है कि आपके उत्पादन वातावरण का विन्यास बदल दिया गया है (या उत्पादन सर्वर अन्य नेटवर्क में स्थानांतरित हो गया है / कुल सर्वर पुनर्निर्माण किया गया है), है ना? पुराने उत्पादन वातावरण में क्वेरी की खपत का समय क्या था?

एक ही नेटवर्क पर किसी अन्य बॉक्स से ... समान क्वेरी में 1 मिनट, 8 सेकंड लगते हैं। 3) आप कह रहे हैं कि क्वेरी लौटा दी जाती है और ग्राहक से खपत होती है, जो दिए गए नेटवर्क में किसी भी मशीन पर स्थित है (अपनी विशिष्ट मशीन को समाप्त करें) लगभग 70 सेकंड में? मैं ठीक से समझ गया? 3.1 संयोग से, इस क्वेरी की खपत के लिए समय क्या है, व्यापार द्वारा स्वीकार्य है? 4) हालांकि, आप निर्दिष्ट कर रहे हैं कि एक विशिष्ट ग्राहक मशीन के लिए जो आप क्वेरी आउटपुट खपत समय का उपयोग कर रहे हैं: ग्राहक निष्पादन समय 15:30: 48 15 मिनट? (और यह समय स्पष्ट रूप से स्वीकार्य नहीं है)? सही बात? 5) तो समस्या एकल ग्राहक मशीन तक सीमित है? या किसी भी ग्राहक / मध्य स्तरीय मशीन (एक नए वातावरण में) के लिए? 6) पिंग द्वारा दर्शाई गई देरी क्या है? क्लाइंट कंप्यूटर से सर्वर पर? 7) आप (या नेटवर्क एडमिन) ने दोनों तरीके (क्लाइंट से सर्वर, सर्वर से क्लाइंट तक) को चलाया था? कितने होप्स? संयुक्त समय क्या है? 8) क्या पुराना उत्पादन नेटवर्क जीवित है? क्या आप पिंग और ट्रेसरआउट का उपयोग कर तुलना कर सकते हैं - वहां क्लाइंट और सर्वर के बीच क्या समय और हॉप्स था?

जिज्ञासा से बाहर: यह क्वेरी का एक उदाहरण है? या क्वेरी का सटीक शब्दांकन? क्वेरी में वास्तव में ऐसा नहीं है कि क्‍लॉज कहां है? मेरे साथ सहमत हूँ कि यह बहुत ही असामान्य है। तालिका में एक क्लस्टर इंडेक्स है या एक ढेर है? तालिका में सभी में कितनी पंक्तियाँ हैं? मेज भारी खंडित है? जिज्ञासा से बाहर: चुनें शीर्ष एनएनएन क्यों? ROWCOUNT NNN को क्यों नहीं बनाया गया - फिर सेलेक्ट करें *? यह क्वेरी क्लाइंट द्वारा प्रति दिन कितनी बार जारी की जाती है? 1? 100? 1MLN? अंडरस्टैंडिंग डेटा स्टैटिक है या डायनेमिक है और इसे कितना बदला गया है? कितना (0.01 प्रतिशत प्रति दिन? 1 प्रतिशत प्रति दिन? 10 प्रतिशत प्रति दिन?) क्वेरी आउटपुट प्रोग्रामेटिक रूप से संसाधित किया जाता है? (उपयोगकर्ता द्वारा नहीं?) इसे मध्य-स्तरीय पर संचित / संगृहीत क्यों नहीं किया जाता है? धन्यवाद, अलेक्सी

Comments

जानकारी के लिए बहुत शुक्रिया। नीचे मेरी प्रतिक्रियाएँ। 1. सही। ग्राहक उपकरण भी ठेस पर स्थापित होते हैं, और मैंने जो उल्लेख किया है वह सभी 30,000 रिकॉर्ड (कुल 4 एमबी आकार) को वापस करने के लिए 2 सेकंड लेता है। वैसे, मेरे द्वारा उपयोग की जाने वाली क्वेरी केवल एक उदाहरण है। यह एक वास्तविक व्यवसाय क्वेरी नहीं है। यह एक टेबल से 4 एमबी डेटा प्राप्त करने का एक साधन है। वर्तमान में हमें किसी भी क्वेरी के साथ वर्तमान में किसी भी तालिका से कई मेगाबाइट डेटा पढ़ने में एक प्रदर्शन समस्या है।

— FranticRock

2. उपभोग का समय करीब था, अगर वही नहीं जो स्थानीय स्तर पर PROD बॉक्स से चलाए गए समान क्वेरी के समान हो। (IE 2 सेकंड) 3. यह सही 1 मिनट 8 सेकंड निष्पादन समय है। यह समय विभिन्न क्लाइंट मशीनों के बीच भिन्न होता है। हमारी विकास मशीन से (चरण मशीन की तुलना में बहुत आगे स्थित), मैंने इस क्वेरी को लगातार 8 बार चलाया, और समय 11 सेकंड से 22 सेकंड तक चला। (औसत 18 सेकंड।)

— फ्रान्टिकरॉक

हमारे देव बॉक्स tracert से Prod_IP_Address 1 53 एमएस 52 एमएस 53 एमएस SQL2008 मंच मशीन से, समय लगातार 1 मिनट से अधिक है। tracert Prod_IP_Address tracert: 1 1 एमएस <1 एमएस <1 एमएस SQL2008 उत्पादन वेब सर्वर से: निष्पादन समय 53 सेकंड है। tracert: 1 1 ms <1 ms <1 ms SQL2008

— FranticRock

4. शीर्ष स्तंभ "क्लाइंट निष्पादन समय" मशीन का स्थानीय समय है (IE: 15:30:00) 5. समस्या किसी भी मशीन पर होती है जो उत्पादन DB सर्वर को मारती है, जिसमें हमारे उत्पादन वेब सर्वर भी शामिल है। 6. पिंग विलंब <1 MS स्टेज बॉक्स से प्रोडक्ट SQL बॉक्स तक है। 7. कृपया ऊपर देखें। 8. दुर्भाग्य से पुराना नेटवर्क अब मौजूद नहीं है।

— 19 पर फ्रान्टिकरॉक

यह वास्तव में दिलचस्प है कि भले ही DEV 53 MS पिंग करता है, यह क्वेरी चलाने के लिए केवल 11-22 सेकंड लेता है। Whilst, मंच 1 MS, डेटा को वापस करने में 1 मिनट से अधिक समय लेता है। भौगोलिक रूप से भी देव बहुत दूर हैं। और स्टेज ठीक ठाक बॉक्स के बगल में है, और अभी बहुत समय लग रहा है।

— फ्रान्टिकरॉक