मेरे उदाहरण को अच्छा प्रदर्शन करने के लिए आवधिक पुनरारंभ क्यों आवश्यक है?

Question

हमें SQL 2005 पर एक उत्पादन DB सर्वर मिला है। सब कुछ सामान्य रूप से थोड़ी देर के लिए चलता है, लेकिन कुछ हफ़्ते बाद हम एक उल्लेखनीय प्रदर्शन ड्रॉप देखते हैं। केवल SQL सर्वर को पुनरारंभ करने से प्रदर्शन वापस सामान्य हो जाता है।

कुछ पृष्ठभूमि:

• 1200 से अधिक डेटाबेस (ज्यादातर एकल किरायेदार, कुछ बहु-किरायेदार) चल रहे हैं। इससे पहले कि कोई केवल बहु-किरायेदार के पास जाने पर व्याख्यान दे, इस संरचना को रखने के लिए वैध कारण हैं ......
• रैम 16 जीबी है। पुनः आरंभ करने के बाद, SQL सर्वर को 15 GB उपयोग पर वापस जाने में अधिक समय नहीं लगता है।
• सक्रिय डीबी कनेक्शन लगभग 80 कनेक्शन हैं - जो हमें लगता है कि काफी स्वस्थ है, यह देखते हुए कि प्रति वेब सर्वर प्रति एक कनेक्शन पूल है - इसलिए हमारे पास कनेक्शन रिसाव मुद्दा नहीं है।

हमने गैर-पीक समय में कई चीजों की कोशिश की है: - डेटा कैश को साफ़ करने के लिए DBCC DROPCLEANBUFFERS (एक CHECKPOINT के साथ) चलाएँ। इसका कोई प्रभाव नहीं है, और न ही यह रैम उपयोग को स्पष्ट करता है)। - क्वेरी योजनाओं और संग्रहीत proc कैश को खाली करने के लिए FREEPROCCACHE और FREESYSTEMCACHE चलाएं। कोई प्रभाव नहीं।

स्पष्ट रूप से SQL सर्वर को पुनरारंभ करना एक सक्रिय उत्पादन वातावरण में आदर्श नहीं है। हम कुछ याद कर रहे हैं। किसी और को इस के माध्यम से जाना?

अद्यतन: अप्रैल-28-2012 अभी भी इस समस्या से जूझ रहा है। मैंने SQL सर्वर के लिए मेमोरी को 10 जीबी तक कम कर दिया है, बस ओएस के साथ किसी भी विवाद को बाहर करने के लिए। मैं इसे कम करने के करीब पहुंच रहा हूं, लेकिन अपने अगले कदम के लिए कुछ मदद चाहिए।

यहां मैंने पाया कि SQL सर्वर को पुनरारंभ करने के बाद, पेज फ़ाइल 12.3 जीबी और 12.5 जीबी के बीच होवर करती है। यह उस तरह से दिनों तक रहेगा। कुल सर्वर थ्रेड्स 850 और 930 के बीच हैंग - एंड पर दिनों के लिए भी स्थिर और सुसंगत रहेंगे (ट्रैवेलर्स पूरी तरह ट्रैफिक के आधार पर 55 से 85 के बीच है)।

फिर, "एक घटना" है। मुझे पता नहीं है कि घटना क्या है, मैं इसे लॉग में नहीं देख सकता हूं, और ऐसा होने वाले सप्ताह या समय के अनुरूप कुछ भी नहीं देख सकता हूं, लेकिन सभी पृष्ठभूमियों में वह 14.1 या 14.2 में कूदता है GB, और थ्रेड्स 1750 और 1785 के बीच कूदते हैं।

ऐसा होने पर परफ्यूम की जाँच करना, उन थ्रेड्स में से 900 से अधिक स्क्वैल्सर हैं। इसलिए मैं sp_who2 में यह देखने के लिए जाता हूं कि ये धागे कहां से आ रहे हैं ... और वहां सिर्फ 80 या इतने db कनेक्शन का उपयोग किया गया है।

