पर्याप्त स्मृति नहीं
यह बहुत संभावना है कि स्मृति समस्या हो सकती है, शायद अन्य चीजों से बढ़ जाती है या ट्रिगर होती है, लेकिन फिर भी स्वाभाविक रूप से स्मृति समस्या होती है। दो अन्य (कम संभावना) संभावनाएं हैं, जिन्हें आपको पहले जांचना और समाप्त करना चाहिए (क्योंकि ऐसा करना आसान है):
संभावनाओं की जांच करने में आसान:
-
आपके पास "ऑटो क्लोज" सक्षम हो सकता है:ऑटो क्लोज में बिल्कुल यही व्यवहार हो सकता है, हालांकि इसे चालू करना दुर्लभ है। इसे जांचने के लिए, SSMS में अपने एप्लिकेशन डेटाबेस पर राइट-क्लिक करें, "गुण" चुनें, और फिर "विकल्प" फलक चुनें। "ऑटो क्लोज" प्रविष्टि को देखें और सुनिश्चित करें कि यह गलत पर सेट है। tempdb भी चेक करें।
-
SQL एजेंट नौकरियां इसका कारण हो सकती हैं:यह देखने के लिए एजेंट के इतिहास लॉग की जाँच करें कि क्या ईवेंट के दौरान कोई कार्य लगातार चल रहा था। रखरखाव की नौकरियों की भी जांच करना याद रखें, क्योंकि पुनर्निर्माण सूचकांक जैसी चीजों को अक्सर प्रदर्शन समस्याओं के रूप में उद्धृत किया जाता है जब वे चल रहे होते हैं। ये अब संभावित उम्मीदवार नहीं हैं, केवल इसलिए कि वे आम तौर पर प्रोफाइलर से प्रभावित नहीं होंगे।
यह एक स्मृति समस्या की तरह क्यों दिखता है:
यदि वे कुछ नहीं दिखाते हैं, तो आपको स्मृति समस्याओं की जांच करनी चाहिए। मुझे आपके मामले में कारण के रूप में स्मृति पर संदेह है क्योंकि:
-
आपके पास 1 जीबी मेमोरी है:हालांकि यह तकनीकी रूप से SQL सर्वर के लिए न्यूनतम से ऊपर है, यह SQL सर्वर के लिए अनुशंसित से नीचे है, और मेरे अनुभव में जो उत्पादन के लिए स्वीकार्य है, यहां तक कि हल्के लोड किए गए सर्वर के लिए भी नीचे है।
-
आप एक ही बॉक्स पर आईआईएस और एसक्यूएल सर्वर चला रहे हैं:यह अपने आप में अनुशंसित नहीं है, बड़े हिस्से में स्मृति के लिए विवाद के परिणामस्वरूप, लेकिन केवल 1 जीबी मेमोरी के साथ इसका परिणाम आईआईएस, ऐप, एसक्यूएल सर्वर, ओएस और कोई अन्य कार्य और/या रखरखाव सभी बहुत कम स्मृति के लिए लड़ रहे हैं। जिस तरह से विंडोज़ इसे प्रबंधित करता है वह सक्रिय प्रक्रियाओं को गैर-सक्रिय प्रक्रियाओं से आक्रामक रूप से हटाकर स्मृति देना है। SQL सर्वर जैसी बड़ी प्रक्रिया को इस स्थिति में अनुरोध को पूरी तरह से पूरा करने में सक्षम होने के लिए पर्याप्त मेमोरी वापस पाने में कई सेकंड या मिनट भी लग सकते हैं।
-
प्रोफाइलर ने 90% समस्या को दूर कर दिया:यह एक बड़ा सुराग है कि स्मृति समस्या की संभावना है, क्योंकि आम तौर पर, प्रोफाइलर जैसी चीजें इस विशेष समस्या पर बिल्कुल यही प्रभाव डालती हैं:प्रोफाइलर कार्य SQL सर्वर को केवल एक छोटा रखता है हर समय थोड़ा सक्रिय। अक्सर, यह या तो OS की "मेहतर" सूची से इसे दूर रखने के लिए पर्याप्त गतिविधि है, या कम से कम इसके प्रभाव को कुछ हद तक कम कर देता है।
अपराधी के रूप में स्मृति की जांच कैसे करें:
-
प्रोफाइलर को बंद करें:इसका समस्या पर हाइजेनबर्ग प्रभाव है, इसलिए आपको इसे बंद करना होगा या आप समस्या को विश्वसनीय रूप से नहीं देख पाएंगे।
-
किसी अन्य बॉक्स से सिस्टम मॉनिटर (perfmon.exe) चलाएँ, जो आपके SQL सर्वर और IIS पर चल रहे बॉक्स पर परफ़ॉर्मेंस संग्रह सेवा से दूरस्थ रूप से कनेक्ट होता है। आप पहले तीन डिफ़ॉल्ट आँकड़ों को हटाकर इसे आसानी से कर सकते हैं (वे केवल स्थानीय हैं), और फिर आवश्यक आँकड़े (नीचे) में जोड़ें, लेकिन अपने SQL से कनेक्ट करने के लिए पहले ड्रॉप-डाउन में कंप्यूटर का नाम बदलना सुनिश्चित करें। बॉक्स।
-
परफ़ॉर्म पर "काउंटर लॉग" बनाकर एकत्रित डेटा को फ़ाइल में भेजें। यदि आप इससे अपरिचित हैं, तो संभवतः सबसे आसान काम यह है कि डेटा को किसी टैब या अल्पविराम से अलग की गई फ़ाइल में एकत्रित किया जाए जिसे आप विश्लेषण करने के लिए एक्सेल के साथ खोल सकते हैं।
-
फ़ाइल में एकत्रित करने के लिए अपना परफ़ॉर्मन सेट करें और उसमें निम्नलिखित काउंटर जोड़ें:
-- प्रोसेसर\%प्रोसेसर समय[कुल]
-- PhysicalDisk\% निष्क्रिय समय[प्रत्येक डिस्क के लिए ]
- फिजिकलडिस्क\औसत। डिस्क कतार की लंबाई[प्रत्येक डिस्क के लिए ]
--मेमोरी\पेज/सेकंड
--मेमोरी\पेज रीड/सेकंड
--मेमोरी\उपलब्ध MBytes
--नेटवर्क इंटरफ़ेस\बाइट्स कुल/सेकंड[प्रयोग में प्रत्येक इंटरफ़ेस के लिए ]
-- प्रक्रिया\% प्रोसेसर समय[नीचे देखें ]
-- प्रक्रिया\पृष्ठ दोष/सेकंड[नीचे देखें ]
-- प्रोसेस\वर्किंग सेट [नीचे देखें ]
-
प्रक्रिया काउंटर (उपरोक्त) के लिए आप sqlserver.exe प्रक्रिया, किसी भी आईआईएस प्रक्रियाओं, और किसी भी स्थिर अनुप्रयोग प्रक्रियाओं को शामिल करना चाहते हैं। ध्यान दें कि यह केवल "स्थिर" प्रक्रियाओं के लिए काम करेगा। प्रक्रियाओं को लगातार आवश्यकतानुसार फिर से बनाया जा रहा है, इस तरह से कब्जा नहीं किया जा सकता क्योंकि उनके अस्तित्व से पहले उन्हें निर्दिष्ट करने का कोई तरीका नहीं है।
-
इस संग्रह को उस समय फ़ाइल में चलाएँ जब समस्या सबसे अधिक बार होती है। संग्रह अंतराल को 10-15 सेकंड के करीब सेट करें। (यह बहुत सारा डेटा एकत्र करता है, लेकिन अलग-अलग ईवेंट चुनने के लिए आपको इस संकल्प की आवश्यकता होगी)।
-
आपके पास एक या अधिक घटनाएं होने के बाद, संग्रह को रोकें और फिर एक्सेल के साथ अपनी एकत्रित डेटा फ़ाइल खोलें। उपयोगी रूप से दिखाई देने और घंटे मिनट और सेकंड दिखाने के लिए आपको शायद टाइमस्टैम्प कॉलम को दोबारा प्रारूपित करना होगा। घटनाओं के सटीक समय का पता लगाने के लिए अपने IIS लॉग का उपयोग करें, फिर घटना के पहले और बाद में क्या चल रहा था, यह देखने के लिए परफ़ॉर्म डेटा देखें। विशेष रूप से आप यह देखना चाहते हैं कि क्या इसका वर्किंग सेट पहले छोटा था और बाद में बड़ा था, जिसके बीच में बहुत सारे पेज फॉल्ट थे। यही इस समस्या का सबसे स्पष्ट संकेत है।
समाधान:
या तो आईआईएस और एसक्यूएल सर्वर को दो अलग-अलग बॉक्स (पसंदीदा) पर अलग करें या फिर बॉक्स में और मेमोरी जोड़ें। मुझे लगता है कि 3-4 जीबी कम से कम होनी चाहिए।
उस अजीब EF सामग्री के बारे में क्या?
यहां समस्या यह है कि यह आपकी मुख्य समस्या के लिए या तो परिधीय या केवल योगदानकर्ता है। याद रखें कि Profiler ने आपकी 90% घटनाओं को दूर कर दिया, तो जो बचा है, हो सकता है एक अलग समस्या हो, या यह केवल सबसे चरम एग्रेवेटर . हो सकता है समस्या का। इसके व्यवहार के कारण मुझे लगता है कि यह या तो अपने कैश को साइकिल चला रहा है या एप्लिकेशन सर्वर प्रक्रियाओं का कोई अन्य पृष्ठभूमि रखरखाव है।
