We run a file-heavy logging service inside our corporate . We noticed that the memory usage spikes rapidly, but the container doesn't always get terminated by the OOM killer. How does the Linux kernel handle page cache memory allocations when calculating strict cgroup limits?
3 answers
The Linux kernel includes both anonymous memory (active application heap) and page cache (cached file data read from disk) when calculating cgroup limits for a . However, page cache is considered reclaimable memory. If your container begins approaching its configured memory limit primarily due to intense disk I/O caching, the kernel will automatically reclaim or drop those page cache blocks before resorting to an OOM kill. The container is only killed if the active anonymous memory itself completely breaches the limit ceiling.
Knowing that the kernel automatically reclaims page cache memory is reassuring, but does high page cache utilization within a pod degrade overall application read performance during the window when the kernel is aggressively dropping those cache files?
The container runtime differentiates between essential active process data and temporary file caches, protecting your pods from unnecessary resource termination.
That distinction is incredibly important, Alice. Understanding how the underlying operating system interacts with cgroup layers prevents a lot of unnecessary engineering panic during heavy file operations.
Yes, it can cause a notable I/O performance penalty. When the kernel drops those cache pages to stay under your limit, subsequent read actions must hit the physical disk again, resulting in increased latency for your application.