Redis एक इन-मेमोरी डेटाबेस है जो बहुत तेज़ प्रदर्शन प्रदान करता है। यह डिस्क-आधारित डेटाबेस के लिए एक सम्मोहक विकल्प बनाता है जब प्रदर्शन एक चिंता का विषय होता है। हो सकता है कि आप अपने प्रदर्शन-संवेदनशील अनुप्रयोगों को सशक्त बनाने के लिए पहले से ही Redis™* के लिए स्केलग्रिड होस्टिंग का उपयोग कर रहे हों। आप कैसे सुनिश्चित करते हैं कि आपकी Redis परिनियोजन स्वस्थ है और आपकी आवश्यकताओं को पूरा कर रही है? आपको यह जानने की आवश्यकता होगी कि Redis™ को कौन से मॉनिटरिंग मेट्रिक्स को देखना है और इसके स्वास्थ्य को सुनिश्चित करने के लिए इन महत्वपूर्ण सर्वर मेट्रिक्स की निगरानी के लिए एक टूल की आवश्यकता है। जब आप Redis शेल पर जानकारी कमांड चलाते हैं, तो Redis डेटाबेस मेट्रिक्स की एक बड़ी सूची देता है। आप इनमें से प्रासंगिक मेट्रिक्स का एक स्मार्ट चयन चुन सकते हैं। और ये आपके सिस्टम के स्वास्थ्य को सुनिश्चित करने और आपके सामने आने वाली किसी भी प्रदर्शन-संबंधी समस्या का मूल कारण विश्लेषण करने में आपकी सहायता कर सकते हैं।
यह ब्लॉग पोस्ट मॉनिटर करने के लिए महत्वपूर्ण डेटाबेस मेट्रिक्स को सूचीबद्ध करता है। हम प्रत्येक मीट्रिक को डेटाबेस प्रदर्शन के दृष्टिकोण से देखेंगे और उनसे जुड़े सामान्य मुद्दों और समाधानों पर चर्चा करेंगे।
<एच3>1. प्रदर्शन मीट्रिक:थ्रूपुटथ्रूपुट आपको बताता है कि आपका सर्वर किसी विशेष समय अवधि में कितने डेटाबेस संचालन कर रहा है। यह आपके एप्लिकेशन वर्कलोड और उसके व्यावसायिक तर्क पर निर्भर है। थ्रूपुट के इतिहास को देखकर, आप सर्वर पर लोड के पैटर्न का अनुमान लगा सकते हैं उदा। पीक लोड, पीक लोड की आवृत्ति, पीक लोड की समय सीमा, औसत लोड इत्यादि।
आप "जानकारी कमांडस्टैट्स को क्रियान्वित करके Redis सर्वर पर चलने वाले सभी कमांड के लिए थ्रूपुट मेट्रिक मान एकत्र कर सकते हैं। .
127.0.0.1:6379> info commandstats # Commandstats cmdstat_get:calls=797,usec=4041,usec_per_call=5.07 cmdstat_append:calls=797,usec=4480,usec_per_call=5.62 cmdstat_expire:calls=797,usec=5471,usec_per_call=6.86 cmdstat_auth:calls=147,usec=288,usec_per_call=1.96 cmdstat_info:calls=46,usec=902,usec_per_call=19.61 cmdstat_config:calls=2,usec=130,usec_per_call=65.00 cmdstat_eval:calls=796,usec=36950,usec_per_call=46.42 cmdstat_command:calls=796,usec=8578,usec_per_call=10.78
Redis अपने विभिन्न कमांड को कनेक्शन, सर्वर, क्लस्टर, जेनेरिक आदि में समूहित करता है। Redis™ के लिए स्केलग्रिड मॉनिटरिंग विभिन्न कमांड के थ्रूपुट को उपर्युक्त समूहों में से एक में एकत्रित करता है। थ्रूपुट को एक स्टैक्ड एरिया ग्राफ़ के रूप में दर्शाया जाता है, जहां प्रत्येक रंगीन क्षेत्र की ऊंचाई कमांड के समूह का थ्रूपुट प्रदान करती है।
एक कम थ्रूपुट आमतौर पर संकेत दे सकता है कि सर्वर को कम क्वेरी मिलती है। यह एक संभावित समस्या का भी संकेत दे सकता है, जैसे, एक महंगी क्वेरी। इसी तरह, बढ़ा हुआ थ्रूपुट सर्वर पर गहन कार्यभार और अधिक विलंबता को दर्शाता है।
<एच3>2. स्मृति उपयोगRedis प्रदर्शन के लिए मेमोरी एक महत्वपूर्ण संसाधन है। प्रयुक्त स्मृति Redis द्वारा अपने आवंटक (या तो मानक libc, jemalloc, या tcmalloc जैसे वैकल्पिक आवंटक) का उपयोग करके आवंटित बाइट्स की कुल संख्या को परिभाषित करता है।
आप "जानकारी मेमोरी चलाकर Redis उदाहरण के लिए सभी मेमोरी उपयोग मेट्रिक्स डेटा एकत्र कर सकते हैं .
127.0.0.1:6379> info memory # Memory used_memory:1007280 used_memory_human:983.67K used_memory_rss:2002944 used_memory_rss_human:1.91M used_memory_peak:1008128 used_memory_peak_human:984.50K
कभी-कभी, जब Redis को बिना अधिकतम मेमोरी सीमा के कॉन्फ़िगर किया जाता है, तो मेमोरी का उपयोग अंततः सिस्टम मेमोरी तक पहुंच जाएगा, और सर्वर "मेमोरी से बाहर" त्रुटियों को फेंकना शुरू कर देगा। अन्य समय में, Redis को अधिकतम स्मृति सीमा के साथ कॉन्फ़िगर किया जाता है लेकिन निष्कासन नीति। यह सर्वर को किसी भी कुंजी को बेदखल नहीं करने का कारण बनता है, इस प्रकार स्मृति मुक्त होने तक किसी भी लिखने को रोकता है। ऐसी समस्याओं का समाधान रेडिस को अधिकतम मेमोरी और कुछ निष्कासन नीति के साथ कॉन्फ़िगर करना होगा। इस मामले में, सर्वर मेमोरी उपयोग अधिकतम तक पहुंचने पर बेदखली नीति का उपयोग करके कुंजियों को निकालना शुरू कर देता है।
मेमोरी RSS (रेजिडेंट सेट साइज) ऑपरेटिंग सिस्टम द्वारा रेडिस को आवंटित बाइट्स की संख्या है। यदि 'memory_rss' से 'memory_used' का अनुपात ~1.5 से अधिक है, तो यह मेमोरी फ़्रेग्मेंटेशन को दर्शाता है। सर्वर को पुनरारंभ करके खंडित स्मृति को पुनर्प्राप्त किया जा सकता है।
<एच3>3. कैश हिट अनुपातकैश हिट अनुपात कैश उपयोग की दक्षता को दर्शाता है। गणितीय रूप से, इसे (कुल कुंजी हिट)/ (कुल कुंजी हिट + कुल कुंजी चूक) के रूप में परिभाषित किया गया है।
“जानकारी के आंकड़े ” कमांड keyspace_hits provides प्रदान करता है &कीस्पेस_मिस चल रहे रेडिस इंस्टेंस के लिए कैश हिट अनुपात की और गणना करने के लिए मीट्रिक डेटा।
127.0.0.1:6379> info stats # Stats ............. sync_partial_err:0 expired_keys:10 evicted_keys:12 keyspace_hits:4 keyspace_misses:15 pubsub_channels:0 pubsub_patterns:0 .............
यदि कैश हिट अनुपात ~0.8 से कम है, तो अनुरोधित कुंजियों की एक महत्वपूर्ण राशि बेदखल कर दी जाती है, समाप्त हो जाती है, या बिल्कुल भी मौजूद नहीं होती है। Redis को कैश के रूप में उपयोग करते समय इस मीट्रिक को देखना महत्वपूर्ण है। कम कैश हिट अनुपात के परिणामस्वरूप बड़ी विलंबता होती है क्योंकि अधिकांश अनुरोध डिस्क से डेटा प्राप्त कर रहे हैं। यह इंगित करता है कि आपको अपने एप्लिकेशन के प्रदर्शन को बेहतर बनाने के लिए Redis कैश का आकार बढ़ाने की आवश्यकता है।
<एच3>4. सक्रिय कनेक्शनकनेक्शन की संख्या एक सीमित संसाधन है जिसे या तो ऑपरेटिंग सिस्टम द्वारा या Redis कॉन्फ़िगरेशन द्वारा लागू किया जाता है। सक्रिय कनेक्शनों की निगरानी करने से आपको यह सुनिश्चित करने में मदद मिलती है कि आपके पास पीक समय पर अपने सभी अनुरोधों को पूरा करने के लिए पर्याप्त कनेक्शन हैं।
5. बेदखल/समाप्त कुंजियाँ
Redis विभिन्न बेदखली नीतियों का समर्थन करता है सर्वर द्वारा उपयोग किया जाता है जब स्मृति उपयोग अधिकतम सीमा को हिट करता है। इस मीट्रिक का लगातार सकारात्मक मान इस बात का संकेत है कि आपको मेमोरी को बढ़ाने की आवश्यकता है।
127.0.0.1:6379> info stats # Stats .............. sync_partial_err:0 expired_keys:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:0 pubsub_patterns:0 ..............
Redis TTL का समर्थन करता है (रहने का समय) प्रत्येक कुंजी के लिए संपत्ति। यदि संबंधित टीटीएल समाप्त हो गया है तो सर्वर कुंजी को हटा देता है। यदि एप्लिकेशन इस संपत्ति को परिभाषित नहीं करता है, तो यह समाप्त हो चुके डेटा को स्मृति में ढेर करने का कारण बनता है। एक सकारात्मक मीट्रिक मान दर्शाता है कि आपके समाप्त हो चुके डेटा को ठीक से साफ़ किया जा रहा है।
<एच3>6. प्रतिकृति मेट्रिक्स'connected_slaves' मीट्रिक एक मास्टर को दास सर्वर की पहुंच क्षमता को सूचित करता है। सर्वर पर पठन लोड के आधार पर स्लेव अगम्यता उच्च पठन विलंबता का कारण बन सकती है।
127.0.0.1:6379> info replication # Replication role:master/slave connected_slaves:0/master_slave_io_seconds_ago:0 master_repl_offset:0 ..............
‘master_slave_io_seconds_ago ' मीट्रिक बताता है कि दास और स्वामी के बीच संचार के दौरान कितना समय व्यतीत होता है। इस मीट्रिक के लिए एक उच्च मूल्य मास्टर/दास या कुछ नेटवर्क समस्याओं पर मुद्दों का संकेत हो सकता है। यह आगे दास को पुराने डेटा की सेवा करने का कारण बनता है।
निष्कर्ष
हमने कुछ महत्वपूर्ण मेट्रिक्स का उल्लेख किया है जो आपके डेटाबेस सर्वर के स्वास्थ्य और प्रदर्शन में अच्छी दृश्यता प्रदान करेंगे। ऐसे अन्य भी हो सकते हैं जो आपके विशेष डेटाबेस सर्वर और उपयोग के मामलों के लिए प्रासंगिक हों। हम अनुशंसा करते हैं कि "सूचना" कमांड द्वारा रिपोर्ट किए गए सभी मीट्रिक को पढ़ने और समझने के लिए।
यदि आपको Redis™ की तैनाती के लिए अपनी AWS होस्टिंग को प्रबंधित करने में सहायता की आवश्यकता है, तो बेझिझक हमसे [email protected] या Twitter @scalegridio पर ईमेल के माध्यम से संपर्क करें।
