Kleine query's werken, grote mislukken: welke packetgrootte is het?
SQL Server-driverpakketten, MySQL-berichtlimieten en de MTU van een IP-pad zijn verschillende eenheden. Een grootteafhankelijke fout maakt ze niet uitwisselbaar.
Kleine query's komen terug, grote blijven hangen of vallen weg, en de eerste gedachte is dat er iets mis is met de packetgrootte. Die gedachte klopt meestal en is bijna altijd op de verkeerde laag gericht. Drie instellingen delen het woord packet en meten drie losstaande dingen: de transportverpakking van een databasedriver, de berichtlimiet van een databaseserver en de maximale transmissie-eenheid van het IP-pad. Eén ervan aanpassen om een symptoom van een andere op te lossen, is hoe een probleem van vijf minuten een week tunen wordt. De volgorde hieronder is degene die me de minste tijd heeft gekost.
Drie lagen, één gedeeld woord
Elke rij hieronder is een andere eenheid met een andere eigenaar, en over geen ervan kan vanuit de andere worden geredeneerd. Een databasemessage kan zich over veel TCP-segmenten en veel IP-pakketten uitstrekken, dus een grotere toegestane grootte verbreedt het pad niet, en een driverinstelling verlagen is niet dezelfde handeling als de MTU van een interface wijzigen. Het woord staat in drie verschillende configuratiebestanden, daarom levert een zoekopdracht ernaar drie losstaande antwoorden op. Lees eerst de fouttekst en beslis dan welk bestand je opent.
| Setting or observation | Unit it describes |
|---|---|
| SQL Server client network packet setting | The provider's transport packaging for that connection |
| MySQL communication packet limit | A database message, such as one statement, row or replication event |
| IP path MTU | The largest IP packet the path carries without fragmentation handling |
Schrijf op bij welke laag de mislukte bewerking hoort voordat je een configuratiebestand opent. De fouttekst zegt het meestal, en juist dat deel slaan mensen over.
Identificeer de provider voordat je de instelling wijzigt
Noteer voor SQL Server de toepassing, de naam van de driver of provider, de versie en de effectieve verbindingsconfiguratie. Een diagnosescript en een desktopapplicatie kunnen dezelfde server via verschillende providers bereiken, dus een instelling die de ene helpt, bewijst niets over de andere. De standaardwaarden van providers verschillen, en een vergelijkbaar genoemd veld in de verbindingsreeks is geen bewijs dat elke provider het op dezelfde manier interpreteert.
Vervang een onderhouden driver niet door een oude alleen omdat een oude workaround de syntaxis ervan gebruikte. De huidige documentatie ontraadt nieuwe ontwikkeling tegen die oudere componenten, en hun beperkingen erven is een slechte ruil voor één instelling.
Berichtafwijzing is geen padstilstand
In MySQL 8.4 beschrijft de documentatie van het communicatiepakket dat een te grote statement, rij of binair-loggebeurtenis wordt afgewezen tegen de geldende limiet, en zowel de client- als de serverlimiet kunnen meespelen. Dat is een afwijzing op de databaselaag, niet de bewering dat het netwerk een gigantisch IP-pakket moet dragen. Lees de werkelijke fout en de vorm van het problematische bericht: een groot resultaat van veel kleine rijen is een ander geval dan één enorme rij, en ze falen anders.
MariaDB-installaties hebben de gedocumenteerde limieten en diagnostiek van hun eigen versie nodig. MySQL-standaardwaarden naar MariaDB kopiëren is gokken met extra stappen.
Hoe padbewijs er echt uitziet
Een padgrootteprobleem heeft zijn eigen vingerafdruk: een reproduceerbare grootteafhankelijke transportfout langs een bepaalde route en adresfamilie, met de overhead van de tunnel in het spel en ontdekkingsfeedback die zich gedraagt zoals het pad toestaat. Een timeout alleen onderscheidt het niet van een trage query, een driverbug of een limiet aan de serverkant, en een timeout behandelen als bewijs van MTU-problemen stuurt je met vertrouwen naar de verkeerde laag.
Als je het pad test, houd dan bestemming, account en werklast vast zodat de enige variabele de grootte is die je onderzoekt. Een test waarin drie dingen veranderden, vertelt je niets over welke ertoe deed.
Wijzig één gedocumenteerde variabele en leg die daarna vast
Houd bestemming, account, provider en werklast constant, leg de oorspronkelijke waarde vast, pas één ondersteunde wijziging toe en leg het resultaat vast. Een kleinere instelling waardoor één test slaagt, is nuttig bewijs over die geteste stack; het is geen universeel optimum en het stelt niet vast wat de oorspronkelijke fout veroorzaakte. Dat zijn verschillende beweringen, en alleen de eerste wordt door één experiment ondersteund.
Los de geïdentificeerde limiet op in zijn eigen laag en noteer daarna welke laag het was. De notitie is wat de volgende persoon ervan weerhoudt de driver te tunen omdat het pad het probleem was.