Linux 内存报告差异
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/5463800/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Linux memory reporting discrepancy
提问by Zoltan Olah
I'm getting a memory usage discrepancy between meminfo and ps. Free is reporting much less free memory than what processes are apparently using according to ps.
我在 meminfo 和 ps 之间发现内存使用差异。Free 报告的可用内存比根据 ps 明显使用的进程少得多。
According to free, I have only 3188mb free:
根据免费,我只有 3188mb 免费:
free -m
total used free shared buffers cached
Mem: 15360 13273 2086 0 79 1022
-/+ buffers/cache: 12171 3188
Swap: 0 0 0
I try to track down where the memory is going using ps (snipped below non 0 RSS values):
我尝试使用 ps 追踪内存的去向(剪下非 0 RSS 值):
ps -A --sort -rss -o comm,pmem,rss
COMMAND %MEM RSS
mysqld 13.1 2062272
java 6.2 978072
ruby 0.7 114248
ruby 0.7 114144
squid 0.1 30716
ruby 0.0 11868
apache2 0.0 10132
apache2 0.0 9092
apache2 0.0 8504
PassengerHelper 0.0 5784
sshd 0.0 3008
apache2 0.0 2420
apache2 0.0 2228
bash 0.0 2120
sshd 0.0 1708
rsyslogd 0.0 1164
PassengerLoggin 0.0 880
ps 0.0 844
dbus-daemon 0.0 736
sshd 0.0 736
ntpd 0.0 664
squid 0.0 584
cron 0.0 532
ntpd 0.0 512
exim4 0.0 504
nrpe 0.0 496
PassengerWatchd 0.0 416
dhclient3 0.0 344
mysqld_safe 0.0 316
unlinkd 0.0 284
logger 0.0 252
init 0.0 200
getty 0.0 120
However, this doesn't make sense as adding up the RSS column leads to a total memory usage of only around 3287mbthat should leave almost 12gbfree!
但是,这没有意义,因为将 RSS 列相加导致总内存使用量仅为3287mb左右,应该会留下近12gb 的空闲空间!
I'm using kernel 2.6.16.33-xenU #2 SMP x86_64 on Amazon AWS.
我在 Amazon AWS 上使用内核 2.6.16.33-xenU #2 SMP x86_64。
Where is my memory going? Can anyone shed some light on how to track this down?
我的记忆去哪儿了?任何人都可以阐明如何追踪这一点吗?
采纳答案by caf
Check the usage of the Slab cache (Slab:
, SReclaimable:
and SUnreclaim:
in /proc/meminfo
). This is a cache of in-kernel data structures, and is separate from the page cache reported by free
.
检查 Slab 缓存(Slab:
、SReclaimable:
和SUnreclaim:
in /proc/meminfo
)的使用情况。这是内核数据结构的缓存,与free
.
If the slab cache is resposible for a large portion of your "missing memory", check /proc/slabinfo
to see where it's gone. If it's dentries or inodes, you can use sync ; echo 2 > /proc/sys/vm/drop_caches
to get rid of them.
如果slab缓存对你“丢失的内存”的很大一部分负责,请检查/proc/slabinfo
它在哪里。如果是 dentries 或 inode,则可以使用sync ; echo 2 > /proc/sys/vm/drop_caches
来摆脱它们。
You can also use the slabtop
tool to show the current usage of the Slab cache in a friendly format. c
will sort the list by current cache size.
您还可以使用该slabtop
工具以友好的格式显示 Slab 缓存的当前使用情况。 c
将按当前缓存大小对列表进行排序。
回答by uesp
You cannot just add up the RSS or VSZ columns to get the amount of memory used. Unfortunately, memory usage on Linux is much more complicated than that. For a more thorough description see Understanding memory usage on Linux, which explains how shared libraries are shared between processes, but double-counted by tools like ps
.
您不能仅将 RSS 或 VSZ 列相加来获得使用的内存量。不幸的是,Linux 上的内存使用比这复杂得多。有关更详尽的描述,请参阅了解 Linux 上的内存使用情况,其中解释了共享库如何在进程之间共享,但被ps
.
I don't know offhand how free computes the numbers it displays but if you need more details you can always dig up its source code.
我不知道如何免费计算它显示的数字,但如果您需要更多详细信息,您可以随时挖掘其源代码。
回答by Zan Lynx
I believe that you are missing the shared memory values. I don't think ps
reports the shared RAM as part of the RSS field. Compare with the top
RES field to see.
我相信您缺少共享内存值。我不认为ps
将共享 RAM 报告为 RSS 字段的一部分。与top
RES字段进行比较以查看。
Of course if you do add in the shared RAM, how much do you add? Because it is shared the same RAM may show up credited to many different processes.
当然,如果你添加共享内存,你添加多少?因为它是共享的,所以相同的 RAM 可能会出现在许多不同的进程中。
You can try to solve that problem by creative parsing of the /proc/[pid]/smaps files.
您可以尝试通过创造性地解析 /proc/[pid]/smaps 文件来解决该问题。
But still, that only gets you part of the way. Some memory pages are shared but accounted as resident. These pages get shared after a fork()
call. They can become unshared at any time but until they are they don't count toward total used system RAM. The proc smaps file doesn't show these either.
但是,这只会让你成功。一些内存页面是共享的,但被视为常驻。这些页面在fork()
通话后共享。它们可以随时变为非共享状态,但在它们变为非共享状态之前,它们不计入已使用的系统 RAM 总量。proc smaps 文件也不显示这些。