सबसे पहले mysql के गुणों को समझते हैं।
interactive_timeout:mysql शेल सेशन के लिए इंटरएक्टिव टाइम आउट सेकंड में mysqldump या mysql कमांड लाइन टूल्स की तरह। कनेक्शन सुप्त अवस्था में हैं। अधिकांश समय यह उच्च मान पर सेट होता है क्योंकि आप नहीं चाहते कि जब आप mysql cli पर कुछ कर रहे हों तो यह डिस्कनेक्ट हो जाए।wait_timeout:निष्क्रियता के दौरान सेकंड की मात्रा जो MySQL प्रतीक्षा करेगा इससे पहले कि यह एक गैर-संवादात्मक कनेक्शन पर एक कनेक्शन को सेकंड में बंद कर देगा। उदाहरण:जावा से जुड़ा हुआ है। कनेक्शन निष्क्रिय अवस्था में हैं।
अब आइए c3po गुणों को समझते हैं और इसका DB प्रॉप्स के साथ संबंध है। (मैं सिर्फ आपके प्रश्न से कॉपी करने वाला हूं)
यह संदर्भित करता है कि कनेक्शन ऑब्जेक्ट कितने समय तक प्रयोग करने योग्य हो सकता है और पूल में उपलब्ध होगा। एक बार टाइमआउट खत्म हो जाने पर c3po इसे नष्ट कर देगा या इसे रीसायकल करेगा।
अब समस्या तब आती है जब आपके पास maxIdleTime . है उच्चतर तो wait_timeout मान लें कि mxIdleTime : 50 सेकंड और wait_timeout : 40 s तो एक संभावना है कि आपको Connection time out exception: Broken Pipe यदि आप अंतिम 10 सेकंड में कोई ऑपरेशन करने का प्रयास करते हैं। तो maxIdelTime हमेशा कम होना चाहिए wait_timeout ।
maxIdleTime के बजाय आप निम्न गुण कर सकते हैं।
idleConnectionTestPeriodएक सीमा निर्धारित करता है कि कोई कनेक्शन परीक्षण करने से पहले कितने समय तक निष्क्रिय रहेगा। बिनाpreferredTestQuery. के , डिफ़ॉल्टDatabaseMetaData.getTables(). है - जो डेटाबेस अज्ञेयवादी है, और हालांकि एक अपेक्षाकृत महंगी कॉल, अपेक्षाकृत छोटे डेटाबेस के लिए शायद ठीक है। यदि आप प्रदर्शन के बारे में पागल हैं, तो अपने डेटाबेस के लिए विशिष्ट क्वेरी का उपयोग करें(i.e. preferredTestQuery="SELECT 1")maxIdleTimeExcessConnectionsगतिविधि में वृद्धि के बाद कनेक्शनकाउंट बैकडाउन को minPoolSize पर वापस लाएगा।
कृपया ध्यान दें कि पूल की कोई भी संपत्ति (उदा. maxIdleTime .) ) केवल कनेक्शन को प्रभावित करता है जो पूल में हैं यानी अगर हाइबरनेट ने एक कनेक्शन हासिल कर लिया है और इसे maxIdleTime की तुलना में निष्क्रिय रखता है और फिर कोई ऑपरेशन करने की कोशिश करता है तो आपको "टूटा हुआ पाइप" मिलेगा
कम wait_timeout होना अच्छा है MySQL पर लेकिन यह हमेशा सही नहीं होता है जब आपके पास पहले से निर्मित एक एप्लिकेशन होता है। आपको इसे कम करने से पहले यह सुनिश्चित करना होगा कि आपके एप्लिकेशन में आप कनेक्शन को अधिक के लिए खुला नहीं रख रहे हैं wait_time बाहर।
आपको यह भी विचार करना होगा कि कनेक्शन प्राप्त करना महंगा काम है और यदि प्रतीक्षा समय बहुत कम है तो यह कनेक्शन पूल होने के पूरे उद्देश्य को हरा देता है, क्योंकि यह अक्सर कनेक्शन प्राप्त करने का प्रयास करेगा।
यह विशेष रूप से महत्वपूर्ण है जब आप मैन्युअल रूप से कनेक्शन प्रबंधन नहीं कर रहे हैं उदाहरण के लिए जब आप स्प्रिंग ट्रांसनेशनल एपीआई का उपयोग करते हैं। जब आप @Transaction . दर्ज करते हैं तो स्प्रिंग लेनदेन शुरू करता है एनोटेट विधि इसलिए यह पूल से कनेक्शन प्राप्त करती है। यदि आप कोई वेब सेवा कॉल कर रहे हैं या कुछ फाइल पढ़ रहे हैं जिसमें प्रतीक्षा_टाइम से अधिक समय लगेगा तो आपको अपवाद मिलेगा।
मैंने एक बार इस मुद्दे का सामना किया है।
मेरी एक परियोजना में मेरे पास एक क्रॉन था जो ग्राहकों के लिए ऑर्डर प्रोसेसिंग करेगा। इसे तेज करने के लिए मैंने बैच प्रोसेसिंग का इस्तेमाल किया। अब एक बार जब मैं ग्राहकों का एक बैच पुनर्प्राप्त करता हूं और कुछ प्रसंस्करण करता हूं (कोई डीबी कॉल नहीं)। जब मैं सभी ऑर्डर सहेजने की कोशिश करता हूं तो मुझे टूटा हुआ पाइप अपवाद मिलता था। समस्या यह थी कि मेरा वेट_टाइमआउट 1 मिनट का था और ऑर्डर प्रोसेसिंग में अधिक समय लग रहा था। इसलिए हमें इसे बढ़ाकर 2 मिनट करना पड़ा। मैं बैच के आकार को कम कर सकता था लेकिन वह समग्र प्रसंस्करण को धीमा कर रहा था।