तो .... क्या किसी को कोई विचार है कि मैं कैसे पता लगा सकता हूं कि SQL सर्वर पर इन 900 थ्रेड्स में से बाकी कहां हैं, और वे क्या कर रहे हैं?

अद्यतन: जून-01-2012 अभी भी समस्या से जूझ रहा है। यह अभी भी पढ़ने वाले किसी के लिए, थ्रेड्स के ऊपर कूदने के साथ समस्या हल हो गई है। यह Autodated ComVault बैकअप सॉफ़्टवेयर के कारण हुआ था। यह बैकअप डेटाबेस की कोशिश कर रहा एक धागा बना रहा था जो अब नहीं थे (यह पिछले डेटाबेस की सूची बनाए हुए था) केवल वर्तमान डेटाबेस का बैकअप लेने के बजाय।

लेकिन - मुद्दा अभी भी बना हुआ है, और हमें हर हफ्ते फिर से शुरू करना है, कुछ दिन देना या लेना है। रैकस्पेस टीम के साथ काम करके देखें कि क्या वे किसी भी प्रकाश को बहा सकते हैं।

Comments

एक गहन सवाल के लिए अंक, लेकिन क्या आपने माना है कि 16 जीबी रैम सिर्फ 1200 डेटाबेस के लिए पर्याप्त नहीं हो सकती है?

— निक वैकेरो

वास्तव में चीजों की भव्य योजना में मदद नहीं कर सकता, लेकिन मुझे पता है कि MSSQL को उपलब्ध रैम के रूप में ज्यादा उपभोग करने के लिए डिज़ाइन किया गया है। यह वास्तव में समझ में आता है अन्यथा राम बेकार जा रहा है। तथ्य यह है कि यह पुनः आरंभ करने के तुरंत बाद 15GB तक कूद जाता है, वास्तव में यह अपने आप में एक मुद्दा नहीं है, मुझे नहीं लगता। हालाँकि @Norla सही हो सकता है कि 16 सिर्फ इतना नहीं है कि आप क्या करना चाहते हैं।

सुस्ती के दौरान कितने एसपीआईडी ​​सक्रिय हैं? Sp_who2 चलाएं और कृपया पंक्ति गणना दें।

— निक वैकेरो

बस जाँच - क्या आपके पास कोई Sql सर्वर जॉब चल रही है? क्या आप उन्हें यह देखने के लिए रोक सकते हैं कि क्या उनमें से कोई भी इस समस्या का कारण है?

इसका आउटपुट क्या है: sysinos_os_memory_clerks से SUM (single_pages_kb + multi_pages_kb) / 1024.0 का चयन करें, जहां [name] = 'TokenAndPermUserStoreore

— Mark Storey-Smith

Answer 1

आप कहते हैं कि सब कुछ ठीक है, तो कुछ हफ़्ते के बाद, प्रदर्शन गिर जाता है। (आमतौर पर, लोग दावा करते हैं कि प्रदर्शन तेज़ी से या विशिष्ट समय पर, या प्रतीत होता है कि यादृच्छिक अंतराल पर गिरता है। इसका मतलब यह हो सकता है कि खराब I / O प्रदर्शन या लॉक तूफानों या सीपीयू-गहन प्रश्नों का अजीब समय पर चल रहा है, या एक हेवीवेट अनुसूचित नौकरी या कमी है। अनुक्रमणिका या खराब आँकड़े cpu- गहन प्रश्नों या डिस्क पढ़ता है। या अन्य सामान।) सप्ताह असामान्य है।

मेरी परिकल्पना यह है कि आपके सर्वर पर एक और एप्लिकेशन मेमोरी लीक कर रहा है। मैंने इसे वायरस सॉफ्टवेयर (हर डीबीए के पसंदीदा सर्वर सॉफ्टवेयर खलनायक) और तीसरे पक्ष के निगरानी सॉफ्टवेयर के साथ देखा है। मैं समय-समय पर SQL सर्वर के मेमोरी उपयोग की दोहरी जांच करूंगा, और मैं बॉक्स पर अन्य सभी अनुप्रयोगों के मेमोरी उपयोग को भी प्राप्त करूंगा। यदि आपके पास SQL ​​सर्वर की मेमोरी के उपयोग पर कठोर सीमाएँ हैं और इसे पेजिंग की अनुमति नहीं देने के लिए सेट है, तो यह अन्य ऐप हो सकते हैं जो पृष्ठांकित हो रहे हैं और I / O क्षमता को खा रहे हैं।

