AIX topas命令中的Memory项% Comp% Noncomp% Client如何理解和分析

AIX内存使用情况（windows 尽量少的用内存aix尽量多的用内存）
svmon -G
size inuse free pin virtual
memory 4046848 3758845 288003 935436 1816226
pg space 2097152 4651
work pers clnt
pin 935174 0 262
in use 1815740 0 1943105
用vmstat 1 11111查看内存瓶颈。

ps aux 显示内存使用
svmon -G 查看内存泄露
谢提供vmstat -v。

从上面显示看来，我想应该是这样：
1、numperm、numclient都是perm或client相对lruable的比值。

内存只有部分是lruable的。

2、当只用jfs或者jfs2用量不大时，client基本上是小于perm，因为jfs cache类型算perm不算client，这部分往往在非计算内存中是最大的。

client只是nfs、cdrfs所用，这部分不算file page，也不算noncomputational，因为没有本地硬盘数据对应，但这部分内存可以被steal，被steal时也不需要占用paging space，因为也只是cache而已，noncomputational从文档用语的理解看来，我的理解是只包含本机硬盘有对应数据的内容，对于远程有的（NFS、CDRFS）的。

而一般来说，NFS和CDRFS的访问量远远比不上本地JFS的访问量，其cache占用也就很少。

3、如果JFS2用量很大，client可能超过noncomp比较多，因为JFS2 CACHE算client不算perm，而noncomp一般来说就是perm。

其实我觉得造成疑惑的应当是IBM对noncomp在实践中的定义不清，到底是内存只有comp与noncomp组成，还是不是？按理说应当是所有的noncomp+comp=lruable，但如果发生numclient>numperm，而系统性能检查命令把perm当作noncomp，这就有偷换概念的嫌疑：某些cache性质的不算noncomp，而显然这些也不能算comp。

好在多数时候这种现象不严重，所以client 应当是noncomp的一部分。

今天在客户现场调试监控系统时，另外一个项目组有一台主机的DB2出现问题，希望我们对其主机的性能进行一些检测。

问题是否解决目前还不知道，但通过这件事，对AIX系统内存使用情况有了更清楚的了解：
通常，使用vmstat指令可以查看系统的空闲内存，但UNIX系统的空闲内存普遍都比较低，但相关指令的man page中声明这属于正常现象。

比如今天这台主机，有8G内存，但Free只有160M左右。

那么，剩余的内存都到哪里去了？
实际上，内存被分为两类，一种为工作区，用于存放进程数据、堆栈、核心Kernal 数据以及共享内存，工作区的数据如果需要换页，只会交换到paging space；另一类为持久存储区，主要是文件数据在内存中的缓冲，当持久存储区的数据需要换页，则会交换到其所归属的文件。

持久存储区的页又被分成Client pages和Non-client pages，其中，None-client page只能缓冲Journaled File System (JFS)文件系统的文件数据，而Client page缓冲所有其它类型文件系统的数据，如：NFS。

上述对内存的两种分类，是因为内存页用途不同，AIX内存管理程序为了提高系统效率，从页交换的角度，将内存页又分为Computational，Non-computational 两种。

所有的工作区内存页都是computational，而持久存储区的内存页则要根据其缓冲的文件情况而定，当文件被打开且第一次被缓存时，默认定为
Non-computational，但当某个进程尝试将该文件作为可执行代码进行执行时，该文件所有的页都被标记为computational。

所以一个文件的所有页只能属于一种类型，且在系统重启之前不会改变。

内存页的分类有助与通过参数调整内存交换程序的效率，详情参见：
/developerworks/aix/library/au-vmm/
AIX topas命令中的Memory项:% Comp% Noncomp% Client如何理解和分析
Memory
显示实际内存大小和使用中的内存分布。

Real,MB 以MB 为单位的实际内存大小。

% Comp 当前分配给计算性页帧的实际内存百分比。

计算性页帧一般是由分页空间支持的页帧。

% Noncomp 当前分配给非计算性页帧的实际内存百分比。

