Спинила застосунок, що наповнював пам'ять зі швидкістю 41 МБ за секунду — зафіксовані 111 ГБ стиснених сторінок на машині з 36 ГБ, — обмеживши кожен потік подій, підписуючись за типом події та поклавши бюджет швидкості на журналювання, що звело 610 996 рядків журналу до 1 411.
Роботу виконано: вересень 2026
41 MB на секунду зростання пам'яті — зупинено
Ситуація. Програма наповнювала пам’ять, доки операційна система її не вбивала. Зафіксований інцидент сягнув 111 ГБ стиснутих сторінок на машині з 36 ГБ, зростаючи приблизно на 41 МБ за секунду, а файл журналу за один короткий сеанс тримав 610 996 рядків. Машина в такому стані не повільна, вона непридатна — вбивство приходить після того, як підкачування вже змусило все інше на робочому столі перестати відповідати.
Завдання. Зростання треба було знайти, а не вгадати, і кожному необмеженому шляху треба було дати межу, бо одна обмежена черга поруч із трьома необмеженими не є виправленням.
Дія. Причин‑множників було три, і саме множення пояснює, чому це відбувалося так швидко. Потік подій із ядра споживався без жодної межі, тож події надходили швидше, ніж інтерфейс міг їх застосувати, і доробок утримувався, а не відкидався. Кожен передплатник отримував кожну подію й фільтрував після цього, тож вартість однієї події множилася на кількість слухачів, і фільтрування кожного слухача виділяло пам’ять. А журналювання було небюджетованим, тож кожна подія породжувала рядки журналу — і це складений доданок, бо обсяг журналювання був пропорційним до обсягу того, що йшло не так. Виправлення взялося за всі три: обмежені буфери з явною політикою того, що стається за їх заповнення, передплата за типом події, тож слухача будять лише для подій, яких він хоче, і бюджет швидкості на журналювання, що згортає повтори, а не пише кожен. Регресійний тест жене високу швидкість подій і стверджує, що стеля пам’яті тримається, тож межа є властивістю збирання, а не коментарем.
Результат. Пам’ять лишається рівною під тривалим навантаженням, і той самий сеанс, що давав 610 996 рядків журналу, дає 1 411. Чесним зауваженням є те, що бюджет швидкості на журналювання відкидає інформацію: коли щось іде не так швидко, запис про це тепер навмисно неповний, і це обмін, зроблений свідомо проти альтернативи, якою є машина, що спиняється.
Читати далі: Написала парсер, який читає справжній C‑заголовок на 7 308 рядків і перевіряє кожне місце виклику, кожну константу переліку й те, що кожен клас‑власник вказівника є final, після того як рукописний заголовок‑заглушка дозволив викликам до трьох вилучених функцій скомпілюватися, злінкуватися й впасти. Або перегляньте повне портфоліо.
Клієнтам ми розповідаємо це як Застосунок, що з'їдав 41 МБ на секунду, зупинено — подивитися разом з іншими кейсами.
Одна частина довшого переліку — і він увесь на цьому сайті.
Кожен запис написано однаково: ситуація, завдання, що ми зробили і що змінилося.