glance查看进程内存使用过大问题

Question

Terms

VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS

Overview
The aim of this post is to provide information that will assist in interpreting memory reports from various tools so the true memory usage for Linux processes and the system can be determined.

Android has a tool called procrank (/system/xbin/procrank), which lists out the memory usage of Linux processes in order from highest to lowest usage. The sizes reported per process are VSS, RSS, PSS, and USS.

For the sake of simplicity in this description, memory will be expressed in terms of pages, rather than bytes. Linux systems like ours manage memory in 4096 byte pages at the lowest level.

VSS (reported as VSZ from ps) is the total accessible address space of a process. This size also includes memory that may not be resident in RAM like mallocs that have been allocated but not written to. VSS is of very little use for determing real memory usage of a process.

RSS is the total memory actually held in RAM for a process. RSS can be misleading, because it reports the total all of the shared libraries that the process uses, even though a shared library is only loaded into memory once regardless of how many processes use it. RSS is not an accurate representation of the memory usage for a single process.

PSS differs from RSS in that it reports the proportional size of its shared libraries, i.e. if three processes all use a shared library that has 30 pages, that library will only contribute 10 pages to the PSS that is reported for each of the three processes. PSS is a very useful number because when the PSS for all processes in the system are summed together, that is a good representation for the total memory usage in the system. When a process is killed, the shared libraries that contributed to its PSS will be proportionally distributed to the PSS totals for the remaining processes still using that library. In this way PSS can be slightly misleading, because when a process is killed, PSS does not accurately represent the memory returned to the overall system.

USS is the total private memory for a process, i.e. that memory that is completely unique to that process. USS is an extremely useful number because it indicates the true incremental cost of running a particular process. When a process is killed, the USS is the total memory that is actually returned to the system. USS is the best number to watch when initially suspicious of memory leaks in a process.

For systems that have Python available, there is also a nice tool called smem that will report memory statistics including all of these categories.

# procrank
procrank
PID      Vss      Rss      Pss      Uss cmdline
481   31536K   30936K   14337K    9956K system_server
475   26128K   26128K   10046K    5992K zygote
526   25108K   25108K    9225K    5384K android.process.acore
523   22388K   22388K    7166K    3432K com.android.phone
574   21632K   21632K    6109K    2468K com.android.settings
521   20816K   20816K    6050K    2776K jp.co.omronsoft.openwnn
474    3304K    3304K    1097K     624K /system/bin/mediaserver
37     304K     304K     289K     288K /sbin/adbd
29     720K     720K     261K     212K /system/bin/rild
601     412K     412K     225K     216K procrank
   1     204K     204K     185K     184K /init
35     388K     388K     182K     172K /system/bin/qemud
284     384K     384K     160K     148K top
27     376K     376K     148K     136K /system/bin/vold
261     332K     332K     123K     112K logcat
33     396K     396K     105K      80K /system/bin/keystore
32     316K     316K     100K      88K /system/bin/installd
269     328K     328K      95K      72K /system/bin/sh
26     280K     280K      93K      84K /system/bin/servicemanager
45     304K     304K      91K      80K /system/bin/qemu-props
34     324K     324K      91K      68K /system/bin/sh
260     324K     324K      91K      68K /system/bin/sh
600     324K     324K      91K      68K /system/bin/sh
25     308K     308K      88K      68K /system/bin/sh
28     232K     232K      67K      60K /system/bin/debuggerd
#

Answer 1

hoho
厉害

Answer 2

太详细了！好东西！

Answer 3

回复 3# pecker_zhao

   对HPUX的内存管理也不是很了解，也是想通过这个帖子学习一下。

好像只看到有一句是不是 只要swapinfo -atm 中的/dev/ used 是0，那就是没发生到/dev上面真正硬盘的交换，那么内存就不存在什么瓶颈

对于HPUX中glance认为text是共享的，RSS中是不是就少了text.share lib ,只有stack heap等

Answer 4

HP-UX下可以使用glance工具监视进程的内存使用情况。比如：

opt/perf/bin> ./glance

when glance is launched we see the PROCESS LIST screen:

                                  PROCESS LIST                      Users=    3

                              User      CPU Util     Cum     Disk         Block

  Process Name   PID   PPID Pri Name    ( 200% max)    CPU   IO Rate    RSS    On

  --------------------------------------------------------------------------------

  ora_pmon_L8  24346      1 156 lsupport  0.0/ 0.0     0.0  0.0/ 0.0  41.8mb OTHER

  ora_pmon_R8   3691      1 156 rsupport  0.0/ 0.0     0.0  0.0/ 0.0   5.4mb   SEM

  ora_reco_L8  24356      1 156 lsupport  0.0/ 0.0     0.0  0.0/ 0.0  32.1mb OTHER

  ora_reco_R7   5501      1 156 rsupport  0.0/ 0.0     0.0  0.0/ 0.0  12.7mb OTHER

                                                                    

我们观察3691号进程的内存使用情况。输入m并输入进程号，显示如下信息：

