Predis: सर्वर से लाइन पढ़ते समय त्रुटि

क्या आपने उसी शीर्षक के साथ एक नया अंक खोलने से पहले अपनी समस्या को डीबग करने के लिए यहां वर्णित चरणों का पालन यह धागा भी देखें, यह क्लाइंट-साइड मुद्दों से असंबंधित कुछ भी हो सकता है।

धन्यवाद एनआरके। मैं सॉकेट_टाइमआउट और रीड_राइट_टाइमआउट सेट करने का प्रयास करूंगा और बाद में यहां अपने निष्कर्षों की रिपोर्ट करूंगा।

यदि आप एक डेमॉन जैसी स्क्रिप्ट में Predis का उपयोग कर रहे हैं, तो आपको read_write_timeout से -1 सेट करना चाहिए यदि आप टाइमआउट को पूरी तरह से अक्षम करना चाहते हैं (यह मान Predis के पुराने और नए संस्करणों के साथ काम करता है)। साथ ही, याद रखें कि आपको redis.conf में timeout = 0 सेट करके Redis के डिफ़ॉल्ट टाइमआउट को अक्षम करना होगा या Redis निष्क्रिय क्लाइंट के कनेक्शन को 300 सेकंड की निष्क्रियता के बाद छोड़ देगा।

एनआरके, जैसा कि उल्लेख किया गया है और अब यह पूरी तरह से काम कर रहा है। आपको धन्यवाद!

हालाँकि, अभी भी बहुत सारे कनेक्शन टाइमआउट हैं। मैंने पहले ही टाइमआउट = 0 और read_write_timeout को -1 पर सेट कर दिया है। क्या ऐसा होने पर हम इसे डीबग करने के लिए कुछ भी कर सकते हैं?

timeout Predis द्वारा मान्यता प्राप्त कनेक्शन पैरामीटर नहीं है, आपको इसके बजाय connection_timeout उपयोग करना चाहिए। connection_timeout लिए डिफ़ॉल्ट मान 5 सेकंड है, आप इसका मान बढ़ाने का प्रयास कर सकते हैं लेकिन मुझे नहीं लगता कि यह आपकी समस्या का समाधान है। आपको कोशिश करनी चाहिए और देखना चाहिए कि जब वे टाइमआउट होते हैं तो आपके सर्वर पर क्या हो रहा है, यह वास्तव में आपके आवेदन पर निर्भर करता है इसलिए मैं कोई मदद नहीं कर सकता। उन टाइमआउट के संभावित कारण हो सकते हैं:

1. यदि आपका रेडिस सर्वर लोकलहोस्ट पर नहीं है तो नेटवर्क कनेक्टिविटी समस्याएँ
2. क्या आप सुनिश्चित हैं कि आप अपनी स्क्रिप्ट में कहीं भी KEYS कमांड के लिए महंगी कॉल का उपयोग नहीं कर रहे हैं? Redis पर कीज़ स्टोर की संख्या के आधार पर, KEYS सर्वर को ब्लॉक कर सकता है, इस बीच, यह अन्य अनुरोधों या आने वाले कनेक्शनों को संसाधित करने में सक्षम नहीं होगा।

मैं इस मुद्दे को अभी के लिए खुला छोड़ दूंगा, लेकिन मुझे पूरा यकीन है कि यह निश्चित रूप से प्रेडिस से संबंधित कुछ नहीं है।

एनआरके सलाह के अनुसार, मैंने कनेक्शन_टाइमआउट को बढ़ाकर 30 कर दिया है। इसकी निगरानी करूंगा।

1. हां, हम कई रेडिस नोड्स का उपयोग कर रहे हैं जो लोकलहोस्ट नहीं हैं लेकिन वे निजी नेटवर्क पर हैं (इसलिए कम से कम अधिक स्थिर होना चाहिए?)
2. कुंजियों का उपयोग नहीं कर रहा है। हालाँकि, हम हर 900 के दशक में स्नैपशॉट ले रहे हैं। लॉग से ऐसा प्रतीत होता है कि सिस्टम HD में सहेजने के लिए 8s ले रहा है। कनेक्शन टाइमआउट का कारण सही नहीं होना चाहिए?
3. टाइमआउट होने पर सर्वर की निगरानी कैसे करें, इस बारे में कोई सलाह? टाइमआउट बहुत यादृच्छिक है। मैंने रेडिस लॉग की जाँच की, और ज्यादातर यह केवल संदेशों को स्नैपशॉट कर रहा है।

