Malé dopyty fungujú, veľké zlyhávajú: ktorá veľkosť paketu?

Malé dopyty sa vracajú, veľké visia alebo padajú, a prvý inštinkt je, že niečo nie je v poriadku s veľkosťou paketu. Ten inštinkt je zvyčajne správny a takmer vždy mierený na nesprávnu vrstvu. Tri nastavenia zdieľajú slovo paket a merajú tri nesúvisiace veci: transportné zabalenie ovládača databázy, limit správ databázového servera a maximálnu prenosovú jednotku IP cesty. Ladiť jedno, aby sa opravil príznak spôsobený iným, je spôsob, akým sa z päťminútového problému stane týždeň ladenia. Poradie nižšie je to, ktoré ma stálo najmenej času.

Tri vrstvy, jedno spoločné slovo

Každý riadok nižšie je iná jednotka s iným vlastníkom a o žiadnej nemožno uvažovať z ostatných. Databázová správa môže pokrývať mnoho TCP segmentov a mnoho IP paketov, takže zväčšenie povolenej veľkosti nerozširuje cestu a zníženie nastavenia ovládača nie je rovnaká operácia ako zmena MTU rozhrania. Slovo sa objavuje v troch rôznych konfiguračných súboroch, preto jeho hľadanie vracia tri nesúvisiace odpovede. Najprv si prečítajte text chyby, potom rozhodnite, ktorý súbor otvoriť.

Pred otvorením konfiguračného súboru si zapíšte, do ktorej vrstvy patrí zlyhávajúca operácia. Text chyby to zvyčajne povie a práve túto časť ľudia preskakujú.

Pred zmenou jeho nastavenia identifikujte poskytovateľa

Pri SQL Serveri si poznačte aplikáciu, názov ovládača alebo poskytovateľa, verziu a efektívnu konfiguráciu pripojenia. Diagnostický skript a desktopová aplikácia sa môžu dostať na ten istý server cez rôznych poskytovateľov, takže nastavenie, ktoré pomôže jednému, nič nedokazuje o druhom. Predvolené hodnoty poskytovateľov sa líšia a podobne nazvané pole v pripojovacom reťazci nie je dôkazom, že ho každý poskytovateľ vykladá rovnako.

Nevymieňajte udržiavaný ovládač za starší len preto, že staré obchádzanie používalo jeho syntax. Súčasná dokumentácia neodporúča nový vývoj na tých starších komponentoch a dediť ich obmedzenia je zlá výmena za jedno nastavenie.

Odmietnutie správy nie je zaseknutie cesty

V MySQL 8.4 dokumentácia ku komunikačnému paketu opisuje odmietnutie príliš veľkého príkazu, riadku alebo udalosti binárneho logu voči platnému limitu a môžu záležať oba limity, klientsky aj serverový. To je odmietnutie na vrstve databázy, nie tvrdenie, že sieť musí preniesť obrovský IP paket. Prečítajte si skutočnú chybu a tvar problematickej správy: veľký výsledok z mnohých malých riadkov je iný prípad ako jeden obrovský riadok a zlyhávajú rôzne.

Inštalácie MariaDB potrebujú dokumentované limity a diagnostiku vlastnej verzie. Kopírovať predvolené hodnoty MySQL na MariaDB je hádanie s krokmi navyše.

Ako dôkazy o ceste skutočne vyzerajú

Problém veľkosti cesty má vlastnú stopu: opakovateľné transportné zlyhanie závislé od veľkosti na určitej trase a rodine adries, so zapojenou réžiou tunela a spätnou väzbou objavovania správajúcou sa tak, ako cesta dovolí. Samotný timeout ho neodlíši od pomalého dopytu, chyby ovládača alebo serverového limitu a považovať timeout za dôkaz problémov s MTU vás s istotou pošle na nesprávnu vrstvu.

Ak cestu testujete, držte cieľ, účet a zaťaženie pevne, aby jedinou premennou bola veľkosť, ktorú skúmate. Test, v ktorom sa zmenili tri veci, vám nepovie, ktorá z nich bola dôležitá.

Zmeňte jednu dokumentovanú premennú a potom ju zaznamenajte

Držte cieľ, účet, poskytovateľa a zaťaženie konštantné, zaznamenajte pôvodnú hodnotu, použite jednu podporovanú zmenu a zaznamenajte výsledok. Menšie nastavenie, vďaka ktorému jeden test prejde, je užitočný dôkaz o tomto testovanom zásobníku; nie je univerzálnym optimom a neurčuje, čo spôsobilo pôvodné zlyhanie. To sú rôzne tvrdenia a iba prvé podporuje jediný experiment.

Vyriešte zistený limit na jeho vlastnej vrstve a potom poznamenajte, ktorá vrstva to bola. Práve poznámka zabráni ďalšiemu človeku ladiť ovládač, pretože problémom bola cesta.