2013-03-07 7 views
5

कमांड redis-cli के माध्यम से info कमांड का उपयोग करते समय जानकारी आउटपुट करने में सक्षम नहीं होने के कारण रेडिस के साथ बहुत अधिक प्रतिक्रिया विलंबता का अनुभव करने के लिए बहुत लंबा समय ले रहा है।रेडिस

यह सर्वर लगभग 200 समवर्ती प्रक्रियाओं से अनुरोधों को संभालता है लेकिन यह बहुत अधिक जानकारी (कम से कम हमारे ज्ञान तक) संग्रहीत नहीं करता है। जब सर्वर उत्तरदायी होता है, तो info कमांड रिपोर्ट 20 - 30 एमबी के आसपास स्मृति का उपयोग करती है।

सर्वर पर top चलाते समय, उच्च प्रतिक्रिया विलंबता की अवधि के दौरान, CPU उपयोग लगभग 95 - 100% हो जाता है।

इस तरह के व्यवहार के लिए कुछ संभावित कारण क्या हैं?

+0

आपका उपयोग कैसा दिखता है? क्या वहां बहुत बड़ा 'एसओआरटी' चल रहा है? क्या आप उत्पादन कोड में 'KEYS' का उपयोग करते हैं? क्या आप कहीं से भी 'मॉनिटर' चला रहे हैं? आपकी दृढ़ता रणनीति क्या है? –

+0

हमने इस उदाहरण में दृढ़ता को अक्षम कर दिया। वर्तमान में कहीं भी 'कुंजी' या 'मॉनिटर' आदेशों का उपयोग नहीं कर रहा है। हमारे पास कम से कम मेरे ज्ञान की सीमा तक 'एसओआरटी' नहीं है। यह उदाहरण 'rq' (www.python-rq.org) को समर्पित है। –

उत्तर

8

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

प्रलेखन के अनुसार, पायथन-आरक ने रेडिस में हैश ऑब्जेक्ट्स के रूप में नौकरियां डालीं, और नौकरियों से छुटकारा पाने के लिए रेडिस संबंधित कुंजी (500 सेकंड डिफ़ॉल्ट मान प्रतीत होता है) को समाप्त कर देता है। यदि आपके पास कुछ गंभीर थ्रूपुट है, तो एक बिंदु पर, आपके पास रेडिस में कई आइटम समाप्त होने की प्रतीक्षा कर रहे हैं। लंबित नौकरियों की तुलना में उनकी संख्या अधिक होगी।

आप INFO कमांड के परिणामस्वरूप समाप्त होने वाली वस्तुओं की संख्या को देखकर इस बिंदु को देख सकते हैं।

रेडिस समाप्ति एक आलसी तंत्र (लागू होने पर लागू होने पर लागू) पर आधारित है, और मुख्य नमूना पर आधारित एक सक्रिय तंत्र, जो घटना लूप (छद्म पृष्ठभूमि मोड में, हर 100 एमएस) में चलाया जाता है। मुद्दा यह है कि सक्रिय समाप्ति तंत्र चल रहा है, कोई Redis कमांड संसाधित नहीं किया जा सकता है।

क्लाइंट अनुप्रयोगों के प्रदर्शन को प्रभावित करने से बचने के लिए, सक्रिय तंत्र ट्रिगर होने पर प्रत्येक बार केवल सीमित संख्या में कुंजी संसाधित की जाती है (डिफ़ॉल्ट रूप से, 10 कुंजी)। हालांकि, अगर 25% से अधिक कुंजी समाप्त हो जाती हैं, तो यह अधिक कुंजी और लूप की अवधि समाप्त करने का प्रयास करती है। इस तरह की संभाव्य एल्गोरिदम स्वचालित रूप से अपनी गतिविधि को रीडिस की अवधि समाप्त होने की कुंजी पर अनुकूलित करने का तरीका है।

जब कई चाबियाँ समाप्त हो जाती हैं, तो यह अनुकूली एल्गोरिदम रेडिस के प्रदर्शन को महत्वपूर्ण रूप से प्रभावित कर सकता है। आप अधिक जानकारी here पा सकते हैं।

मेरा सुझाव पाइथन-आरक को समाप्ति की सेटिंग द्वारा रेडिस को आइटम की सफाई करने के लिए रोकने का प्रयास करना होगा। वैसे भी क्यूइंग सिस्टम के लिए यह एक खराब डिजाइन है।

+0

यह एक अच्छा समाधान की तरह लगता है। इस तरह के एक विस्तृत उत्तर के लिए धन्यवाद। मैं इसे आज़माउंगा और देख सकता हूं कि यह कैसे काम करता है। एक बार फिर धन्यवाद! –

+0

हाँ, 'जॉब' ttl को कम करते समय कम CPU उपयोग को देखते हुए। बहुत बहुत धन्यवाद! –

0

मुझे लगता है कि Redis समाप्त होने पर कुंजी को सीपीयू उपयोग से बचने का सही तरीका नहीं होना चाहिए।

डिडिएर कहते हैं, एक अच्छी बात के साथ, कि पाइथन-आरक का वर्तमान आर्किटेक्चर कि यह कुंजी-समाप्ति सुविधा का उपयोग करके रेडिस को सफाई नौकरियों का प्रतिनिधित्व करता है। और निश्चित रूप से, डिडिएर ने कहा कि यह सबसे अच्छा तरीका नहीं है। (इसका उपयोग केवल तभी किया जाता है जब परिणाम_ttl 0 से अधिक हो)

तब समस्या तब बढ़नी चाहिए जब आपके पास एक दूसरे के पास समाप्ति तिथियों के साथ कुंजी/नौकरियों का एक सेट हो, और यह तब हो सकता है जब आपके पास विस्फोट हो नौकरी निर्माण का।

लेकिन अजगर-RQ सेट, समय सीमा समाप्त हो कुंजी जब काम एक कार्यकर्ता में समाप्त कर दिया गया,

तो यह भी समझ में नहीं होने के कारण कुंजी उन दोनों के बीच काफी समय से बचने के लिए इस के साथ समय चारों ओर फैले चाहिए स्थिति