Gumagana ang maliliit na query, nabibigo ang malalaki: aling laki ng packet?
Ang mga packet ng driver ng SQL Server, mga limitasyon ng mensahe ng MySQL at ang MTU ng isang IP path ay magkaibang unit. Hindi ginagawang mapagpapalit ng isang pagkabigong umaasa sa laki ang mga ito.
Bumabalik ang maliliit na query, ang malalaki ay nakabitin o bumabagsak, at ang unang instinct ay may mali sa laki ng packet. Karaniwang tama ang instinct na iyon at halos palaging nakatutok sa maling layer. Tatlong setting ang naghahati sa salitang packet at sumusukat ng tatlong walang kaugnayang bagay: ang transport packaging ng isang database driver, ang limitasyon ng mensahe ng isang database server at ang maximum transmission unit ng IP path. Ang pag-adjust ng isa para ayusin ang sintomas na dulot ng isa pa ang paraan kung paano nagiging isang linggong tuning ang limang minutong problema. Ang pagkakasunod-sunod sa ibaba ang pinakakaunting oras na ginugol ko.
Tatlong layer, isang karaniwang salita
Ang bawat hilera sa ibaba ay ibang unit na may ibang may-ari, at wala sa kanila ang maaaring hanguan ng pangangatwiran mula sa iba. Ang isang mensahe ng database ay maaaring sumaklaw sa maraming TCP segment at maraming IP packet, kaya ang pagpapalaki ng pinapayagang laki ay hindi nagpapalawak ng path, at ang pagbaba ng setting ng driver ay hindi kaparehong operasyon ng pagbabago ng MTU ng isang interface. Lumilitaw ang salita sa tatlong magkaibang config file, kaya ang paghahanap dito ay nagbabalik ng tatlong walang kaugnayang sagot. Basahin muna ang teksto ng error, pagkatapos ay magpasya kung aling file ang bubuksan.
| 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 |
Isulat kung saang layer nabibilang ang nabigong operasyon bago magbukas ng config file. Karaniwang sinasabi ito ng teksto ng error, at ang teksto ng error ang bahaging nilalaktawan ng mga tao.
Kilalanin ang provider bago baguhin ang setting nito
Para sa SQL Server, itala ang application, ang pangalan ng driver o provider, ang bersyon at ang epektibong configuration ng koneksyon. Ang diagnostic script at desktop application ay maaaring makarating sa parehong server sa pamamagitan ng magkaibang provider, kaya ang setting na tumutulong sa isa ay walang pinapatunayan tungkol sa isa. Magkaiba ang default ng mga provider, at ang isang field ng connection string na may katulad na pangalan ay hindi ebidensya na lahat ng provider ay pareho itong binibigyang-kahulugan.
Huwag palitan ang isang inaalagaang driver ng mas luma dahil lang ginamit ng lumang workaround ang syntax nito. Hindi hinihikayat ng kasalukuyang dokumentasyon ang bagong development laban sa mga lumang component na iyon, at ang pagmamana ng kanilang mga limitasyon ay masamang palitan para sa isang setting.
Ang pagtanggi ng mensahe ay hindi pagtigil ng path
Sa MySQL 8.4, inilalarawan ng dokumentasyon ng communication packet na ang isang masyadong malaking statement, hilera o binary-log event ay tinatanggihan laban sa naaangkop na limitasyon, at ang limitasyon ng client at server ay parehong maaaring mahalaga. Iyon ay pagtanggi sa layer ng database, hindi isang pahayag na kailangang magdala ang network ng napakalaking IP packet. Basahin ang aktwal na error at ang hugis ng problemang mensahe: ang malaking resulta na binubuo ng maraming maliliit na hilera ay ibang kaso kaysa sa isang napakalaking hilera, at magkaiba ang paraan ng pagbigo nila.
Ang mga installation ng MariaDB ay nangangailangan ng dokumentadong limitasyon at diagnostic ng sarili nitong bersyon. Ang pagkopya ng default ng MySQL sa MariaDB ay paghula na may dagdag na hakbang.
Paano talaga nagmumukha ang ebidensya ng path
Ang problema sa laki ng path ay may sariling fingerprint: isang nauulit na pagkabigong transport na umaasa sa laki sa isang partikular na ruta at address family, kung saan kasama ang overhead ng tunnel at kumikilos ang discovery feedback ayon sa pinapayagan ng path. Ang timeout lamang ay hindi ito nakikilala mula sa mabagal na query, bug ng driver o limitasyon sa panig ng server, at ang pagtrato sa timeout bilang ebidensya ng mga problema sa MTU ay nagpapadala sa iyo nang may kumpiyansa sa maling layer.
Kung susubukan mo ang path, panatilihing fixed ang destinasyon, account at workload para ang tanging variable ay ang laki na sinusuri mo. Ang pagsusulit kung saan tatlong bagay ang nagbago ay walang sinasabi kung alin ang mahalaga.
Baguhin ang isang dokumentadong variable, pagkatapos ay itala ito
Panatilihing pare-pareho ang destinasyon, account, provider at workload, itala ang orihinal na halaga, ilapat ang isang sinusuportahang pagbabago at itala ang resulta. Ang mas maliit na setting na nagpapapasa sa isang pagsusulit ay kapaki-pakinabang na ebidensya tungkol sa nasubok na stack na iyon; hindi ito pangkalahatang optimum at hindi nito itinatag kung ano ang naging sanhi ng orihinal na pagkabigo. Magkaibang pahayag ang mga ito, at tanging ang una ang sinusuportahan ng isang eksperimento.
Lutasin ang natukoy na limitasyon sa sarili nitong layer, pagkatapos ay itala kung aling layer iyon. Ang talaan ang pumipigil sa susunod na tao na i-tune ang driver dahil ang path ang problema.