摘要：有时会看到hp-unix下单个Oracle进程占用内存很多，有时又会很少，好多人对此都有些疑惑，是正常的还是内存泄露？同时好多人对相关的概念也不清晰，本文以一个问题入门来解答一下这方面的疑问。

1 引言
一直未太关注过Hp unix下单进程内存的使用问题，因我的各正式系统库的这部分都是很正常的，每个Oracle的进程内存的占用以性能观测工具观察在7mb左右。且系统的内存使用比也比较平稳。直到最近，itpub赵宇的一个问题才使我对Hp unix下Oracle进程的内存使用捉摸一番。帖子中单个Oracle进程以kmeminfo工具及Top工具来看占用内存很多个在100mb之上。新开一个Oracle连接什么也不做相应的后台进程也会占用93.2mb内存。相应的问题就来了，难道发生了内存泄露？单个进程占这么多内存正常吗？93.2mb内存由哪些部分组成的呢？

2 本文使用的系统工具
2.1 glance软件
Glance是Hp出品的一个非常好用的hp unix的性能监测和诊断工具，功能类似Aix的nmon工具。可以用其十分方便的表现系统性能(cpu、内存、IO、网络。。)的时时态及保存状态的历史，方便的找出系统性能的瓶颈，glance是一个比Top好用的十分多的一个工具。不过glance不是像Top一样的免费软件，glance工具需要购买，也可以向Hp工程师要一个免注册码的glance。Hp unix application盘上有一个Trail版的glance，可以使用30天，可以临时用或感受一下。这个工具可以方便的诊断单进程的内存使用，包含了类以solaris中的pmap命令的功能。

2.2 kmeminfo工具
Kmeminfo是一个hp的unsupport的内部工具，非常好用，用于内存具体使用的诊断。例如我想知道系统中所有的用户进程每个占用了多少内存？内存占用系统部分每个子部分都用��多少？Buffer cache占用的细节等等。Kmeminfo –user查看每个用户进程每个占用了多少内存的结果是按降序排序的，看起来非常的方便。如需要可以向Hp工程师要一个。

2.3 procsize 工具
Procsize也是一个unsupport的内部工具，用于观察进程的UAREA、TEXT、DATA、STACK等部分都为多少的细节，只所以使用这个工具是为了更好的说明ps命令的SZ。
2.4 ps命令
不用太细说，应该是每个人都用过，查看进程状态的。

3 问题重现
3.1 测试的环境
测试的环境是我的一个应用的测试系统，glance观察发现很多的Oracle进程占用了60mb多的内存。系统具体配置如下：
系统:3cpu，6GB物理内存，hp-ux11.11的操作系统，做过patch分析无问题。
数据库：Oracle 9.2.0.6 2GB内存用于SGA区

3.2 测试流程细节
○1打开glance初步看一下第一页，很多oracle进程占内存(RSS)都在60mb之上

○2 开一个Oracle连接并找到其进程号为7861

○3glance里7861进程占用内存(RSS)为57.9mb

○4kmeminfo里7861占用内存为56.6mb

○5 ps里7861占用了16992个内存页，计算起来为66.375mb
每个内存页为4096字节：

执行ps命令：

计算一下：

○6 看一下Oracle库内查到的该进程的pga占用为多少，结果为306kb

3.3 疑惑和问题
3.3.1 疑惑1
从3.2的测试中可以看到5861进程什么都未做，在glance中表现为占用57.9mb内存，kmeminfo表现为56.6mb内存，ps命令中为66.375 mb内存，哪个内存表现才为5861真实的物理内存占用？

3.3.2 疑惑2
Oracle库内5861使用pga才为300多kb，系统为什么分配给5861这么多的内存？出现了内存泄露？56.6mb的内存占用都含哪些部分？哪一部分占用的大呢？

4 解惑及我的见解
4.1 glance、kmeminfo及ps都不是进程真实占用物理内存的反映
4.1.1 glance与kmeminfo对进程的内存占用是一样，都为RSS
glance、kmeminfo及ps都不是进程真实占用内存的反映，这是我的第一个见解。这么一说可能会有N个人出来反对我，主要原因在于 kmeminfo这个工具。从kmeminfo这个工具的使用上看，它的体现的该是每个部分占用物理内存的大小，它的-user选项该也是每个进程实际占用物理内存，用过这个工具的人都会这样理解，我原来也这样认为。经过认真的评测，发现glance与kmeminfo对于某一个进程的内存占用实际上是一样的，也是一个东西，即为RSS，而不是真���的物理内存。这里又出现了一个概念上的问题，何为进程的真实的物理内存？何为RSS?