इसकी तलाश मुश्किल नहीं है। यदि आप पहले से ही सर्वर पर मेट्रिक्स नहीं रख रहे हैं, तो मैं सिर्फ परफॉमन शुरू करूंगा और हर 30 या 60 मिनट में इसका एक नमूना ले सकता हूं। कुछ दिनों के बाद, आप एक और एप्लिकेशन मेमोरी उपयोग रेंगना ऊपर की ओर देख सकते हैं।

क्या SQL सर्वर लॉग में त्रुटि संदेश है कि "sql सर्वर के महत्वपूर्ण भागों को पृष्ठांकित किया गया है"? यह भी एक बड़ा सुराग होगा।

Comments

मैं सहमत हूँ, व्यवहार इसे स्मृति रिसाव की तरह आवाज़ करता है।

— निक कवाडियास 16

मेमोरी रिसाव के लिए +1। मुझे संदेह है कि इस सर्वर पर पृष्ठ जीवन प्रत्याशा बहुत लंबी है, लेकिन यह पेजफाइल को तेजी से विकसित नहीं करना चाहिए। : FYI करें, लगभग एक ही यहाँ मुद्दा (यह ए वी कि इस मुद्दे था) social.msdn.microsoft.com/Forums/en/sqlsetupandupgrade/thread/...

— ब्रायन

Answer 2

मैं आपको केवल 16 जीबी रैम के साथ SQL सर्वर के एक ही उदाहरण पर 1200 DBs चलाने में सक्षम होने पर बधाई देता हूं और कुछ हफ़्ते के बाद केवल इस प्रकार के मुद्दे हैं। स्थानीय पास अध्याय में बताने के लिए अच्छी कहानी है।

अब समस्या निवारण के लिए: आपकी रैम SQL और OS दोनों के लिए 16 GB है। मैं मान रहा हूं कि आपकी अधिकतम मेमोरी सेटिंग 15 जीबी या अधिकतम है। यह बफर पूल को सभी मेमोरी का उपयोग करने और ओएस को चोक करने का कारण बन सकता है। आप कह रहे हैं कि बफ़र पूल को साफ़ करना और कैश में कोई अंतर नहीं दिखाई दे रहा है, साथ ही आपका PLE 300 से ऊपर है। यह मेमोरी बॉटल नेक के विरुद्ध गवाही देता है। CPU और IO सर्वर पर कैसे है (चश्मा / आँकड़े)?

चलाएं select * from sys.dm_exec_request where session_id>50 and session_id<>@@spidऔर आपके द्वारा देखे जाने वाले संसाधन सामग्री क्या है (Wait_type, Wait_time, last_wait_type, Wait_tource)।

Comments

1200 बुरा बुरा नहीं है! सबसे बड़ी बाधा कनेक्शन पूल के मुद्दों पर काबू पाने की थी, जो कनेक्शन स्ट्रिंग को मास्टर करने के लिए सेट करके हल किया गया था, और फिर कनेक्शन के बाद एक USE [DBName]। क्वेरी के संदर्भ में, मैं sysinos_exec_requests से सेलेक्ट * सेलेक्ट किया गया जहां सेशन_आईडी> 50 और सेशन_आईडी <> @@ स्पिड, और यह 4 से 5 अनुरोधों की एक छोटी सूची है, अधिकतम, और वे सूची को 500 एमएस पर छोड़ देते हैं। लेकिन मैं यह कोशिश करने जा रहा हूं कि एक बार जब हम धीमा हो जाए, यह रविवार को फिर से शुरू हो गया, इसलिए अब यह हमेशा की तरह गुनगुना रहा है।

— पॉलजे