非计算性页帧一般是由文件空间（无论是数据文件、可执行文件还是共享库文件）支持的页帧。

% Client 当前分配用于缓存远程安装的文件的实际内存百分比。

文档上都这么说,小弟就是无法理解。

我看到的现象也是comp类型
但是就是原因搞不清楚
了解有关AIX® 虚拟内存管理器(AIX VMM) 如何工作，以及如何利用可调参数来调整AIX VMM 操作的详细信息。

AIX VMM 负责管理系统中所有的内存。

AIX VMM 的操作对于系统性能来说是至关重要的，并且它还提供了几个可调参数，对于不同的工作负载，您可以使用这些参数对其操作进行优化。

引言
AIX® 虚拟内存管理器(AIX VMM) 是一种基于分页的虚拟内存管理器。

一个分页就是一个固定大小的数据块。

分页既可以位于内存中（也就是说，映射到物理内存中的某个位置）、也可以位于磁盘中（也就是说，从物理内存中替换到分页空间或者文件系统）。

AIX VMM 有一个非常独特的方面，即缓存的文件数据的管理。

AIX VMM 将缓存的文件数据与对其它类型虚拟内存（例如，进程数据、进程堆栈等等）的管理集成到了一起。

它将文件数据缓存为分页，就如同进程的虚拟内存一样。

AIX 根据需要将分页映射到实际内存。

如果应用程序引用了某个分页，而该分页并没有映射到实际内存中，那么系统将产生一个缺页。

为了解决缺页，AIX 内核会将所引用的分页加载到实际内存中的某个位置。

如果所引用的分页是一个新的分页（也就是说，位于先前从未引用过的进程数据堆中的分页），那么“加载” 所引用的分页只需要用零来填充一个实际内存位置（也就是说，提供一个填满零的分页）。

如果所引用的分页是一个预先存在的分页（也就是说，文件中的某个分页、或者先前换出的某个分页），那么加载所引用的分页需要从磁盘（分页空间或者磁盘文件系统）中将该分页读入到实际内存中的某个位置。

在将分页加载到实际内存中之后，它将被标记为未经修改的。

如果某个进程或者内核修改了该分页，那么该分页的状态将更改为已修改的。

这允许AIX 跟踪在将某个分页加载到内存之后是否对其进行过修改。

随着系统将更多的分页添加到实际内存中，实际内存中空闲位置（可以包含分页）的数目将会减少。

也可以将空闲位置的数目称为空闲分页框架的数目。

当空闲分页框架的数目达到某个较低的值时，AIX 内核就必须清空实际内存中的某些位置，以便重用新的分页。

这个过程也称为分页替换。

AIX VMM 提供了一些后台守护进程，专门负责进行分页替换。

其中一个分页替换守护进程称为lrud（显示为ps -k 的输出中的lrud）。

lrud 守护进程负责在内存分页中进行扫描，并回收某些分页以便为实际内存腾出空间。

当分页替换守护进程确定它希望回收某个特定的分页时，这个分页替换守护进程将执行下面两项操作中的一项：
•如果该分页经过了修改，那么分页替换守护进程将该分页写入到辅助存储位置（例如，分页空间或者文件系统磁盘）。

将包含该分页的物理内存块标记为空闲，并为其它的分页做好重用的准备。

•如果该分页没有经过修改，那么分页替换守护进程可以简单地将物理内存块标记为空闲，这样一来，就可以将该物理内存块重用于另一个分页。

在这种情况下，分页替换守护进程不需要将该分页写入到磁盘，因为该分页在内存中的版本并没有经过修改，因此与位于磁盘中（在分页空间中、或者在磁盘文件系统中）的分页副本完全相同。

分页替换守护进程可以根据系统内存的使用情况和可调参数，选择不同类型的分页进行回收。

本文剩下的部分将详细地介绍分页替换守护进程如何选择要进行回收的分页。

分页类型
从本质上看，AIX 中一共有两种分页类型：
•工作存储分页（Working storage pages）
•永久存储分页（Permanent storage pages）
工作存储
工作存储分页是一些包含易变数据（换句话说，即重新启动后将不复存在的数据）的分页。

