k8s pod 内存 所以判断container_memory_working_set_bytes会比container_memory_usage_bytes更为准确
container_memory_working_set_bytes = container_memory_usage_bytes - total_inactive_anon - total_inactive_file
memory used =container_memory_usage_bytes - cache
cache = total_inactive_file + total_active_file
PS：kubelet比较container_memory_working_set_bytes和container_spec_memory_limit_bytes来决定oom container
total_inactive_anon、total_inactive_file为非活动内存，可以被交换到磁盘 cache 缓存存储器存储当前保存在内存中的磁盘数据，所以判断container_memory_working_set_bytes会比container_memory_usage_bytes更为准确
这里workingSet的计算是先比较memory.memory.usage_in_bytes的大小是不是比memory.stats里面的total_inactive_file小，如果没有，就减去total_inactive_file的值，最后为workingSet的值，这部分的值我们可以认为是linux占用的hot(正在使用)内存值(容器同理)。
4.2 kubectl top pod 内存怎么计算，包含 pause容器 吗
每次启动 pod，都会有一个 pause 容器，既然是容器就一定有资源消耗（一般在 2-3M 的内存），cgroup 文件中，业务容器和 pause 容器都在同一个 pod的文件夹下。
但 cadvisor 在查询 pod 的内存使用量时，是先获取了 pod 下的container列表，再逐个获取container的内存占用，不过这里的 container 列表并没有包含 pause，因此最终 top pod 的结果也不包含 pause 容器
pod 的内存使用量计算
kubectl top pod 得到的内存使用量，并不是cadvisor 中的container_memory_usage_bytes，而是container_memory_working_set_bytes，计算方式为：
-
container_memory_usage_bytes == container_memory_rss + container_memory_cache + kernel memory
-
container_memory_working_set_bytes = container_memory_usage_bytes - total_inactive_file（未激活的匿名缓存页）
container_memory_working_set_bytes是容器真实使用的内存量，也是limit限制时的 oom 判断依据
cadvisor 中的 container_memory_usage_bytes对应 cgroup 中的 memory.usage_in_bytes文件，但container_memory_working_set_bytes并没有具体的文件，他的计算逻辑在 cadvisor 的代码中，如下：
https://segmentfault.com/a/1190000021402244?utm_source=tag-newest
https://blog.csdn.net/palet/article/details/82889493
https://zhuanlan.zhihu.com/p/96597715
https://www.ibm.com/support/pages/kubectl-top-pods-and-docker-stats-show-different-memory-statistics
kubectl top 12.5G
container_memory_working_set_bytes = container_memory_usage_bytes - total_inactive_anon - total_inactive_file rss = total_inactive_anon + total_active_anon cache = total_inactive_file + total_active_file
kubelet比较container_memory_working_set_bytes和container_spec_memory_limit_bytes来决定oom container
container_memory_usage_bytes和container_memory_working_set_bytes之间是没有固定的换算公式的，它们衡量内存使用的角度不同。但是可以通过一些技巧来对它们进行近似转换。
一种常见的方法是利用两个指标之间的比例关系，并结合容器内存的其他指标来计算它们的近似值。具体而言，可以记录容器在一个时间周期内的内存使用情况（例如1分钟），并计算平均值、最大值和最小值等统计数据。然后，可以使用以下公式来近似计算两个指标之间的关系：
container_memory_working_set_bytes ≈ container_memory_usage_bytes - page_cache
其中，page_cache表示页缓存所占用的内存大小，通常可以通过查看 /proc/meminfo 文件中的内容来获取。因此，可以通过减去缓存占用的内存大小来计算出正在使用的内存大小，从而近似计算出container_memory_working_set_bytes的值。
需要注意的是，这种计算方式仅为近似值，可能存在一定的误差。因此，建议在实际使用时结合其他指标和实际场景进行判断和分析。
2023/6/19 10:36:05
是的，你提到的公式可以用于计算container_memory_working_set_bytes和container_memory_usage_bytes之间的近似换算关系。
具体而言，container_memory_working_set_bytes表示正在使用的内存大小，即由操作系统分配给容器并正在活跃使用的内存。而container_memory_usage_bytes则表示容器当前使用的实际内存大小，包括容器镜像的只读部分和容器运行时的可读写部分。
在这个公式中，total_inactive_anon和total_inactive_file分别表示匿名页和文件页的非活跃内存大小。它们是已经被操作系统回收但尚未被重新分配的内存。因此，将它们从实际内存使用中减去，可以得到近似正在使用的内存大小。
需要注意的是，这个公式仅为近似计算值，并不能完全准确反映容器内存使用情况。在实际使用中，建议结合其他指标和实际场景进行判断和分析。
