एसक्यूएल सर्वर

10

रैम के आकार के अप्रासंगिक, आपको अभी भी भौतिक RAM की मात्रा कम से कम 1.5 गुना पृष्ठफाइल की आवश्यकता है। यह सच है भले ही आपके पास 1 टीबी रैम मशीन है, आपको डिस्क पर 1.5 टीबी पेजफाइल की आवश्यकता होगी (पागल लगता है, लेकिन सच है)।

जब एक प्रक्रिया VirtualAlloc/VirtualAllocEx के माध्यम से MEM_COMMIT स्मृति पूछता है, अनुरोध किया आकार पृष्ठ फ़ाइल में आरक्षित किया जाना चाहिए। यह पहली जीत NT सिस्टम में सही था, और आज देख Managing Virtual Memory in Win32 अभी भी सत्य है:

जब स्मृति के लिए प्रतिबद्ध है, स्मृति के भौतिक पृष्ठों आवंटित किए जाते हैं और अंतरिक्ष एक पृष्ठ फ़ाइल में आरक्षित है।

कुछ चरम विषम मामलों को देखें, SQL सर्वर हमेशा MEM_COMMIT पृष्ठों के लिए पूछेगा। और इस तथ्य है कि SQL एक Dynamic Memory Management नीति है कि संभव के रूप में अग्रिम के रूप में ज्यादा बफर पूल सुरक्षित रखता है (भंडार और वीएएस के मामले में करता है) का उपयोग करता है को देखते हुए, एसक्यूएल सर्वर पर पृष्ठ फ़ाइल में अंतरिक्ष की एक बड़ी आरक्षण शुरू का अनुरोध करेंगे। यदि पेजफाइल ठीक से आकार नहीं है 801/802 एसक्यूएल की ERRORLOG फ़ाइल और संचालन में दिखाना शुरू हो जाएगा।

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

स्रोत

2009-11-22 22:11:18

+0

वही जो मैं खोज रहा था, धन्यवाद! 32 जीबी वीएम के साथ पेज फ़ाइल निश्चित रूप से बहुत सारी जगह लेती है, हालांकि जानवर की प्रकृति की तरह लगता है ... – tsquillario

1

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

स्रोत

2008-08-11 12:22:31

+0

यह वास्तव में गलत है। MEM_COMMIT आवंटन को पृष्ठफाइल में स्थान * रिजर्व * के बिना सम्मानित नहीं किया जा सकता है। आपकी पेजफाइल रैम की मात्रा कम से कम 1.5 गुना होनी चाहिए, भले ही आपके पास 1 टीबी रैम हो। –

+0

रीमस, यह सच नहीं है, पेजफाइल के लिए नियम 1.5 * रैम की अनुशंसा की जाती है, लेकिन इसकी आवश्यकता नहीं है। बड़ी रैम (अधिक 16 जीबी) के साथ 64 बिट मशीन पर एसक्यूएल सर्वर के मामले में, पेजफाइल को बेहतर बंद कर दें, या पेजफाइल सेट करें उदाहरण के लिए 4 जीबी तक। पूरी तरह से गलती है, अगर आपके पास 96 जीबी रैम वाली मशीन है, तो एसक्यूएल सर्वर के मामले में 144 जीबी पेजफाइल का उपयोग करें। मैं मशीनों पर 16 से 9 6 जीबी रैम के साथ दसियों उत्पादन एसक्यूएल सर्वर का प्रबंधन कर रहा हूं, मेरे पास पेजफाइल = 4 जीबी है। –

2

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

स्रोत

2008-12-23 14:45:57 ConcernedOfTunbridgeWells

2

हमने हाल ही में हमारे एसक्यूएल सर्वर में से एक यह है कि हम पूरी तरह से नीचे संकीर्ण करने में सक्षम नहीं थे, और वास्तव में हमारे Microsoft समर्थन टिकट में से एक का इस्तेमाल किया उनकी समस्याओं का निवारण करने में मदद करने के लिए के साथ कुछ प्रदर्शन के मुद्दों कर रहे थे। SQL सर्वर के साथ उपयोग करने के लिए इष्टतम पृष्ठ फ़ाइल आकार आया था, और माइक्रोसॉफ्ट के सिफारिश यह है कि यह 1 1/2 बार राम की राशि होना है।

स्रोत

2009-09-10 05:05:52

3

माइक्रोसॉफ्ट के मुताबिक, "कंप्यूटर में रैम की मात्रा बढ़ जाती है, इसलिए पेज फ़ाइल की आवश्यकता कम हो जाती है।" लेख तो कैसे प्रदर्शन लॉग्स उपयोग करने के लिए निर्धारित करने के लिए कैसे पेज फ़ाइल की ज्यादा है वास्तव में इस्तेमाल किया जा रहा वर्णन करने के लिए चला जाता है। शुरुआत के लिए अपनी पृष्ठ फ़ाइल को 1.5 एक्स सिस्टम मेमोरी में सेट करने का प्रयास करें, फिर अनुशंसित निगरानी करें और वहां से समायोजन करें।

How to determine the appropriate page file size for 64-bit versions of Windows

स्रोत

2010-08-03 18:58:10

1

काफी अनुसंधान के बाद हमारे समर्पित एसक्यूएल Windows 2003 Enterprise x64 पर उद्यम x64 चल सर्वर कोई पेज फ़ाइल है।

बस, पृष्ठ फ़ाइल उन फ़ाइलों के लिए एक कैश है जो ओएस द्वारा प्रबंधित की जाती है, और एसक्यूएल की अपनी आंतरिक मेमोरी प्रबंधन प्रणाली है।

