Малі запити працюють, великі зриваються: який розмір пакета?
Пакети драйвера SQL Server, ліміти повідомлень MySQL і MTU IP-шляху — різні одиниці. Збій, що залежить від розміру, не робить їх взаємозамінними.
Малі запити повертаються, великі зависають або обриваються, і перша думка — щось не так із розміром пакета. Ця думка зазвичай правильна й майже завжди спрямована на невірний рівень. Три налаштування ділять слово пакет і вимірюють три незв'язані речі: транспортне пакування драйвера бази даних, ліміт повідомлень сервера бази даних і максимальну одиницю передачі IP-шляху. Налаштовувати одне, щоб виправити симптом, спричинений іншим, — це шлях, яким проблема на п'ять хвилин перетворюється на тиждень налаштування. Порядок нижче — той, що коштував мені найменше часу.
Три рівні, одне спільне слово
Кожен рядок нижче — різна одиниця з різним власником, і про жодну не можна міркувати з інших. Повідомлення бази даних може охоплювати багато сегментів TCP і багато IP-пакетів, тому збільшення дозволеного розміру не розширює шлях, а зменшення налаштування драйвера — не та сама операція, що зміна MTU інтерфейсу. Слово трапляється в трьох різних файлах конфігурації, тому пошук за ним повертає три незв'язані відповіді. Спершу прочитайте текст помилки, потім вирішуйте, який файл відкрити.
| 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 |
Запишіть, до якого рівня належить невдала операція, перш ніж відкрити файл конфігурації. Текст помилки зазвичай це каже, і саме цю частину люди пропускають.
Визначте постачальника, перш ніж змінювати його налаштування
Для SQL Server запишіть застосунок, назву драйвера чи постачальника, версію та чинну конфігурацію з'єднання. Діагностичний скрипт і настільний застосунок можуть досягати того самого сервера через різних постачальників, тому налаштування, що допомагає одному, нічого не доводить про іншого. Типові значення постачальників різняться, і схоже назване поле рядка підключення не є доказом, що кожен постачальник тлумачить його однаково.
Не замінюйте підтримуваний драйвер на старий лише тому, що старе обхідне рішення використовувало його синтаксис. Поточна документація не заохочує нову розробку на тих старіших компонентах, а успадкування їхніх обмежень — погана угода заради одного налаштування.
Відхилення повідомлення — не зупинка шляху
У MySQL 8.4 документація щодо пакета зв'язку описує відхилення завеликого оператора, рядка або події бінарного журналу щодо застосовної межі, і можуть мати значення як клієнтська, так і серверна межі. Це відхилення на рівні бази даних, а не твердження, що мережа мусить нести гігантський IP-пакет. Прочитайте фактичну помилку й форму проблемного повідомлення: великий результат із багатьох малих рядків — інший випадок, ніж один величезний рядок, і вони зриваються по-різному.
Інсталяціям MariaDB потрібні задокументовані межі та діагностика власної версії. Копіювати типові значення MySQL на MariaDB — це вгадування з додатковими кроками.
Як насправді виглядають докази шляху
Проблема розміру шляху має власний відбиток: відтворюваний збій транспорту, що залежить від розміру, на певному маршруті й родині адрес, із задіяними накладними витратами тунелю та зворотним зв'язком виявлення, що поводиться так, як дозволяє шлях. Самий лише тайм-аут не відрізняє її від повільного запиту, помилки драйвера чи серверної межі, і ставлення до тайм-ауту як до доказу проблем MTU впевнено надсилає вас не на той рівень.
Якщо ви перевіряєте шлях, тримайте пункт призначення, обліковий запис і навантаження фіксованими, щоб єдиною змінною був розмір, який ви досліджуєте. Тест, у якому змінилися три речі, нічого не каже про те, що саме мало значення.
Змініть одну задокументовану змінну, потім запишіть її
Тримайте пункт призначення, обліковий запис, постачальника й навантаження сталими, запишіть вихідне значення, застосуйте одну підтримувану зміну та запишіть результат. Менше налаштування, завдяки якому один тест проходить, є корисним доказом про цей перевірений стек; воно не є універсальним оптимумом і не встановлює, що спричинило початковий збій. Це різні твердження, і лише перше підкріплене одним експериментом.
Вирішіть виявлену межу на її власному рівні, потім занотуйте, який це був рівень. Саме нотатка не дає наступній людині налаштовувати драйвер, бо проблемою був шлях.