प्रारंभिक क्वेरी पर आपकी देखी गई प्रदर्शन समस्या संभवतः निम्नलिखित मुद्दों में से एक है (संभावना के मोटे क्रम में):
1) आपके एप्लिकेशन/वेब सेवा में पहले अनुरोध पर आरंभ करने के लिए कुछ ओवरहेड है (यानी स्मृति आवंटित करना, कनेक्शन पूल स्थापित करना, DNS को हल करना, ...)।
2) आपके द्वारा अनुरोधित अनुक्रमणिका या डेटा अभी तक स्मृति में नहीं हैं, इसलिए लोड करने की आवश्यकता है।
3) क्वेरी ऑप्टिमाइज़र पहले अनुरोध पर चलने में थोड़ा अधिक समय लग सकता है, क्योंकि यह आपके क्वेरी पैटर्न के लिए योजना निष्पादन की तुलना कर रहा है।
mongo . के माध्यम से क्वेरी का परीक्षण करना बहुत उपयोगी होगा खोल, और अलग करें कि क्या ओवरहेड MongoDB या आपकी वेब सेवा से संबंधित है (बजाय दोनों को समय देने के, जैसा आपने किया है)।
MongoDB से संबंधित कुछ नोट्स निम्नलिखित हैं।
कैशिंग
MongoDB के पास मेमोरी में दस्तावेज़ों के लिए "कैशिंग" समय नहीं है। यह डिस्क I/O के लिए मेमोरी-मैप्ड फ़ाइलों का उपयोग करता है और मेमोरी में मौजूद दस्तावेज़ आपके सक्रिय प्रश्नों (दस्तावेज़/इंडेक्स जिन्हें आपने हाल ही में लोड किया है) और साथ ही उपलब्ध मेमोरी पर आधारित होते हैं। ऑपरेटिंग सिस्टम का वर्चुअल मेमोरी मैनेजर कैशिंग का प्रभारी होता है। , और आम तौर पर यह तय करने के लिए कि कौन से पेज मेमोरी से बाहर स्वैप करना है, यह तय करने के लिए कम-हाल ही में प्रयुक्त (LRU) एल्गोरिथम का पालन करेगा।
स्मृति उपयोग
अपेक्षित व्यवहार यह है कि समय के साथ MongoDB आपके सक्रिय कार्यशील डेटा सेट को संग्रहीत करने के लिए सभी निःशुल्क मेमोरी का उपयोग करने के लिए बढ़ेगा।
आपके द्वारा दिए गए db.stats() . को देखते हुए संख्याएं (और यह मानते हुए कि यह आपका केवल है) डेटाबेस), ऐसा लगता है कि आपके डेटाबेस का आकार लगभग 1Gb है, इसलिए आपको अपने 10Gb की कुल RAM में सब कुछ रखने में सक्षम होना चाहिए जब तक कि:
- स्मृति के लिए प्रतिस्पर्धा करने वाली अन्य प्रक्रियाएं हैं
- आपने अपने
mongodको पुनः आरंभ कर दिया है सर्वर और उन दस्तावेज़ों/अनुक्रमणिकाओं का अभी तक अनुरोध नहीं किया गया है
MongoDB 2.2 में, एक नया touch है
आदेश आप सर्वर पुनरारंभ होने के बाद अनुक्रमणिका या दस्तावेज़ों को स्मृति में लोड करने के लिए उपयोग कर सकते हैं। इसका उपयोग केवल प्रारंभिक स्टार्टअप पर सर्वर को "वार्म अप" करने के लिए किया जाना चाहिए, अन्यथा आप वास्तविक "सक्रिय" डेटा को मेमोरी से बाहर करने के लिए मजबूर कर सकते हैं।
उदाहरण के लिए, linux सिस्टम पर, आप top . का उपयोग कर सकते हैं आदेश और देखना चाहिए कि:
- वर्चुअल बाइट्स/VSIZE पूरे डेटाबेस के आकार का होगा
- यदि सर्वर में अन्य प्रक्रियाएं नहीं चल रही हैं, तो निवासी बाइट्स/RSIZE मशीन की कुल मेमोरी होगी (इसमें फ़ाइल सिस्टम कैश सामग्री शामिल है)
mongodस्वैप का उपयोग नहीं करना चाहिए (चूंकि फाइलें मेमोरी-मैप की गई हैं)
आप mongostat का उपयोग कर सकते हैं
अपने mongod . को तुरंत देखने के लिए टूल गतिविधि .. या अधिक उपयोगी रूप से, MMS
जैसी सेवा का उपयोग करें समय के साथ मेट्रिक पर नज़र रखने के लिए.
क्वेरी ऑप्टिमाइज़र
MongoDB क्वेरी ऑप्टिमाइज़र
प्रत्येक ~1,000 लिखने के संचालन के लिए एक क्वेरी पैटर्न के लिए योजना निष्पादन की तुलना करता है, और फिर अगली बार ऑप्टिमाइज़र चलने तक "विजेता" क्वेरी योजना को कैश करता है .. या आप स्पष्ट रूप से एक explain()
उस प्रश्न पर।
यह परीक्षण करने के लिए एक सीधा होना चाहिए:अपनी क्वेरी को mongo . में चलाएं खोल के साथ .explain() और एमएस टाइमिंग को देखें, और साथ ही इंडेक्स प्रविष्टियों और स्कैन किए गए दस्तावेजों की संख्या भी देखें। व्याख्या के लिए समय () प्रश्नों को चलाने में लगने वाला वास्तविक समय नहीं है, क्योंकि इसमें योजनाओं की तुलना करने की लागत शामिल है। सामान्य निष्पादन बहुत तेज़ होगा .. और आप अपने mongod में धीमे प्रश्नों की तलाश कर सकते हैं लॉग।
डिफ़ॉल्ट रूप से MongoDB सभी प्रश्नों को 100ms से धीमी गति से लॉग करेगा, इसलिए यह अनुकूलित करने के लिए प्रश्नों को देखने के लिए एक अच्छा प्रारंभिक बिंदु प्रदान करता है। आप धीमे एमएस मान को --slowms
config विकल्प, या Database Profiler का उपयोग करके
आदेश।