एक और अपडेट, मैंने कनेक्शन को मापा, और ऐसा प्रतीत होता है कि वास्तव में अपवाद 5s के बाद हुआ। मैंने कनेक्शन_टाइमआउट को संशोधित करने का प्रयास किया:

नया Predis_Client($param, array('read_write_timeout' => -1, 'connection_timeout' => 30));

क्या वो सही है? ऐसा लगता है कि 30 के कनेक्शन_टाइमआउट को प्रभावी नहीं किया गया है और अभी भी अपवाद फेंक दिया गया है।

वे कनेक्शन पैरामीटर हैं और क्लाइंट विकल्प नहीं हैं, इसलिए read_write_timeout और connection_timeout को $param में पैरामीटर के रूप में निर्दिष्ट किया जाना चाहिए।

1. जब तक यह Amazon EC2 (उच्च विलंबता और समय-समय पर विभिन्न मुद्दों) पर एक निजी नेटवर्क नहीं है, तब तक ऐसा नहीं होना चाहिए।
2. जहाँ तक मुझे पता है, स्नैपशॉटिंग सर्वर को ब्लॉक नहीं करना चाहिए
3. आप स्नैपशॉटिंग लॉग के विरुद्ध टाइमआउट के समय की जांच कर सकते हैं। इसके अलावा, यह वास्तव में आपके आवेदन के आर्किटेक्चर और आपके बुनियादी ढांचे पर निर्भर करता है, क्षमा करें, लेकिन मैं आपको उस पर समर्थन नहीं दे सकता।

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

एनआरके, आपके उत्तर के लिए फिर से धन्यवाद। मुझे समस्या मिली, और यह सिर्फ सर्वर है जो ip_conntrack समस्या से बाहर चल रहा है। एक बार कॉन्ट्रैक तय हो जाने के बाद, कनेक्शन टाइमआउट भी चला जाता है।

यह जानकर अच्छा लगा कि आपको अंततः उन टाइमआउट के पीछे की वास्तविक समस्या मिल गई है। उपयोगकर्ताओं को टाइमआउट समस्याओं के निवारण के लिए चेक की प्रारंभिक सूची देने के लिए मैं शायद इसे एफएक्यू में कहीं जोड़ दूंगा।

एक ही त्रुटि हो रही थी, read_write_timeout को 0 के रूप में सेट करके हल किया गया।
मैंने प्रीडिस में ऐसा किया है, क्या हम प्रीडिस क्लाइंट का उपयोग करके ऐसा कर सकते हैं?
जैसा कि यहां दिखाया गया है http://code.google.com/p/dires/source/browse/trunk/predis/examples/PubSubContext.php?r=4
मैं predis क्लाइंट का उपयोग कर रहा हूँ: $redis = new Predis\Client("tcp://"।$turboConfig->getActivitiesRedisHost ()); मुझे अपने कार्यान्वयन में read_write_timeout कैसे पास करना चाहिए।

@amitchhajer क्लाइंट नामित सरणियों या यूआरआई स्ट्रिंग्स दोनों के साथ समान कनेक्शन पैरामीटर स्वीकार करता है, इसलिए यदि आप यूआरआई स्ट्रिंग का उपयोग कर रहे हैं तो आप इसे केवल एक क्वेरी स्ट्रिंग के रूप में जोड़ सकते हैं: tcp://127.0.0.1:6379?read_write_timeout=0 ।

@nrk जानकारी के लिए धन्यवाद, अब बहुत अच्छा काम करता है।

क्या होगा अगर हमें रनटाइम पर read_write_timeout बदलने की आवश्यकता है? क्या टाइमआउट पैराम (कन्स्ट्रक्टर को छोड़कर) के लिए कुछ सेटर मौजूद है?

