文字链接：《》
文章地址：
除非标注，所有博文均为原创，转载请加文字链接注明来源
Recommendationlinux系统监视器中的内存和共享内存分别指什么呀?-红联Linux系统门户
您的位置：
&& 查看内容 － － －
linux系统监视器中的内存和共享内存分别指什么呀?
lovemmlzy发布于
&&字号: &&&&(网友评论&3&条)&
linux系统监视器中的内存和共享内存分别指什么呀?
作者: iuears&发布日期:
内存是你的实际内存
共享内存指在多处理器的计算机系统中，可以被不同中央处理器（CPU）访问的大容量内存。由于多个CPU需要快速访问存储器，这样就要对存储器进行缓存（Cache）。任何一个缓存的数据被更新后，由于其他处理器也可能要存取，共享内存就需要立即更新，否则不同的处理器可能用到不同的数据
共享内存 (shared memory)是 Unix下的多进程之间的通信方法 ,这种方法通常用于一个程序的多进程间通信，实际上多个程序间也可以通过共享内存来传递信息。
作者: lovemmlzy&发布日期:
多谢这位兄台，在下受教了
作者: liwenwei1980&发布日期:
纠正一下，之前网友的回答是望文生义，根据汉语名称进行解释。实际上，只要看看“系统监视器”的帮助，就知道不是这样的，下面是帮助中关于进程使用的“内存”与“共享内存”的解释，直译过来的大概意思是（不准确，本人并非计算机专业，名词翻译可能有不妥之处）：共享内存是每个进程使用的一些“库程序”所占有的内存，可能被其它使用这些“库程序”的进程所使用。
This is the amount of real physical memory that this process is using by itself, and approximates the Private memory usage of the process.
It does not include any swapped out memory, nor the code size of its shared libraries.
This is often the most useful figure to judge the memory use of a program.
Shared Mem
This is approximately the amount of real physical memory that this process's shared libraries are using. This memory is shared among all processes that use this library
共有评论数 3/每页显示数 10
发表评论，与各位同人交流。回复请点击下方的我要评论按钮(游客可回复)，要发表贴子请点击
Linux教程下载？“”（请点击），Linux教程免费下载。
求助Linux问题？论坛有39版块，覆盖所有Linux技术层面。前往“”
　|　　|　　|　　|　　|　　|　　|　　|　　|　　|　　|　　|　
&2017 红联 Powered by SupSitelinux中的常用内存问题检测工具是什么？_电脑网络问题_土巴兔装修问答
linux中的常用内存问题检测工具是什么？
报价结果查看方式：
微信人工报价
报价结果将发送到您的手机
深圳装修顾问-馨馨
4年行业经验，24h可咨询
10秒闪电通过好友
您的装修预算约
*装修管家将回电您，免费提供装修咨询服务
*因材料品牌及工程量不同，具体报价以量房实测为准
深圳装修顾问 -馨馨
（四年装修行业经验）
微信扫一扫
linux中的常用内存问题检测工具是什么？
提问者：严彬郁|
时间： 16:08:21
已有3条答案
回答数：8034|被采纳数：10
志存高远_9250
所有回答：&8034
top命令能显示系统内存。
目前常用的Linux下查看内容的专用工具是free命令。
下面是对内存查看free命令输出内容的解释：
total：总计物理内存的大小。
used：已使用多大。
free：可用有多少。
Shared：多个进程共享的内存总额。
Buffers/cached：磁盘缓存的大小。
回答数：14275|被采纳数：1
所有回答：&14275
Gperftools(Google &&Performance &&Tools)为一组工具集，包括了thread-caching &&malloc(TCMalloc)和CPU &&profiler等组件。TCMalloc和Glibc中的ptmalloc相比更快，并可以有效减少多线程之间的竞争，因为它会为每个线程单独分配线程本地的Cache。这里先只关注它的内存相关组件。通过tcmalloc可以做heap-checking和heap-profiling。
回答数：6374|被采纳数：1
所有回答：&6374
首先，比较常见的内存问题有下面几种： &&
· &&memory &&overrun：写内存越界 &&
· &&double &&free：同一块内存释放两次 &&
· &&use &&after &&free：内存释放后使用 &&
· &&wild &&free：释放内存的参数为非法值 &&
· &&access &&uninitialized &&memory：访问未初始化内存 &&
· &&read &&invalid &&memory：读取非法内存，本质上也属于内存越界 &&
· &&memory &&leak：内存泄露 &&
· &&use &&after &&return：caller访问一个指针，该指针指向callee的栈内内存 &&
· &&stack &&overflow：栈溢出
针对上面的问题，主要有以下几种方法： &&
1. &&为了检测内存非法使用，需要hook内存分配和操作函数。hook的方法可以是用C-preprocessor，也可以是在链接库中直接定义（因为Glibc中的malloc/free等函数都是weak &&symbol），或是用LD_PRELOAD。另外，通过hook &&strcpy(),memmove()等函数可以检测它们是否引起buffer &&overflow。 &&
2. &&为了检查内存的非法访问，需要对程序的内存进行bookkeeping，然后截获每次访存操作并检测是否合法。bookkeeping的方法大同小异，主要思想是用shadow &&memory来验证某块内存的合法性。至于instrumentation的方法各种各样。有run-time的，比如通过把程序运行在虚拟机中或是通过binary &&translator来运行；或是compile-time的，在编译时就在访存指令时就加入检查操作。另外也可以通过在分配内存前后加设为不可访问的guard &&page，这样可以利用硬件(MMU)来触发SIGSEGV，从而提高速度。 &&
3. &&为了检测栈的问题，一般在stack上设置canary，即在函数调用时在栈上写magic &&number或是随机值，然后在函数返回时检查是否被改写。另外可以通过mprotect()在stack的顶端设置guard &&page，这样栈溢出会导致SIGSEGV而不至于破坏数据。
已有 3 个回答
已有 3 个回答
已有 4 个回答
已有 6 个回答
已有 3 个回答
位业主已在问吧找到答案
一万套装修案例
下载土巴兔APP
中国装修网& Linux Used内存到底哪里去了？
Linux Used内存到底哪里去了？
原创文章，转载请注明： 转载自
本文链接地址:
前几天 纯上 同学问了一个问题：
我ps aux看到的RSS内存只有不到30M，但是free看到内存却已经使用了7,8G了，已经开始swap了，请问ps aux的实际物理内存统计是不是漏了哪些内存没算？我有什么办法确定free中used的内存都去哪儿了呢？
这个问题不止一个同学遇到过了，之前子嘉同学也遇到这个问题，内存的计算总是一个迷糊账。 我们今天来把它算个清楚下!
通常我们是这样看内存的剩余情况的：
-/+ buffers/cache:
那么这个信息是如何解读的呢，以下这个图解释的挺清楚的！
补充（不少人反映图不清晰，请参考：http://www./redpapers/pdfs/redp4285.pdf P46-47)
上面的情况下我们总的内存有48262M，用掉了7913M。 其中buffer+cache总共14+267=281M, 由于这种类型的内存是可以回收的，虽然我们用掉了7913M，但是实际上我们如果实在需要的话，这部分buffer/cache内存是可以放出来的。
我们来演示下：
$ sudo sysctl vm.drop_caches=3
vm.drop_caches = 3
-/+ buffers/cache:
我们把buffer/cache大部分都清除干净了，只用了44M，所以我们这次used的空间是7676M。
到现在我们比较清楚几个概念：
1. 总的内存多少
2. buffer/cache内存可以释放的。
3. used的内存的概率。
即使是这样我们还是要继续追查下used的空间（7637M)到底用到哪里去了？
这里首先我们来介绍下这个工具，它对内存的使用显示比较直观。
使用的内存的去向我们很自然的就想到操作系统系统上的各种进程需要消耗各种内存，我们透过top工具来看下：
通常我们会看进程的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]/statm
Provides information about memory usage, measured in pages.
columns are:
total program size
(same as VmSize in /proc/[pid]/status)
resident set size
(same as VmRSS in /proc/[pid]/status)
shared pages (from shared mappings)
text (code)
library (unused in Linux 2.6)
data + stack
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]&`
if [ -f /proc/$PROC/statm ]; then
TEP=`cat /proc/$PROC/statm | awk '{print ($2)}'`
RSS=`expr $RSS + $TEP`
RSS=`expr $RSS \* 4`
echo $RSS&KB&
$ ./RSS.sh
从数字来看，我们的进程使用了大概7024M内存，距离7637M还有几百M内存哪里去了？ 哪里去了？ 猫吃掉了？
我们再回头来仔细看下nmon的内存统计表。
那个该死的slab是什么呢？ 那个PageTables又是什么呢？
简单的说内核为了高性能每个需要重复使用的对象都会有个池，这个slab池会cache大量常用的对象，所以会消耗大量的内存。运行命令：
我们可以看到：
从图我们可以看出各种对象的大小和数目，遗憾的是没有告诉我们slab消耗了多少内存。
我们自己来算下好了：
$ echo `cat /proc/slabinfo |awk 'BEGIN{sum=0;}{sum=sum+$3*$4;}END{print sum/}'` MB
904.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}'` KB
好吧，小结下！内存的去向主要有3个：1. 进程消耗。 2. slab消耗 3.pagetable消耗。
我把三种消耗汇总下和free出的结果比对下,这个脚本的各种计算项仲同学帮忙搞定的:
$ cat cm.sh
#/bin/bash
for PROC in `ls /proc/|grep &^[0-9]&`
if [ -f /proc/$PROC/statm ]; then
TEP=`cat /proc/$PROC/statm | awk '{print ($2)}'`
RSS=`expr $RSS + $TEP`
RSS=`expr $RSS \* 4`
PageTable=`grep PageTables /proc/meminfo | awk '{print $2}'`
SlabInfo=`cat /proc/slabinfo |awk 'BEGIN{sum=0;}{sum=sum+$3*$4;}END{print sum/}'`
echo $RSS&KB&, $PageTable&KB&, $SlabInfo&MB&
printf &rss+pagetable+slabinfo=%sMB\n& `echo $RSS/1024 + $PageTable/1024 + $SlabInfo|bc`
7003756KB, 59272KB, 904.334MB
rss+pagetable+slabinfo=MB
-/+ buffers/cache:
free报告说7629M， 我们的cm脚本报告说7800.3M， 我们的CM多报了171M。
damn,这又怎么回事呢？
我们重新校对下我们的计算。 我们和nmon来比对下，slab和pagetable的值是吻合的。 那最大的问题可能在进程的消耗计算上。
resident set size 包括我们使用的各种库和so等共享的模块，在前面的计算中我们重复计算了。
$ pmap `pgrep bash`
848K r-x--
592K rw---
116K r-x--
/lib64/libtinfo.so.5.7
/lib64/ld-2.12.so
1628K r-x--
/lib64/libc-2.12.so
/usr/lib/locale/locale-archive
/lib64/libnss_files-2.12.so
/usr/lib64/gconv/gconv-modules.cache
00007fff5e553000
00007fff5e5e4000
ffffffffff600000
多出的171M正是共享库重复计算的部分。
但是由于每个进程共享的东西都不一样，我们也没法知道每个进程是如何共享的，没法做到准确的区分。
所以只能留点小遗憾，欢迎大家来探讨。
总结：内存方面的概念很多，需要深入挖掘！
祝玩的开心！
Post Footer automatically generated by
for wordpress.
Related posts:
Categories: ,
buy me a coffee.
阿里核心系统数据库组招募高手！
招聘信息：
Recent Posts