为什么我的linux只认64m内存？（我有128m内存）
[问题点数：0分]
为什么我的linux只认64m内存？（我有128m内存）
[问题点数：0分]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
匿名用户不能发表回复！|(千夫影子)
(豆瓣HHman)
第三方登录：专家工作平台
专家工作平台
访问的文章不存在Linux中的任何程序能占用的最大物理存储空间是64M?吗
如果是这样，Linux 早就被人废弃了。要知道梦工厂作动画片用的是 Linux ，无数台 Linux 机器互联，只有 64M 内存会是什么状态？一台普通的 Windows 机器上 4G 内存（家用 4G 有的是，服务器现在一般 8G+ ），就等于 64 台 Linux 机器的内存？1000台 Windows 4G 内存的机器，等于 64000 台 Linux 的机器？要知道跑这种电影运算程序 64M 连 Linux 系统 + 电影运算程序都放不下。－－－－－－－－－－以下为引用新闻：梦工厂使用流行的Linux Maya商业软件来做3D建模。场景加上灯光材质后用3,000多个 CPU的Linux 渲染集群逐帧渲染。通过一个网格工具（他们使用LSP平台，一个Linux商业软件包）将每一帧分配给集群里面一个节点。所以许多帧可以同步的输出。然后这些帧用Avid软件来进行编辑（这个不是在Linux下）。他们用HP xw9300 workstations 装上RHEL 4来做桌面，用HP DL145 G2 server来构建渲染集群。标准的内存配置是每个CPU core分配2G内存。server一般有4核，所以是8G内存。DreamWorks Animation 跟Red Hat的关系很好。
首选项→性能
使用top命令
RSS列 表示， 程序占用了多少物理内存。 虚拟内存可以不用考虑，它并不占用实际物理内存。 (2). top 命令也可以 其中VIRT(或VSS)列 表示，程序占用了多少虚拟内存。 同 ps aux 中的 VSZ列 RES列 表示， 程序占用了多少物理内存。同 ps aux 中的RSS列 2.在linux下， 查看当前系统占用了多少内存， 一般的命令是 free其中， free就是系统还有多少内存可以使用。但由于 linux 系统对内存使用有一个原则， 就是， 内存是宝贵的， 能使用多少就使用多少。 所以， linux会把已经调用过的包缓存起来，放在内存里。这样，实际上，可以使用的内存，就可以理解为， free+buffers+cached3.当你了解完这些命令以后， 再去使用ps aux 命令去查看的时候， 会发现一个奇怪的现象。 所有的 RSS 列的数据，加起来， 比物理内存的数要大很多。 比如， 物理内存为2G， 而RSS列的数据加起来，可能有5个G之多， 这是怎么回事了？ 这是因为RSS列的值骗了我们。 linux的内存机制是这样的： 在运行一个程序时， linux会调用该程序依赖的链接库， 如lib.xx.so。 首先看该链接库是否被映射进内存中，如果没有被映射，则将代码段与数据段映射到内存中，否则只是将其加入进程的地址空间。 这样，当N个程序，依赖到lib.xx.so的时候， 实际上，内存中只有一个lib.xx.so ，而不是N个。 而RSS在显示一个程序占用的实际物理内存时， 将lib.xx.so也算了进来。 比如， X程序， 本身占用内存为5M， lib.xx.so 占用内存2M，lib.xx.so被N个程序共享依赖。 则RSS显示为，X程序运行，占用内存为7M。 实际上， X程序占用了5M空间。 多余的2m被讨入到RSS中了。 当你在用ps aux显示内存占用情况时， N个共享依赖lib.xx.so的N个程序，都把这2m空间，算在自己的RSS中了， 这样RSS的sum值，就比实际物理内存多了。 当然， linux的内存使用机制很复杂， 不是一句两句能说清楚的。这里只是简单的说明了一下， ps aux中的RSS值， 并不能真实反映物理内存的使用情况。 4. 如果查看更详细的内存使用情况， 可用以下几种方法， 或者几种方法结合使用：这几种方法，都需要root账户的权限(1). pmap -d $pid $pid 是正在运行的程序的pid(2). cat /proc/$pid/smaps smaps的数据比较详细，可简单的归纳一下，归纳的命令如下： cat /proc/$pid/smaps | awk '/Size|Rss|Pss|Shared|Private|Referenced|Swap/{val_name=gensub(/([a-zA-Z_]*).*/,&\\1&,1,$1); list[val_name]+=$2; }END{for(val in list)print val,list[val];}' (3). cat /proc/$pid/maps(4). cat /proc/$pid/statm输出解释第一列 size:任务虚拟地址空间大小
第二列 Resident：正在使用的物理内存大小
第三列 Shared：共享页数
第四列 Trs：程序所拥有的可执行虚拟内存大小
第五列 Lrs：被映像倒任务的虚拟内存空间的库的大小
第六列 Drs：程序数据段和用户态的栈的大小
第七列 dt：脏页数量(5). vmstat这个命令据说也可以提供一些参考信息，具体还未研究 5.作为phper，尝试过使用php的函数memory_get_usage()， 该函数也不能得到php当前运行的程序，实际的，真正占用的内存数量。 如果真想得到，php真正占用的内存， 大概只能在, 程序运行的开始，执行一次memory_get_usage(). 在程序运行结束，执行一次memory_get_usage()。 将两者的值相减，得到的值， 应该是一个相对比较准确的，内存占用数量了。 这个方法还没有测试， 考虑到， 得到这个数量，也没有实际意义， 加上平时又比较忙，懒得试了。
首选项里吧
不是。这个跟内核有关，你可以自己编译内核
人的综合分
感谢您为社区的和谐贡献力量请选择举报类型
经过核实后将会做出处理感谢您为社区和谐做出贡献
确定要取消此次报名，退出该活动？原创文章，转载请注明： 转载自
本文链接地址:
前几天 纯上 同学问了一个问题：
我ps aux看到的RSS内存只有不到30M，但是free看到内存却已经使用了7,8G了，已经开始swap了，请问ps aux的实际物理内存统计是不是漏了哪些内存没算？我有什么办法确定free中used的内存都去哪儿了呢？
这个问题不止一个同学遇到过了，之前子嘉同学也遇到这个问题，内存的计算总是一个迷糊账。 我们今天来把它算个清楚下!
通常我们是这样看内存的剩余情况的：
-/+ buffers/cache:
那么这个信息是如何解读的呢，以下这个图解释的挺清楚的！
补充（不少人反映图不清晰，请参考：http://www.redbooks.ibm.com/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.
相关 [linux used 内存] 推荐：
- 非业余研究
原创文章，转载请注明： 转载自
非业余研究. Linux Used内存到底哪里去了. 前几天 纯上 同学问了一个问题：. 我ps aux看到的RSS内存只有不到30M，但是free看到内存却已经使用了7,8G了，已经开始swap了，请问ps aux的实际物理内存统计是不是漏了哪些内存没算. 我有什么办法确定free中used的内存都去哪儿了呢.
- Sepher - NoSQLFan
下面是一篇翻译文章，原文出自MongoDB的核心开发工程师 Kristina Chodorow 的个人博客，由NoSQLFan翻译整理. 我们都知道，MongoDB 使用内存映射的方式来进行数据文件的存取操作. 本文的目的就在于描述操作系统虚拟内存的使用及内存映射的内部实现. 当你运行一个程序，程序中有许多东西需要存储，堆、栈以及各种功能库.
- BlogJava-qileilove
Linux下看内存和CPU使用率一般都用top命令，但是实际在用的时候，用top查看出来的内存占用率都非常高，如：. 　　top –M看更直观，以M为单位. 　　接近98.7%，而实际上的应用程序占用的内存往往并没这么多，. 　　看%MEM这列的数字，按内存排序后，把前几名加起来，撑死了才不过55%，那剩下的内存都干嘛用了.
- 美团技术团队
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约600m，Linux自身使用大约800m. 从表面上，物理内存应该是足够使用的；但实际运行的情况是，会发生大量使用SWAP(说明物理内存不够使用了)，如下图所示. 同时，由于SWAP和GC同时发生会致使JVM严重卡顿，所以我们要追问：内存究竟去哪儿了.
- d0ngd0ng - 服务器运维与网站架构|Linux运维|互联网研究
前天有朋友问我，为啥我的Linux系统没运行多少程序，显示的可用内存这么少. 其实Linux与Win的内存管理不同，会尽量缓存内存以提高读写性能，通常叫做Cache Memory. 有时候你会发现没有什么程序在运行，但是使用top或free命令看到可用内存free项会很少，此时查看系统的 /proc/meminfo 文件，会发现有一项 Cached Memory：.
- IT技术博客大学习
Nginx. Nginx是一个非常出色的静态资源web服务器. 如果你嫌它还不够快，可以把放在磁盘中的文件，映射到内存中，减少高并发下的磁盘IO. nginx.conf中所配置站点的路径是/home/wwwroot/res，站点所对应文件原始存储路径：/opt/web/res. shell脚本非常简单，思路就是拷贝资源文件到内存中，然后在把网站的静态文件链接指向到内存中即可.
- heiyeluren的blog（黑夜路人的开源世界）
http://www.dcshi.com/?p=79. 所谓共享内存就是使得多个进程可以访问同一块内存空间，是最快的可用IPC形式. 是针对其他通信机制运行效率较低而设计的. 往往与其它通信机制，如信号量结合使用，来达到进程间的同步及互斥. 其他进程能把同一段共享内存段“连接到”他们自己的地址空间里去.
- CSDN博客系统运维推荐文章
1.Valgrind简介.
1.在我们编写C/C++的时候，最常见的错误之一就是内存泄露，这样的问题其实跟程序员的编程习惯密不可分. 如果你在申请内存空间之后能够马上在合适的位置释放内存. 会极大程度的避免内存泄漏的情况. 有时候我们确实忘记释放内存而导致了比较严重的错误，所以这个时候我们需要借助valgrind这个工具来判断内存泄漏.
- 操作系统 - ITeye博客
我们知道，直接从物理内存读写数据要比从硬盘读写数据要快的多，因此，我们希望所有数据的读取和写入都在内存完成，而内存是有限的，这样就引出了物理内存与虚拟内存的概念. 物理内存就是系统硬件提供的内存大小，是真正的内存，相对于物理内存，在linux下还有一个虚拟内存的概念，虚拟内存就是为了满足物理内存的不足而提出的策略，它是利用磁盘空间虚拟出的一块逻辑内存，用作虚拟内存的磁盘空间被称为交换空间（Swap Space）.
- 上善若水 厚德载物
一、常见的Java内存溢出有以下三种. 1. java.lang.OutOfMemoryError: Java heap space ----JVM Heap（堆）溢出. JVM在启动的时候会自动设置JVM Heap的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)不可超过物理内存.
--> 坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：itarea.。