在其他的平台中，工作存储内存有时也称为匿名内存。

下面提供了一些由工作存储分页组成的虚拟内存区域的示例：•进程数据
•堆栈
•共享内存
•内核数据
当需要将经过修改的工作存储分页替换出（从内存移动到磁盘）时，它们将被写入到分页空间。

不会将工作存储分页写入到文件系统。

当进程退出时，系统将释放其所有的私有工作存储分页。

因此，当进程退出时，系统将释放进程数据和堆栈的工作存储分页。

对于共享内存区域，直到删除共享内存区域之后，才会释放其工作存储分页。

永久存储
永久存储分页是一些包含永久数据（也就是说，重新启动后仍然存在的数据）的分页。

这种永久数据就是文件数据。

因此，永久存储分页就是缓存在内存中的部分文件。

当经过修改的永久存储分页需要换出（从内存移动到磁盘）的时候，会将它写入到文件系统中。

如前所述，可以直接释放没有经过修改的永久存储分页，无需将其写入到文件系统中，因为文件系统包含该数据的原始副本。

例如，如果一个应用程序正在读取某个文件，那么该文件数据将缓存于永久存储分页的内存中。

这些永久存储分页没有经过修改，这意味着并没有在内存中对这些分页进行修改。

因此，内存中的永久存储分页与磁盘中的文件数据完全相同。

当AIX 需要清空内存的时候，它只需要“释放”这些分页即可，而不将任何内容写入到磁盘。

如果应用程序对某个文件进行写操作（而不是读操作），那么永久存储分页将是“经过修改的”，并且AIX 必须在释放这些分页之前将其刷新到磁盘。

您可以将永久存储分页划分为两种子类型：
•客户端分页
•非客户端分页
非客户端分页是一些包含缓存的日志文件系统(JFS) 文件数据的分页。

非客户端分页有时也称为持久性分页。

客户端分页是一些包含所有其他文件系统（例如，JFS2 和网络文件系统(NFS)）的缓存数据的分页。

分页分类
为了帮助分页替换守护进程更好地选择用来进行替换的分页，AIX 将分页分为下面两种类型：
•计算性分页
•非计算性分页
计算性分页是一些用于文本、数据、堆栈和进程的共享内存的分页。

非计算性分页是一些包含正在进行读取和写入的文件的文件数据的分页。

如何对分页进行分类
所有的工作存储分页都是计算性的。

不会将工作存储分页标记为非计算性的。

永久存储分页既可以是计算性的、也可以是非计算性的，这取决于您使用这些分页的方式。

如果一个文件包含某个进程的可执行文本，那么系统会将该文件视为计算性的，并且将该文件中的所有永久存储分页都标记为计算性的。

如果该文件不包含可执行文本，那么系统会将该文件视为非计算性的，并且将该文件中的所有永久存储分页都标记为非计算性的。

当您第一次打开一个文件的时候，AIX 内核将创建一个内部VMM 对象以代表该文件。

并且将其标记为非计算性的，这意味着所有的文件在一开始都是非计算性的。

随着程序对该文件进行读写操作，AIX 内核将该文件的数据作为非计算性的永久存储分页在内存中进行缓存。

如果关闭该文件，那么AIX 内核将继续在内存中（在永久存储分页中）缓存该文件的数据。

内核继续缓存该文件是为了提高性能；例如，如果稍后出现了另一个进程，并且它也使用了相同的文件，那么该文件数据仍然位于内存中，并且AIX 内核不需要从磁盘读入该文件的数据。

如果某个文件因为指令取出发生了缺页，那么会将非计算性文件转换为计算性状态。

当对某个文件出现进程缺页（意味着该进程引用了文件的部分内容，而这部分内容当前没有缓存在永久存储分页的内存中）的时候，该进程将产生一个缺页。

如果是由于指令取出而导致的缺页（意味着该进程正在尝试加载来自该分页的指令，以便进行相关操作），那么内核会将该文件标记为计算性的。