Memory Regions PID:  3691, ora_pmon_R817   PPID:     1 euid:1040 User: rsupport

                              

  Type     RefCt   RSS    VSS  Locked  Virtual Address      File Name   

  --------------------------------------------------------------------------------

  TEXT  /S    9 10.0mb 16.0mb    0kb 0x0dd7d400.0x00001000

  DATA  /P    1  1.8mb  2.1mb    0kb 0x08188000.0x40001000

  MEMMAP/P    1    4kb    4kb    0kb 0x08188000.0x7aff6000

  MEMMAP/P    1    4kb   20kb    0kb 0x08188000.0x7aff7000

  MEMMAP/P    1    8kb    8kb    0kb 0x08188000.0x7affc000

  MEMMAP/P    1   12kb   12kb    0kb 0x08188000.0x7affe000

  MEMMAP/P    1   12kb   16kb    0kb 0x08188000.0x7b001000

  MEMMAP/P    1    4kb    4kb    0kb 0x08188000.0x7b005000

  MEMMAP/P    1   12kb   16kb    0kb 0x08188000.0x7b006000

  MEMMAP/P    1   40kb   44kb    0kb 0x08188000.0x7b00a000

  MEMMAP/P    1   60kb  136kb    0kb 0x08188000.0x7b015000

  MEMMAP/P    1   12kb   12kb    0kb 0x08188000.0x7b037000

  STACK /P    1   20kb   20kb    0kb 0x08188000.0x7b03a000

  UAREA /P    1   16kb   16kb    0kb 0x09489800.0x7ffe6000

  LIBTXT/S  150   56kb   60kb    0kb 0x00000000.0xc0003000

  LIBTXT/S   95  1.2mb  1.4mb    0kb 0x00000000.0xc0012000

  LIBTXT/S  150    4kb    4kb    0kb 0x00000000.0xc0177000

  LIBTXT/S  115  440kb  440kb    0kb 0x00000000.0xc054a000

  LIBTXT/S   55   72kb   76kb    0kb 0x00000000.0xc06d4000

  LIBTXT/S    9    4kb    8kb    0kb 0x00000000.0xc2b8e000

  SHMEM /S    9  2.6mb  5.5mb    0kb 0x00000000.0xc9de8000

  0/lvol9,inode:20151>   

  Text  RSS/VSS: 10mb/ 16mb  Data  RSS/VSS:1.8mb/2.1mb  Stack RSS/VSS: 20kb/ 20kb

  Shmem RSS/VSS:2.6mb/5.5mb  Other RSS/VSS:2.0mb/2.2mb

可以看出，代码16MB，私有数据占2.1MB，堆栈占用20KB，共享内存占用5.5MB，其他内存占用2.2MB。

Answer 5

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之上

     Process Name PID PPID Pri Name ( 300% max) CPU IO Rate RSS Cnt
--------------------------------------------------------------------------------
glance 7961 11741 154 root 0.9/ 1.8 0.5 0.0/ 0.0 21.4mb 1
oraclevcard 2194 1 154 oracle 0.7/ 0.1 3060.2 0.0/ 0.0 61.4mb 1
midaemon 15077 1 -16 root 0.2/ 0.2 6648.9 0.0/ 0.0 26.2mb 3
oraclevcard 2204 1 154 oracle 0.0/ 0.1 3062.9 0.0/ 0.0 61.1mb 1
oraclevcard 14589 1 154 oracle 0.0/ 0.0 1.0 0.0/ 0.0 80.5mb 1
oraclevcard 25202 1 154 oracle 0.0/ 0.0 17.8 0.0/ 0.0 61.2mb 1
oraclevcard 25149 1 154 oracle 0.0/ 0.0 27.6 0.0/ 0.0 79.9mb 1
oraclevcard 17069 1 154 oracle 0.0/ 0.0 23.0 0.0/ 0.0 79.6mb 1
scopeux 15078 1 127 root 0.0/ 0.1 3753.4 0.0/ 0.1 23.5mb 1
oraclevcard 2206 1 154 oracle 0.0/ 0.1 3060.9 0.0/ 0.0 61.4mb 1
oraclevcard 2214 1 154 oracle 0.0/ 0.0 410.9 0.0/ 0.0 64.7mb 1
oraclevcard 2208 1 154 oracle 0.0/ 0.1 3064.9 0.0/ 0.0 61.1mb 1
oraclevcard 16060 1 154 oracle 0.0/ 0.0 39.8 0.0/ 0.0 79.5mb 1
oraclevcard 10987 1 154 oracle 0.0/ 0.0 104.3 0.0/ 0.0 79.4mb 1
oraclevcard 11009 1 154 oracle 0.0/ 0.2 695.2 0.0/ 0.0 80.0mb 1
oraclevcard 7900 1 154 oracle 0.0/ 0.2 0.2 0.0/ 0.0 60.7mb 1
oraclevcard 7861 7860 154 oracle 0.0/ 0.1 0.1 0.0/ 0.0 62.1mb 1
oraclevcard 6838 1 154 oracle 0.0/ 0.0 0.2 0.0/ 0.0 64.4mb 1
oraclevcard 6882 1 154 oracle 0.0/ 0.0 0.3 0.0/ 0.0 62.2mb 1
oraclevcard 6890 1 154 oracle 0.0/ 0.0 0.2 0.0/ 0.0 63.9mb 1
oraclevcard 6015 1 154 oracle 0.0/ 0.0 0.2 0.0/ 0.0 60.7mb 1
oraclevcard 5675 1 154 oracle 0.0/ 0.0 0.5 0.0/ 0.0 64.0mb 1
oraclevcard 5705 1 154 oracle 0.0/ 0.0 0.2 0.0/ 0.0 60.9mb 1
oraclevcard 5815 1 154 oracle 0.0/ 0.0 0.3 0.0/ 0.0 60.7mb 1
oraclevcard 6374 1 154 oracle 0.0/ 0.0 1.3 0.0/ 0.0 79.5mb 1
oraclevcard 2202 1 154 oracle 0.0/ 0.1 3061.3 0.0/ 0.0 61.4mb 1
oraclevcard 2200 1 154 oracle 0.0/ 0.1 3059.1 0.0/ 0.0 61.4mb 1
○2 开一个Oracle连接并找到其进程号为7861
$ sqlplus qiuyb/test

