用心创造滤镜
扫码下载App
汇聚2000万达人的兴趣社区下载即送20张免费照片冲印
扫码下载App
温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
要搞清楚这个问题，首先从top输出开始研究：top命令的输出中VIRT RES SHR这三列的意思我就不多解释了，man top 一下就明白了。VIRT 是进程使用的总的虚拟内存大小。RES 是常驻内存的大小（不能SWAP）。SHR 是共享内存的大小（包括共享库等）。然后看一下这几个值分别是从哪里来的？看了一下top命令的源代码，在m_linux.c中有这几个值的来源，简单说就是，这些值都是从/proc/$pid 下面读出来的：VIRT 是 /proc/$pid/stat 中的第23个数字。RES 是/proc/$pid/stat 中的第24个数字，但是要注意，这个是用页来表示的，所以需要成字节。SHR 是 /proc/$pid/statm 中的第三个数字，这个也是用页表示的，需要转换。总的虚拟内存大小不用管它，这里主要关注RES 和 SHR。查看linux内核代码可知RES的值获取方式如下：mm ? get_mm_rss(mm) : 0而get_mm_rss的定义如下：411 #define get_mm_rss(mm) \412 (get_mm_counter(mm, file_rss) + get_mm_counter(mm, anon_rss))而get_mm_counter也是一个宏，它获取了进程的内存结构体mm_struct中变量 _file_rss 和_anon_rss 成员。SHR的获取代码如下：*shared = get_mm_counter(mm, file_rss);由此可见：RES = mm_struct-&_file_rss + mm_struct-&_anon_rssSHR = mm_struct-&file_rss那么，file_rss 和anon_rss是怎么计算出来的？它们代表的意思又是什么？要彻底搞清楚这两个东西，直接从代码上解释比较麻烦，比较不容易说清楚。但是我们可以换个地方去寻找答案。我们发现，在/proc/$pid 下面还有其他的一些文件，那么这些文件又是什么意思呢？有没有用的上的呢？其实是有的。/proc/$pid/maps 这个文件描述了当前映射到进程的内存和它们的访问权限/proc/$pid/smaps 这个文件是对/proc/$pid/maps更详细的描述，包括了每个映射内存的大小和使用情况 （具体参见文档 kernel/Documentation/filesystems/proc.txt）在我的机器上将进程ID为50893，RES=2.3G的进程的 statm 和 smaps 保存到文件：cat /proc/50893/statm & statmcat /proc/50893/smaps & smaps[ocsrun@OCSPROXY1 lqb]$ cat statm1467525&602414& 0 559 0这里重点关注第二个数字，这个数是什么意思以及怎么取到的后面会说。[ocsrun@OCSPROXY1 lqb]$ grep Rss smaps |awk 'BEGIN {sum = 0;} {sum += $2} END{print sum}'2409656然后发现：602414 × 4K = 2409656K 与smaps中所有的Rss的和相等。而2409656 / 1024 / 1024 = 2.298 = 2.3G 这不就是RES的大小吗？现在来说statm 中的第二个数，这个数就是 file_rss + anon_rss，代码我就不贴了，参看/kernel/fs/proc/array.c 和 /kernel/fs/proc/task_mmu.c而smaps中所有的Rss，是遍历进程所有的虚拟映射链表，一个一个累加出来的。以下是相关结构体的片段。202 struct mm_struct {203 struct vm_area_struct * /* list of VMAs */134 struct vm_area_struct {135 struct mm_struct * vm_ /* The address space we belong to. */136 unsigned long vm_ /* Our start address within vm_mm. */137 unsigned long vm_ /* The first byte after our end address138 within vm_mm. */至此我们知道file_rss + anon_rss 就是进程所有映射的页面的大小，注意这里说的都是虚拟地址空间，而不是物理内存（当然也包括了一部分的物理内存）。前面那个关于file_rss 和 anon_rss的问题算是基本上搞清楚了，但是为什么有的进程的映射页面会突然变得很大呢？为了搞清楚这个问题，我们仔细查看一下smaps文件：仔细查看后发现，smaps里面包括了所有映射的动态库，heap，stack等等。当然也包括了共享内存。共享内存是以下面的方式而存在的：7f43df rw-s :04 8749063 /SYSV00c9b457 (deleted)Size: 5242880 kBRss: 2098384 kBPss: 1052946 kBShared_Clean: 541256 kBShared_Dirty: 1548472 kBPrivate_Clean: 7656 kBPrivate_Dirty: 1000 kBReferenced: 2098364 kBSwap: 0 kBKernelPageSize: 4 kBMMUPageSize: 4 kB而普通共享库是这样的：7f452c11d000-7f452c4c9000 r-xp :09 8172 /home/ocsrun/xerces-c/xerces-c-3.0.0/lib/libxerces-c-3.0.soSize: 3760 kBRss: 1336 kBPss: 93 kBShared_Clean: 1336 kBShared_Dirty: 0 kBPrivate_Clean: 0 kBPrivate_Dirty: 0 kBReferenced: 1336 kBSwap: 0 kBKernelPageSize: 4 kBMMUPageSize: 4 kB将上面共享内存的行移下来：7f43df rw-s :04 8749063 /SYSV00c9b457(deleted)该行的意思如下：第一列是（虚拟）地址映射空间，第二列是访问权限，第三列是偏移量，第四列是设备号，以主设备号:次设备号的方式显示，第五列是inode，最后一列是路径。这里为什么是deleted呢？因为对于共享内存来说，根本不存在实际的文件跟它对应。运行ipcs输出如下（部分输出）：[ocsrun@OCSPROXY1 ~]$ ipcs------ Shared Memory Segments --------key shmid owner perms bytes nattch status0x00c9b455 8683525 ocsrun 660 0x00c9b456 8716294 ocsrun 660 0x00c9b457 8749063 ocsrun 660
50x00c9b45f 8781832 ocsrun 660 可以看到，在smaps中共享内存的inode是8749063，也就是ipcs显示的shmid，而key就是文件路径的后面一段。如上面所示，共享内存的映射有一个大于2G的，所以加上另外两块共享内存的映射，总的RES有2.3G也就不奇怪了。而关于共享内存的分配，多说两句：sys v shared memory实现，shmget基本就是在ramfs上写一个名字是SYSV&shm_key&的文件（这里是/SYSV00c9457），然后该文件的inode号是内核ipc核心数据结构的唯一id号，之后shmat基本就是mmap这个文件的过程，也就是说shmget返回的shmid其实就是用于存储内容的文件的inode编号。所以：Linux上top输出中RES和SHR的值比较高是没有关系的，因为可能大部分都是共享内存。top和ps等的输出中关于内存占用的部分都包括了共享内存/共享库等占用的虚拟内存空间。
阅读(4715)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_',
blogTitle:'Linux上通过top查看进程的RES和SHR的值很高，表示进程（独）占用的内存很多吗？',
blogAbstract:'在Linux上通过top看到的RES和SHR的值很高，表示进程占用的内存很多吗？会有什么问题吗？要搞清楚这个问题，首先从top输出开始研究：top命令的输出中VIRT RES SHR这三列的意思我就不多解释了，man top 一下就明白了。VIRT 是进程使用的总的虚拟内存大小。RES 是常驻内存的大小（不能SWAP）。SHR 是共享内存的大小（包括共享库等）。然后看一下这几个值分别是从哪里来的？看了一下top命令的源代码，在m_linux.c中有这几个值的来源，简单说就是，',
blogTag:'源码',
blogUrl:'blog/static/',
isPublished:1,
istop:false,
modifyTime:0,
publishTime:2,
permalink:'blog/static/',
commentCount:0,
mainCommentCount:0,
recommendCount:0,
bsrk:-100,
publisherId:0,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:false,
hostIntro:'',
hmcon:'0',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}查看Linux下系统占用的资源的命令(top、free、uptime)内存使用情况 | 红颜丽人Linux 内存使用方法详细解析 - 博客 - 伯乐在线
& Linux 内存使用方法详细解析
我是一名程序员，那么我在这里以一个程序员的角度来讲解Linux内存的使用。
一提到内存管理，我们头脑中闪出的两个概念，就是虚拟内存，与物理内存。这两个概念主要来自于linux内核的支持。
Linux在内存管理上份为两级，一级是线性区，类似于00c00，对应于虚拟内存，它实际上不占用实际物理内存；一级是具体的物理页面，它对应我们机器上的物理内存。
这里要提到一个很重要的概念，内存的延迟分配。Linux内核在用户申请内存的时候，只是给它分配了一个线性区（也就是虚存），并没有分配实际物理内存；只有当用户使用这块内存的时候，内核才会分配具体的物理页面给用户，这时候才占用宝贵的物理内存。内核释放物理页面是通过释放线性区，找到其所对应的物理页面，将其全部释放的过程。
char *p=malloc(2048) //这里只是分配了虚拟内存2048，并不占用实际内存。
strcpy(p,”123”) //分配了物理页面，虽然只是使用了3个字节，但内存还是为它分配了2048字节的物理内存。
free(p) //通过虚拟地址，找到其所对应的物理页面，释放物理页面，释放线性区。
我们知道用户的进程和内核是运行在不同的级别，进程与内核之间的通讯是通过系统调用来完成的。进程在申请和释放内存，主要通过brk,sbrk,mmap,unmmap这几个系统调用，传递的参数主要是对应的虚拟内存。
注意一点，在进程只能访问虚拟内存，它实际上是看不到内核物理内存的使用，这对于进程是完全透明的。
glibc内存管理器
那么我们每次调用malloc来分配一块内存，都进行相应的系统调用呢？
答案是否定的，这里我要引入一个新的概念，glibc的内存管理器。
我们知道malloc和free等函数都是包含在glibc库里面的库函数，我们试想一下，每做一次内存操作，都要调用系统调用的话，那么程序将多么的低效。
实际上glibc采用了一种批发和零售的方式来管理内存。glibc每次通过系统调用的方式申请一大块内存（虚拟内存），当进程申请内存时，glibc就从自己获得的内存中取出一块给进程。
内存管理器面临的困难
我们在写程序的时候，每次申请的内存块大小不规律，而且存在频繁的申请和释放，这样不可避免的就会产生内存碎块。而内存碎块，直接会导致大块内存申请无法满足，从而更多的占用系统资源；如果进行碎块整理的话，又会增加cpu的负荷，很多都是互相矛盾的指标，这里我就不细说了。
我们在写程序时，涉及内存时，有两个概念heap和stack。传统的说法stack的内存地址是向下增长的，heap的内存地址是向上增长的。
函数malloc和free，主要是针对heap进行操作，由程序员自主控制内存的访问。
在这里heap的内存地址向上增长，这句话不完全正确。
glibc对于heap内存申请大于128k的内存申请，glibc采用mmap的方式向内核申请内存，这不能保证内存地址向上增长；小于128k的则采用brk，对于它来讲是正确的。128k的阀值，可以通过glibc的库函数进行设置。
这里我先讲大块内存的申请，也即对应于mmap系统调用。
对于大块内存申请，glibc直接使用mmap系统调用为其划分出另一块虚拟地址，供进程单独使用；在该块内存释放时，使用unmmap系统调用将这块内存释放，这个过程中间不会产生内存碎块等问题。
针对小块内存的申请，在程序启动之后，进程会获得一个heap底端的地址，进程每次进行内存申请时，glibc会将堆顶向上增长来扩展内存空间，也就是我们所说的堆地址向上增长。在对这些小块内存进行操作时，便会产生内存碎块的问题。实际上brk和sbrk系统调用，就是调整heap顶地址指针。
那么heap堆的内存是什么时候释放呢？
当glibc发现堆顶有连续的128k的空间是空闲的时候，它就会通过brk或sbrk系统调用，来调整heap顶的位置，将占用的内存返回给系统。这时，内核会通过删除相应的线性区，来释放占用的物理内存。
下面我要讲一个内存空洞的问题：
一个场景，堆顶有一块正在使用的内存，而下面有很大的连续内存已经被释放掉了，那么这块内存是否能够被释放？其对应的物理内存是否能够被释放？
很遗憾，不能。
这也就是说，只要堆顶的部分申请内存还在占用，我在下面释放的内存再多，都不会被返回到系统中，仍然占用着物理内存。为什么会这样呢？
这主要是与内核在处理堆的时候，过于简单，它只能通过调整堆顶指针的方式来调整调整程序占用的线性区；而又只能通过调整线性区的方式，来释放内存。所以只要堆顶不减小，占用的内存就不会释放。
提一个问题：
char *p=malloc(2);
为什么申请内存的时候，需要两个参数，一个是内存大小，一个是返回的指针；而释放内存的时候，却只要内存的指针呢？
这主要是和glibc的内存管理机制有关。glibc中，为每一块内存维护了一个chunk的结构。glibc在分配内存时，glibc先填写chunk结构中内存块的大小，然后是分配给进程的内存。
chunk ------size
p------------ content
在进程释放内存时，只要 指针-4 便可以找到该块内存的大小，从而释放掉。
注：glibc在做内存申请时，最少分配16个字节，以便能够维护chunk结构。
glibc提供的调试工具：
为了方便调试，glibc 为用户提供了 malloc 等等函数的钩子（hook），如 __malloc_hook
对应的是一个函数指针，
void *function (size_t size, const void *caller)
其中 caller 是调用 malloc 返回值的接受者（一个指针的地址）。另外有 __malloc_initialize_hook函数指针，仅仅会调用一次（第一次分配动态内存时）。（malloc.h）
一些使用 malloc 的统计量（SVID 扩展）可以用 struct mallinfo 储存，可调用获得。
struct mallinfo mallinfo (void)
如何检测 memory leakage？glibc 提供了一个函数
void mtrace (void)及其反作用void muntrace (void)
这时会依赖于一个环境变量 MALLOC_TRACE 所指的文件，把一些信息记录在该文件中
用于侦测 memory leakage，其本质是安装了前面提到的 hook。一般将这些函数用
#ifdef DEBUGGING 包裹以便在非调试态下减少开销。产生的文件据说不建议自己去读，
而使用 mtrace 程序（perl 脚本来进行分析）。下面用一个简单的例子说明这个过程，这是
intmain( int argc, char *argv[] )
#ifdef DEBUGGING
mtrace( ) ;
p = malloc( sizeof( int ) ) ;
q = malloc( sizeof( int ) ) ;
printf( &p = %p\nq = %p\n&, p, q ) ;
free( p ) ;
return 0 ;
很简单的程序，其中 q 没有被释放。我们设置了环境变量后并且 touch 出该文件
执行结果如下：
p = 0x98c0378q = 0x98c0388
该文件内容如下
@./test30:[0x8048446] + 0x98c
@./test30:[0x8048455] + 0x98c
@./test30:[0x804848f] - 0x98c0378
到这里我基本上讲完了，我们写程序时，数据部分内存使用的问题。
代码占用的内存
数据部分占用内存，那么我们写的程序是不是也占用内存呢？
在linux中，程序的加载，涉及到两个工具，linker 和loader。Linker主要涉及动态链接库的使用，loader主要涉及软件的加载。
exec执行一个程序
elf为现在非常流行的可执行文件的格式，它为程序运行划分了两个段，一个段是可以执行的代码段，它是只读，可执行；另一个段是数据段，它是可读写，不能执行。
loader会启动，通过mmap系统调用，将代码端和数据段映射到内存中，其实也就是为其分配了虚拟内存，注意这时候，还不占用物理内存；只有程序执行到了相应的地方，内核才会为其分配物理内存。
loader会去查找该程序依赖的链接库，首先看该链接库是否被映射进内存中，如果没有使用mmap，将代码段与数据段映射到内存中，否则只是将其加入进程的地址空间。这样比如glibc等库的内存地址空间是完全一样。
因此一个2M的程序，执行时，并不意味着为其分配了2M的物理内存，这与其运行了的代码量，与其所依赖的动态链接库有关。
运行过程中链接动态链接库与编译过程中链接动态库的区别
我们调用动态链接库有两种方法：一种是编译的时候，指明所依赖的动态链接库，这样loader可以在程序启动的时候，来所有的动态链接映射到内存中；一种是在运行过程中，通过dlopen和dlfree的方式加载动态链接库，动态将动态链接库加载到内存中。
这两种方式，从编程角度来讲，第一种是最方便的，效率上影响也不大，在内存使用上有些差别。
第一种方式，一个库的代码，只要运行过一次，便会占用物理内存，之后即使再也不使用，也会占用物理内存，直到进程的终止。
第二中方式，库代码占用的内存，可以通过dlfree的方式，释放掉，返回给物理内存。
这个差别主要对于那些寿命很长，但又会偶尔调用各种库的进程有关。如果是这类进程，建议采用第二种方式调用动态链接库。
占用内存的测量
测量一个进程占用了多少内存，linux为我们提供了一个很方便的方法，/proc目录为我们提供了所有的信息，实际上top等工具也通过这里来获取相应的信息。
/proc/meminfo 机器的内存使用信息
/proc/pid/maps pid为进程号，显示当前进程所占用的虚拟地址。
/proc/pid/statm 进程所占用的内存
[root@localhost ~]# cat /proc/self/statm
654 57 44 0 0 334 0
CPU 以及CPU0。。。的每行的每个参数意思（以第一行为例）为：
参数 解释 /proc//status
Size (pages) 任务虚拟地址空间的大小 VmSize/4
Resident(pages) 应用程序正在使用的物理内存的大小 VmRSS/4
Shared(pages) 共享页数 0
Trs(pages) 程序所拥有的可执行虚拟内存的大小 VmExe/4
Lrs(pages) 被映像到任务的虚拟内存空间的库的大小 VmLib/4
Drs(pages) 程序数据段和用户态的栈的大小 （VmData+ VmStk ）4
dt(pages) 04
查看机器可用内存
/proc/28248/&free
total used free shared buffers cached
Mem: 400 668 503688
-/+ buffers/cache: 744
Swap: 08 1870312
我们通过free命令查看机器空闲内存时，会发现free的值很小。这主要是因为，在linux中有这么一种思想，内存不用白不用，因此它尽可能的cache和buffer一些数据，以方便下次使用。但实际上这些内存也是可以立刻拿来使用的。
所以 空闲内存=free+buffers+cached=total-used
查看进程使用的内存
查看一个进程使用的内存，是一个很令人困惑的事情。因为我们写的程序，必然要用到动态链接库，将其加入到自己的地址空间中，但是/proc/pid/statm统计出来的数据，会将这些动态链接库所占用的内存也简单的算进来。
这样带来的问题，动态链接库占用的内存有些是其他程序使用时占用的，却算在了你这里。你的程序中包含了子进程，那么有些动态链接库重用的内存会被重复计算。
因此要想准确的评估一个程序所占用的内存是十分困难的，通过写一个module的方式，来准确计算某一段虚拟地址所占用的内存，可能对我们有用。(T002)
可能感兴趣的话题
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线博客团队正试图以我们微薄的力量，把优秀的原创/译文分享给读者，做一个小而精的精选博客，为“快餐”添加一些“营养”元素。
新浪微博：
微信号：Jobbole
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选博客文章
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2015 伯乐在线
赞助云主机比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
Linux下查看内存使用情况命令
　　在Windows下面我们可以通过任务管理器来查看内存的使用情况。在下面虽然没有任务管理器，但是我们同样可以查看内存使用，和监控系统进程。在Linux下面，我们常用top命令来查看系统进程，top也能显示系统内存。我们常用的Linux下查看内容的专用工具是free命令。
　　Linux下内存查看命令free详解：
　　在Linux下查看内存我们一般用free命令：
　　$ free
　　total used free shared buffers cached
　　-/+ buffers/cache: 5064
　　Swap: 60 1968116
　　下面是对内存查看free命令输出内容的解释：
　　total:总计物理内存的大小。
　　used:已使用多大。
　　free:可用有多少。
　　Shared:多个进程共享的内存总额。
　　Buffers/cached:缓存的大小。
　　第三行(-/+ buffers/cached)：
　　used:已使用多大。
　　free:可用有多少。
　　第四行就不多解释了。
　　-/+ buffers/cache与区别：
　　第二行(mem)的used/free与第三行(-/+ buffers/cache) used/free的区别在于使用的角度来看：
　　第二行是从的角度来看，因为对于OS，buffers/cached 都是属于被使用，所以他的可用内存是16176KB,已用内存是3250004KB,其中包括，内核(OS)使用+Application(X,,etc)使用的+buffers+cached.
　　第三行所指的是从应用程序角度来看，对于应用程序来说，buffers/cached 是等于可用的，因为buffer/cached是为了提高文件读取的性能，当应用程序需在用到内存的时候，buffer/cached会很快地被回收。
　　所以从应用程序的角度来说，可用内存=系统free memory+buffers+cached。
　　如上例：
　　76+8236
　　内存如何进行交换
　　接下来解释什么时候内存会被交换，以及按什么方交换。 当可用内存少于额定值的时候，就会开会进行交换。如何看额定值：
　　cat /proc/meminfo
　　输出为：
　　$ cat /proc/meminfo
　　MemTotal: 3266180 kB
　　MemFree: 17456 kB
　　Buffers: 111328 kB
　　Cached: 2664024 kB
　　SwapCached: 0 kB
　　Active: 467236 kB
　　Inactive: 2644928 kB
　　HighTotal: 0 kB
　　HighFree: 0 kB
　　LowTotal: 3266180 kB
　　LowFree: 17456 kB
　　SwapTotal: 2048276 kB
　　SwapFree: 1968116 kB
　　Dirty: 8 kB
　　Writeback: 0 kB
　　Mapped: 345360 kB
　　Slab: 112344 kB
　　Committed_AS: 535292 kB
　　PageTables: 2340 kB
　　VmallocTotal:
　　VmallocUsed: 272696 kB
　　VmallocChunk:
　　HugePages_Total: 0
　　HugePages_Free: 0
　　Hugepagesize: 2048 kB
　　用free -m查看的结果：
　　[root@scs-2 tmp]# free -m
　　total used free shared buffers cached
0 107 2605
　　-/+ buffers/cache: 460 2729
　　Swap: 1
　　查看/proc/kcore文件的大小(内存镜像)：
　　$ ll -h /proc/kcore
　　-r-------- 1 root root 4.1G Jun 12 12:04 /proc/kcore
　　备注：
　　占用内存的测量
　　测量一个进程占用了多少内存，linux为我们提供了一个很方便的方法，/proc目录为我们提供了所有的信息，实际上top等工具也通过这里来获取相应的信息。
　　/proc/meminfo 机器的内存使用信息
　　/proc/pid/maps pid为进程号，显示当前进程所占用的虚拟地址。
　　/proc/pid/statm 进程所占用的内存
　　$ cat /proc/self/statm
　　654 57 44 0 0 334 0
　　输出解释
　　CPU 以及CPU0……的每行的每个参数意思(以第一行为例)为：
　　参数 解释 /proc/status
　　Size (pages) 任务虚拟地址空间的大小 VmSize/4
　　Resident(pages) 应用程序正在使用的物理内存的大小 VmRSS/4
　　Shared(pages) 共享页数 0
　　Trs(pages) 程序所拥有的可执行虚拟内存的大小 VmExe/4
　　Lrs(pages) 被映像到任务的虚拟内存空间的库的大小 VmLib/4
　　Drs(pages) 程序数据段和用户态的栈的大小 (VmData+ VmStk )4
　　dt(pages) 04
　　查看机器可用内存
　　/proc/28248/&free
　　total used free shared buffers cached
　　Mem: 400 668 503688
　　-/+ buffers/cache: 744
　　Swap: 08 1870312
　　Linux查看内存及内存使用小结：
　　我们通过free命令查看机器空闲内存时，会发现free的值很小。这主要是因为，在linux中有这么一种思想，内存不用白不用，因此它尽可能的cache和buffer一些数据，以方便下次使用。但实际上这些内存也是可以立刻拿来使用的。
[ 责任编辑：之极 ]
为更好推动开放架构发展，打造开…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte