![Linux:进程内存占缓存量](https://linux22.com/image/678513/Linux%EF%BC%9A%E8%BF%9B%E7%A8%8B%E5%86%85%E5%AD%98%E5%8D%A0%E7%BC%93%E5%AD%98%E9%87%8F.png)
我们的 ubuntu 服务器上有一个非常奇怪的内存使用情况。一个进程(从 sphinxsearch 搜索)分配了几乎所有可用内存,其 VSize、RSS 和 SHR 几乎相等(约 18GB)。但真正让我惊讶的是,该命令free
将大部分内存视为“缓存” - 我一直认为这是“内核拥有的”,也就是说 - 不绑定到特定进程。此外,同时它被标记为“共享”,尽管没有其他进程具有如此高的内存使用率。
因此,free -h显示:
root@st3:/proc/31633# free -h
total used free shared buffers cached
Mem: 23G 22G 649M 18G 62M 18G
-/+ buffers/cache: 4.4G 19G
Swap: 0B 0B 0B
但是对于 searchd 过程我们有:
VmPeak: 20451512 kB
VmSize: 20413352 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 20325488 kB
VmRSS: 20287332 kB
VmData: 1344768 kB
VmStk: 136 kB
VmExe: 4268 kB
VmLib: 16204 kB
VmPTE: 39924 kB
VmSwap: 0 kB
所以我真的不明白这里的实际用途是什么——似乎大多数内存仅用于缓存,所以这不应该是一个问题,另一方面,我们已经遇到了几个简单分叉的“无法分配内存”故障,所以这就是我试图理解它的原因。
如果你想要更多,这是该机器的完整 meminfo, 和这是该searchd
进程的完整内存映射列表。
看看最后一个,我看到了很多:
7f7c905b7000-7f7c90713000 rw-s 00000000 00:05 226801755 /dev/zero (deleted)
7f7c90713000-7f7c91fff000 rw-s 00000000 00:05 225400928 /dev/zero (deleted)
7f7c92055000-7f7c921c7000 rw-s 00000000 00:05 226767567 /dev/zero (deleted)
7f7c921da000-7f7c92338000 rw-s 00000000 00:05 226774289 /dev/zero (deleted)
...所以我只能猜测这可能是一个要点,searchd 正在做一些巧妙的技巧来保留内存,但同时又在需要时为系统提供内存。也许它不能完全按照预期工作。但这只是我的猜测,我可能完全错了。
答案1
“缓存”条目正在计算标记为“共享”的页面数。给定的映射被标记为共享。
内核在内部看不到设置了共享标志的内存和仅仅被操作系统捕获并存储在缓存中的文件的区别(缓存中的所有文件实际上都是共享映射)。
这由 /dev/zero 支持这一事实无关紧要。它们共享的原因几乎肯定是因为需要向修改数据的所有子进程提供相同的内存数据。
从语义角度来看,它的行为就像正常分配的内存(或匿名内存),因为实际上没有可用的文件可以将页面逐出到(/dev/zero 实际上不是一个可以保存的文件),并且如果页面未被使用,则会被移动到交换区。
因此 - 令人困惑的是 - 数据被视为“缓存”,但实际上被视为匿名支持的内存。
您可以在 meminfo 中看到这种情况:
root@st3:/proc/31633# cat /proc/meminfo
MemTotal: 24690512 kB
...
Cached: 19504260 kB
...
Active(anon): 3734376 kB
Inactive(anon): 18973184 kB
Active(file): 227128 kB
Inactive(file): 365828 kB
...
Mapped: 19237684 kB
Shmem: 18985464 kB
...
如果您也使用 IPC 共享内存,也会发生同样的行为。
'file' 实际上是文件支持的内容,而 'anon' 则是没有文件支持的内容——就像您的映射一样。