Ein Service wird alle paar Tage wegen Speichermangel gekillt. Wie untersuchst du das?

Bestätige zuerst das Muster über die Metriken: stetiges Wachstum deutet auf ein Leck oder einen unbegrenzten Cache, ein steiler Ausschlag auf einen einzelnen Request, der zu viel auf einmal lädt. Nimm ein Heap-Profil vor und nach einer Wachstumsphase und vergleich die gehaltenen Allokationen. Die üblichen Ursachen sind Caches ohne Eviction, wachsende Collections, die an langlebigen Objekten hängen, nicht geschlossene Ressourcen und Endpoints, die ein ganzes Result Set in den Speicher laden.

Die Form des Graphen sagt mir, wo ich suchen muss. Ein langsamer Anstieg über Tage, der ruhige Phasen übersteht, ist ein Leck oder ein Cache ohne Grenze. Ein Sägezahn, der bei bestimmten Requests ausschlägt, heißt, irgendetwas lädt zu viel auf einmal. Für den ersten Fall nehme ich Heap-Profile im Abstand von ein paar Stunden bei ähnlichem Traffic und diffe sie nach gehaltener Größe, dann schaue ich, was die größten Objekte hält. In der Praxis war es meistens etwas Langweiliges: eine Map als Cache ohne Eviction und ohne Maximum, ein Metrik-Label aus einem nutzergelieferten Wert, dessen Kardinalität ewig wuchs, oder Listener, die an einem langlebigen Objekt registriert und nie entfernt wurden. Bei Ausschlägen suche ich nach Endpoints, die eine ganze Tabelle in eine Liste lesen statt zu streamen, oder nach einem Batch-Job, der alle Zeilen lädt, bevor er schreibt. Genau das hatte ich bei einem CSV-Export, der eine Million Zeilen materialisiert hat; seitenweises Streaming hat den Speicher flach gemacht. Danach lege ich einen Alert auf den Speichertrend statt nur auf den Crash, damit ich davon höre, bevor es der Neustart tut.