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。
所以一个文件的所有页只能属于一种类型，且在系统重启之前不会改变。 内存页的分类有助与通过参数调整内存交换程序的效率，详情参见：
http://www.ibm.com/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=\前者会导致自动向操作系统申请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=\
属于初始化定义，也就是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老大，您的光辉形象将永远成为激励我们前进的原动力！
原帖由 orian 于 2008-6-20 00:21 发表
另外非计算内存并非完全可以丢弃，其中还有是否dirty，如果dirty，等同于计算内存处理，我还没有证据说明aix足够聪明到对于dirty的非计算内存会直接写磁盘原数据区还是写paging space，但以我个人推断，由于写磁盘数据区的是syncd，而处理pagingspace的是swap，两个截然不同的进程，他们在那么短暂的时间内，没有道理会相互通信，而且很有可能死锁，最好的办法就是dirty非计算内存完全等同于计算内存，paging到交换区。
syncd只是确保flush文件系统cache的最后一道防线，缺省syncd间隔是60秒，这中间syncd肯定是不干活的，但我们知道，文件系统cache必须以60秒进行flush，而中间绝对不commit任何cache page，这显然不符合常理。
当遇到dirty的fs cache page，是一定会自动先flush它们的。
以下说法来自AIX Information Center：
文件同步性能调整
JFS 的非顺序文件 I/O 会一直存储在内存中直到满足一定条件：
空闲列表缩小到 minfree，以致需要进行页替换。 syncd 守护程序按固定调度间隔刷新页。 执行了 sync 命令。
随机后写在达到随机后写阈值后清空脏页面。
顺序后写
如果簇的所有 4 页都是脏页，那么只要修改了下一个分区中的页，会调度将该簇中的 4 个脏页写入磁盘。如果不具备这一功能，那么直到 syncd 守护程序运行前，该页都会留存于内存，导致可能的 I/O 瓶颈和文件碎片。
缺省情况下，一个 JFS 文件划分成 16 KB 大小的分区或 4 页。每一个这样的分区被称为一簇。
VMM 用于充当阈值的簇数是可调整的。缺省值是一簇。使用 ioo -o numclust 命令增大 numclust 参数可延迟后写入。
对于增强型 JFS，ioo -o j2_nPagesPerWriteBehindCluster 命令用来指定每次调度的页数，而不是簇数。增强型 JFS 簇的缺省页数为 32，意味着增强型 JFS 的缺省大小为 128 KB。
随机后写
后写功能提供了这样一种机制，即当给定文件在内存中的脏页数超过规定阈值后，那么会调
度所写的后续页面以写到磁盘上。
可能存在一些应用程序执行大量的随机 I/O，即 I/O 模式不满足后写算法的要求，因而导致所有页面驻留在内存中，直到 syncd 守护程序运行为止。如果应用程序修改了内存中的很多页面，那么在 syncd 守护程序发出 sync() 调用时，这会使得向磁盘写入大量页。
将 ioo 命令与 JFS maxrandwrt 参数一起使用，可调整阈值。缺省值为 0，表示随机后写是禁用的。将该值增加到 128 表示一旦文件驻留于内存的页达到 128 页，随后的任何脏页都将被调度写入磁盘。而这些页将在调用 sync() 后刷新。
对于增强型 JFS，ioo 命令选项 j2_nRandomCluster（-z 标志）和 j2_maxRandomWrite（-J 标志）用于调整随机后写。两个选项缺省值都为 0。增强型 JFS 的 j2_maxRandomWrite 选项和 JFS 的 maxrandwrt 功能相同。即它限定了每个文件可以留在内存中的脏页数。j2_nRandomCluster 选项指定了可以被视为随机的两次连续写入之间的簇数。
也就是说：
一个规则先说，这是前提：当一个fs cache page必须被另外使用时，一定是minfree已经达到了，否则系统只用从free list中取未用页来用即可。 ●顺序后写造成的dirty page，当真正需要用到这些页时，minfree已经达到，而minfree达到时，一定会做先做commit dirty page的事情，所以不用占用paging space；
●缺省情况下，随机后写完全是关闭的，所以随机后写不会导致fs cache被使用，也就不可能产生dirty
●非缺省情况下，随机后写打开，那么情形同顺序后写。
所以您设想的dirty fs cache page需要换出到paging space的可能性并不存在。
[ 本帖最后由 larryh 于 2008-6-20 01:36 编辑 ]
原帖由 FromHell 于 2008-6-19 21:54 发表
对于AIX ....可执行程序文件的代码段 属于计算内存
虽然对于这些段来说(代码 段和初始数据段) 其实是有文件部分在磁盘上对应的...但是最
后还是会变成计算内存
这里有个转化的概念 OS 的Loader在装入可执行文件时...因为从disk 装入 ...这时所使
用的还是属于NonComp..
一旦发生指令预取的page fault....则NonComp会转为Comp
这一点，我倒没有看到有足够详细的官方资料来证明是或否
由此我引申想到两个有趣的问题：
1、某个页当前属于非计算内存还是计算内存，是否有专用的页标志来标明？我怀疑没有，因为IBM自己，都可能对内存页的那么多种用途到底算什么类型没有完全一致意见（除了典型的，占用量大的类型没有什么异议外）。比如nmon和topas显示的非计算内存和计算内存比例就不同。
2、这个更加有趣，而且有兴趣有精力的可以做做试验（需要POWER汇编的知识，至少可以查看特定代码的十六进制数据体现是什么，以在内存中定位出来，我没做）。有没有用户进程可访问的非计算内存？按照概念来说不应该有。那么如果用户进程去写非计算内存，应当会被操作系统发现越权访问不属于自己的内存，而把它干掉同时产生coredump。
如果您说的代码实际被引用到，会导致其转化为计算内存这一点，确实是AIX的标准行为，那么这个计算内存算不算这个进程自有？
这样会有这么几种情况：
●代码已经被执行过，所以它是计算内存： 如果它属于用户进程自有：自然这个进程可以修改已经被执行过的自身代码——可以设计一个试验来验证；
如果它不属于用户进程，则必然属于系统进程：这个进程修改已经被执行过的自身代码的尝试将导致coredump；
●代码尚未被执行过，所以它是非计算内存：
非计算内存不应该属于进程自有，所以试图修改它会造成coredump。
又要翻船
在infocenter找到明确说明：
Pages that are part of working segments are written to paging space; persistent segments are
written to disk.（不过没有写是paging space还是file，还有机会。。。）
中午吃多了。。。嗨，怎么没想起来lrud是罪魁祸首，它会根据page情况调用磁盘写，否则也不会猜想两个进程争相刷新磁盘。。。
原帖由 larryh 于 2008-6-20 02:40 发表
1、某个页当前属于非计算内存还是计算内存，是否有专用的页标志来标明？我怀疑没有，因为IBM自己，都可能对内存页的那么多种用途到底算什么类型没有完全一致意见（除了典型的，占用量大的类型没有什么异议外）。比如nmon和topas显示的非计算内存和计算内
存比例就不同。
2、这个更加有趣，而且有兴趣有精力的可以做做试验（需要POWER汇编的知识，至少可以查看特定代码的十六进制数据体现是什么，以在内存中定位出来，我没做）。有没有用户进程可访问的非计算内存？按照概念来说不应该有。那么如果用户进程去写非计算内存，应当
会被操作系统发现越权访问不属于自己的内存，而把它干掉同时产生coredump。
如果您说的代码实际被引用到，会导致其转化为计算内存这一点，确实是AIX的标准行为，
那么这个计算内存算不算这个进程自有？
这样会有这么几种情况：
●代码已经被执行过，所以它是计算内存：
如果它属于用户进程自有：自然这个进程可以修改已经被执行过的自身代码——可以设计一
个试验来验证；
如果它不属于用户进程，则必然属于系统进程：这个进程修改已经被执行过的自身代码的尝
试将导致coredump；
●代码尚未被执行过，所以它是非计算内存：
非计算内存不应该属于进程自有，所以试图修改它会造成coredump。
发扬一不怕死，二不怕水，死猪不怕开水烫的精神，继续水。偷偷跟您说一声，为了保证灌水质量，我连晚饭都没吃，只喝水！力争保持清醒！忽然想起来，刚说了一句，现在LU高手越来越多，保不准什么时候就被一刀毙命！乌鸦嘴啊！
以下来自infocenter和我自己的理解，请大家多多水场。http://publib.boulder.ibm.com/in ... _memory_mngment.htm
VMM管理将memory分成page，缺省page大小4KB，但aix操作系统支持更大的page，例如16M，但对于非4k的page，aix不能处理page in/out，只能将其pin在real memory中，aix中每256M的memory只能采用一种page size（aix支持混合使用），而且不需要重新启动，（需要预先将vmo参数large_page_heap_size=1以允许其它page），只需更改vmo
参数到需要的大小，。但注意，使用其他大小的 page，不能交换。 与vmm不同， real memory (RAM)只有4k page, vmm管理程序需要将其page与real memory的4k对应（或者与磁盘交换区对应，就是page out出去了）。
vmm使用一些算法来进行对应。
Virtual-memory segments分为persistent segments 或者 working segments. Virtual-memory segments同时还被分为computational or file memory
如果需要访问的Virtual-memory pages不在real memory，则引起page fault中断 Page faults又可能是new-page faults或者repage faults，最近一段时间（这个时间长短好像是lrud扫描完一遍内存pool的时间，有待确认。lrud不停地循环扫描内存pool，内存pool的大小根据机器拥有的物理内存多少和cpu数量有关，vmstat -v可以看到memory pool的数量，每个pool对应lrud的一个线程）第一次访问此页是new page fault，如果在这段时间第二次发生此page faults，则是repage faults。如果发生repage fault，系统会记录下来vmstat 1 的re一项既是。
Persistent和working segments
Persistent内存页如larry老大所说，就是在磁盘上有对应的，无论程序，数据文件还是cache（其实也是为数据文件准备的）， working segment是临时生成，例如malloc申请的。但由于单位是segment（256M），所以并不能按照4k断定那个是persistent，那个是working，而是vmm根据内存申请的特点来存放对应的page（我猜想，不确定，有待探讨）。也就是说，系统一定知道那些page是persistent，那些是working，因为这些page在初始化使用的时候，是在不同的段里面申请的！如果读写文件，vmm就在persistent segment分配page给请求者（打开文件通常由lvm内核操作，所以是系统调用），而程序通过malloc申请，即使保存的是文件的一部分（通过memcpy过来），但系统依然认为是working，在working段分配。
如果persistent里面的page被修改并且不能在real memory保存(什么情况下不能保存？待确定），则vmm将其写回到磁盘上对应的数据文件区。如果没被修改，则直接丢弃，不需要io，以后再有需求，重新读回来，因为磁盘上有对应文件（数据）。
c程序在执行的时候，操作系统vmm会自动分配stack/data段（working），heap段（working）, program text段（persistent）， shared lib段（persistent），每段256M，但只是一个虚拟空间，程序真正使用的时候，才会占据一个又一个4k，才会对应到real memory
Working segments是个临时区域，仅仅存活于程序执行期间，磁盘上也没有对应的数据文件。一点例外，系统内核的text和shared library本来应当保存在persistent段（因为内核也是程序，而程序的这些区域应当是persistent内存），但是他们也被算作working的，难道是防止系统运行过程中系统内核文件被误删除直接导致系统崩溃？而给大家留个缓冲时间，因为这些文件不会再从磁盘读入，只读一次，以后即使内存不够，也不会如同其他
程序文件直接丢弃，而是交换到paging space! 推论：如果误删除了系统内核文
件（限于执行文件和调用库，参数文件不算），千万别停机，系统还会正常工作！想办法还
能从内存中找回来。
Persistent-segment还有更多的类型。Client segments 是用于远程文件，例如nfs mount过来的，这些page如果需要交换出去，则写回原位置或者丢弃（如果没有修改），而不会交换到交换区（我印象中4.3.3似乎是写本地交换区，估计是现在认为网络足够快了）。Journaled和deferred segments是persistent segments，必须进行原子操作写（原子操作大家都知道，就是同时只允许一个线程进行写，别的必须等待，不能并行写） 如果 journaled或者deferred segment需要从real memory偷页 (paged out), it must be written to disk paging space unless it is in a state that allows it to be committed (written to its permanent file location).
这是真正的疑点所在，哪些数据属于Journaled和deferred？我猜想是jfs的inode之类的数据，deferred呢？不确定。先放到这，回去找aix kernal internal继续专研。
Computational和file memory
Computational memory也就是computational pages, 包含working-storage segments或者program text (executable files) segments. 也就是说计算内存包括working段或者程序代码。 又出现疑点，程序代码以往我是当成非计算内存的，难道又疏忽了。。。？
file memory是所有其他的内存页，交换到自己原有对应的文件，这没什么说的。
但愿是5.3与以往版本有出入，否则误人子弟，诲人不倦啊！专研几天先。
多谢Larry老大给我们指出了一条康庄大道，道上还堆砌了无数荆棘。。。
原帖由 larryh 于 2008-6-20 21:12 发表
jfs2用的是client段，这个和jfs不同，也就是说应当和NFS的处理方法完全一样了。至于fs cache在NFS和JFS之间表现有什么不同我还不清楚
黄老大能详细指点一下？ 永久存储
永久存储分页是一些包含永久数据（也就是说，重新启动后仍然存在的数据）的分页。这种永久数据就是文件数据。因此，永久存储分页就是缓存在内存中的部分文件。
当经过修改的永久存储分页需要换出（从内存移动到磁盘）的时候，会将它写入到文件系统中。如前所述，可以直接释放没有经过修改的永久存储分页，无需将其写入到文件系统中，
因为文件系统包含该数据的原始副本。
例如，如果一个应用程序正在读取某个文件，那么该文件数据将缓存于永久存储分页的内存中。这些永久存储分页没有经过修改，这意味着并没有在内存中对这些分页进行修改。因此，内存中的永久存储分页与磁盘中的文件数据完全相同。当 AIX 需要清空内存的时候，它只需要“释放”这些分页即可，而不将任何内容写入到磁盘。如果应用程序对某个文件进行写操作（而不是读操作），那么永久存储分页将是“经过修改的”，并且 AIX 必须在释放这些分页之前将其刷新到磁盘。
您可以将永久存储分页划分为两种子类型：
客户端分页
非客户端分页
非客户端分页是一些包含缓存的日志文件系统 (JFS) 文件数据的分页。非客户端分页有时也称为持久性分页。客户端分页是一些包含所有其他文件系统（例如，JFS2 和网络文件系统 (NFS)）的缓存数据的分页。 ibm developer works上的！
正好要写aix 未公开的秘密，今天就把内存这个问题终结吧。。。哈哈，口气有点大，我没说我终结啊！等待黄老大、农老大、鸡老大、红旗老大、void老大、beginner老大以及各位隐
形埋名的世外高人老大总结
鉴于细节太多，本文为续，只针对以前疑问。具体请参考以前讨论。本文内容引自inforcenter, developerworks（为主，假定其为真实）及其它google搜索结果（为辅，参考），并且时间为今天，版本是5.3（以后ibm可能更新算法，所以不能确认永远如此）
page 虽然可以有超过4k的内存page，但为了简化讨论，一下均指4k。
PFT page frame table， 这是物理内存分配、状态表。所有物理内存都在表中有对应，大概4k的page用8位标记（这个不确认，还没来得及查找信息）。其中有内存地址、内存类型（分别是Working, Persistent, Client类型，这回答了Larry的问题）、最近是否被访问（reference）、是否被修改标记。
当由于程序看到的是全部vmm，因此无论申请内存还是访问内存，都会发生vmm地址和real mem地址的转换，这个是cpu中硬件完成，如果转换的地址不在real mem中，则发生mem fault，并触发内核处理，内核将在free memory中申请一块空间，并把需要的vmm数据读到此处（如果需要读入，如果新申请，当然就不用读入了）
根据一些参数，aix维护一个free memory的列表，这个已经讨论多次，暂时不提。如果free memory不足，试图释放一些real memory内存出来。reallrud首先开始扫描物理内存页（real memory=physical memory），检查此page最近是否被referenced，如果没有被reference，立刻释放，而并在第一次扫描的时候已经被reference，则清掉reference标记。物理内存被分为若干bucket，大小为vmo中lrubucket界定，缺省512M，第一次扫描完某个bucket之后，找不到可释放内存（这句话不确定，也可能无论怎样都扫描两遍），则重新再扫描一遍这个bucket，如果某页依然没被referenced，则释放。这两遍扫描的时间就是给内存是否被频繁referenced的缓冲时间，内存从来没reference，立刻释放，如果被reference过，则等一小段时间，再看。此内存很忙，很有可能在两遍扫描期间被referenced，这样该内存也就被保留下来，不会释放，如果没有，则释放。这种两遍扫描的策略，最大限度增加了可被释放内存的数量（如果大部分内存都不能被释放，lrud效率就变得很低），但同时给可能被频繁访问的内存留有机会。
不知道这种策略是否最好，但肯定不错。通过以上分析，如果更改lru bucket的大小可以极大地影响第二次扫描的结果，也就是如果lru bucket越小，则内存被referenced的可能性越小（扫描间隔越小，时间大约是用cpu做一遍bucket大小内存hash比较的时间，缺省是128KB，估计远在1微秒以内）。对于高速cpu系统，例如在若干GHz这种cpu速度下，这个时间可能太小，在此期间，通常都不会被reference，所以也许很没效率，就是最近被访问的页面也被弄出去了。注意，这部分不一定对应的paging space操作，但很可能对应文件系统操作。一个建议，如果系统具有极其巨大的内存，例如几百G，并且使用文件系统，不妨尽可能增大lrubucket，最大可达到系统所拥有的所有物理内存页面。反之，可以减到最小65536。本人不负责后果！haha vmstat的sr, fr可以观看结果。
有关repage, aix保存一个repage history buffer, 如果在一段时间第二次发生此page faults，则是repage faults。如果发生repage fault，系统会记录下来vmstat 1 的re一项既是。系统依然用512M大约128KB的 history buffer空间，置于能保留多长时间，那就看此page fault发生的频率了，也就是如果系统reference page越多，page fault的可能性越大，history buffer也对应的时间也就越短。
此参数在系统没有严重设计问题的时候（例如内存过小，或者分配不合理），应当没什么用，但一旦有repage（同样不能有pi, po），一定要想办法避免。
memory pools影响lrud的并行度，如果cpu多，可以最多设置为cpu数量。
strict_maxperm 影响file cache，也就是限定了系统分配给filesystem cache的最大值为maxperm。
不写了，休息，休息一会。