SQL*Plus: Release 9.2.0.6.0 - Production on Fri Apr 18 09:12:06 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production

SQL>

# ps -ef|grep "sqlplus qiuyb"
oracle 7860 7579 0 09:13:04 pts/te 0:00 sqlplus qiuyb/byuiq_145
root 7891 11741 1 09:13:35 pts/td 0:00 grep sqlplus qiuyb
#
# ps -ef|grep 7860
oracle 7860 7579 0 09:13:04 pts/te 0:00 sqlplus qiuyb/test
oracle 7861 7860 0 09:13:04 ? 0:00 oraclevcard (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
root 8107 11741 1 09:16:24 pts/td 0:00 grep 7860
○3glance里7861进程占用内存(RSS)为57.9mb
User CPU Util Cum Disk Thd
Process Name PID PPID Pri Name ( 300% max) CPU IO Rate RSS Cnt
--------------------------------------------------------------------------------
oraclevcard 7861 7860 154 oracle 0.0/ 0.0 0.2 0.0/ 0.0 57.9mb 1

    ○4kmeminfo里7861占用内存为56.6mb
    # ./kmeminfo -user |grep 7861
    7861 7860 548101 2.1g 14481 56.6m 14332 56.0m oracle
    ○5 ps里7861占用了16992个内存页，计算起来为66.375mb
    每个内存页为4096字节：
    # getconf PAGE_SIZE
    4096
    执行ps命令：

    # ps -flp 7861
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME COMD
1001 S oracle 7861 7860 0 154 20 6e5745c0 16992 4f54e32e 09:13:04 ? 0:00 oraclevcard (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
计算一下：
16992*4096/1024/1024=66.375mb
○6 看一下Oracle库内查到的该进程的pga占用为多少，结果为306kb
SQL> SELECT pga_alloc_mem,pga_max_mem FROM v$process WHERE spid=7861
2 /

PGA_ALLOC_MEM PGA_MAX_MEM
------------- -----------
313689 313689

    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的计算公式为：
    RSS = sum of private region pages +(sum of shared region pages /number of references)

        其中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的计算方式而产生的差别的因素，原文中的一段如下：
    On HP-UX, the calculation of this metric differs depending on whether this process has used any CPU time since the midaemon process was started. This metric is less accurate and does not include shared memory regions in its calculation when the process has been idle since the midaemon was started.
    This value is only updated when a process uses CPU. Thus, under memory pressure, this value may be higher than the actual amount of resident memory for processes which are idle because their memory pages may no longer be resident or the reference count for shared segments may have changed.
    即因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工具了。
    # ./procsize -R -p 7861
    libp4 (6.93): Opening /stand/vmunix /dev/kmem

    Loading symbols from /stand/vmunix
    regions set to 1000
    hpux 11.11 64 bit in Wide mode
    nproc=30000
    pid Comm UAREA TEXT DATA STACK SHMEM IO MMAP Total
    7861 oracle r 8 16384 512 96 524661 0 1203 542865
    其中-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。
    User CPU Util Cum Disk Thd
    Process Name PID PPID Pri Name ( 300% max) CPU IO Rate RSS Cnt
    --------------------------------------------------------------------------------
    oraclevcard 7861 7860 154 oracle 0.0/ 0.0 0.2 0.0/ 0.0 57.9mb 1

    Resources PID: 7861, oraclevcard PPID: 7860 euid: 103 User: oracle
    --------------------------------------------------------------------------------
    CPU Usage (util): 0.0 Log Reads : 0 Wait Reason : PIPE
    User/Nice/RT CPU: 0.0 Log Writes: 0 Total RSS/VSS : 57.9mb/ 58.9mb
    System CPU : 0.0 Phy Reads : 0 Traps / Vfaults: 0/ 0
    Interrupt CPU : 0.0 Phy Writes: 0 Faults Mem/Disk: 0/ 0
    Cont Switch CPU : 0.0 FS Reads : 0 Deactivations : 0
    Scheduler : HPUX FS Writes : 0 Forks & Vforks : 0
    Priority : 154 VM Reads : 0 Signals Recd : 0
    Nice Value : 20 VM Writes : 0 Mesg Sent/Recd : 0/ 0
    Dispatches : 0 Sys Reads : 0 Other Log Rd/Wt: 0/ 0
    Forced CSwitch : 0 Sys Writes: 0 Other Phy Rd/Wt: 0/ 0
    VoluntaryCSwitch: 0 Raw Reads : 0 Proc Start Time
    Running CPU : 0 Raw Writes: 0 Fri Apr 18 09:14:16 2008
    CPU Switches : 0 Bytes Xfer: 0kb :
    Argv1: (DESCRIPTION=(LOCAL=YES)
    Cmd : oraclevcard (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
    再键入”M”，进入详细的内存分布列表，如下：
    Memory Regions PID: 7861, oraclevcard PPID: 7860 euid: 103 User: oracle

    Type RefCt RSS VSS Locked File Name
    --------------------------------------------------------------------------------
    NULLDR/Shared 137 4kb 4kb 0kb <nulldref>
    MEMMAP/Shared 55 4kb 4kb 0kb /var/spool/pwgr/status
    TEXT /Shared 41 64.0mb 64.0mb 0kb /oracle/.../bin/oracle
    UAREA /Priv 1 32kb 32kb 0kb <uarea>
    DATA /Priv 1 2.0mb 2.0mb 0kb /oracle/.../bin/oracle
    MEMMAP/Priv 1 512kb 512kb 0kb <mmap>
    MEMMAP/Priv 1 16kb 16kb 0kb <mmap>
    MEMMAP/Priv 1 8kb 8kb 0kb <mmap>
    MEMMAP/Priv 1 60kb 60kb 0kb /usr/lib/pa20_64/libc.2
    MEMMAP/Priv 1 52kb 52kb 0kb <mmap>
    MEMMAP/Priv 1 12kb 12kb 0kb /usr/lib/pa20_64/libm.2
    MEMMAP/Priv 1 4kb 4kb 0kb /usr/lib/pa20_64/libdl.1
    MEMMAP/Priv 1 8kb 8kb 0kb <mmap>
    MEMMAP/Priv 1 4kb 4kb 0kb /usr/.../libnss_dns.1
    MEMMAP/Priv 1 12kb 12kb 0kb /usr/.../libpthread.1
    MEMMAP/Priv 1 8kb 8kb 0kb <mmap>
    MEMMAP/Priv 1 4kb 4kb 0kb /usr/lib/pa20_64/librt.2
    MEMMAP/Priv 1 36kb 272kb 0kb /usr/lib/pa20_64/libcl.2
    MEMMAP/Priv 1 0kb 32kb 0kb <mmap>
    MEMMAP/Priv 1 8kb 8kb 0kb <mmap>
    MEMMAP/Priv 1 500kb 504kb 0kb /oracle/.../libjox9.sl
    MEMMAP/Priv 1 0kb 12kb 0kb <mmap>
    MEMMAP/Priv 1 4kb 4kb 0kb /oracle/.../libskgxn9.sl
    MEMMAP/Priv 1 4kb 4kb 0kb /oracle/.../libodmd9.sl
    MEMMAP/Priv 1 8kb 8kb 0kb <mmap>
    MEMMAP/Priv 1 8kb 8kb 0kb /usr/lib/pa20_64/dld.sl
    MEMMAP/Priv 1 4kb 4kb 0kb <mmap>
    STACK /Priv 1 384kb 576kb 0kb <stack>
    MEMMAP/Shared 44 140kb 140kb 0kb /usr/lib/pa20_64/dld.sl
    MEMMAP/Shared 43 12kb 12kb 0kb /usr/.../libnss_dns.1
    MEMMAP/Shared 44 16kb 20kb 0kb /usr/lib/pa20_64/librt.2
    MEMMAP/Shared 41 4kb 4kb 0kb /oracle/.../libodmd9.sl
    MEMMAP/Shared 41 8kb 8kb 0kb /oracle/.../libskgxn9.sl
    MEMMAP/Shared 44 16kb 16kb 0kb /usr/lib/pa20_64/libdl.1
    MEMMAP/Shared 44 72kb 532kb 0kb /usr/lib/pa20_64/libcl.2
    MEMMAP/Shared 44 96kb 96kb 0kb /usr/.../libpthread.1
    MEMMAP/Shared 44 136kb 152kb 0kb /usr/lib/pa20_64/libm.2
    MEMMAP/Shared 44 1.1mb 1.1mb 0kb /usr/lib/pa20_64/libc.2
    MEMMAP/Shared 41 1.9mb 5.4mb 0kb /oracle/.../libjox9.sl
    SHMEM /Shared 41 2.00gb 2.02gb 0kb <shmem>

    Text RSS/VSS: 64mb/ 64mb Data RSS/VSS:2.0mb/2.0mb Stack RSS/VSS:384kb/576kb
    Shmem RSS/VSS:2.0gb/2.0gb Other RSS/VSS:4.7mb/9.0mb

    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真实占用内存（私有区）=
    32kb+2.0mb+512kb+….+500kb+0kb+4kb+4kb+8kb+8kb+4kb+384kb=3.6mb
    Shared部分均摊=
    4kb/137+4kb/55+64.0mb/41+…. +1.1mb/44+1.9mb/41+2.00gb/41=54mb
    所以RSS=54+3.6=57.6mb
    与57.9mb基本相当，当然这其中有精度及取舍的问题。
5 补充
    5.1 如果通过inode发现相应的文件
        有的时候进程详细列表显示的不是文件面是inode，如inode:8391，那8391是哪个文件呢？方法如下：

     # lsof |grep 8391
oracle 2048 oracle txt REG 64,0x9 77848056 8391 /oracle (/dev/vg00/lv_oracle_software)
oracle 2050 oracle txt REG 64,0x9 77848056 8391 /oracle (/dev/vg00/lv_oracle_software)
oracle 2052 oracle txt REG 64,0x9 77848056 8391 /oracle (/dev/vg00/lv_oracle_software)
oracle 2054 oracle txt REG 64,0x9 77848056 8391 /oracle (/dev/vg00/lv_oracle_software)
oracle 2056 oracle txt REG 64,0x9 77848056 8391 /oracle (/dev/vg00/lv_oracle_software)

# ncheck -i 8391 /dev/vg00/lv_oracle_software
/dev/vg00/lv_oracle_software:
8391 /app/oracle/product/9.2.0/bin/oracle

    5.2 如何查看所有进程的实际占用的多少？
        可以使用如下命令：
    procsize -fcn |sort -rnk 11 | more
    每一行，把Total 减掉TEXT项后，再乘上4096大体即为该进程实际占用的大小

Answer 6

本文使用的系统工具
    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命令的功能。
    sd11#[root:/]swlist -l product|grep -i glance
    Glance C.03.72.00 HP GlancePlus/UX

    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命令
    不用太细说，应该是每个人都用过，查看进程状态的。

Answer 7

什么是交换(Swap)与伪交换(Pseudo swap)?

关键字：交换分区、伪交换、swap、Pseudo swap

与其他版本的 Unix 一样，HP-UX 也使用 Virtual Memory 将进程加载到内存中。简单来讲，Virtual Memory 由两部分组成，物理内存，即 RAM 和 swap。物理内存是程序运行所在的位置，swap 是 "交换"。Swap 设备通常属于物理硬件驱动器。 Swap 允许进程的总数超过物理 RAM 的数量，而且可以根据需要进行分配。

产生 (Spawn) 进程时，Kernel 将检查虚拟内存，看看该进程是否可以直接加载到物理内存中。该 Kernel 还会进行检查，以确保该进程能够节省 swap 区域中的空间。如果两个测试均失败，该进程则不会产生，将被终止。生成的错误消息为 malloc 或 fork 失败。所有进程都必须能够节省 swap 区域中的空间。要保留足够的可用物理内存，以便进程运行，有一个被称为 vhand 的 daemon 会扫描 Kernel 中的所有进程表，查找尚未使用过的数据页。如果 vhand 发现了任何 "非活动" 页，vhand 就会将这些页移动到 swap 区域。如果可用内存下降至太低，另一个被称为 swapper 的 daemon 则会删除或 swap 出整个进程。Swapper 将继续将进程从物理内存推入 swap 区域，直到可用内存增加。当系统进行 swap 时，该 swapper 进程非常活跃。在 HP-UX 10.x 及以上版本中，不会 swap 出整个进程，而只是 swap 部分进程。Swap 的部分进程称为已分页。

如果系统上没有配置足够的 swap，系统性能则可能会受到很大的影响。有些影响是，系统可能无法访问系统上安装的所有物理内存。只有在 Swap 区域的可用空间多到可用于进程的情况下，Kernel 才允许产生进程。应用程序也依赖于 swap，如果没有配置足够的 swap，则生成与内存相关的错误消息，如 malloc 或 fork 失败。如果系统无须将进程从物理内存 swap 到 swap 区域，则将执行附加磁盘 I/O。该 Kernel 还将使用附加资源来监视内存并处理进程到 swap 设备的移动。这种附加开销将降低系统性能。如果这一问题非常严重，系统则可使用所有 CPU 或进程管理的其他资源。一旦系统达到此状态，则称为 Thrashing。

您至少应该将 Swap 和物理内存的比例配置为 1:1。这是一个基础比例，允许您访问整个物理 RAM，并处理大多数操作系统的 swap 需求。但是，您安装的应用程序可能需要配置更多 swap。您应该与供应商或提供商联系，获得更多有关 swap 的建议。一般系统上的物理内存数量不会是 swap 数量的四倍。

用于 swap 的磁盘区或者 logical volume 称为设备 swap。默认情况下，安装了操作系统的情况下 (/dev/vg00/lvol2)，系统至少会配置一个区域的设备 swap。设备 swap 就是一个 logical volume 或者一个磁盘区，是为系统提供用于 swap 的。类似 bdf 的命令不会显示系统上的 swap，但是 swapinfo 命令会显示。设备 swap 可以配置在系统上的任意 volume group 上。涉及到性能问题时，最提倡使用 logical volume，当系统需要附加 swap 时应首先配置 logical volume。设备 swap 也包括两个术语，第一个是主 swap。此 swap 设备应为 /dev/vg00/lvol2，是在安装操作系统时创建的。主 swap 只能位于引导驱动器上。任何附加设备 swap 都称为次 swap。次 swap 设备可以配置在任何 volume group 上。

文件系统 swap 使系统管理员能够在所有磁盘空间均已分配给文件系统的情况下，向系统添加更多的 swap。使用文件系统 swap，您可以设置和配置文件系统中可用的空间。当您分配文件系统 swap 时，该系统会创建一个目录，称为 paging，并会在该 paging 目录中创建 swap 文件。当且仅当系统开始向该 swap 区域进行 swap 时，系统才会执行到这些文件的写入。系统性能将会因维护文件系统 swap 而受到影响。这是因为，操作系统已经从物理内存删除了页，然后将其以小块的形式写入文件。如果系统只需要文件系统 swap 用于保留空间，系统的性能就不会受到影响。文件系统 swap 应该仅用作 swap 问题的临时解决方案。一旦向系统中添加了附加驱动器，文件系统 swap 就应尽快删除。由于性能方面的原因，我们建议将文件系统 swap 区域的优先级设成高于设备 swap。

Pseudo swap 是该规则的例外。Pseudo swap 可使系统管理员利用具有较大物理 ram 的系统，而无须配置较大的 swap 区域。Pseudo swap 不是设备 swap 的替代品，而是 swap 的增强。当系统引导时，会计算 pseudo swap 的数量。此计算是 75% 的物理内存，此值是不可调整内核参数。该 Kernel 会此增强看作是产生新进程时可以分配的附加 swap 区域。系统只会将 pseudo swap 用作保留空间，而不会将进程分页进出 pseudo swap。如果进程需要分页出物理内存，Kernel 则会 swap 到设备或文件系统 swap。Pseudo swap 默认情况下处于打开状态，将内核参数 swapmem_on 改为 off，即可关闭。

下面是使用 pseudo swap 的优点示例。假设我们有一个系统，它有 1GB 的物理 RAM。要使操作系统能够使用所有内存，操作系统至少需要 1GB 的 swap。系统管理员为 swap 配置了 1GB 的 logical volume。另外，系统管理员还保持 pseudo swap 处于启用状态。当系统引导时，它会将 75% 的物理内存配置成 pseudo swap。我们大约有 750 (1000 * .75)M 的附加 swap 用于该系统。现在系统的 swap 总数为 1.75GB，或 2.75GB 的虚拟内存。Pseudo swap 不会增大 swap 的总数。Kernel 会将该系统视为具有 1.75 GB 的 swap，并将按照系统配置了 1.75GB 设备 swap 的方式使用 swap。但是，只配置了 1GB 的设备 swap。

由于 pseudo swap 会增加系统上的 swap 总数，所以有些系统管理员可能想减少设备 swap 的数量，并将该空间用于数据。在有些情况下，系统管理员可以执行此操作。此外，系统管理员还需要规划转储空间。此转储空间用于系统写入系统崩溃。默认情况下，主 swap (/dev/vg00/lvol2) 既用于 swap 也用于转储。在 10.X 系统上，系统管理员必须将 root volume group，即 /dev/vg00 上的设备 swap 和物理内存比例配置成至少 1:1。这样即能满足操作系统的最小 swap 和转储需求。在 11.0 及以上版本中，不再需要将 swap/转储空间与物理内存的比例配置为 1:1。配置系统崩溃只是为了节省确定系统崩溃的根本原因所需的部分。这非常容易，因为文件系统很少会配置 16GB 的 RAM。要在 11.X 上配置正确数量的转储空间，请参阅 crashconf(1m) 的 Manpage。

到目前为止，用于监视 10.X 和 11.X 系统上 swap 的最简单的命令是 swapinfo。使用一个命令，系统管理员即可看到配置了多少 swap，有多少 swap 是用于进程的，甚至有多少 swap 正处于活动状态，且可用于 swap 的进程。下面是一个示例:

#swapinfo -tam
           Mb       Mb       Mb   PCT   START/   Mb
TYPE      AVAIL    USED    FREE  USED   LIMIT RESERVE  PRI  NAME
dev         128     10      118   8%  0    -    1   /dev/vg00/lvol2
localfs      60      0       60   0%   60    0    4   /var/paging
reserve       -     52      -52
memory       91     68       23  75%
total       279    130      149  47% -   0      -

此输出显示了此系统上配置的设备 swap(dev)、文件系统 swap(localfs) 和 pseudo swap(memory)。我要指出的第一个点是 total 行。从左到右，您可以快速了解系统上正在如何执行 swap。在 Mb Avail 列下面，它显示此系统总共配置了 279M 的 swap。在配置的 279M 中，130M 正在使用。我的意思是说，如果 swap 用于保留或分页时，total 行不会显示。130M 正在用于 "某些内容"，剩下 149 M 的 swap 未在使用。Pct Used 列只显示了已在使用的 swap 百分比。

"memory" 行显示 pseudo swap 用量，这是所有 swapinfo 输出中最令人困惑的地方。正如我在以前的文章中提到的那样，pseudo swap 仅用于保留进程。因此，从此示例中可以看出，总共配置了 91M 的 pseudo swap，其中，68M 的 pseudo swap 正在由内存中运行的进程使用。剩下未使用的 pseudo swap 是 23 M。之所以令人困惑，其中的一个原因是 pseudo swap 使用不会像设备 swap 和文件系统 swap 那样降低系统性能。换句话说，无论使用 3% 还是 99% 的 pseudo swap，系统性能都是一样的。在查看 swapinfo 时，我们通常建议忽略 "memory" 行。

"reserve" 行仅涉及我们用于保留设备和文件系统 swap 区域中进程的 swap 数量。在此示例中，我们的设备和文件系统 swap 总共是 188 M，其中只有 52M 用于保留进程。现在，如果您采用用于内存和保留的所有数量，我们就会将 120(52+6M swap 保留下来，用于活动进程。因此，从这两行信息可以看出，我们已经计算了 92% 的 swap，这部分仅保留下来，用于运行的进程。

"localfs" 行显示的一些信息说明了，对于 /var 上配置的文件系统 swap，系统将使用的空间量。该行有一点很有意思，这就是 swap 的优先级，它的优先级是 4。这说明，优先级设为 1 的所有设备 swap (/dev/vg00/lvol2) 都将在该文件系统 swap 区域使用之前使用。

"dev" 行是 swapinfo 命令可以显示的最重要的信息之一。如果 percent used 一行大于 0，系统就会进行 swap。这明确说明，系统上安装的物理 RAM 不足。只有两个方法能够使系统停止 swap，第一个是安装更多的物理内存，另一个是减少系统上运行的进程。在此示例中使用的 dev 行已经进行了更改，用以显示系统发生分页时输出是什么样子。如果还剩下 149M 的保留空间时，系统则不会将进程分页到 swap 区域中。

[ 本帖最后由 sunyone 于 2006-4-26 14:23 编辑 ]

--------------------------------------------------------------------------------

ChinaUnix虚拟化版块全新推出！| Oracle顶级认证,OCM:高薪的象征 | 《开源时代》2010年4月期 | 众说纷“云” 云计算征文活动！  
  

sunyone 发短消息
加为好友
sunyone 当前离线

UID575897 帖子681 精华0 积分1181 可用积分1181  信誉积分100  专家积分0 (本版空间积分0  阅读权限30 性别男 在线时间59 小时 注册时间2005-06-27 最后登录2009-10-03   
风云使者

帖子681 主题99 精华0 可用积分1181  专家积分0 (本版:0)在线时间59 小时 注册时间2005-06-27 最后登录2009-10-03 状态：...当前离线...

[微博] [博客] [短信]
  [报告] [回复] [引用]
2楼 发表于 2006-04-26 16:16 | 只看该作者
--------------------------------------------------------------------------------

澄清 Swap 和 Pseudoswap
澄清 Swap 和 Pseudoswap

问题描述
如何确定 pseudo swap 的 'used' 部分 - 系统如何确定哪些进程或者进程的哪些部分位于该区域内 - 相对于页面交换到设备swap中保留?

在 pseudo-swap环境中,使用和保留是什么意思-尤其是在物理内存的使用中?
系统到底在什么时候开始要 page out?

配置信息
Glance swap 空间报告屏幕:
B3692A GlancePlus C.03.20.00               Current  Avg  High
----------------------------------------------------------
CPU  Util   S     SA  AU   U                | 30%   30%   30%
Disk Util   F   F                           |  9%    9%    9%
Mem  Util   SSU              UB      B      | 50%   50%   50%
Swap Util   U    UR          R              | 35%   35%   35%
---------------------------------------------------------
                     SWAP SPACE                   Users=   14

Swap Device             Type        Avail   Used     Priority
----------------------------------------------------------
/dev/vg00/lvol2         device       1.5gb   0mb        1
/dev/vg00/lvol8         device       512mb   0mb        1
pseudo-swap             memory       2.8gb   552mb       na

Swap Available: 4900mb
Swap Used: 552mb
Swap Util (%):  35
Reserved: 1735mb

解决方法
1) "如何确定 pseudo swap 的 'used' 部分 - 系统如何确定哪些进程或者 进程的哪些部分位于该区域内 - 相对于页面交换到设备swap中保留?"
这个问题有两个部分。

首先，与 Glance swap 空间报告中以及 swapinfo 输出中 "memory" 一行中报告的 "used" 数据有关。这只是一个计数器操作，表明我们可用于 pseudo-swap *reservation* 的数量大大减少了。它并不表示 pseudo-swap 使用的任何实际内存数量。例如 Pseudo-swap 不是内存中的 paging 区域。

请记住，按照定义 pseudo 表示 '假冒' 或 '模拟'。
在当前的环境中，pseudo-swap 不是磁盘块备份的物理 Swap 空间 (设备 swap reservation 是磁盘块备份的物理 Swap 空间)。
它不是内存，即使 swapinfo 中相关的数据表报告在 "memory" 行中。因为 pseudo-swap 不是物理 paging 区域 (磁盘上或内存中)，所以不会对 pseudo-swap 进行任何 page-in 或 page-out 活动。

第二，与系统如何确定哪些是保护用于设备 swap 和 pseudo-swap 的。
Kernel 的 Swap 分配策略总是首先从真正的 Swap 中保留 (swapspc_cnt)，然后才是pseudo-swap (swapmem_cnt) - 其中 swapspc_cnt 和 swapmem_cnt 为用于跟踪一些内容的内部计数器。

查看 swapinfo 输出中的 memory (pseudo-swap) 和 reserve (device/filesystem swap) 行，下面的内容讲述了这些内部计数器是如何使用的。

最初，swapmem_cnt 设置的值与 swapmem_max 相同，其中 swapmem_max counter 在引导时设置为系统上物理内存的 7/8。
请记住这些数字只与 "pseudo"-swap 的数字相关。

           Mb      Mb      Mb    PCT    START/  Mb
TYPE          AVAIL   USED    FREE  USED   LIMIT RESERVE PRI  NAME
memory     15      10       5    67%
           |       |        |     |
           |       |        |     |__(USED*100) / swapmem_max
           |       |        |
           |       |        |____ swapmem_cnt
           |       |
           |       |____ swapmem_max - swapmem_cnt
           |
           |____ swapmem_max

reserve   1127424  1118110 --1048576
            |        |           |
            |        |           |____ pages_alloc
            |        |
            |        |____ swapspc_cnt
            |
            |____ swapspc_max

swapmem_cnt 计数器可能会由于下列两个原因而递减:
- 如果 Kernel 为自己分配物理内存，或者内存页被 locked/plocked
(pseudo-swap 和可锁定内存之间存在某种关系)。

- 如果没有足够的真正 [device/filesystem] swap (swapspc_cnt)，并且我们现在要真正从 swapmem_cnt 保留。一个类似 pseudo-swap 的纯粹的计数器不是由任何物理磁盘块 (或内存) 组成的。

在上面的两种情况下，"used" 一词表示了不同的含义。在第一个情况下，它表示 "不再可用于 swap 保留"。在第二种情况下，它表示 "已被pseudo-swap保留"。

在上面的示例输出中的 'CONFIGURATION' 区域，因为 reserve 一行表明没有保留所有的已配置设备 Swap，552Mb used 表示swapmem_cnt 计数器已经减小,反映出分配的内核物理内存或被锁定的内存页面(比如共享内存段)已经被用户应用程序锁定在内存中.

如果您需要有关如何考虑系统上内存使用情况的信息，您的开发人员/供应商则了解有关它们应用程序的共享内存使用情况以及被锁定的数量。
如果您对 Kernel 内存使用情况感兴趣，则存在用来显示这种信息的工具。

2) "在 pseudo-swap环境中,使用和保留是什么意思-尤其是在物理内存的使用中?"。

"used" 一词实际上是 pseudo-swap 用词不当。它并不表示真正用于设备 Swap 的 "used" 内容，它也不表示 pseudo-swap 已经使用了一些内存。

对于设备 Swap，它表示已分配的磁盘块。保留的设备 Swap 只是为了保证系统存在内存压力时具有 Swap 空间。该数字不等于将要 page out 到磁盘的页数。实际上 vhand 进程会根据内部参数决定哪些页以及多少页会 page out 到磁盘 (下面对于第三个问题的回答中有详细说明)。

在 pseudo-swap环境中，used 和 reserved 表示相同的意思。
pseudo-swap 的 "used" 字段的一个更加精确的解释可能是不能用于 pseudo-swap reservation 的数量。它不表示 pseudo-swap 使用的真正内存、虚拟或者物理内存的任何数量。

相关的 swapinfo 示例输出如下所示:

  root@server1:/users/root $ swapinfo -tm
          Mb  Mb   Mb   PCT  START/   Mb
  TYPE   AVAIL USED FREE  USED  LIMIT RESERVE  PRI  NAME
  dev   1528  0    1528    0%    0   - 1  /dev/vg00/lvol2
  dev    512   0     512    0%   0  -  1  /dev/vg00/lvol8
  reserve -    1205   -1205
  memory 2860  552    2308   19%
  total  4900  1757  3143   36%   -   0    -

总共有 4900 Mb 可用于 swap reservation，其中真正的
swap (swapspc_cnt)= 2040 Mb (1528 + 512)，
pseudo-swap (swapmem_cnt) = 2860。
设备 Swap 的 "USED" 列显示没有任何 paging 活动，因为没有使用任何磁盘块。

pseudo-swap 的 552 Mb "USED" 数据 ("memory" 表示 Kernel 已经分配了这么多的动态内存用于某些用途，或者已经锁定了这些内存页。因此这个数字不再可用于 swap reservation，swapmem_cnt 计数器也会相应递减。
它在这个意义上是 "used" ... 但是此处的 "used" 一词并不表示内存页已经 page out。只是表示可用于 swap reservation 的数量减少了。

"FREE" 一列基本是 AVAILable 的数量减去 USED 的数量。
"reserve" 一行显示了有多少内存已保留。换句话说，"reserve" 一行显示了从 swap 计数器 (swapspc_cnt) 减少了多少数量。请注意，我们总是在 pseudo-swap 计数器之前首先从真正的 swap 计数器进行保留的。

3) "系统到底在什么时候开始要 page out?"

下面的信息是基于文档 WP1030009A 中的信息的，该文档标题为
"HP-UX Memory Management White Paper, Part I"，位于
http://itrc.hp.com 上的知识库中。

影响 paging 阈值的内核参数

# echo maxfree/D | adb /stand/vmunix /dev/kmem
# echo desfree/D | adb /stand/vmunix /dev/kmem
# echo minfree/D | adb /stand/vmunix /dev/kmem
# echo gpgslim/D | adb /stand/vmunix /dev/kmem

可用页列表中的页数是由 statdaemon 每秒钟检查一次的。
当可用页列表低于 lotsfree 设置的值时，vhand 就会开始 对页进行 aging。
一个过期的页面将会被设置ref bit然后关闭-表示它要从 TLB 清除。如果在下一次中该页的 ref bit 仍然保持了设置状态，则该页可能被stolen。

当可用页列表低于 gpgslim 设置的值时，vhand 就会开始 steal 页。
当可用页列表低于 desfree 和 minfree 设置的值时，vhand 就会变得更大。当可用页列表低于 minfree 设置的值时，swapper 则会 wake up。

desfree: 在一个内存较小的系统上 (系统初始化之后为 32 Mbytes 可用内存或更少)，desfree 设置为了非 Kernel 内存的 1/16，而且不会超过 60 页 (240 Kbytes)。在一个内存较大的系统上 (系统初始化之后多于 32 Mbyte 可用内存)，desfree 设置为了非 Kernel 内存的 1/64，而且不会超过 1024 页 (4MB)。如果非 Kernel 内存超过了 2Gb，desfree 则设置为 3072 页 (12 Mbyte)。

lotsfree: 在一个系统初始化之后为 32 Mbytes 可用内存或更少的系统上，lotsfree 设置为了非 Kernel 内存的 1/8，而且不会超过 256 页(1Mbytes)。在一个系统初始化之后多于 32 Mbyte 可用内存的系统上， lotsfree 设置为了非 Kernel 内存的 1/16，而且不会超过 8192 页 (32MB)。如果非 Kernel 内存超过了 2Gb，lotsfree 则设置为 16384 页 (64 Mbyte)。

minfree: 在一个内存较小的系统上 (系统初始化之后为 32 Mbytes 可用内存或更少)，minfree 设置为了 desfree 的 ?，而且不会超过 25 页 (100 Kbytes)。在一个内存较大的系统上 (系统初始化之后多于 32 Mbyte 可用内存)，minfree 设置为了 desfree 的 ?，而且不会超过 256 页 (1MB)。如果非 Kernel 内存超过了 2Gb，minfree 则设置为 1280 页 (5 Mbyte)。

通常情况下，page reclaim 是正常的。它基本上表示系统不必转入磁盘来执行 I/O。它而是会发现 Kernel 页缓存中与磁盘块相关的页，并且会保存一个 I/O 操作。

page reclaim 和 page out 值都与虚拟内存 paging 活动相关。但是 reclaim 值可能反映的是内存压力情况下 page out 到磁盘的内存，它们可能还包括内存映射文件的活动 - 即，内存映射文件的 I/O 被视为 paging I/O。

假设一个内存页用于内存映射文件，则该内存映射文件是非映射的。
该页将被链接到可用页池，但仍然会包含有效数据。如果在页分配用于其他目的之前，有些应用程序请求这些磁盘数据，则无需磁盘 I/O，因为该页仍然位于内存中。
该页将从可用列表中提取 - page reclaim 将会在 vmstat 中得到反映 (如果此时正在运行的话)。

因此，在这个没有明显的内存压力，但是 vmstat 反映了 page reclaim 的示例系统环境中，可能应该对应用程序 IO 活动进行进一步研究。
这些磁盘活动的 Glance(1) 和 sar(1M) 输出信息可能有所帮助。

[ 本帖最后由 sunyone 于 2006-4-26 16:19 编辑 ]

http://bbs.chinaunix.net/viewthread.php?tid=746261