这涉及到将该文件中的所有分页都标记为计算性的。

一个文件要么完全是计算性的，要么完全是非计算性的。

在将文件标记为计算性文件之后，它将一直保持为计算性文件，直到删除该文件（或者重新启动系统）。

因此，即使移动了该文件、或者对它进行了重命名，该文件仍然标记为计算性的文件。

分页替换
AIX 分页替换守护进程一次扫描内存的一个分页，找出要回收的分页以释放内存。

分页替换守护进程必须仔细地选择分页，以便将分页对系统的性能影响降到最低，并且分页替换守护进程将根据可调参数设置和系统情况来选择不同类型的分页。

您可以使用大量的可调参数来控制AIX 选择分页进行替换的方式。

minperm 和maxperm
minperm 和maxperm 是两个最基本的分页替换可调参数。

这两个可调参数用于指出AIX 内核应该使用多少内存来缓存非计算性的分页。

maxperm 可调参数指出应该用于缓存非计算性分页的最大内存量。

在缺省情况下，maxperm 是一个“非严格的”限制，这意味着在某些情况下可以超出这个限制。

将maxperm 设定为非严格的限制，这允许在具有可用空闲内存的时候，可以在内存中缓存更多的非计算性文件。

通过将strict_maxperm 可调参数设置为1，就可以使maxperm 限制成为“严格”的限制。

当maxperm 是严格限制的时候，即使有可供使用的空闲内存，内核也不允许非计算性分页的数目超出maxperm 的限制。

因此，将maxperm 作为严格限制的缺点是，非计算性分页的数目不能超出maxperm 的限制，并且在系统中具有空闲内存的时候，也不能使用更多的内存。

minperm 限制指出应该用于非计算性分页的最低内存量。

非计算性分页的数目称为numperm：vmstat –v 命令可以显示系统的numperm 值所占系统实际内存的百分比。

按上面的理解
oracle引用到的分页属于工作存储分页（Working storage pages）
而工作存储分页都属计算性分页
所以oracle引用到的分页就属于计算型分页
还有2个疑问
1
那么非计算型的分页是不是就只属于以下2种类型中不包含可执行分页(指令取出)的部分？
•客户端分页
•非客户端分页
非客户端分页是一些包含缓存的日志文件系统(JFS) 文件数据的分页。

非客户端分页有时也称为持久性分页。

客户端分页是一些包含所有其他文件系统（例如，JFS2 和网络文件系统(NFS)）的缓存数据的分页。

分页分类
2 如果内存足够大是不是在一个只有oracle应用的系统中paging space的使用率就会变的很低？
因为不存在缺页的情况缺页已经被oracle处理了(它自己有自己的LRU list 引入和刷出data block) 已经不会出现操作系统层面上的缺页
这个概念很绕口，其实简单一点说：非计算就是AIX的文件系统缓存。

因为oracle有自已的缓存机制，所以在纯数据库服务器上应该降低文件缓存数量，以避免重复缓存，所以在aix 需要用vmo将maxperm等值调低。

[原创]非计算内存和计算内存的概念
看到有XD发帖说这个问题，我也想详细给大家一个说明，请各位老手新手指教。

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

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

以上所谓“硬盘上有无对应数据”的前提是：计算内存、非计算内存是操作系统的分类，所以操作系统知道硬盘上有对应，才叫非计算内存。

虽然任何数据库的内存占用绝大部分是磁盘缓冲，按理说其中的数据硬盘上有对应，但是，这些内存是数据库管理的，操作系统只知道这些内存是DBMS主动向操作系统申请的，其中放的什么，操作系统并不知道，所
以是计算内存
breakdown:
计算内存、非计算内存都是指物理内存占用，而物理内存的情况，由于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=0
而lru_file_repage=1是AIX系统的default的值
lru_file_repage参数存在的意义：
1、是否应该考虑VMM重分页计数
2、替换什么类型的内存
当lru_file_repage=0的时候将只替换非计算内存，这显然达到了我们需要保护计算内存的目的
最近看了些资料，发现AIX5.3相对于以前的版本在多方面有提高和改变
绝对是一个好版本，不得不佩服IBM开发人员
非计算内存在开通ftp或者nfs服务的时候, 可能会影响到oracle内存性能.
当然了，象我, 条件不允许, 生产库的小鸡又不能随便动, 郁闷。

