Ein aktueller Debugging-Fall beleuchtet ein subtiles, aber wirkungsvolles Speicherproblem in Kubernetes: Der Page-Cache des Linux-Kernels kann die Speichernutzung von Containern weit über den tatsächlichen Heap und Off-Heap-Speicher der Anwendung hinaus aufblähen. In diesem Fall verbrauchte ein Spring-Boot-Pod über 4 GB Speicher, während der JVM-Heap plus Off-Heap nur etwa 1 GB betrug. Die Untersuchung ergab, dass der active_file (Page-Cache) die 3 GB an Logdateien cached, die auf einem gemounteten Host-Verzeichnis (/logs) gespeichert waren. Dies ist ein bekanntes Verhalten: Wenn ein Container ein Host-Verzeichnis mountet, cached der Kernel die Dateidaten im Page-Cache, der auf das Speicher-Cgroup-Limit des Containers angerechnet wird. Die Lösung umfasst entweder die Begrenzung des Page-Caches über Memory-Cgroup-Einstellungen, die Verwendung eines tmpfs-Mounts für Logs oder die Konfiguration von Log-Rotation und -Komprimierung, um die gecachte Datenmenge zu reduzieren. Dieser Fall ist eine wertvolle Erinnerung für DevOps- und SRE-Teams, bei der Verwendung von Volume-Mounts in der Produktion nicht nur den Anwendungsspeicher, sondern auch das Kernel-Level-Caching zu überwachen.
Ein Entwickler stellte fest, dass die Speichernutzung eines Spring-Boot-Pods (4 GB+) weit über Heap+Off-Heap (1 GB) hinausging. Der Übeltäter war der Page-Cache des Linux-Kernels, der Logdateien aus einem gemounteten Host-Verzeichnis cached. Dies ist ein häufiges, aber oft übersehenes Problem in K8s-Umgebungen.