Små forespørgsler returnerer, store hænger eller droppes, og den første tanke er, at noget er galt med pakkestørrelsen. Den tanke er som regel rigtig og næsten altid rettet mod det forkerte lag. Tre indstillinger deler ordet pakke og måler tre uafhængige ting: en databasedrivers transportindpakning, en databaseservers meddelelsesgrænse og IP-rutens maksimale transmissionsenhed. At justere én for at rette et symptom skabt af en anden er måden, hvorpå et problem på fem minutter bliver en uges tuning. Rækkefølgen nedenfor er den, der har kostet mig mindst tid.

Tre lag, et fælles ord

Hver række nedenfor er en anden enhed med en anden ejer, og ingen af dem kan ræsonneres ud fra de andre. En databasemeddelelse kan strække sig over mange TCP-segmenter og mange IP-pakker, så en større tilladt størrelse udvider ikke ruten, og at sænke en driverindstilling er ikke den samme handling som at ændre en interface-MTU. Ordet optræder i tre forskellige konfigurationsfiler, og derfor giver en søgning på det tre uafhængige svar. Læs fejlteksten først, og beslut derefter, hvilken fil du skal åbne.

Setting or observationUnit it describes
SQL Server client network packet settingThe provider's transport packaging for that connection
MySQL communication packet limitA database message, such as one statement, row or replication event
IP path MTUThe largest IP packet the path carries without fragmentation handling

Skriv ned, hvilket lag den fejlende handling hører til, før du åbner en konfigurationsfil. Fejlteksten siger det som regel, og fejlteksten er netop den del, folk springer over.

Identificér udbyderen, før du ændrer dens indstilling

For SQL Server skal du registrere programmet, driver- eller udbydernavnet, versionen og den effektive forbindelseskonfiguration. Et diagnostikscript og et skrivebordsprogram kan nå den samme server gennem forskellige udbydere, så en indstilling, der hjælper den ene, beviser intet om den anden. Udbydernes standarder er forskellige, og et lignende navngivet felt i forbindelsesstrengen er ikke bevis for, at hver udbyder fortolker det ens.

Udskift ikke en vedligeholdt driver med en ældre, blot fordi en gammel løsning brugte dens syntaks. Den aktuelle dokumentation fraråder ny udvikling mod de ældre komponenter, og at arve deres begrænsninger er en dårlig handel for én indstilling.

Afvisning af en meddelelse er ikke en fastlåst rute

I MySQL 8.4 beskriver dokumentationen for kommunikationspakker, at en for stor sætning, række eller binærloghændelse afvises mod den gældende grænse, og både klient- og servergrænsen kan have betydning. Det er en afvisning på databaselaget, ikke en erklæring om, at netværket skal bære en gigantisk IP-pakke. Læs den faktiske fejl og formen på den problematiske meddelelse: et stort resultat af mange små rækker er et andet tilfælde end én enorm række, og de fejler forskelligt.

MariaDB-installationer har brug for deres egen versions dokumenterede grænser og diagnostik. At kopiere MySQL-standarder over på MariaDB er gætteri med ekstra trin.

Sådan ser rutebevis i virkeligheden ud

Et rutestørrelsesproblem har sit eget fingeraftryk: en reproducerbar størrelsesafhængig transportfejl langs en bestemt rute og adressefamilie, med tunnelens overhead i spil og opdagelsesfeedback, der opfører sig, som ruten tillader. En timeout alene adskiller det ikke fra en langsom forespørgsel, en driverfejl eller en servergrænse, og at behandle en timeout som bevis for MTU-problemer sender dig med selvtillid til det forkerte lag.

Hvis du tester ruten, så hold destination, konto og arbejdsbyrde fast, så den eneste variabel er den størrelse, du undersøger. En test, hvor tre ting ændrede sig, fortæller dig intet om, hvilken der betød noget.

Ændr én dokumenteret variabel, og registrér den derefter

Hold destination, konto, udbyder og arbejdsbyrde konstante, registrér den oprindelige værdi, anvend én understøttet ændring, og registrér resultatet. En mindre indstilling, der får én test til at lykkes, er nyttigt bevis om den testede stak; den er ikke et universelt optimum og fastslår ikke, hvad der forårsagede den oprindelige fejl. Det er forskellige påstande, og kun den første understøttes af et enkelt eksperiment.

Løs den identificerede grænse på dens eget lag, og notér derefter, hvilket lag det var. Noten er det, der forhindrer den næste person i at tune driveren, fordi ruten var problemet.

Relaterede artikler