Англійська мова для пояснення інциденту вичерпання бази даних з'єднання

Вичерпання бази даних з’єднань є специфічним, поширеним режимом невдачі - і один, який часто описується як “база даних була повільною”, коли фактичний механізм досить точний: програма використовувала всі доступні з’єднання, а не об’єм бази даних. Цей підручник містить англійською мовою опис цього режиму помилки, що важливо як для пошуку справжнього виправлення, так і для написання постмортного повідомлення, яке витримає перевірку.

Ключовий словник

** Пул з’ єднань ** — фіксоване число з’ єднань з базою даних, які можна використовувати знову і знову, підтримуваних програмою, які використовуються замість відкриття нового з’ єднання для кожного запиту, оскільки налаштування з’ єднання є відносно дорогим.

• « Наш пул з’ єднань налаштовано на максимальну кількість 20 з’ єднань на екземпляр програми. » *

** Вичерпання / насиченість пулу ** — стан, коли всі з’ єднання у пулу використовуються, отже нові запити повинні чекати, поки одне з них звільниться, або зазнаватимуть повної невдачі, якщо першим буде досягнуто часу очікування.

• “Це сталося через вичерпання бази даних — кожне з наших 20 з’ єднань було заблоковано повільним запитом, тому нові запити чекали у черзі на вільне з’ єднання.” *

** Витік з’ єднання ** — помилка, коли з’ єднання було отримано з пулу, але так і не було повернуто, поступово зменшуючи кількість дійсно доступних з’ єднань, навіть якщо налаштований розмір пулу не змінився.

• “Це не було звичайним перевантаженням під навантаженням — це був витік з’ єднання. Шлях коду, який викликався винятком перед викликом connection.release() означав, що з’єднання зникали з пулу назавжди, а не поверталися після використання. ”*

** Тайм- аут (тайм- аут отримання з’ єднання) ** — максимальний час очікування запиту на з’ єднання, яке стане доступним, перед тим, як запит буде відхилено і завершиться невдачею.

• “Запити зазнавали невдачі з повідомленням « timeout connection acquisition after 5000ms » — це не помилка бази даних, а програма, яка перестала чекати на вільне з’ єднання зі свого власного пулу.” *

** Черга ** — поведінка запитів, які чекають у черзі на доступність ресурсу (наприклад, з’ єднання з базою даних), що спричиняє збільшення затримки навіть до того, як запит зазнає повної невдачі. “Перед тим, як запиту почали відмовляти, ми бачили, як затримка постійно зростала — це так зване чергування, коли запити чекають з’ єднання все довше і довше, оскільки пул стає зайнятим.”

Звичайні фрази

• Це виснаження бази даних, а не повільна база даних — сама база даних була здоровою
• «Запити мають тайм-аут очікування з’єднання, а не тайм-аут самого запиту.»
• «Це виглядає як витік з’єднання, а не просто насичення, пов’язане з навантаженням»
• «Затримка піднялася до того, як запити почали зазнавати невдач, що збігається з чергою»
• Ми збільшили розмір басейну як зменшення, але витік є справжньою причиною. “

Приклади висловлювань

Відмінність між витоком бази даних і повільною роботою бази даних у звіті про подію, що є найважливішим відмінним моментом:

• “Корінна причина: пул з’ єднань програми (максимум 20 з’ єднань) був повністю переповнений набором повільних аналітичних запитів, кожен з яких утримував з’ єднання протягом 30+ секунд. Це відрізняється від проблеми з продуктивністю бази даних — Postgres сам показав нормальну продуктивність процесора і вводу/виводу протягом усього інциденту. Вузлове місце було повністю в тому, скільки з’єднань нашій програмі було дозволено мати одночасно.”*

Опис повідомлення про помилку і правильна приписка його джерела:

• “Помилки, які бачили користувачі, були « затримкою під час отримання з’ єднання з пулу » — ця помилка походить з нашої бібліотеки пулу з’ єднань, а не з Postgres, що є важливою відмінністю, оскільки вона вказує на дослідження налаштування пулу і циклу з’ єднання, а не налаштування бази даних.” *

Визначення витоку у порівнянні з очікуваним насиченням під навантаженням:

• “Якби це було просто насичення, пов’ язане з навантаженням, ми очікували б, що використання бази даних повернеться до нормального стану, як тільки зменшиться обсяг трафіку. Замість цього, активні з’єднання продовжували підніматися навіть після того, як трафік повернувся до базисного, що є підписом протікання - з’єднання перевіряються і ніколи не повертаються, а не просто зайняті. ”*

