Små spørringer virker, store feiler: hvilken pakkestørrelse er det?

Små spørringer kommer tilbake, store henger eller faller ut, og den første tanken er at noe er galt med pakkestørrelsen. Den tanken er som regel riktig og nesten alltid rettet mot feil lag. Tre innstillinger deler ordet pakke og måler tre uavhengige ting: en databasedrivers transportinnpakning, en databaseservers meldingsgrense og IP-rutens maksimale overføringsenhet. Å justere én for å rette et symptom som en annen har skapt, er måten et femminuttersproblem blir en uke med tuning. Rekkefølgen nedenfor er den som har kostet meg minst tid.

Tre lag, ett felles ord

Hver rad nedenfor er en annen enhet med en annen eier, og ingen av dem kan resonneres ut fra de andre. En databasemelding kan strekke seg over mange TCP-segmenter og mange IP-pakker, så å øke den tillatte størrelsen utvider ikke ruten, og å senke en driverinnstilling er ikke samme operasjon som å endre en grensesnitt-MTU. Ordet står i tre forskjellige konfigurasjonsfiler, og derfor gir et søk etter det tre uavhengige svar. Les feilteksten først, og bestem deg deretter for hvilken fil du åpner.

Skriv ned hvilket lag den feilende operasjonen hører til, før du åpner en konfigurasjonsfil. Feilteksten sier det som regel, og feilteksten er nettopp den delen folk hopper over.

Identifiser leverandøren før du endrer innstillingen

For SQL Server, registrer programmet, navnet på driveren eller leverandøren, versjonen og den effektive tilkoblingskonfigurasjonen. Et diagnostikkskript og et skrivebordsprogram kan nå samme server via forskjellige leverandører, så en innstilling som hjelper den ene, beviser ingenting om den andre. Leverandørenes standardverdier er forskjellige, og et lignende navngitt felt i tilkoblingsstrengen er ikke bevis for at hver leverandør tolker det likt.

Ikke bytt ut en vedlikeholdt driver med en eldre bare fordi en gammel løsning brukte syntaksen dens. Gjeldende dokumentasjon fraråder ny utvikling mot de eldre komponentene, og å arve begrensningene deres er en dårlig handel for én innstilling.

Avvisning av en melding er ikke en fastlåst rute

I MySQL 8.4 beskriver dokumentasjonen for kommunikasjonspakken at en for stor setning, rad eller binærlogghendelse avvises mot gjeldende grense, og både klient- og servergrensen kan spille inn. Det er en avvisning på databaselaget, ikke en påstand om at nettverket må bære en gigantisk IP-pakke. Les den faktiske feilen og formen på den problematiske meldingen: et stort resultat av mange små rader er et annet tilfelle enn én enorm rad, og de feiler forskjellig.

MariaDB-installasjoner trenger sine egne versjoners dokumenterte grenser og diagnostikk. Å kopiere MySQL-standarder over på MariaDB er gjetting med ekstra trinn.

Hvordan rutebevis faktisk ser ut

Et rutestørrelsesproblem har sitt eget fingeravtrykk: en reproduserbar størrelsesavhengig transportfeil langs en bestemt rute og adressefamilie, med tunnelens overhead i spill og oppdagelsesfeedback som oppfører seg slik ruten tillater. En timeout alene skiller det ikke fra en treg spørring, en driverfeil eller en servergrense, og å behandle en timeout som bevis for MTU-problemer sender deg med selvtillit til feil lag.

Hvis du tester ruten, hold destinasjon, konto og arbeidsbelastning fast slik at den eneste variabelen er størrelsen du undersøker. En test der tre ting ble endret, forteller deg ingenting om hvilken som betydde noe.

Endre én dokumentert variabel, og registrer den deretter

Hold destinasjon, konto, leverandør og arbeidsbelastning konstant, registrer den opprinnelige verdien, bruk én støttet endring og registrer resultatet. En mindre innstilling som får én test til å lykkes, er nyttig bevis om den testede stakken; den er ikke et universelt optimum og fastslår ikke hva som forårsaket den opprinnelige feilen. Det er forskjellige påstander, og bare den første støttes av ett enkelt eksperiment.

Løs den identifiserte grensen på sitt eget lag, og noter deretter hvilket lag det var. Notatet er det som hindrer neste person i å tune driveren fordi ruten var problemet.