易企秀可以做网站吗,如何做企业网站加v,网站风格评价,重庆建设工程安全网Linux used内存到底去哪里了呢#xff1f;阅读文章之前请先思考这么个问题我ps aux看到的RSS内存只有不到30M#xff0c;但是free看到内存却已经使用了7,8G了#xff0c;已经开始swap了#xff0c;请问ps aux的实际物理内存统计是不是漏了哪些内存没算#xff1f;我有什么… Linux used内存到底去哪里了呢阅读文章之前请先思考这么个问题我ps aux看到的RSS内存只有不到30M但是free看到内存却已经使用了7,8G了已经开始swap了请问ps aux的实际物理内存统计是不是漏了哪些内存没算我有什么办法确定free中used的内存都去哪儿了呢这个问题不止一个同学遇到过了内存的计算总是一个迷糊账。我们今天来把它算个清楚下!通常我们是这样看内存的剩余情况的$free -m total used free shared buffers cachedMem: 48262 7913 40349 0 14 267-/ buffers/cache: 7631 40631Swap: 2047 336 1711那么这个信息是如何解读的呢以下这个图解释的挺清楚的img上面的情况下我们总的内存有48262M用掉了7913M。其中buffercache总共14267281M, 由于这种类型的内存是可以回收的虽然我们用掉了7913M但是实际上我们如果实在需要的话这部分buffer/cache内存是可以放出来的。我们来演示下$ sudo sysctl vm.drop_caches3vm.drop_caches 3$ free -m total used free shared buffers cachedMem: 48262 7676 40586 0 3 41-/ buffers/cache: 7631 40631Swap: 2047 336 1711我们把buffer/cache大部分都清除干净了只用了44M所以我们这次used的空间是7676M。到现在我们比较清楚几个概念1. 总的内存多少2. buffer/cache内存可以释放的。3. used的内存的概率。即使是这样我们还是要继续追查下used的空间(7637M)到底用到哪里去了这里首先我们来介绍下nmon这个工具它对内存的使用显示比较直观。img使用的内存的去向我们很自然的就想到操作系统系统上的各种进程需要消耗各种内存我们透过top工具来看下img通常我们会看进程的RES这一项这项到底是什么意思呢这个数字从哪里出来的呢通过strace对top和nmon的追踪和结合源码我们确定这个值是从/proc/PID/statm的第二个字段读取出来的。那这个字段什么意思呢man proc或者http://www.kernel.org/doc/man-pages/online/pages/man5/proc.5.html 会详细的解释/proc/下的文件的具体意思我们摘抄下/proc/[pid]/statmProvides information about memory usage, measured in pages. Thecolumns are:size total program size(same as VmSize in /proc/[pid]/status)resident resident set size(same as VmRSS in /proc/[pid]/status)share shared pages (from shared mappings)text text (code)lib library (unused in Linux 2.6)data data stackdt dirty pages (unused in Linux 2.6)resident set size 也就是每个进程用了具体的多少页的内存。由于linux系统采用的是虚拟内存进程的代码库堆和栈使用的内存都会消耗内存但是申请出来的内存只要没真正touch过是不算的因为没有真正为之分配物理页面。我们实际进程使用的物理页面应该用resident set size来算的遍历所有的进程就可以知道所有的所有的进程使用的内存。我们来实验下RSS的使用情况$ cat RSS.sh#/bin/bash for PROC in ls /proc/|grep ^[0-9]do if [ -f /proc/$PROC/statm ]; then TEPcat /proc/$PROC/statm | awk {print ($2)} RSSexpr $RSS $TEP fidoneRSSexpr $RSS \* 4echo $RSSKB$ ./RSS.sh 7024692KB从数字来看我们的进程使用了大概7024M内存距离7637M还有几百M内存哪里去了哪里去了猫吃掉了我们再回头来仔细看下nmon的内存统计表。img那个该死的slab是什么呢那个PageTables又是什么呢简单的说内核为了高性能每个需要重复使用的对象都会有个池这个slab池会cache大量常用的对象所以会消耗大量的内存。运行命令$ slabtop我们可以看到img从图我们可以看出各种对象的大小和数目遗憾的是没有告诉我们slab消耗了多少内存。我们自己来算下好了$ echo cat /proc/slabinfo |awk BEGIN{sum0;}{sumsum$3*$4;}END{print sum/1024/1024} MB904.256 MB好吧把每个对象的数目*大小再累加我们就得到了总的内存消耗量:904M那么PageTables呢我们万能的内核组的同学现身了伯瑜:你还没有计算page tables的大小还有struct page也有一定的大小(每个页一个,64bytes)如果是2.6.32的话每个页还有一个page_cgroup(32bytes)也就是说内存大小的2.3%(96/4096)会被内核固定使用的含黛:struct page是系统boot的时候就会根据内存大小算出来分配出去的18内核是1.56%左右32内核由于cgroup的原因会在2.3%好吧知道是干嘛的啦管理这些物理页面的硬开销那么具体是多少呢$ echo grep PageTables /proc/meminfo | awk {print $2} KB58052 KB好吧小结下内存的去向主要有3个\1. 进程消耗。\2. slab消耗3.pagetable消耗。我把三种消耗汇总下和free出的结果比对下,这个脚本的各种计算项仲同学帮忙搞定的:$ cat cm.sh#/bin/bashfor PROC in ls /proc/|grep ^[0-9]do if [ -f /proc/$PROC/statm ]; then TEPcat /proc/$PROC/statm | awk {print ($2)} RSSexpr $RSS $TEP fidoneRSSexpr $RSS \* 4PageTablegrep PageTables /proc/meminfo | awk {print $2}SlabInfocat /proc/slabinfo |awk BEGIN{sum0;}{sumsum$3*$4;}END{print sum/1024/1024}echo $RSSKB, $PageTableKB, $SlabInfoMBprintf rsspagetableslabinfo%sMB\n echo $RSS/1024 $PageTable/1024 $SlabInfo|bcfree -m$ ./cm.sh7003756KB, 59272KB, 904.334MBrsspagetableslabinfo7800.334MB total used free shared buffers cachedMem: 48262 8050 40211 0 17 404-/ buffers/cache: 7629 40633Swap: 2047 336 1711free报告说7629 我们的cm脚本报告说7800.3M 我们的CM多报了171M。damn,这又怎么回事呢我们重新校对下我们的计算。我们和nmon来比对下slab和pagetable的值是吻合的。那最大的问题可能在进程的消耗计算上。resident resident set size 包括我们使用的各种库和so等共享的模块在前面的计算中我们重复计算了。$ pmap pgrep bash...22923: -bash0000000000400000 848K r-x-- /bin/bash00000000006d3000 40K rw--- /bin/bash00000000006dd000 20K rw--- [ anon ]00000000008dc000 36K rw--- /bin/bash00000000013c8000 592K rw--- [ anon ]000000335c400000 116K r-x-- /lib64/libtinfo.so.5.7...0000003ec5220000 4K rw--- /lib64/ld-2.12.so0000003ec5221000 4K rw--- [ anon ]0000003ec5800000 1628K r-x-- /lib64/libc-2.12.so...0000003ec5b9c000 20K rw--- [ anon ]00007f331b910000 96836K r---- /usr/lib/locale/locale-archive00007f33217a1000 48K r-x-- /lib64/libnss_files-2.12.so...00007f33219af000 12K rw--- [ anon ]00007f33219bf000 8K rw--- [ anon ]00007f33219c1000 28K r--s- /usr/lib64/gconv/gconv-modules.cache00007f33219c8000 4K rw--- [ anon ]00007fff5e553000 84K rw--- [ stack ]00007fff5e5e4000 4K r-x-- [ anon ]ffffffffff600000 4K r-x-- [ anon ] total 108720K多出的171M正是共享库重复计算的部分。但是由于每个进程共享的东西都不一样我们也没法知道每个进程是如何共享的没法做到准确的区分。总结内存方面的概念很多需要深入挖掘作者Yu Feng 链接http://blog.yufeng.info/archives/245
