凡是硬盘上有对应的数据，占用的内存，就是非计算内存，非计算内存需要被别的进程用到时，其中的数据无需page out，因为再次需要读取的时候从硬盘文件中拿出来即可。

凡是硬盘上没有数据对应的内存占用叫做计算内存，例如用C写个程序，分配一块1MB的内存，这部分内存不管其中数据是否有意义，硬盘上没有文件对应，叫做计算内存。

以上所谓“硬盘上有无对应数据”的前提是：计算内存、非计算内存是操作系统的分类，所以操作系统知道硬盘上有对应，才叫非计算内存。虽然任何数据库的内存占用绝大部分是磁盘缓冲，按理说其中的数据硬盘上有对应，但是，这些内存是数据库管理的，操作系统只知道这些内存是DBMS主动向操作系统申请的，其中放的什么，操作系统并不知道，所以是计算内存

计算内存、非计算内存都是指物理内存占用，而物理内存的情况，由于VMM机制，是时刻在变化的，所以只能说某一瞬间，计算内存、非计算内存各占用多少。

●计算内存：
凡是进程/程序运行中用程序代码向操作系统申请的内存，全部是计算内存，也就是说除非这个程序运行起来，除了自身代码占用的内存，一点额外的内存也不用，否则它几乎必然会造成计算内存占用的。说“几乎”，是因为计算内存、非计算内存都是指物理内存，如果一个程序申请了1MB内存，但一段时间没有用这部分内存，很可能在其他进程需要内存，且物理内存比较紧张时，按照LRU算法（Latest Recently Unused，最近最少使用），被操作系统部分或全部page out到paging space中，如果全部被page out了，可以说这个时刻，此进程没有使用���算内存。换句话说，就是程序申请了1MB内存，那么它在某一时刻占用的计算内存从0字节～1MB都有可能。

进程主动向操作系统申请分配的内存，从程序编码上来看，以C为例，典型的就是malloc，当然，还有程序语言中的隐式分配，反正对于操作系统来说都一样，例如char *string1="ABCDEFG"; int number=22222; 前者会导致自动向操作系统申请8个字节，后一个会申请一个字（两个字节）

当进程退出，或者意外崩溃，对于操作系统来说，它知道进程不在了，而进程申请的内存，操作系统明确知道是哪些的，在资源回收的过程中，会自动把这个进程申请的内存释放掉，这个过程是很快的。所以我们可以看到：如果计算内存高企，我们把应用一停，也就是把使用计算内存最多的进程停止，计算内存占用率立刻就下来了。

●非计算内存：
操作系统明确知道这部分内存的用途是放硬盘对应数据的，所以，显然这部分内存不是任何进程可以控制，也就是说不可能一个程序主动要求分配多少非计算内存或者释放多少。这部分完全是操作系统在直接管理：分配、记录状态、使用、释放，其他进程只可能用间接手段影响非计算内存，例如读写文件。

非计算内存我们常见的是如下用途：
——程序代码：当运行程序时，代码初始装入到物理内存的什么地方、重定位到什么地方，是操作系统管理的，它会记住程序代码放在物理内存什么地方，及其对应程序文件的位置。当程序代码占用的page frame需要被其他用途使用时，操作系统直接把这个page frame转给要使用这部分内存的进程，并记录标志，下次要是这个page原来的内容需要被引用，从对应程序文件中的对应位置读取进入物理内存。有些进程的某些计算内存占用是不能被替换的，例如执行VMM管理任务的操作系统核心进程，所以这部分会有操作系统机制设置标志，这个就是常说的pin住某些内存不准替换掉。
——磁盘访问缓冲区：这个不是常说的缓存区，缓存区（英文Cache）的目的是用来提高性能，而缓冲区（英文Buffer），是为了块设备访问特点的要求，比如硬盘块设备、逻辑卷块设备，必须读写的基本单位是一个块，一般是512字节，哪怕你只读写一个字���，也必须一次读进512字节，修改特定的那一个字节，然后再整个512字节块全部写出到硬盘。这就需要缓冲区的存在。缓冲区的总个数，是不固定的，操作系统可以根据同时在访问的块的数量随时调整。
——NFS访问缓冲区，原理基本同上；
——文件系统缓存：这个肯定是每一个字节都有硬盘文件对应的，显然是非计算内存。 

计算内存 -- Work segment
临时的；没有对应的持久磁盘存储位置；
一个进程结束，将释放物理和分页空间；
当空闲物理内存较少时，将page out到分页空间，以帮助释放更多物理内存

非计算内存 -- Persistent segment 
持久段；在磁盘上有持久存储位置
数据文件or exe程序通常都映射为非计算内存；
数据文件：jfs、jfs2、nfs等

