छोटी क्वेरी चलती हैं, बड़ी विफल होती हैं: यह कौन-सा पैकेट आकार है?

छोटी क्वेरी लौट आती हैं, बड़ी अटक जाती हैं या गिर जाती हैं, और पहला अनुमान यह होता है कि पैकेट आकार में कुछ गड़बड़ है। वह अनुमान आमतौर पर सही होता है और लगभग हमेशा गलत परत पर निशाना लगाता है। तीन सेटिंग पैकेट शब्द साझा करती हैं और तीन असंबंधित चीज़ें मापती हैं: किसी डेटाबेस ड्राइवर की परिवहन पैकेजिंग, किसी डेटाबेस सर्वर की संदेश सीमा, और IP पथ की अधिकतम संचरण इकाई। एक को दूसरे से पैदा हुए लक्षण को ठीक करने के लिए समायोजित करना वह रास्ता है जिससे पाँच मिनट की समस्या एक हफ़्ते की ट्यूनिंग बन जाती है। नीचे का क्रम वही है जिसमें मुझे सबसे कम समय लगा।

तीन परतें, एक साझा शब्द

नीचे की हर पंक्ति अलग मालिक वाली अलग इकाई है, और उनमें से किसी के बारे में बाकी से तर्क नहीं किया जा सकता। एक डेटाबेस संदेश कई TCP खंडों और कई IP पैकेटों में फैल सकता है, इसलिए उसका अनुमत आकार बढ़ाना पथ को नहीं चौड़ा करता, और ड्राइवर सेटिंग घटाना किसी इंटरफ़ेस का MTU बदलने जैसा वही कार्य नहीं है। यह शब्द तीन अलग कॉन्फ़िगरेशन फ़ाइलों में आता है, इसीलिए इसे खोजने पर तीन असंबंधित उत्तर मिलते हैं। पहले त्रुटि का पाठ पढ़ें, फिर तय करें कौन-सी फ़ाइल खोलनी है।

कॉन्फ़िगरेशन फ़ाइल खोलने से पहले लिखें कि विफल कार्य किस परत का है। त्रुटि का पाठ आमतौर पर यही कहता है, और त्रुटि का पाठ वही हिस्सा है जिसे लोग छोड़ देते हैं।

उसकी सेटिंग बदलने से पहले प्रदाता की पहचान करें

SQL Server के लिए एप्लिकेशन, ड्राइवर या प्रदाता का नाम, संस्करण और प्रभावी कनेक्शन कॉन्फ़िगरेशन दर्ज करें। एक डायग्नोस्टिक स्क्रिप्ट और एक डेस्कटॉप एप्लिकेशन अलग प्रदाताओं के माध्यम से उसी सर्वर तक पहुँच सकते हैं, इसलिए एक की मदद करने वाली सेटिंग दूसरे के बारे में कुछ सिद्ध नहीं करती। प्रदाताओं के डिफ़ॉल्ट अलग होते हैं, और कनेक्शन स्ट्रिंग में मिलते-जुलते नाम का फ़ील्ड इस बात का प्रमाण नहीं है कि हर प्रदाता उसे एक ही तरह समझता है।

केवल इसलिए किसी अनुरक्षित ड्राइवर को पुराने से न बदलें कि किसी पुराने उपाय ने उसका सिंटैक्स इस्तेमाल किया था। मौजूदा दस्तावेज़ीकरण उन पुराने घटकों पर नए विकास को हतोत्साहित करता है, और उनकी सीमाओं को विरासत में लेना एक सेटिंग के लिए खराब सौदा है।

संदेश का अस्वीकार होना पथ का ठहराव नहीं है

MySQL 8.4 में, संचार-पैकेट दस्तावेज़ीकरण बताता है कि लागू सीमा के विरुद्ध बहुत बड़ा स्टेटमेंट, पंक्ति या बाइनरी-लॉग घटना अस्वीकार की जाती है, और क्लाइंट तथा सर्वर दोनों की सीमाएँ मायने रख सकती हैं। यह डेटाबेस परत पर अस्वीकृति है, यह कथन नहीं कि नेटवर्क को विशाल IP पैकेट ढोना पड़ेगा। वास्तविक त्रुटि और समस्या वाले संदेश का आकार पढ़ें: कई छोटी पंक्तियों से बना बड़ा परिणाम एक विशाल पंक्ति से अलग मामला है, और वे अलग तरह से विफल होते हैं।

MariaDB इंस्टॉलेशन को अपने ही संस्करण की दस्तावेज़ी सीमाएँ और निदान चाहिए। MySQL के डिफ़ॉल्ट MariaDB पर कॉपी करना अतिरिक्त क़दमों के साथ अनुमान लगाना है।

पथ का प्रमाण वास्तव में कैसा दिखता है

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

अगर आप पथ का परीक्षण करें, तो गंतव्य, खाता और कार्यभार स्थिर रखें ताकि एकमात्र चर वह आकार हो जिसे आप जाँच रहे हैं। जिस परीक्षण में तीन चीज़ें बदलीं, वह यह नहीं बताता कि कौन-सी मायने रखती थी।

एक दस्तावेज़ी चर बदलें, फिर उसे दर्ज करें

गंतव्य, खाता, प्रदाता और कार्यभार स्थिर रखें, मूल मान दर्ज करें, एक समर्थित परिवर्तन लागू करें और परिणाम दर्ज करें। छोटी सेटिंग जो एक परीक्षण को सफल करती है, उस परीक्षित स्टैक के बारे में उपयोगी प्रमाण है; यह सार्वभौमिक इष्टतम नहीं है और यह स्थापित नहीं करती कि मूल विफलता का कारण क्या था। ये अलग-अलग दावे हैं, और केवल पहले को एक प्रयोग समर्थन देता है।

पहचानी गई सीमा को उसकी अपनी परत पर हल करें, फिर दर्ज करें कि कौन-सी परत थी। यही टिप्पणी अगले व्यक्ति को ड्राइवर ट्यून करने से रोकती है क्योंकि समस्या पथ में थी।