Små spørjingar virkar, store feilar: kva pakkestorleik er det?

Små spørjingar kjem tilbake, store heng eller fell ut, og den første tanken er at noko er gale med pakkestorleiken. Den tanken er som regel riktig og nesten alltid retta mot feil lag. Tre innstillingar deler ordet pakke og måler tre uavhengige ting: transportinnpakninga til ein databasedrivar, meldingsgrensa til ein databaseserver og den maksimale overføringseininga til IP-ruta. Å justere éin for å rette eit symptom som ein annan har skapt, er måten eit femminuttsproblem blir ei veke med tuning. Rekkjefølgja nedanfor er den som har kosta meg minst tid.

Tre lag, eitt felles ord

Kvar rad nedanfor er ei anna eining med ein annan eigar, og ingen av dei kan ein resonnere seg fram til frå dei andre. Ei databasemelding kan strekkje seg over mange TCP-segment og mange IP-pakkar, så å auke den tillatne storleiken utvidar ikkje ruta, og å senke ei drivarinnstilling er ikkje same operasjon som å endre ein grensesnitt-MTU. Ordet står i tre ulike konfigurasjonsfiler, og difor gjev eit søk etter det tre uavhengige svar. Les feilteksten først, og avgjer deretter kva fil du opnar.

Skriv ned kva lag den feilande operasjonen høyrer til, før du opnar ei konfigurasjonsfil. Feilteksten seier det som regel, og feilteksten er nettopp den delen folk hoppar over.

Identifiser leverandøren før du endrar innstillinga

For SQL Server, registrer programmet, namnet på drivaren eller leverandøren, versjonen og den effektive tilkoplingkonfigurasjonen. Eit diagnostikkskript og eit skrivebordsprogram kan nå same server via ulike leverandørar, så ei innstilling som hjelper den eine, beviser ingenting om den andre. Standardverdiane til leverandørane er ulike, og eit liknande namngjeve felt i tilkoplingstrengen er ikkje bevis for at kvar leverandør tolkar det likt.

Ikkje byt ut ein vedlikehalden drivar med ein eldre berre fordi ei gammal løysing brukte syntaksen hans. Gjeldande dokumentasjon frårår ny utvikling mot dei eldre komponentane, og å arve avgrensingane deira er ein dårleg handel for éi innstilling.

Avvising av ei melding er ikkje ei fastlåst rute

I MySQL 8.4 skildrar dokumentasjonen for kommunikasjonspakken at ei for stor setning, rad eller binærlogghending blir avvist mot gjeldande grense, og både klient- og servergrensa kan spele inn. Det er ei avvising på databaselaget, ikkje ein påstand om at nettet må bere ein gigantisk IP-pakke. Les den faktiske feilen og forma på den problematiske meldinga: eit stort resultat av mange små rader er eit anna tilfelle enn éi enorm rad, og dei feilar ulikt.

MariaDB-installasjonar treng dei dokumenterte grensene og diagnostikken til sine eigne versjonar. Å kopiere MySQL-standardar over på MariaDB er gjetting med ekstra steg.

Korleis rutebevis faktisk ser ut

Eit rutestorleiksproblem har sitt eige fingeravtrykk: ein reproduserbar storleiksavhengig transportfeil langs ei bestemd rute og adressefamilie, med overheaden til tunnelen i spel og oppdagingsrespons som oppfører seg slik ruta tillèt. Ein timeout åleine skil det ikkje frå ei treg spørjing, ein drivarfeil eller ei servergrense, og å handsame ein timeout som bevis for MTU-problem sender deg med sjølvtillit til feil lag.

Viss du testar ruta, hald destinasjon, konto og arbeidslast fast slik at den einaste variabelen er storleiken du granskar. Ein test der tre ting vart endra, fortel deg ingenting om kva som betydde noko.

Endre éin dokumentert variabel, og registrer han deretter

Hald destinasjon, konto, leverandør og arbeidslast konstant, registrer den opphavlege verdien, bruk éi støtta endring og registrer resultatet. Ei mindre innstilling som får ein test til å lukkast, er nyttig bevis om den testa stakken; ho er ikkje eit universelt optimum og fastset ikkje kva som førte til den opphavlege feilen. Det er ulike påstandar, og berre den første vert støtta av eitt enkelt eksperiment.

Løys den identifiserte grensa på sitt eige lag, og noter deretter kva lag det var. Notatet er det som hindrar neste person i å tune drivaren fordi ruta var problemet.