所以，当物理内存较少，计算内存将page out到pagingsapce，主机性能下降，这就是我们通常看到的内存瓶颈
我们需要保护计算内存，限制非计算内存，这是我们愿意看到的情况

AIX5.3以前的调整参数方法：maxperm%=maxclient%设置较低通常在20%左右
minperm%设置的更低一点，通常可以是maxperm%的一半5%-10%

AIX5.3以后的调整参数方法：maxperm%=maxclient%设置的比较高90%左右
minperm%还是设置的比较低，通常可以设置为5%-20%左右

而lru_file_repage=1是AIX系统的default的值

lru_file_repage参数存在的意义：
1、是否应该考虑VMM重分页计数
2、替换什么类型的内存

当lru_file_repage=0的时候将只替换非计算内存，这显然达到了我们需要保护计算内存的目的

如果由文件页面占有的实际内存的百分比低于这个级别，则页面替换算法既替换文件页面也替换计算页面，而不管repage rate。 

如果由文件页面占有的实际内存的百分比高于这个级别，则页面替换算法仅替换文件页面。 

如果由文件页面占有的实际内存的百分比高于这个级别，则页面替换算法仅替换客户机页面。

设置内存参数：

AIX 中Paging Space使用率过高分析和解决时间:2008-04-16 10:54来源:互联网
AIX 操作系统中的 Paging Space 是很重要的设备，Paging Space 使用率过高将影响系统整体性能，甚至会造成系统挂起。文中对 Paging Space 使用率过高的常见原因进行了分析，并给出了��应的解决方案。 AIX操作系统中Paging Space是很重要的设备，当系统中Paging Space使
   
AIX 操作系统中的 Paging Space 是很重要的设备，Paging Space 使用率过高将影响系统整体性能，甚至会造成系统挂起。文中对 Paging Space 使用率过高的常见原因进行了分析，并给出了相应的解决方案。
AIX操作系统中Paging Space是很重要的设备，当系统中Paging Space使用率过高、系统内存不足时，将影响系统的整体性能，甚至会造成系统的挂起。针对这种情况，通常能够靠增加Paging Space来加以缓解；但是当Paging Space已相当大，而Paging Space使用率仍旧居高不下时，则需要通过进一步的分析来找出原因并加以解决。文中分析了几种Paging Space使用率持续增长直至过高的常见原因，并给出了相应的解决方案，以确保Paging Space使用率被控制在安全的范围内。

1 Paging Space的创建原则

AIX中Paging Space大小确定的指导原则如下：

系统实际内存小于64MB, paging space= 2 * RAM ； 
系统实际内存在 64MB to 256MB 之间, Page Space = RAM size 16MB ； 
系统实际内存大于 256MB , Page Space = 512 ( RAM - 256 ) * 1.25 ； 
当内存超过4GB时,则需要根据实际情况来定，一般可初始3GB, 然后观察paging space的使用情况,假如使用率超过70%, 则需要增加paging space 。 
此外在创建Paging Space时还应遵循以下原则以提高性能：

创建的数量应尽可能的多； 
每个Paging Space的大小应该相同； 
每个Paging Space应尽可能的分配在不同的硬盘上。 
AIX中能够通过命令lsps -s查看Paging Space的使用情况。列Total Paging Space给出的是系统总的Paging Space空间大小，Percent Used则表示已被占用的Paging Space的百分比。

命令lsps -a能够用来查看Paging Space的分布情况

2 文档型内存对Paging Space使用率的影响

在AIX系统中，内存能够简单的分为两类：计算型内存和文档型内存。类似大量文档类操作，如压缩、数据库的dump/load等操作会大量占用文���型内存。假如按照系统缺省的配置，文档型内存最多会占用到内存总量的80%，由于文档型内存占用并不主动释放，从而可能造成内存资源的短缺及Paging Space使用率过高。

命令topas能够用来查看文档型内存占用内存情况，在MEMORY一栏中的%Noncomp显示的是文档型内存的占用百分比。

假如文档型内存所占比例很高，而Paging Space使用率居高不下时，能够通过降低minperm、maxperm的参数值来进行调优，减少文档型内存可占用的份额。

在进行调整前，首先通过命令vmo -a/vmtune -a来查看现在的参数值；minperm及maxperm的缺省值分别��30%和80%。

随后根据当前的值来确定minperm、maxperm新的参数值，并通过命令vmo 及参数p和P来进行设定。如需将minperm、maxperm的值分别设为15%和30%可用命令vmo -p 15 -P 30来实现。

因为参数maxperm充当的是软限制，所以文档型内存的占用率依旧能够超过maxperm的设定值。假如需要进行强制限制，则需要将参数strict_maxperm的值设为1，该参数的缺省值为0，但此方法需谨慎使用。