कनेक्शन पूलिंग पर टिप के लिए @PaJJ धन्यवाद। मैं अभी इस पर कुछ पढ़ रहा हूं।

— स्टेनली जॉन्स

Answer 3

1200 डेटाबेस, एक ओएस, और संभवतः अन्य सामान? हाँ, मुझे लगता है कि सर्वर को कार्य करने के लिए 1gb से अधिक RAM की आवश्यकता होती है, विशेष रूप से यह देखते हुए कि यदि आप 15gb को SQL सर्वर की अधिकतम मेमोरी सेटिंग के रूप में सेट करते हैं, तो उसे थ्रेड्स के लिए उस 15gb के बाहर अतिरिक्त मेमोरी की आवश्यकता होती है ।

मैं सर्वर को थोड़ा और सांस लेने के कमरे में देने के लिए 14gb नीचे SQL सर्वर से टकराऊंगा।

साथ ही, SQL Server 2008 x64 सिस्टम पर स्मृति भत्ते के लिए "व्यावसायिक SQL Server 2008 आंतरिक और समस्या निवारण" में दिए गए एक उदाहरण में 16 जीबी रैम के साथ तीसरे-भाग बैकअप उपयोगिता है:

• विंडोज के लिए 2 जीबी
• कार्यकर्ता धागे के लिए 1 जीबी
• एमपीए आदि के लिए 1 जीबी।
• बैकअप प्रोग्राम के लिए 1GB
• SQL सर्वर के लिए 11GB

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

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

Comments

महान सामान, धन्यवाद। मैंने इसे 14 जीबी तक नीचे स्थानांतरित कर दिया है। यहाँ कुछ नया सीखा है, क्योंकि मैंने हमेशा SQL सर्वर को वही लेने दिया था जो वह चाहता था। इस संदर्भ के लिए एक और अच्छा लेख: sqlservercentral.com/blogs/glennberry/2009/10/29/…

— PaulJ

Answer 4

यदि डेटाबेस मेमोरी सभी डेटाबेस में समान रूप से वितरित की जाती है, तो आपके पास प्रत्येक डेटाबेस के लिए केवल 12.8 Megs (15 * 1024) / 1200=12.8 है। आपको अधिक मेमोरी की आवश्यकता है।

आपको यह देखने की आवश्यकता है कि प्रदर्शन धीमा क्यों हो रहा है। क्या आप लॉकिंग, ब्लॉकिंग आदि देख रहे हैं? प्रतीक्षा आँकड़े क्या दिख रहे हैं?

Answer 5

DBCC कमांड केवल मेमोरी बफ़र्स को खाली करने जा रहे हैं जो वे मेमोरी को ओएस पर वापस नहीं जा रहे हैं।

क्या आप जानते हैं कि SQL Server वास्तव में मेमोरी की खपत कर रहा है? मैं सुझाव दूंगा कि परफ़ॉर्म सत्र की स्थापना करना या SQL सर्वर क्या कर रहा है और काम कर रहा है, यह जानने के लिए पुनः आरंभ करने के बाद DMV जानकारी एकत्र करना शुरू करें। यह भी ध्यान रखें कि यदि उपयोगकर्ता आपके संग्रह समय (जैसे कि एंड-ऑफ-मंथ प्रोसेसिंग, आदि) के दौरान सामान्य से अधिक काम कर रहे हैं। क्या आप SSRS, SSIS या SSAS को एक ही सर्वर पर चला रहे हैं?

आपके पास सिस्टम पर 1200 डेटाबेस हैं, आपके पास सबसे बड़ा आकार डीबी क्या है?

Comments

सबसे बड़ी db 5GB है। उनमें से केवल ~ 25 ही 1GB या उससे अधिक के हैं। विशाल बहुमत 50 से 200 एमबी है।

— पॉल जेआर

"क्या आप SSRS, SSIS, या SSAS को एक ही सर्वर पर चला रहे हैं?" - उन सेवाओं में से कोई भी नहीं चल रहा है। यह एक शुद्ध sql बॉक्स है।

— पॉल जेआर