K8S 中 Prometheus 监控内存 Limit 的说明

阿里云的 Prometheus 使用 container_memory_working_set_bytes 来进行告警设置
container_memory_working_set_bytes 是容器真实使用的内存量，也是资源限制limit时的重启判断依据

# 进入容器 pod 内部，获取到的pod内存数据：
cat /sys/fs/cgroup/memory/memory.stat 

# 重要说明
total_cache：        表示当前pod缓存内存量
total_rss：          表示当前应用进程实际使用内存量
total_inactive_anon：表示匿名不活跃内存使用量
total_active_anon：  表示匿名活跃内存使用量，jvm堆内存使用量会被计算在此处
total_inactive_file：表示不活跃文件内存使用量
total_active_file：  表示活跃文件内存使用量


# 容器当前使用内存量：   container_memory_usage_bytes = total_cache + total_rss
# 容器当前使用缓存内存： total_cache = total_inactive_file + total_active_file

container_memory_working_set_bytes = container_memory_usage_bytes - total_inactive_file
                                   = (total_cache + total_rss) - total_inactive_file
                                   = ((total_inactive_file + total_active_file) + total_rss) - total_inactive_file
# 转化公式后可得：
container_memory_working_set_bytes = total_active_file + total_rss

# 其中 total_rss为应用真实使用内存量，正常情况下该指标数值稳定，那为何该指标会持续上升而且一直维持很高呢？其实问题就出现在total_active_file上；

Linux系统为了提高文件读取速率，会划分出来一部分缓存内存，即cache内存，这部分内存有个特点，当应用需要进行io操作时，会向Linux申请一部分内存，这部分内存归属于操作系统，当应用io操作完毕后，操作系统不会立即回收；
当操作系统认为系统剩余内存不足时（判断依据未深究），才会主动回收这部分内存。

这部分内存属于操作系统，jvm无任何管理权限，故也不会把这部分内存计算到JVM中。container_memory_working_set_bytes指标升高一部分是应用本身JVM内存使用量增加，另一部分就是进行了io操作，total_active_file升高；该指标异常一般都是应用进行了io相关操作。

参考

https://help.aliyun.com/zh/arms/prometheus-monitoring/why-are-memory-values-obtained-in-containers-inconsistent#:~:text=container_memory_working_set_bytes %3D container_memory_usage_bytes,- total_inactive_file（未激活的匿名缓存页） container_memory_working_set_bytes是容器真实使用的内存量，也是资源限制limit时的重启判断依据

https://blog.csdn.net/qq_34468174/article/details/130643948