|
This document addresses how RAM and paging space are used . The information
applies to AIX Versions 4.3 and above.
VMM Overview Real-Memory management Free list Persistent vs. working memory segments Paging space allocation and virtual memory VMM memory load control facility VMSTAT's avm field VMSTAT's fre field How the system is using memory Explanation of svmon output VMM overview
The Virtual Memory Manager (VMM) services memory requests from the system and
its
applications. Virtual-memory segments are partitioned in 4096 byte units called
pages;
each page is either located in physical memory (RAM) or stored on disk in
paging space
until it is needed. AIX uses virtual memory in order to address more memory
than is
physically available in the system. The management of memory pages in RAM or on
disk in
paging space is handled by the VMM.
Real-memory management
In AIX, virtual-memory segments are partitioned into 4096-byte units called
pages. Real
memory is divided into 4096-byte page frames. The VMM has two major functions:
- manage the allocation of page frames
- resolve references to virtual-memory pages that are not currently in RAM
or stored on disk paging space.
In order to accomplish its tasks, the VMM maintains a free list of available
page
frames. The VMM also uses a page-replacement algorithm to determine which
virtual-memory
pages currently in RAM will have their page frames re-assigned to the free
list. The
page replacement algorithm takes into account the existence of persistent vs.
working
segments, repaging, and VMM thresholds.
Free list
The VMM maintains a list of free page frames that it uses to satisfy page
faults. The
free list is made up of unallocated page frames. To enhance performance, AIX
tries to
use all of RAM all the time, except for a small amount which it maintains on
the free
list. To maintain this small amount of unallocated pages the VMM will use Page
Outs and
Page Ins (page steals) to free up space and reassign those page frames to the
free
list. The virtual-memory pages whose page frames are to be re-assigned are
selected via
the VMM's page replacement algorithm.
Persistent vs. working memory segments
AIX distinguishes between different types of memory segments, and to understand
the
Virtual Memory Manager, it is important to understand the difference between
working and
persistent segments.
A persistent segment has a permanent storage location on disk. Files containing
non-modifiable
data or read-only executable programs are mapped to persistent segments. When
a Journaled
File System (either JFS or JFS2 ) is opened and accessed the file data is
copied into RAM.
VMM parameters control when physical memory frames allocated to persistent
pages should be
overwritten and used to store this new data.
Working segments are transitory, exist only during their use by a process, and
have no
permanent disk storage location. Process stack and data regions as well as
shared library
text are mapped to working segments. Pages containing working segment data
require disk
storage locations in paging space when they cannot be kept in real memory. When
a program
exits, all of its working pages are placed back on the free list.
Paging space allocation and virtual memory
In AIX 4.3.2 and later, working pages in RAM that can be modified and paged out
are assigned
a corresponding slot in paging space in a deferred manner. That is, the space
is allocated
on disk immediately before the pages are paged out. Prior to AIX 4.3.2 the
corresponding slots
in paging space were allocated when the working pages were touched (referenced)
in memory
by AIX . This is referred to as the late location scheme. On even earlier
versions of AIX,
early paging space allocation was done when pages were initially read into
memory, even
before they were referenced. The current deffered allocation scheme lets the
utilization
of the page space ( % used) more accurately represent paging space usage. It
also significantly
reduces the paging space requirements of the system.
Since persistent pages already exist somewhere else on a system disk, paging
space never needs
to be allocated for persistent pages.
VMM memory load control facility
When a process references a virtual memory page that is on disk (because it
either has been
paged out or has yet to be read in ) the referenced page must be paged in and,
if the memory
is already nearly full, this may cause one or more pages to be paged out to
make room. This
happens when the available free page frames (on the free list) is low. The VMM
uses the
page-replacement algorithm to steal page frames that have not been recently
referenced, and
thus would be unlikely to be referenced in the near future.
A successful page-replacement keeps the memory pages of all currently active
processes in
RAM, while the memory pages of inactive processes are paged out. However, when
RAM is
over-committed, it becomes difficult to choose pages for page out because they
will be
referenced in the near future by currently running processes. The result is
that pages that
will soon be referenced still get paged out and then paged in again later.
When this happens,
continuous paging in and paging out may occur. This condition is called
thrashing. The
system spends most of its time paging in and paging out instead of executing
useful instructions,
and none of the active processes make any significant progress. The VMM has a
memory load
control algorithm that detects when the system is thrashing and then attempts
to correct
the condition.
VMSTAT's avm field avm stands for "Active Virtual Memory" and not "Available Memory".
The avm value in VMSTAT
indicates the average number of 4K virtual memory pages that have been accessed
but not
necessarily paged out. With the previous policy of late page space allocation,
avm
was equivalent to "paging space blocks" since the VMM would allocate one paging
space disk
block for each working page that was accessed. With the current deferred
allocation policy,
the page space disk blocks are allocated at the time the pages are actually
paged out. The
avm number will grow as more processes get started and/or existing
processes allocate more
working storage. Likewise, the avm number will shrink when processes
(not threads) terminate
or are released by the disclaim ( ) system call. They are not released by the
free ( ) system
call.
VMSTAT's fre field fre is the average number of 4K pages that are currently on the free
list. When an application
terminates, all of its working pages are immediately returned to the free
list. Its persistent
pages (files), however, remain in RAM and are not added back to the free list
until they are
stolen by the VMM for use by other programs. Persistent pages are also freed
if the corresponding
file is deleted.
For these reasons, the fre value may not indicate all the real memory
that can be readily
available for use by processes. If a page frame is needed, then persistent
pages previously
referenced by terminated applications are among the first to be handed over to
another program.
The minimum number of pages that the Virtual Memory Manager keeps on the free
list is determined
by the minfree parameter of vmtune. If the number of pages on the
free list drops below minfree,
the Virtual Memory Manager will steal pages until the free list has been
restored to the maxfree
value.
How the system is using memory
The svmon command can be used to determine roughly how much memory the
system is using.
NOTE: perfagent.tools must be installed in order to use
svmon. Check
to see if this is installed, by executing the following command:
$ lslpp -1 perfagent.tools
If you are at AIX Version 4.3.0 or higher, then this file can be found on the
AIX BASE Operating
System media.
As root, type svmon or svmon -G.
Explanation of svmon output
Example :
$ [4.3.3 or later] svmon
size inuse free pin virtual
memory 130904 129388 1516 7600 35349
pg space 65536 5048
work pers clnt
pin 7600 0 0
in use 38073 91315 0
$ [4.3.2] svmon
m e m o r y i n u s e p i n p g s p a c e
size inuse free pin work pers clnt work pers clnt size inuse
32768 30873 1895 2187 21691 9182 0 2187 0 0 65536 354
Memory:
SIZE Total size of memory in 4K pages
INUSE Number of pages in RAM that are in use by a
process plus the
number of persistent pages that belonged to a terminated process and are still
resident
in RAM. This value is the total size of memory minus the number of pages on
the free list.
FREE Number of pages on free list.
PIN Number of pages pinned in RAM (a pinned page
is a page that is always
resident in RAM and cannot by paged out)
VIRTUAL Number of pages allocated in the system
virtual space (version 4.3.3 or
later)
Pgspace: SIZE Total size of paging space in 4K pages
INUSE Total number of allocated slots. (see
"Paging space allocation and
Virtual Memory" above)
Pin: WORK Number of working pages pinned in RAM
PERS Number of persistent pages pinned in RAM
CLNT Number of client pages pinned in RAM
In use: WORK Number of working pages in RAM
PERS Number of persistent pages in RAM
CLNT Number of client pages in RAM (client page
is a remote
file page)
To find out how much memory a single process is using, enter:
$ svmon -P
To find out how much memory the top 5 processes are using, enter:
$ [4.3.3 or later] svmon -Put 5
$ [4.3.2] svmon -Pau 5
To find out how much memory every process is using, enter:
$ [4.3.3 or later] svmon -Pu | more
$ [4.3.2] svmon -Pau | more
Example : [4.3.3]
$ svmon -P 19088
--------------------------------------------------------------------------
Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd
19088 java 7759 1402 1161 4416 N Y
Vsid Esid Type Description Inuse Pin Pgsp Virtual Addr Range
e01c d work shared library text 3510 0 23 33 0..65535
0 0 work kernel seg 1869 1396 1103 3175 0..21740 :
65348..65535
7c2d 2 work process private 1031 1 31 1042 0..2724 :
65307..65535
9bb3 - pers /dev/hd2:35149 437 0 - - 0..2404
93b2 - pers /dev/hd2:2394 428 0 - - 0..590
83b0 - pers /dev/hd2:2393 231 0 - - 0..338
7cae f work shared library data 109 0 2 87 0..1575
9893 - work 77 5 2 79 0..49746
7baf - pers /dev/hd2:2392 41 0 - - 0..53
abb5 - pers /dev/hd2:35119 10 0 - - 0..144
...
To determine the number of working pages used in all of virtual memory that are
unique to this process' private stack and data, look for the following items:
The svmon output may also list several shared segments. For a complete
picture, determine which segments are unique to an individual process and which
are shared with other programs.The Vsid (virtual segment id) and Esid
(effective segment register ids in 4.3.3 or greater) numbers will be
identical for each shared segment.
Since each page in memory is 4KB in size, multiply the Inuse values by 4096 to
get the number of bytes in memory that the process is using. Divide the number
of pages by 256 in order to get megabytes.
|