有一点似乎需要纠正:
对于AIX ....可执行程序文件的代码段属于计算内存
虽然对于这些段来说(代码段和初始数据段) 其实是有文件部分在磁盘上对应的...但是最后还是会变成计算内存
这里有个转化的概念OS 的Loader在装入可执行文件时...因为从disk 装入...这时所使用的还是属于NonComp..
一旦发生指令预取的page fault....则NonComp会转为Comp
pageOut去swapdevice的pages 对AIX叫WorkingStoragePages
所有的WorkingStoragePages都是Comp
然而不是所有的Comp都是WorkingStoragePage
应该说Disk上有文件对应的就叫PermanentStoragePages....无文件对应的叫WorkingStoragePages
对不起，各位老大，水一下。

程序中
char *string1="ABCDEFG"; int number=22222;
属于初始化定义，也就是static的代码，到底是计算内存还是非计算内存，看以后是否有改写，由编译程序在编译的时候决定到低是什么。

如果以后虽然有引用，但是没有改写，则在程序代码段，非计算内存，例如类似char *string2; string2=string1的引用，其实这个变量是个常量,ABCDEFG保存在代码段中，非计算内存，string1作为指针本身并不存在，因为指向是个常量，程序可以优化，把这个指针省略掉。

如果以后有改写，例如string1=string2;则在程序初始化会在堆中申请空间，也就是计算内存，同时程序代码段还是有该常量ABCDEFG, 22222，这部分还是非计算内存。

-----------
另外非计算内存并非完全可以丢弃，其中还有是否dirty，如果dirty，等同于计算内存处理，我还没有证据说明aix足够聪明到对于dirty的非计算内存会直接写磁盘原数据区还是写paging space，但以我个人推断，由于写磁盘数据区的是syncd，而处理pagingspace的是swap，两个截然不同的进程，他们在那么短暂的时间内，没有道理会相互通信，而且很有可能死锁，最好的办法就是dirty非计算内存完全等同于计算内存，paging到交换区。

------------------
以上一段严重错误，（又是中午吃多了惹得祸，今天老板请吃自助餐）。

经过larry老大当头棒喝，醍醐灌顶，七窍顿开！lrud是唯一的对内存进行检验的程序，而是否sync到磁盘或者交换区，syncd自己是不管的，它尊从内存页标记，因此不会出现两个程序争相处理一块内存的情况。

再次感谢larry老大高风亮节，不耻屈尊与我等小辈讨论！不过经过刚刚专研，发现依然有疑惑，很多说法比较模糊，继续研究之中。

预知后事如何，请看下集。

---------------------------------------------
由此，如果有大量的数据文件改写操作，例如copy，tar的目标文件，都会造成内存消耗，而且无法通过参数优化，只能增加syncd的写操作频繁程度或者增加并行数来解决。

-------------------
这段没有大问题，但前提条件正如larry老大所说，系统有足够的fremem的时候才会等待syncd被动刷新，否则lrud会主动调用syncd刷新，由于有fremem存在，通常不会系统有太大影响，优化不优化没什么意义，除非此时系统紧跟（在几分钟之内）着要进行大量申请内存的操作，例如load数据等批量操作、启动数据库等等，由于系统会lazy清理内存，只有申请的时候才会清理，所以后续程序会稍慢，如果非常必要（就差几分钟，一般没必要），可以主动进行内存清理，把用于文件系统的内存writeback，并释放。

释放的方式有：
1.删除刚刚进行操作的大文件，文件没了，内存中的cache就没了，自然变成fremem
2. 抖动系统，就是更改maxfre, minfre之类的参数，改成很大的值，然后再改回来。

最后感谢一次Larry老大，您的光辉形象将永远成为激励我们前进的原动力！。