संदर्भित एमएस आलेख योग्य नहीं है कि सलाह ओएस के लिए फाइल साझा करने जैसी सेवाओं के बाहर चल रही है।

एक पृष्ठ फ़ाइल होने से बस डिस्क I/O को बोझ होता है क्योंकि विंडोज़ मदद करने की कोशिश कर रहा है, जब केवल एसक्यूएल ओएस काम कर सकता है।

स्रोत

2011-05-24 12:47:26 Alex

11

रीमस (जिसे मैं बहुत सम्मान करता हूं) के सभी सम्मान के साथ, मैं दृढ़ता से असहमत हूं। यदि आपकी पृष्ठ फ़ाइल पूर्ण डंप का समर्थन करने के लिए पर्याप्त है, तो यह हर बार एक पूर्ण डंप करेगा। यदि आपके पास रैम की एक बड़ी मात्रा है, तो इससे एक छोटी सी चीज एक बड़ी आबादी बन सकती है।

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

प्लस, यदि आपका सर्वर 1 टीबी पूर्ण डंप की अनुमति देने के लिए कॉन्फ़िगर किया गया है और आवर्ती समस्या होती है, तो आप हाथ पर होने वाली कितनी खाली डिस्क स्थान की सिफारिश करेंगे? आप एक सप्ताहांत में एक संपूर्ण SAN भर सकते हैं।

एक पृष्ठ फ़ाइल 1.5 * रैम उन दिनों में मानक था जब आप भाग्यशाली थे कि 3 या 4 जीबी रैम वाला SQL सर्वर हो। यह अब और मामला नहीं है। मैं पेज डिफ़ॉल्ट रूप से विंडोज़ डिफ़ॉल्ट आकार और सभी उत्पादन सर्वरों पर सेटिंग्स को छोड़ देता हूं (एक एसएसएएस सर्वर को छोड़कर जो स्मृति दबाव का अनुभव कर रहा है)।

और केवल स्पष्टीकरण के लिए, मैंने 2 जीबी रैम से 2 टीबी रैम तक के सर्वरों के साथ काम किया है। 11 से अधिक वर्षों के बाद, मुझे केवल एक बार पूर्ण डंप कैप्चर करने के लिए पेजिंग फ़ाइल को बढ़ाना पड़ा।

स्रोत

2011-10-05 21:39:39

0

इस मामले में, 1.5 गुणा कुल भौतिक रैम की सामान्य सिफारिश सबसे अच्छी नहीं है। यह सामान्य सिफारिश इस धारणा के तहत प्रदान की जाती है कि सभी स्मृति का उपयोग "सामान्य" प्रक्रियाओं द्वारा किया जा रहा है, जो आम तौर पर कम से कम उपयोग किए जाने वाले पृष्ठों को स्मृति प्रक्रिया से संबंधित अनुप्रयोग प्रक्रिया के लिए बड़े प्रदर्शन समस्याओं को उत्पन्न किए बिना डिस्क पर स्थानांतरित हो सकते हैं।

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

रीमस द्वारा उल्लिखित MEM_COMMIT के संबंध में, शब्दावली भ्रमित है क्योंकि वर्चुअल मेमोरी पार्लान्स में, "आरक्षित" वास्तविक आवंटन को संदर्भित नहीं करता है, लेकिन किसी अन्य प्रक्रिया द्वारा पता स्थान (भौतिक स्थान नहीं) का उपयोग रोकने से रोकने के लिए। "प्रतिबद्ध" होने के लिए उपलब्ध स्मृति मूल रूप से भौतिक RAM और पृष्ठ फ़ाइल आकार के बराबर होती है, और एक MEM_COMMIT करने से प्रतिबद्ध पूल में उपलब्ध राशि कम हो जाती है। यह उस समय पृष्ठ फ़ाइल में एक मिलान पृष्ठ आवंटित करता है।जब एक प्रतिबद्ध स्मृति पृष्ठ वास्तव में लिखा जाता है, तो वह तब होता है जब वर्चुअल मेमोरी सिस्टम भौतिक मेमोरी पेज आवंटित करेगा और संभावित रूप से भौतिक RAM से पृष्ठ फ़ाइल तक एक और मेमोरी पेज टक्कर देगा। एमएसडीएन के VirtualAlloc function संदर्भ देखें।

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

जब तक सर्वर अन्य स्मृति के भूखे प्रक्रियाओं नहीं चल रहा है, 4 जीबी की एक पृष्ठ फ़ाइल आकार बहुत होना चाहिए। यदि आपने स्मृति पृष्ठों को स्मृति में लॉक करने की अनुमति देने के लिए SQL सर्वर सेट किया है, तो आपको SQL सर्वर की अधिकतम मेमोरी सेटिंग सेट करने पर भी विचार करना चाहिए ताकि यह ओएस को कुछ भौतिक RAM स्वयं और अन्य प्रक्रियाओं के लिए उपलब्ध हो।

SQL सर्वर में 802 त्रुटियों से संकेत मिलता है कि सिस्टम डेटा कैश के लिए कोई और पृष्ठ नहीं कर सकता है। पेजफाइल आकार को बढ़ाने से केवल इस स्थिति में मदद मिलेगी क्योंकि विंडोज गैर-SQL सर्वर प्रक्रियाओं से स्मृति को बाहर करने में सक्षम है। इस स्थिति में पेजफाइल में बढ़ने के लिए SQL सर्वर मेमोरी को अनुमति देना त्रुटि संदेशों से छुटकारा पा सकता है, लेकिन यह पहले स्थान पर डेटा कैश के कारण के कारण बिंदु के कारण प्रतिकूल है।

स्रोत

2014-04-03 23:51:13 js5

एसक्यूएल सर्वर

उत्तर

संबंधित मुद्दे