我在我们的ubuntu服务器上有非常奇怪的内存使用情况。 一个进程（从sphinxsearchsearch）分配几乎所有可用的内存，其VSize，RSS和SHR几乎相等（约18GB）。 但令我惊讶的是，命令free将这些内存中的大部分视为“caching” – 我一直以为是“内核拥有”，即不受特定进程的约束。 此外，同时它被标记为“共享”，虽然没有其他进程具有如此高的内存使用率。
所以，免费-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
所以我不能真正理解这里的真正用法 – 看起来大部分内存只用于caching，所以不应该担心，OTOH我们已经遇到了几个与“无法分配内存”的简单分叉故障，所以这就是为什么我试图理解它。
如果你想要更多， 这里是来自该机器的完整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正在做一些聪明的技巧，以保持记忆，但在同一点，有需要时，系统可用。 也许它没有像预期的那样完全工作。 但这只是我的猜测，我可能在这里完全错了。
“caching”条目将统计标记为“共享”的页面数量。 给定的映射被标记为共享。
内核在内部看到的是用共享标志设置的内存和一个只被操作系统捕获并存储在caching中的文件（caching中的所有文件都是有效的共享映射）没有区别。
这是由/ dev / zero支持的事实是无足轻重的。 他们共享的原因几乎肯定是因为需要将相同的内存数据提供给修改数据的所有subprocess。
从语义angular度来看，它的行为就像通常分配的内存（或匿名内存），因为实际上没有可用的文件可以将页面驱逐出去（/ dev / zero并不是真的可以保存的文件），页面将移动到如果他们没有被使用，交换。
所以 – 令人困惑的是 – 数据帐户被“caching”，但实际上被视为匿名支持的内存。
你可以看到这是你的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共享内存，则会发生相同的行为。
'文件'真的是什么文件支持，'anon'是什么没有得到一个文件支持它 – 就像你的映射。