Stoppade en applikation som fyllde minnet med 41 MB i sekunden — uppmätt 111 GB komprimerade sidor på en maskin med 36 GB — genom att begränsa varje händelseström, prenumerera per händelsetyp och sätta en hastighetsbudget på loggningen, vilket tog ned 610 996 loggrader till 1 411.

Situation. Appen fyllde minnet tills operativsystemet dödade den. Den registrerade incidenten nådde 111 GB komprimerade minnessidor på en maskin med 36 GB, med en ökning på ungefär 41 MB i sekunden, och loggfilen för en enda kort session innehöll 610 996 rader. En maskin i det tillståndet är inte långsam, den är oanvändbar — processen dödas först när swappningen redan har fått allt annat på skrivbordet att sluta svara.

Uppgift. Tillväxten måste hittas i stället för att gissas, och varje obegränsad väg måste få en gräns, eftersom en begränsad kö bredvid tre obegränsade inte är någon lösning.

Handling. Det fanns tre orsaker som multiplicerade varandra, och multiplikationen är förklaringen till att det gick så fort. Händelseströmmen från kärnan konsumerades utan någon gräns, så händelserna kom in snabbare än gränssnittet hann tillämpa dem, och eftersläpningen behölls i stället för att kastas. Varje prenumerant tog emot varje händelse och filtrerade i efterhand, så kostnaden för en händelse multiplicerades med antalet lyssnare, och varje lyssnares filtrering allokerade minne. Och loggningen saknade budget, så varje händelse gav upphov till loggrader — vilket är den term som förstärker allt, eftersom loggvolymen var proportionell mot omfattningen av det som gick fel. Lösningen tog itu med alla tre: begränsade buffertar med en uttrycklig policy för vad som händer när de blir fulla, prenumeration per händelsetyp så att en lyssnare bara väcks för de händelser den vill ha, och en taktbudget för loggningen som slår ihop upprepningar i stället för att skriva var och en. Ett regressionstest driver en hög händelsetakt och verifierar att minnestaket håller, så gränsen är en egenskap hos bygget snarare än en kommentar.

Resultat. Minnesanvändningen ligger platt under ihållande last, och samma session som gav 610 996 loggrader ger nu 1 411. Det ärliga förbehållet är att taktbudgeten för loggningen kastar information: när något går fel snabbt är spåren av det numera medvetet ofullständiga, och det är en avvägning som gjorts med öppna ögon mot alternativet, en maskin som stannar.