छोट्या क्वेरी चालतात, मोठ्या अयशस्वी होतात: कोणता पॅकेट आकार?

छोट्या क्वेरी परत येतात, मोठ्या अडकतात किंवा पडतात, आणि पहिला अंदाज असा असतो की पॅकेट आकारात काहीतरी चुकीचे आहे। तो अंदाज सहसा बरोबर असतो आणि जवळजवळ नेहमी चुकीच्या स्तरावर लक्ष्य ठेवतो। तीन सेटिंग्ज पॅकेट हा शब्द सामायिक करतात आणि तीन असंबंधित गोष्टी मोजतात: डेटाबेस ड्राइव्हरचे वाहतूक पॅकेजिंग, डेटाबेस सर्व्हरची संदेश मर्यादा आणि IP मार्गाचे कमाल प्रक्षेपण एकक। एक समायोजित करून दुसऱ्यामुळे झालेले लक्षण दुरुस्त करणे हा पाच मिनिटांची समस्या आठवडाभराच्या ट्यूनिंगमध्ये बदलण्याचा मार्ग आहे। खालील क्रम हा मला सर्वात कमी वेळ खर्च करून गेलेला क्रम आहे।

तीन स्तर, एक सामायिक शब्द

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

कॉन्फिगरेशन फाइल उघडण्यापूर्वी अयशस्वी क्रिया कोणत्या स्तराची आहे ते लिहा। त्रुटीचा मजकूर सहसा ते सांगतो, आणि लोक जो भाग वगळतात तोच तो मजकूर आहे।

त्याची सेटिंग बदलण्यापूर्वी प्रदाता ओळखा

SQL Server साठी अनुप्रयोग, ड्राइव्हर किंवा प्रदात्याचे नाव, आवृत्ती आणि प्रभावी कनेक्शन कॉन्फिगरेशन नोंदवा। डायग्नोस्टिक स्क्रिप्ट आणि डेस्कटॉप अनुप्रयोग वेगवेगळ्या प्रदात्यांमार्फत एकाच सर्व्हरपर्यंत पोहोचू शकतात, म्हणून एकाला मदत करणारी सेटिंग दुसऱ्याबद्दल काहीही सिद्ध करत नाही। प्रदात्यांची डीफॉल्ट मूल्ये वेगळी असतात, आणि कनेक्शन स्ट्रिंगमधील समान नावाचे फील्ड हे प्रत्येक प्रदाता ते एकाच पद्धतीने अर्थ लावतो याचा पुरावा नाही।

जुना उपाय त्याची सिंटॅक्स वापरत होता म्हणूनच देखभाल केलेला ड्राइव्हर जुन्याने बदलू नका। सध्याची माहिती त्या जुन्या घटकांवर नवीन विकासाला प्रोत्साहन देत नाही, आणि त्यांच्या मर्यादा वारसा म्हणून घेणे एका सेटिंगसाठी वाईट सौदा आहे।

संदेश नाकारणे हे मार्गाचे थांबणे नाही

MySQL 8.4 मध्ये, संवाद-पॅकेट माहिती लागू मर्यादेपुढे खूप मोठे विधान, ओळ किंवा बायनरी-लॉग घटना नाकारली जाते असे वर्णन करते, आणि क्लायंट व सर्व्हर अशा दोन्ही मर्यादा महत्त्वाच्या असू शकतात। ते डेटाबेस स्तरावर नाकारणे आहे, नेटवर्कला प्रचंड IP पॅकेट वाहून न्यावे लागते असे विधान नाही। प्रत्यक्ष त्रुटी आणि समस्याग्रस्त संदेशाचा आकार वाचा: अनेक लहान ओळींचा मोठा निकाल एका प्रचंड ओळीपेक्षा वेगळा प्रसंग आहे, आणि ते वेगळ्या पद्धतीने अयशस्वी होतात।

MariaDB प्रतिष्ठापनांना त्यांच्या स्वतःच्या आवृत्तीच्या नोंदवलेल्या मर्यादा आणि निदान आवश्यक आहे। MySQL ची डीफॉल्ट मूल्ये MariaDB वर कॉपी करणे म्हणजे अतिरिक्त पायऱ्यांसह अंदाज लावणे।

मार्गाचा पुरावा प्रत्यक्षात कसा दिसतो

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

तुम्ही मार्गाची चाचणी केली तर गंतव्य, खाते आणि कार्यभार स्थिर ठेवा जेणेकरून एकमेव चल तुम्ही तपासत असलेला आकार असेल। तीन गोष्टी बदललेली चाचणी कोणती महत्त्वाची होती हे काहीही सांगत नाही।

एक नोंदवलेला चल बदला, नंतर तो नोंदवा

गंतव्य, खाते, प्रदाता आणि कार्यभार स्थिर ठेवा, मूळ मूल्य नोंदवा, एक समर्थित बदल लागू करा आणि निकाल नोंदवा। एक चाचणी यशस्वी करणारी लहान सेटिंग त्या चाचणी केलेल्या स्टॅकबद्दल उपयुक्त पुरावा आहे; ती सार्वत्रिक इष्टतम नाही आणि मूळ अयशस्वीतेचे कारण काय होते हे स्थापित करत नाही। हे वेगळे दावे आहेत, आणि फक्त पहिल्यालाच एका प्रयोगाचा आधार आहे।

ओळखलेली मर्यादा तिच्या स्वतःच्या स्तरावर सोडवा, नंतर कोणता स्तर होता ते नोंदवा। तीच नोंद पुढच्या व्यक्तीला ड्राइव्हर ट्यून करण्यापासून थांबवते कारण समस्या मार्गात होती।