मूल रूप से, हाल के ojdbc जार के लिए ऑरैकल की डिफ़ॉल्ट रणनीति प्रति "प्रीफ़ेच" पंक्ति में एक सरणी को "पूर्व आवंटित" करना है जो उस क्वेरी से वापस आने के लिए संभावित रूप से सबसे बड़े आकार के लिए समायोजित होती है। सभी पंक्तियों के लिए। तो मेरे मामले में मेरे पास कुछ VARCHAR2 (4000) थे, और 50 धागे (विवरण) * varchar2 के * 4000 के 3 कॉलम कुछ सौ [yikes] के सेटFetchSize के साथ रैम के गीगाबाइट से अधिक जोड़ रहे थे। यह कहने का विकल्प प्रतीत नहीं होता है कि "उस सरणी को पूर्व आवंटित न करें, बस आकार का उपयोग करें जैसे वे आते हैं।" Ojdbc इन पूर्व-आवंटित बफ़र्स को तैयार किए गए कथनों के बीच . के आसपास भी रखता है (कैश्ड/कनेक्शन) ताकि यह उनका पुन:उपयोग कर सके। निश्चित रूप से एक स्मृति हॉग।
एक समाधान:setFetchSize . का उपयोग करें कुछ समझदार राशि के लिए। डिफ़ॉल्ट 10 है जो उच्च विलंबता कनेक्शन पर काफी धीमा हो सकता है। प्रोफ़ाइल और केवल उच्च setFetchSize के रूप में उपयोग करें क्योंकि वास्तव में महत्वपूर्ण गति सुधार करता है।
एक अन्य समाधान यह है कि अधिकतम वास्तविक कॉलम आकार निर्धारित किया जाए, फिर क्वेरी को इसके साथ बदलें (यह मानते हुए कि 50 ज्ञात अधिकतम वास्तविक आकार है) select substr(column_name, 0, 50) चुनें।
अन्य चीज़ें जो आप कर सकते हैं:प्रीफ़ेच पंक्तियों की संख्या कम करें, जावा बढ़ाएँ -Xmx पैरामीटर, केवल उन स्तंभों का चयन करें जिनकी आपको वास्तव में आवश्यकता है।
एक बार जब हम कम से कम प्रीफेच 400 का उपयोग करने में सक्षम हो गए [यह देखने के लिए कि कौन सी संख्याएं आपके लिए अच्छी हैं, प्रोफ़ाइल देखना सुनिश्चित करें, उच्च विलंबता के साथ हमने सभी प्रश्नों पर प्रीफ़ेच आकार 3-4K तक सुधार देखा], प्रदर्शन में नाटकीय रूप से सुधार हुआ।
मुझे लगता है कि यदि आप विरल "वास्तव में लंबी" पंक्तियों के खिलाफ वास्तव में आक्रामक होना चाहते हैं तो आप इन [दुर्लभ] बड़ी पंक्तियों में भाग लेने पर फिर से पूछताछ करने में सक्षम हो सकते हैं।
विवरण विज्ञापन मतली यहां
