Malé dotazy fungují, velké selhávají: která velikost paketu to je?

Malé dotazy vracejí výsledek, velké visí nebo spadnou, a první instinkt říká, že je něco špatně s velikostí paketu. Ten instinkt bývá správný a téměř vždy míří na špatnou vrstvu. Tři nastavení sdílejí slovo paket a měří tři nesouvisející věci: transportní zabalení ovladače databáze, limit zpráv databázového serveru a maximální přenosovou jednotku IP cesty. Ladit jedno, aby se opravil příznak způsobený jiným, je způsob, jak se z pětiminutového problému stane týden ladění. Pořadí níže je to, které mě stálo nejméně času.

Tři vrstvy, jedno společné slovo

Každý řádek níže je jiná jednotka s jiným vlastníkem a o žádné nelze uvažovat z těch ostatních. Databázová zpráva může pokrývat mnoho TCP segmentů a mnoho IP paketů, takže zvětšení její povolené velikosti nerozšiřuje cestu a zmenšení nastavení ovladače není stejná operace jako změna MTU rozhraní. Slovo se objevuje ve třech různých konfiguračních souborech, a proto jeho hledání vrací tři nesouvisející odpovědi. Nejprve si přečtěte text chyby, potom rozhodněte, který soubor otevřít.

Než otevřete konfigurační soubor, zapište si, do které vrstvy selhávající operace patří. Text chyby to obvykle říká a právě tuto část lidé přeskakují.

Než změníte jeho nastavení, určete poskytovatele

U SQL Serveru si poznamenejte aplikaci, název ovladače nebo poskytovatele, verzi a efektivní konfiguraci připojení. Diagnostický skript a desktopová aplikace se mohou dostat na stejný server přes různé poskytovatele, takže nastavení, které pomůže jednomu, nic nedokazuje o druhém. Výchozí hodnoty poskytovatelů se liší a pole připojovacího řetězce s podobným názvem není důkaz, že ho každý poskytovatel vykládá stejně.

Nevyměňujte udržovaný ovladač za starší jen proto, že staré obejití používalo jeho syntaxi. Současná dokumentace nedoporučuje nový vývoj na těchto starších komponentech a dědit jejich omezení je špatná výměna za jedno nastavení.

Odmítnutí zprávy není zaseknutí cesty

V MySQL 8.4 dokumentace ke komunikačním paketům popisuje odmítnutí příliš velkého příkazu, řádku nebo události binárního logu vůči platnému limitu a mohou záležet oba limity, klientský i serverový. To je odmítnutí na vrstvě databáze, nikoli tvrzení, že síť musí přenést obrovský IP paket. Přečtěte si skutečnou chybu a tvar problematické zprávy: velký výsledek složený z mnoha malých řádků je jiný případ než jeden obrovský řádek a selhávají různě.

Instalace MariaDB potřebují dokumentované limity a diagnostiku vlastní verze. Kopírovat výchozí hodnoty MySQL na MariaDB je hádání s kroky navíc.

Jak důkazy o cestě skutečně vypadají

Problém velikosti cesty má vlastní otisk: opakovatelné transportní selhání závislé na velikosti na určité trase a rodině adres, se zapojenou režií tunelu a zpětnou vazbou objevování chovající se tak, jak cesta dovolí. Samotný timeout jej neodliší od pomalého dotazu, chyby ovladače nebo serverového limitu a považovat timeout za důkaz problémů s MTU vás s jistotou pošle na špatnou vrstvu.

Pokud cestu opravdu testujete, držte cíl, účet a zátěž pevně, aby jedinou proměnnou byla velikost, kterou zkoumáte. Test, ve kterém se změnily tři věci, vám neřekne, která z nich byla důležitá.

Změňte jednu dokumentovanou proměnnou a potom ji zaznamenejte

Držte cíl, účet, poskytovatele a zátěž konstantní, zaznamenejte původní hodnotu, použijte jednu podporovanou změnu a zaznamenejte výsledek. Menší nastavení, díky kterému jeden test projde, je užitečný důkaz o tomto testovaném zásobníku; není univerzálním optimem a neurčuje, co způsobilo původní selhání. To jsou různá tvrzení a jen první z nich podporuje jediný experiment.

Vyřešte zjištěný limit na jeho vlastní vrstvě a potom poznamenejte, která vrstva to byla. Právě poznámka zabrání dalšímu člověku ladit ovladač, protože problémem byla cesta.