چھوٹی استفسارات کام کرتی ہیں، بڑی ناکام ہوتی ہیں: کون سا پیکٹ سائز ہے؟

چھوٹی استفسارات واپس آتی ہیں، بڑی لٹک جاتی ہیں یا گر جاتی ہیں، اور پہلا گمان یہ ہوتا ہے کہ پیکٹ سائز میں کچھ غلط ہے۔ وہ گمان عموماً درست ہوتا ہے اور تقریباً ہمیشہ غلط طبقے کو نشانہ بناتا ہے۔ تین ترتیبات پیکٹ کا لفظ بانٹتی ہیں اور تین غیر متعلق چیزیں ناپتی ہیں: ڈیٹا بیس ڈرائیور کی نقل و حمل کی پیکنگ، ڈیٹا بیس سرور کی پیغام کی حد اور IP راستے کی زیادہ سے زیادہ ترسیلی اکائی۔ ایک کو ایڈجسٹ کر کے دوسرے سے پیدا ہونے والی علامت درست کرنا وہ راستہ ہے جس سے پانچ منٹ کا مسئلہ ایک ہفتے کی ٹیوننگ بن جاتا ہے۔ نیچے دیا گیا ترتیب وہی ہے جس میں مجھے سب سے کم وقت لگا۔

تین طبقے، ایک مشترکہ لفظ

نیچے کی ہر سطر مختلف مالک کی مختلف اکائی ہے، اور ان میں سے کسی کے بارے میں باقیوں سے استدلال نہیں کیا جا سکتا۔ ڈیٹا بیس کا پیغام کئی TCP قطعوں اور کئی IP پیکٹوں پر پھیل سکتا ہے، اس لیے اس کا اجازت شدہ سائز بڑھانا راستے کو کشادہ نہیں کرتا، اور ڈرائیور کی ترتیب کم کرنا انٹرفیس کے MTU کو بدلنے جیسی وہی کارروائی نہیں ہے۔ یہ لفظ تین مختلف کنفیگریشن فائلوں میں آتا ہے، اسی لیے اسے تلاش کرنے پر تین غیر متعلق جواب ملتے ہیں۔ پہلے غلطی کا متن پڑھیں، پھر فیصلہ کریں کہ کون سی فائل کھولنی ہے۔

کنفیگریشن فائل کھولنے سے پہلے لکھیں کہ ناکام کارروائی کس طبقے کی ہے۔ غلطی کا متن عموماً یہی بتاتا ہے، اور غلطی کا متن ہی وہ حصہ ہے جسے لوگ چھوڑ دیتے ہیں۔

اس کی ترتیب بدلنے سے پہلے فراہم کنندہ کی شناخت کریں

SQL Server کے لیے ایپلیکیشن، ڈرائیور یا فراہم کنندہ کا نام، ورژن اور مؤثر کنکشن کنفیگریشن درج کریں۔ ایک تشخیصی اسکرپٹ اور ڈیسک ٹاپ ایپلیکیشن مختلف فراہم کنندگان کے ذریعے ایک ہی سرور تک پہنچ سکتے ہیں، اس لیے ایک کی مدد کرنے والی ترتیب دوسرے کے بارے میں کچھ ثابت نہیں کرتی۔ فراہم کنندگان کی طے شدہ اقدار مختلف ہوتی ہیں، اور کنکشن سٹرنگ میں ملتے جلتے نام کا فیلڈ اس بات کا ثبوت نہیں کہ ہر فراہم کنندہ اسے ایک ہی طرح سمجھتا ہے۔

صرف اس لیے کہ کسی پرانے حل نے اس کا نحو استعمال کیا تھا، دیکھ بھال والے ڈرائیور کو پرانے سے نہ بدلیں۔ موجودہ دستاویزات ان پرانے اجزا پر نئی ترقی کی حوصلہ افزائی نہیں کرتیں، اور ان کی حدود وراثت میں لینا ایک ترتیب کے لیے برا سودا ہے۔

پیغام کا مسترد ہونا راستے کا رکنا نہیں ہے

MySQL 8.4 میں، رابطہ پیکٹ کی دستاویزات بیان کرتی ہیں کہ قابل اطلاق حد کے خلاف بہت بڑا بیان، سطر یا بائنری لاگ واقعہ مسترد ہوتا ہے، اور کلائنٹ اور سرور دونوں کی حدیں اہم ہو سکتی ہیں۔ یہ ڈیٹا بیس طبقے پر مسترد ہونا ہے، یہ بیان نہیں کہ نیٹ ورک کو بہت بڑا IP پیکٹ ڈھونا پڑے گا۔ اصل غلطی اور مسئلہ والے پیغام کی شکل پڑھیں: بہت سی چھوٹی سطروں سے بننے والا بڑا نتیجہ ایک بہت بڑی سطر سے مختلف معاملہ ہے، اور وہ مختلف طریقوں سے ناکام ہوتے ہیں۔

MariaDB کی تنصیبات کو اپنے ورژن کی دستاویزی حدوں اور تشخیص کی ضرورت ہے۔ MySQL کی طے شدہ اقدار MariaDB پر کاپی کرنا اضافی مراحل کے ساتھ اندازہ لگانا ہے۔

راستے کا ثبوت درحقیقت کیسا دکھتا ہے

راستے کے سائز کا مسئلہ اپنی انگوٹھی کی چھاپ رکھتا ہے: کسی خاص راستے اور پتہ خاندان پر دہرایا جا سکنے والا سائز پر منحصر نقل و حمل کا ناکامی، جس میں سرنگ کا اضافی بوجھ شامل ہو اور دریافت کی رائے راستہ جس طرح اجازت دے ویسے برتاؤ کرے۔ صرف ایک ٹائم آؤٹ اسے سست استفسار، ڈرائیور کی خرابی یا سرور کی طرف کی حد سے الگ نہیں کرتا، اور ٹائم آؤٹ کو MTU مسائل کا ثبوت سمجھنا آپ کو اعتماد سے غلط طبقے پر بھیجتا ہے۔

اگر آپ راستے کی جانچ کریں تو منزل، اکاؤنٹ اور کام کا بوجھ مستقل رکھیں تاکہ واحد متغیر وہ سائز ہو جو آپ جانچ رہے ہیں۔ جس جانچ میں تین چیزیں بدلیں، وہ یہ نہیں بتاتی کہ کون سی اہم تھی۔

ایک دستاویزی متغیر بدلیں، پھر اسے درج کریں

منزل، اکاؤنٹ، فراہم کنندہ اور کام کا بوجھ مستقل رکھیں، اصل قدر درج کریں، ایک معاون تبدیلی لاگو کریں اور نتیجہ درج کریں۔ ایک جانچ کو کامیاب کرنے والی چھوٹی ترتیب اس جانچے گئے اسٹیک کے بارے میں مفید ثبوت ہے؛ یہ عالمگیر بہترین نہیں ہے اور یہ قائم نہیں کرتی کہ اصل ناکامی کی وجہ کیا تھی۔ یہ مختلف دعوے ہیں، اور صرف پہلے کو ایک تجربے کی تائید حاصل ہے۔

شناخت شدہ حد کو اس کے اپنے طبقے میں حل کریں، پھر درج کریں کہ کون سا طبقہ تھا۔ وہی نوٹ اگلے شخص کو ڈرائیور ٹیون کرنے سے روکتا ہے کیونکہ مسئلہ راستے میں تھا۔