@bondeg कनेक्शन पैरामीटर जानबूझकर अपरिवर्तनीय हैं जिसका अर्थ है कि कनेक्शन शुरू होने के बाद आप उन्हें बदल नहीं सकते हैं, लेकिन आप क्लाइंट द्वारा उपयोग किए गए कनेक्शन ऑब्जेक्ट से अंतर्निहित स्ट्रीम संसाधन प्राप्त करके इस सीमा के आसपास काम कर सकते हैं और तदनुसार स्ट्रीम विकल्प बदल सकते हैं। यह मानते हुए कि आप क्लस्टर या प्रतिकृति मोड में क्लाइंट का उपयोग नहीं कर रहे हैं, यहां एक छोटा सा स्निपेट दिया गया है:

$connection = $client->getConnection();
$stream = $connection->getResource();
stream_set_timeout($stream, 2);

कृपया ध्यान दें कि $connection->getResource() करने से connect() ऑपरेशन रेडिस को प्रभावी ढंग से ट्रिगर करता है ताकि आप इस सुविधा का उपयोग करने के तरीके के आधार पर आलसी कनेक्शन के लाभों को खो सकें।

कृपया ध्यान दें कि प्रेडिस के नए संस्करण में पैरामीटर connection_timeout का नाम बदलकर timeout कर दिया गया है।

मैं काफी व्यापक रूप से ' एच कुंजी' का उपयोग कर रहा हूं। क्या इससे ताले लग सकते हैं?

यदि आप एक डेमॉन जैसी स्क्रिप्ट में Predis का उपयोग कर रहे हैं, तो आपको read_write_timeout से -1 सेट करना चाहिए यदि आप टाइमआउट को पूरी तरह से अक्षम करना चाहते हैं (यह मान Predis के पुराने और नए संस्करणों के साथ काम करता है)। साथ ही, याद रखें कि आपको redis.conf में timeout = 0 सेट करके Redis के डिफ़ॉल्ट टाइमआउट को अक्षम करना होगा या Redis निष्क्रिय क्लाइंट के कनेक्शन को 300 सेकंड की निष्क्रियता के बाद छोड़ देगा।

redis.conf पर टाइमआउट = 0 सेट करने से जुड़ी कोई कमी या सावधानी?

मुझे जो संदेह है वह है .. क्योंकि कनेक्शन कभी नहीं गिरेंगे
रेडिस का उपयोग उच्च रहेगा

एनआरके, आपके उत्तर के लिए फिर से धन्यवाद। मुझे समस्या मिली, और यह सिर्फ सर्वर है जो ip_conntrack समस्या से बाहर चल रहा है। एक बार कॉन्ट्रैक तय हो जाने के बाद, कनेक्शन टाइमआउट भी चला जाता है।

इस अनुबंध को कैसे ठीक करें.. कहां देखें?

redis.conf पर टाइमआउट = 0 सेट करने से जुड़ी कोई कमी या सावधानी?

@aditya-rewari-cb वास्तव में timeout = 0 redis.conf में Redis 2.4 (कुछ साल पहले जारी) के बाद से डिफ़ॉल्ट है, इसलिए मैं कहूंगा कि कोई कमियां नहीं हैं।

यदि आप एक डेमॉन जैसी स्क्रिप्ट में Predis का उपयोग कर रहे हैं, तो आपको read_write_timeout से -1 सेट करना चाहिए यदि आप टाइमआउट को पूरी तरह से अक्षम करना चाहते हैं (यह मान Predis के पुराने और नए संस्करणों के साथ काम करता है)। साथ ही, याद रखें कि आपको redis.conf में timeout = 0 सेट करके Redis के डिफ़ॉल्ट टाइमआउट को अक्षम करना होगा या Redis निष्क्रिय क्लाइंट के कनेक्शन को 300 सेकंड की निष्क्रियता के बाद छोड़ देगा।

@nrk मैं डेमॉन प्रोसेसेस (लारवेल पर्यवेक्षक कार्यकर्ता) के साथ-साथ नियमित कैशिंग के साथ कर रहा हूं
'read_write_timeout' => -1 का उपयोग करने के लिए कोई सावधानी?
मैं इस बदलाव के कारण रेडिस के अपने नियमित कैशिंग उपयोग में टूटने या बग की किसी भी संभावना की पुष्टि करना चाहता था!

धन्यवाद !