4.1.2 何为进程的真实的物理内存？何为RSS?
关于RSS，在hp-unix中的定义为：The size (in KB) of resident memory allocated for the process.
指的是进程相关数据驻留内存的大小。Hp-unix定义的RSS的计算公式为：

其中sum of private region pages即为进程占用真实的物理内存(sum of shared region pages /number of references)表现的是为共享内存部分在某一个进程上的均分。

此时我们对一个进程内存占用该有一个清晰的理解，当fork一个进程，假定名字为p1，malloc一个区域，这个区域用于存放进程的data、 stack、code等这些私有的数据，这才是真实的其物理内存的占用。同时系统内会有一些共享内存部分(ipcs看到的)，如oracle的SGA 区，p1也会引用到。此时p1的RSS该为：自已私有的占用+SGA它的引用。
假定p1的私有占用为2mb，它只引用共享部分如2gb的SGA区的5mb，那么p1的RSS=2+5=7mb，在glancee及kmeminfo的表现都会为7mb。

4.2 glance与kmeminfo的值不一样的原因在于glance的计算方式而产生的差别
4.1.1有人就会有不同意见，因为5861进程在glance中表现为占用57.9mb内存，kmeminfo表现为56.6mb内存，明明值不一样， 为什么说是一个东西？原因在于glance的不实时性及glance的计算方式而产生的差别。
做一个大量的抽样可以得到glance与kmeminfo的值不一样，可却相差很小，就像如上的57.9与56.6一样，也可以认为是等同的。 Glance默认是每2秒刷新一次的，而且由于unix内存的管理如page in/out，两者会有一点差别。同时看一下Hp对Rss的描述也会知道，这有glance的计算方式而产生的差别的因素，原文中的一段如下：

即因glance软件启用后，是否进程使用了cpu会差生RSS计算上的一点差别。

4.3 ps中的sz是text、data和stack三项的和,而text在hp-ux下属于共享部分, 故产生了ps的计算也不准确的状况
3.2的测试可以看到ps里7861的sz为16992个内存页，计算起来为66.375mb，那这16992个内存页由哪些部分组成的呢？每
每部分都为多少呢？man一个ps命令就能知道ps中的sz是text、datat和stack三项的和。如果想要知道text、data和stack都为多少需要借助procsize工具了。

其中-R表明查驻留的部分，可见16384(TEXT)+512(DATA )+96(STACK)恰好为16992。因TEXT部分在在hp-ux下属于共享部分，故产生了ps的计算也不准确的状况。
4.4 glance诊断单进程使用过多的问题
4.4.1 查看内存详细map列表
做了如些多的铺垫，该进入正题了，如下解析一下7861进程glance中57.9mb RSS源于何处的问题。
关注一下7861进程,进程列表界面按"s"键，然后提供process id 7861。

再键入”M”，进入详细的内存分布列表，如下：

4.4.2 信息项说明
RefCt指的是Reference Count，即有多少个进程引用共享区域
/Priv表明该内存区是进程私有的，此时RefCt也为1。/Shared表明该内存区是共享的，此时RefCt>1。
Text表明的是文本及代码区，说过几次了，此部分在Hp unix是共享的。
Data表明的是数据区，是一个私有区，如Oracle进程的pga就位于此区。
Stack 即为栈区，这也是一个私有区
MEMMAP 大多表现的是与swap相关的部分
SHMEM 此处是Oracle共享内存

4.4.3 按RSS的定义来算一下
7861真实占用内存（私有区）=

Shared部分均摊=

所以RSS=54+3.6=57.6mb
与57.9mb基本相当，当然这其中有精度及取舍的问题。

5 补充
5.1 如果通过inode发现相应的文件
有的时候进程详细列表显示的不是文件面是inode，如inode:8391，那8391是哪个文件呢？方法如下：

5.2 如何查看所有进程的实际占用的多少？
可以使用如下命令：

每一行，把Total 减掉TEXT项后，再乘上4096大体即为该进程实际占用的大小。