Malgrandaj demandoj funkcias, grandaj malsukcesas: kiu paketa grandeco ĝi estas?

Malgrandaj demandoj revenas, grandaj pendas aŭ falas, kaj la unua instinkto estas, ke io malĝustas pri la paketa grandeco. Tiu instinkto kutime pravas kaj preskaŭ ĉiam celas la malĝustan tavolon. Tri agordoj dividas la vorton pakaĵo kaj mezuras tri malsamrilatajn aferojn: la transportan pakumadon de datumbaza legilo, la mesaĝan limon de datumbaza servilo kaj la maksimuman sendunuon de la IP-vojo. Agordi unu por ripari simptomon kaŭzitan de alia estas la maniero, kiel kvin-minuta problemo fariĝas semajno da agordado. La ordo sube estas tiu, kiu kostis al mi la malplej da tempo.

Tri tavoloj, unu komuna vorto

Ĉiu vico sube estas malsama unuo kun malsama posedanto, kaj pri neniu eblas rezonadi el la aliaj. Datumbaza mesaĝo povas etendiĝi trans multaj TCP-segmentoj kaj multaj IP-pakaĵoj, do pliigi ĝian permesitan grandecon ne plivastigas la vojon, kaj malpliigi legilan agordon ne estas la sama operacio kiel ŝanĝi la MTU de interfaco. La vorto aperas en tri malsamaj agordaj dosieroj, do serĉo pri ĝi redonas tri malsamrilatajn respondojn. Legu unue la erartekston, poste decidu kiun dosieron malfermi.

Notu, al kiu tavolo la fiaskinta operacio apartenas, antaŭ ol malfermi agordan dosieron. La erarteksto kutime diras tion, kaj la erarteksto estas la parto, kiun homoj preterlasas.

Identigu la provizanton antaŭ ol ŝanĝi ĝian agordon

Por SQL Server, notu la aplikaĵon, la nomon de la legilo aŭ provizanto, la version kaj la efektivan konekto-agordon. Diagnoza skripto kaj surtabla aplikaĵo povas atingi la saman servilon per malsamaj provizantoj, do agordo, kiu helpas unu, pruvas nenion pri la alia. Provizantaj defaŭltoj malsamas, kaj simile nomata kampo de konekta ĉeno ne estas pruvo, ke ĉiu provizanto interpretas ĝin same.

Ne anstataŭigu prizorgatan legilon per malnova nur ĉar malnova solvo uzis ĝian sintakson. Aktuala dokumentaro malinstigas novan disvolvon kontraŭ tiuj pli malnovaj komponantoj, kaj heredi iliajn limigojn estas malbona interŝanĝo por unu agordo.

Mesaĝa malakcepto ne estas voja halto

En MySQL 8.4, la dokumentaro pri komunikadaj pakaĵoj priskribas malakcepton de tro granda ordono, vico aŭ binara protokola evento kontraŭ la aplikebla limo, kaj povas gravi kaj klienta kaj servila limoj. Tio estas malakcepto ĉe la datumbaza tavolo, ne aserto, ke la reto devas porti gigantan IP-pakaĵon. Legu la faktan eraron kaj la formon de la problema mesaĝo: granda rezulto el multaj malgrandaj vicoj estas malsama kazo ol unu enorma vico, kaj ili fiaskas malsame.

MariaDB-instalaĵoj bezonas la dokumentitajn limojn kaj diagnozon de sia propra versio. Kopii MySQL-defaŭltojn al MariaDB estas diveni kun pliaj paŝoj.

Kiel voja pruvo vere aspektas

Voja grandecproblemo havas sian propran fingrospuron: ripetebla grandec-dependa transporta fiasko laŭ difinita itinero kaj adresa familio, kun la superkosto de la tunelo en ludo kaj malkovra retrokuplo kondutanta kiel la vojo permesas. Nur tempolimo ne distingas ĝin de malrapida demando, legila eraro aŭ servila limo, kaj trakti tempolimon kiel pruvon de MTU-problemoj sendas vin kun konfido al la malĝusta tavolo.

Se vi tamen testas la vojon, tenu la celon, konton kaj laborŝarĝon fiksaj, por ke la sola variablo estu la grandeco, kiun vi sondas. Testo, en kiu ŝanĝiĝis tri aferoj, diras al vi nenion pri tio, kiu gravis.

Ŝanĝu unu dokumentitan variablon, poste registru ĝin

Tenu la celon, konton, provizanton kaj laborŝarĝon konstantaj, registru la originan valoron, apliku unu subtenatan ŝanĝon kaj registru la rezulton. Pli malgranda agordo, kiu igas unu teston sukcesi, estas utila pruvo pri tiu testita stako; ĝi ne estas universala optimumo kaj ne establas, kio kaŭzis la originan fiaskon. Tiuj estas malsamaj asertoj, kaj nur la unua estas subtenata de unu eksperimento.

Solvu la identigitan limon ĉe ĝia propra tavolo, poste notu, kiu tavolo ĝi estis. La noto estas tio, kio malhelpas la sekvan personon agordi la legilon ĉar la vojo estis la problemo.