3 应用程式内存泄露对Paging Space使用率的影响

应用程式的内存泄露也是造成Paging Space使用率不断增长的另一常见原因，此类情况的解决方法主要是找出内存泄露的应用，然后进行修正或安装补丁。

以下方法可用来找出发生内存泄露的应用：

该命令每m秒钟按降序列出前n个最耗内存进程。为了便于分析，能够将结果输出到文档中，然后对内容进行分析，从而找出内存泄露的应用。

下例中命令svmon -P -t 10 -i 5的结果被输出到文档svmonresult.txt中，该命令每5秒种输出一次最耗内存的前10个进程。

找出发生内存泄露的应用后可自行进行修正或查找相关的补丁进行安装。

4 数据库参数配置对Paging Space使用率的影响

在装有数据库的系统环境中，数据库相关参数的配置不当也容易造成Paging Space的占用率过高。以DB2为例，因为 DB2 使用自己的缓冲池进行数据缓存，所以其所能占用的内存量不受参数maxperm的控制，而是由自身的参数值来决定。数据库占用的内存过多并且不及时释放的话同样会造成Paging Space使用率的持续增长乃至耗尽，本节中采用DB2的配置为例来对此类情况进行说明。

就Paging Space使用率而言，DB2的相关参数中需要特别关注的有DB2MEMDISCLAIM、DB2MEMMAXFREE、NUM_POOLAGENTS、 ESTORE_SEG_SZ及NUM_ESTORE_SEGS。其中DB2MEMDISCLAIM、DB2MEMMAXFREE、 NUM_POOLAGENTS和DB2中代理的私有内存相关，而ESTORE_SEG_SZ、NUM_ESTORE_SEGS则决定扩展缓冲池的大小。

AIX中，注册变量DB2MEMDISCLAIM指明当程式停止时DB2 UDB是否应该释放其占用的全部或部分内存。DB2MEMDISCLAIM保持缺省值YES，则在DB2MEMMAXFREE的值为空时，程式结束后释放任何相关内存，否则只保留DB2MEMMAXFREE值大小的内存量，该值缺省为8M。假如DB2MEMDISCLAIM的值被改为NO，则程式结束后内存不会被释放。 

NUM_POOLAGENTS指定了DB2中能够保留的空闲代理的最大数目，假如该值过大，将会有大量的内存被空闲代理占用。如 NUM_POOLAGENTS的值为125，DB2MEMMAXFREE的值为8M，在DB2MEMDISCLAIM为YES时将最多有约1G的内存被空闲代理占用。

因此，当Paging Space使用率偏高时，能够尝试查看DB2MEMDISCLAIM、DB2MEMMAXFREE、NUM_POOLAGENTS的值来确保没有过多的内存被DB2代理所占用。假如空闲代理占用内存太多，则需要调整DB2MEMMAXFREE、NUM_POOLAGENTS的值来削减。

DB2MEMDISCLAIM、DB2MEMMAXFREE的值可用db2set命令来查看和设定；NUM_POOLAGENTS的值则能够通过以下步骤来查看和修改：

DB2中除了主缓冲池之外还经常用到扩展缓冲池，扩展缓冲池的大小也是决定内存使用量的一个重要因素。扩展缓冲池（EXTENDED STORAGE）充当的是缓冲池中被换出页的辅助缓存，他的存在能够减少I/O操作，提高查询速度。通常扩展缓冲池占用的内存不会主动释放，因此假如扩展缓冲池过大，随着时间的增加、缓冲池占用的内存量的不断增长，有相当大的可能造成内存资源的短缺、Paging Space使用率过高。

扩展缓冲池的大小是由参数ESTORE_SEG_SZ、NUM_ESTORE_SEGS一起决定的，通过以下命令能够查看他们的值：

扩展缓冲池最多占用内存的计算方式如下：

假如系统中共有3个配置相同的DB，ESTORE_SEG_SZ的值为16000，NUM_ESTORE_SEGS的值为65，页面大小为4K，则扩展缓冲池最多可占用的内存为：
ESTORE_SEG_SZ、NUM_ESTORE_SEGS的参数值设定能够通过如下命令来实现：

DB2中更有其他一些参数决定着内存的使用情况，但是当发现内存占用后不释放的情况时，能够考虑首先查看本节中提到的相关参数。

对于其他的数据库，同样也需要注意一些类似参数值的配置，避免造成对内存的过量占用，从而造成对系统整体性能的影响。

5 结束语
文中针对AIX中Paging Space使用率过高的问题，分别从文档型内存、应用程式内存泄露和数据库参数配置三个方面进行了分析，并给出了相关的解决方法。