# En app, der åd 41 MB i sekundet, standset

Har stoppet en applikation i at fylde hukommelsen med 41 MB i sekundet — 111 GB komprimerede sider målt på en maskine med 36 GB — ved at begrænse hver hændelsesstrøm, abonnere efter hændelsestype og lægge et ratebudget på logning, hvilket bragte 610.996 loglinjer ned på 1.411.

september 2026

**Situation.** Programmet fyldte hukommelsen, indtil styresystemet slog det ihjel. Den registrerede hændelse nåede op på 111 GB komprimerede sider på en maskine med 36 GB, stigende med omkring 41 MB i sekundet, og logfilen for en enkelt kort session rummede 610.996 linjer. En maskine i den tilstand er ikke langsom, den er ubrugelig — nedlukningen kommer, efter at swap allerede har fået alt andet på skrivebordet til at holde op med at svare.

**Opgave.** Væksten skulle findes og ikke gættes på, og hver ubegrænset vej skulle gives en grænse, for én afgrænset kø ved siden af tre uafgrænsede er ikke en rettelse.

**Handling.** Der var tre årsager, der gangede sig op med hinanden, og det er grunden til, at det gik så hurtigt. Hændelsesstrømmen fra kernen blev forbrugt uden nogen grænse, så hændelser ankom hurtigere, end grænsefladen kunne anvende dem, og efterslæbet blev gemt i stedet for kasseret. Hver abonnent modtog hver hændelse og filtrerede bagefter, så omkostningen ved én hændelse blev ganget med antallet af lyttere, og hver lytters filtrering allokerede. Og logningen havde intet budget, så hver hændelse gav loglinjer — og det er det led, der forstærker resten, for logningens omfang voksede i takt med omfanget af det, der gik galt. Rettelsen tog fat på alle tre: afgrænsede buffere med en udtrykkelig politik for, hvad der sker, når de er fulde, abonnement efter hændelsestype, så en lytter kun vækkes af de hændelser, den vil have, og et hastighedsbudget for logningen, der slår gentagelser sammen i stedet for at skrive hver enkelt. En regressionstest driver en høj hændelseshastighed og efterprøver, at hukommelsesloftet holder, så grænsen er en egenskab ved buildet og ikke en kommentar.

**Resultat.** Hukommelsen holder sig flad under vedvarende belastning, og den samme session, der frembragte 610.996 loglinjer, frembringer 1.411. Den ærlige bemærkning er, at hastighedsbudgettet for logningen kasserer information: når noget går galt hurtigt nu, er optegnelsen over det bevidst ufuldstændig, og det er en afvejning, der er truffet med åbne øjne, over for alternativet: en maskine, der går i stå.

---

- Rolle: macOS‑applikationsudvikler
- Kategorier: [Løsningsarkitektur](https://engineer.company/da/categories/solution-architecture/), [Frontend‑udvikling](https://engineer.company/da/categories/frontend/), [Driftssikkerhed & backup](https://engineer.company/da/categories/reliability/), [Overvågning & observerbarhed](https://engineer.company/da/categories/observability/), [Optimering af ydeevne](https://engineer.company/da/categories/performance/), [Test & QA](https://engineer.company/da/categories/testing/)
- Ydelser: [Platform- & løsningsarkitektur](https://engineer.company/da/services/platform-architecture/), [Frontend‑udvikling](https://engineer.company/da/services/frontend-development/), [Site reliability & overvågning](https://engineer.company/da/services/site-reliability/)

<https://engineer.company/da/portfolio/an-app-that-ate-41-mb-a-second-stopped/>
