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