Як пояснити паузу в збиранні сміття англійською мовою

Паузи збирання сміття (GC) є однією з тих проблем продуктивності, які легко помітити — піки затримки, процеси, що не відповідають — але важче пояснити чітко, тому що причина невидима в коді програми. Цей посібник містить англійські слова, які описують поведінку GC, незалежно від того, чи ви зневаджуєте службу JVM, процес Node. js або програму Go.

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

** Пауза зупинки світу ** — період під час збирання сміття, коли всі потоки програми призупинено, щоб збірник міг безпечно відновити пам’ ять. “Пік затримки p99 точно збігається з паузами зупинки світу в журналах GC — кожна пауза більше 200 мс з’являється як відповідний пік затримки.”

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

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

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

** Повний GC / незначний GC ** — повний GC сканує і відновлює всю купу і зазвичай є повільним; незначний GC відновлює лише об’ єкти з коротким життям у меншій області і зазвичай є швидким.

• “Незначні GC часто, але швидко, зазвичай менше 5 мс. Проблема полягає в повних GCs — вони рідкісні, але кожен з них призупиняє службу на більше ніж секунду.»*

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

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

• «Ми бачимо піки затримки, які корелюють з часом паузи GC в журналах»
• «Це виглядає як тиск пам’яті, а не витік — використання зростає під навантаженням і падає назад після цього»
• «Повна пауза GC є в’язким місцем тут, а не незначні колекції.»
• «Ми налаштували розмір купу і алгоритм GC, який зменшив час паузи з 800ms до 150ms.»
• «Використання хепа не повертається до бази після падіння трафіку, що вказує на витік»

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

Опис симптому перед причиною, в звіті про інцидент: “Між 10:14 і 10:22, затримка p99 зросла до 4,2 секунди на службі оплати. Журнали GC для того ж вікна показують три повних паузи GC в середньому 1,8 секунди кожна, що відповідає більшості спостережуваної затримки.”

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

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

Пояснення виправлення в PR або після смерті:

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

Пояснення для нетехнічного користувача:

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

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

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

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

1. Напишіть речення, яке пов’ язує пік затримки з даними про паузу GC у звіті про подію.
2. Напишіть два речення, у яких буде показано відмінність між тиском пам’ яті і витоком пам’ яті за допомогою одного і того ж симптому (зростання використання стека).
3. Поясніть паузу GC нетехнічним учасникам у двох реченнях, не використовуючи термін «збір сміття»

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

Розуміння * garbage collection * (GC) пауз є критичним для будь-якого розробника, який працює з такими мовами, як Java, C# або Go. Але просто сказати “GC призупинено” недостатньо. У професійних умовах, особливо під час перегляду коду, обговорення продуктивності або при повідомленні про інциденти, вам потрібно ясно сформулювати проблему - і це часто вимагає використання певного англійського словника. Розглянемо сценарій: ви виявили уповільнення у вашій програмі після розгортання нової можливості. Під час перегляду коду старший інженер коментує ваше повідомлення про затвердження: « Здається, це спричиняє часті паузи GC. Чи можеш ти розкритись?»

Ключовим тут є визнання * технічної * природи проблеми і її обґрунтування відповідною мовою. Уникайте нечітких термінів, таких як « це повільно » або « програма поводиться дивно ». Замість цього зосередьтеся на описі вимірюваного впливу паузи. Ви можете відповісти, сказавши: «Я спостерігав значне збільшення часу паузи GC, особливо близько 50-70 мілісекунд під час пікової навантаження. Використання стека різко зросло, оскільки створюються нові об’ єкти, що збільшує потребу у обробці даних у зв’ язку з новою можливістю. Зауважте, що у тексті уважно використовуються такі фрази, як « значне збільшення », « час паузи GC », а також кількісне визначення тривалості (50- 70 мілісекунд). Ці терміни демонструють технічне розуміння і дозволяють фокусувати обговорення на потенційних рішеннях.

Інша ситуація виникає при поясненні проблеми більшій команді через Slack. Ви отримаєте повідомлення з запитанням « Що відбувається з програмою? ». Хорошою відповіддю на це запитання буде « Ми спостерігаємо підвищений тиск на пам’ ять через збільшення кількості об’ єктів, які слід виділити. Збірник сміття запускається частіше, щоб відновити невживану пам’ ять, що призводить до пауз, які впливають на швидкість відповіді. Зараз ми досліджуємо потенційні оптимізації, такі як зменшення створення об’ єктів або налаштування параметрів GC. Знову ж таки, використання фраз на кшталт « підвищений тиск пам’ яті », « розподіл об’ єктів », « збирання сміття працює частіше » і « впливає на швидкість реагування » забезпечує чітку картину проблеми, не заважаючи читачеві технічним жаргоном.

Нарешті, під час написання опису Запиту на завантаження, у якому буде описано запропоновані зміни для поліпшення швидкодії, вам слід бути так само точним. Замість того, щоб сказати: «Я збираюся виправити паузи GC», розгляньте: «Ця PR реалізує декілька змін, розроблених для зменшення тиску пам’яті і скорочення часу паузи GC. Зокрема, ми оптимізуємо об’ єднання об’ єктів для часто створюваних структур даних і налаштовуємо параметри збирання сміття JVM, щоб надавати перевагу коротшим, менш інтрузивним паузам. » Використання таких фраз, як « зменшити тиск на пам’ ять » і « надавати перевагу коротшим, менш інтрузивним паузам », демонструє активний підхід і підкреслює очікуваний результат ваших змін. Сфокусування на впливі - як зміна зменшить проблему - є надзвичайно важливим в професійному спілкуванні.