Пояснення виправлення і чому воно стосується справжньої кореневої причини:

• “Протікання було в логіці повторення — якщо запит зазнав невдачі і шлях повторення був викинут перед запуском блоку finally, з’ єднання не було відновлено. Ми виправили логіку випуску, щоб працювати в finally блоку безумовно, і додали метрику відстеження активних проти неактивних з’єднань, щоб ми могли ловити цей шаблон швидше наступного разу. “*

Професійні поради

• Завжди відрізняйте ** виснаження пулу ** від ** повільності бази даних ** у постмортемі — вони виглядають схоже ззовні (запити повільні або не виконуються), але мають абсолютно різні кореневі причини і виправлення.
• Визначте, чи походить повідомлення про помилку з вашої ** бібліотеки пулів з’ єднань ** або з ** самої бази даних ** — ця одна подробиця, зазвичай, негайно вказує на правильний напрямок дослідження.
• Відрізняти ** витік ** (з’ єднання ніколи не поверталися) від звичайного ** насичення під навантаженням ** (з’ єднання зайняті, але зрештою повертаються) за допомогою перевірки, чи відновлюється кількість активних з’ єднань після зниження навантаження — витік не відновлюватиметься, але насиченість відновлюватиметься.
• Описувати ** чергу ** як окремий симптом на ранній стадії перед повними збоями — збільшення затримки без помилок є корисним раннім попередженням, яке варто вказати у спостереженні і звітах.
• Коли ви пропонуєте виправлення, відрізняйте зменшення (збільшення розміру бази даних) від справжнього виправлення кореневої причини (виправлення витоку) — рецензенти повинні знати, яке з них ви пропонуєте і чому обидва можуть бути потрібні.

Практичні вправи

1. Напишіть речення, яке відрізняє виснаження бази даних від повільності бази даних для звіту про помилку.
2. Напишіть речення, у якому буде вказано, чи є шаблон симптому ознакою витоку, чи звичайного насичення, пов’ язаного з навантаженням.
3. Напишіть речення, яке відрізняє зменшення шкоди від виправлення кореневої причини інциденту з пулом з’ єднань.

Науковий напрямок: вивчення мови

Звітування про інцидент рідко є простим. Часто, основна проблема - вичерпаний басейн з’єднань - має бути повідомлена з точністю, особливо при роботі з колегами, не знайомими з основними технічними деталями. Недостатньо просто сказати « з’ єднання переповнені ». Ясність і конкретне формулювання є ключем до ефективного усунення несправностей і запобігання їх повторенню у майбутньому. Добре складений опис показує, що ви розумієте проблему і веде тих, хто допомагає вам, до її вирішення. Розгляньте, як ви пояснили б цю ситуацію комусь, хто не регулярно стежить за показниками продуктивності бази даних.

Одним з ключових елементів є уникнення жаргону, який не є універсально зрозумілим. Терміни, такі як «насиченість», можуть бути нечіткими; замість цього зосередьтеся на спостережуваних ефектах. Замість того, щоб сказати « купа з’ єднань досягла насиченості », спробуйте використати щось більш описове, наприклад: « Ми спостерігали значне збільшення затримки запиту під час годин пік, що корелює з високим рівнем використання (95%) з’ єднань з базою даних. Це свідчить про те, що пул з’ єднань не зміг задовольнити попит. » Також важливо розуміти різницю між таймом очікування і вичерпанням. * Тайм- аут * — це заздалегідь визначене обмеження; * вичерпання * — це стан, коли запити зазнають невдачі через відсутність наявних з’ єднань.

Крім того, під час документування проблеми у коментарі перегляду коду або під час написання опису запиту на звантаження, використовуйте активний тон. Замість пасивного повідомлення « Пул з’ єднань вичерпано », розгляньте такі фрази: « Щоб зменшити потенційні проблеми з продуктивністю, я реалізував механізм черги для запитів на базу даних, щоб запобігти вичерпання пула з’ єднань під час пікового навантаження. Це забезпечить ефективну обробку всіх запитів і зменшить ризик перевищення часу очікування. Це демонструє ініціативність і передбачуване вирішення проблем — цінні якості у будь- якій технічній комунікації.

Нарешті, пам’ ятайте, що документація повинна бути доступною навіть для тих, хто не знайомий з вашою конкретною базою коду. Використання чіткої структури речення, активного голосу і коротких описів значно поліпшить розуміння і прискорить час розв’ язання. Сфокусуйтеся на * впливі * проблеми - що було вплине і на як довго - поряд з точним описом технічної причини.