POD 内存利用率和 RSS 与节点的 ps 存在差异

提问者：小点点

POD 内存利用率和 RSS 与节点的 ps 存在差异

我已经在我的K8s集群（1.15版）中部署了metrics-server
我认为这是执行简单内存利用率检查的标准方法

我有一个包含多个进程的POD（为了获取进程，用＜code＞dumb init＜/code＞包装）

我想知道我的POD当前的确切内存使用情况。

输出kube capacity-util--pods：

NODE      NAMESPACE           POD                               CPU REQUESTS   CPU LIMITS   CPU UTIL      MEMORY REQUESTS   MEMORY LIMITS   MEMORY UTIL
sj-k8s1   kube-system         kube-apiserver-sj-k8s1            250m (6%)      0m (0%)      77m (1%)      0Mi (0%)          0Mi (0%)        207Mi (2%)

...
sj-k8s3   salt-provisioning   salt-master-7dcf7cfb6c-l8tth      0m (0%)        0m (0%)      220m (5%)     1536Mi (19%)      3072Mi (39%)    1580Mi (20%)

显示salt-master POD目前使用约1.6Gi，kubeapi使用约200Mi

然而，在sj-k8s3上执行命令ps aux|awk'12美元~ /salt-master/{sum=6美元}END{print sum}'（PS输出的RSS总和）：

即~2Gi，/sys/fs/cgroup/memory/memory.stats的输出：

cache 173740032
rss 1523937280
rss_huge 0
shmem 331776
mapped_file 53248
dirty 4096
writeback 0
pgpgin 34692690
pgpgout 34278218
pgfault 212566509
pgmajfault 6
inactive_anon 331776
active_anon 1523916800
inactive_file 155201536
active_file 18206720
unevictable 0
hierarchical_memory_limit 2147483648
total_cache 173740032
total_rss 1523937280
total_rss_huge 0
total_shmem 331776
total_mapped_file 53248
total_dirty 4096
total_writeback 0
total_pgpgin 34692690
total_pgpgout 34278218
total_pgfault 212566509
total_pgmajfault 6
total_inactive_anon 331776
total_active_anon 1523916800
total_inactive_file 155201536
total_active_file 18206720
total_unevictable 0

这个POD实际上包含两个docker容器，所以RSS的实际总和是：

更大：2.3Gi

在 apiserver 节点上，仅执行 ps aux 显示进程 RSS 为： 447948 /sys/fs/cgroup/memory/memory.stats 的输出：

cache 78499840
rss 391188480
rss_huge 12582912
shmem 0
mapped_file 69423104
dirty 0
writeback 0
pgpgin 111883
pgpgout 1812
pgfault 100603
pgmajfault 624
inactive_anon 0
active_anon 215531520
inactive_file 253870080
active_file 270336
unevictable 0
hierarchical_memory_limit 8361357312
total_cache 78499840
total_rss 391188480
total_rss_huge 12582912
total_shmem 0
total_mapped_file 69423104
total_dirty 0
total_writeback 0
total_pgpgin 111883
total_pgpgout 1812
total_pgfault 100603
total_pgmajfault 624
total_inactive_anon 0
total_active_anon 215531520
total_inactive_file 253870080
total_active_file 270336
total_unevictable 0

有人能解释为什么报告的POD内存利用率与简单的＜code＞ps＜/code＞相差近40%（对于apiserver进程，相差100）吗？

编辑：我已经更新了内存报告值，以包括/sys/fs/cgroup/内存/memory.stat的输出，这似乎对应于库贝-容量
报告的POD利用率正如第一条评论中建议的那样：这是否意味着差异仅是共享内存（由PS报告，而不是由POD指标/cgroup报告）？
差异很大。

共1个答案

匿名用户

ps不反映应用程序使用的实际内存量，而只反映为其保留的内存量。如果页面由多个进程共享或使用一些动态链接的库，则可能会产生很大的误导。

了解 Linux 上的内存使用情况是一篇非常好的文章，描述了 Linux 中的内存使用情况如何工作以及 ps 实际报告的内容。

为什么ps是“错误的”

根据您的看法，ps不会报告进程的实际内存使用情况。它真正要做的是显示如果只有一个进程在运行，每个进程将占用多少实际内存。当然，一台典型的Linux机器在任何给定时间都有几十个进程在运行，这意味着ps报告的VSZ和RSS数字几乎肯定是错误的。

这就是为什么ps不应用于某些内存消耗的详细数据。

ps的替代品将是smem。它报告物理内存使用情况，将共享内存页考虑在内。然后在 USS（唯一集大小）上报告未共享内存。因此，当您想要忽略共享内存时，可以使用 USS。

非共享内存(< code>USS)加上进程的共享内存比例在< code>PSS(比例集大小)中报告。基本上，它添加了< code>USS以及其共享内存的比例除以共享该内存的进程数。

另一方面，< code>RSS(常驻集大小)是每个进程使用的共享内存加上非共享内存的数量。如果任何进程共享内存，这将短报告超过实际使用的内存量。

Linux使用编程中使用的资源管理技术来有效地实现重复或复制操作。这称为写时复制。因此，当您有父进程和子进程时，它们都将显示相同的RSS。使用写时复制linux确保两个进程确实使用相同的内存。