AIX Frequently Asked Questions - Memory and Processes - 反映90年代的AIX

来源:百度文库 编辑:神马文学网 时间:2024/04/29 14:05:55

AIX Frequently Asked Questions - Memory and Processes


Some info about the memory management system

From: Michael Coggins (MCOG@CHVM1.VNET.IBM.COM).
  1. Does AIX use more paging space than other unix systems?

    Under many scenarios, AIX requires more paging space than other unix systems. The AIX VMM implements a technique called "early allocation of paging space". When a page is allocated in RAM, and it is not a "client" (NFS) or a "persistent" (disk file) storage page, then it is considered a "working" storage page. Working storage pages are commonly an application's stack, data, and any shared memory segments. So, when a program's stack or data area is increased, and RAM is accessed, the VMM will allocate space in RAM and space on the paging device. This means that even before RAM is exhausted, paging space is used. This does not happen on many other unix systems, although they do keep track of total VM used.

    Example 1:

    Workstation with 64mb RAM is running only one small application that accesses a few small files. Everything fits into RAM, including all accessed data. On AIX, some paging space will already be used. On other unix systems, paging space will be 100% free. Clearly, this is an example that shows where we use more paging space than the other machines.

    Example 2:

    Same machine as above, except we are in an environment where many applications are running with inadequate RAM. Also, the system is running applications that are started, run, left idle, and not in constant use. A session of FRAME running in a window, for example. What happens is that eventually (theoretically) all applications will be paged out at least once. On the AIX system and the other systems the total paging requirements will be the same (assuming similar malloc algorithm). The major difference is that the AIX system allocated the paging space pages before they were actually needed, and the other systems did not allocate them until they were needed. However, most other systems have an internal variable that gets incremented as virtual memory pages are used. AIX does not do this. This can cause the AIX system to run out of paging space (virtual memory), even though malloc() continues to return memory. This "feature" allows sparse memory segments to work, but requires that all normal users of malloc() (sbrk()) know how much virtual memory will be available (actually impossible), and to handle a paging space low condition. A big problem. There are some pretty obvious pros and cons to both methods of doing Virtual Memory.

  2. How much paging space do I need?

    Concerning the rule of thumb of having 2 times RAM for paging space: this is rather simplistic, as are most rules of thumb. If the machine is in a "persistent storage environment", meaning that they have a few small programs, and lots of data, they may not need even as much as 1 times RAM for paging space. For example, a 1GB database server running on a 6000 with 256MB of RAM, and only running about 50MB of "working" storage does not need 512MB of paging space, or even 256MB. They only need the amount of paging space that will allow all their working storage to be paged out to disk. This is because the 1GB database is mostly "persistent storage", and will require little or no paging space. Excessive paging space may simply mean wasted disk space. However, avoid insufficient paging space. Tip: Don't have more than one paging space per disk. Tip: Put lots of RAM in your system - it will use it.

  3. Why does vmstat show no free RAM pages?

    AIX uses RAM as a possibly huge disk buffer. If you read a file in the morning, that file is read into RAM, and left there. If no other programs need that RAM, that file will be left in RAM until the machine is halted. This means that if you need the file again, access will be quick. If you need that RAM, the system will simply use the pages the file were using. The pages were flushed back to disk earlier. This means that you can get a huge speedup in disk access if you have enough RAM. For example, a 200MB database will just ease into RAM if you have a 256MB system.

  4. Since vmstat shows no free RAM pages, am I out of RAM?

    Probably not. Since disk files will be "mapped" into RAM, if vmstat shows lots of RAM pages FREE, then you probably have too much RAM (not usual on a RISC System/6000)!

  5. Shouldn't the "avm" and the "fre" fields from vmstat add up to something?

    No. The "avm" field tells you how much "Active Virtual Memory" AIX thinks you are using. This will closely match the amount of paging space you are using. This number has *ABSOLUTELY* nothing to do with the amount of RAM you are using, and does *NOT* include your mapped files (disk files).

  6. Why does the "fre" field from vmstat sometimes show lots of free RAM pages?

    This will happen after an application that used a lot of RAM via "working" storage (not NFS storage, and not disk file or "persistent" storage) exits. When RAM pages that were used by working storage (a program's stack and data area) are no longer needed, there is no need to leave them around. AIX completely frees these RAM pages. The time to access these pages versus a RAM page holding a "sync'd" mapped file is almost identical. Therefore, there is no need to periodically "flush" RAM.

  7. Is the vmstat "fre" field useful?

    The vmstat "fre" field represents the number of free page frames. If the number is consistently small (less than 500 pages), this is normal. If the number is consistently large (greater than 4000 pages), then you have more memory than you need in this machine.

How much should I trust the ps memory reports?

From: chukran@austin.VNET.IBM.COM

Using "ps vg" gives a per process tally of memory usage for each runningprocess. Several fields give memory usage in different units, but thesenumbers do not tell the whole story on where all the memory goes.

First of all, the man page for ps does not give an accurate descriptionof the memory related fields. Here is a better description:

RSS - This tells how much RAM resident memory is currently being usedfor the text and data segments for a particular process in units ofkilobytes. (this value will always be a multiple of 4 since memory isallocated in 4 KB pages).

%MEM - This is the fraction of RSS divided by the total size of RAM fora particular process. Since RSS is some subset of the total residentmemory usage for a process, the %MEM value will also be lower than actual.

TRS - This tells how much RAM resident memory is currently being usedfor the text segment for a particular process in units of kilobytes.This will always be less than or equal to RSS.

SIZE - This tells how much paging space is allocated for this processfor the text and data segments in units of kilobytes. If the executablefile is on a local filesystem, the page space usage for text is zero.If the executable is on an NFS filesystem, the page space usage will benonzero. This number may be greater than RSS, or it may not, dependingon how much of the process is paged in. The reason RSS can be larger isthat RSS counts text whereas SIZE does not.

TSIZ - This field is absolutely bogus because it is not a multiple of 4and does not correlate to any of the other fields.

These fields only report on a process text and data segments. Segmentsize which cannot be interrogated at this time are:

  • Text portion of shared libraries (segment 13)

    Files that are in use. Open files are cached in memory as individual segments. The traditional kernel cache buffer scheme is not used in AIX 3.

  • Shared data segments created with shmat.

    Kernel segments such as kernel segment 0, kernel extension segments, and virtual memory management segments.

Speaking of kernel segments, the %MEM and RSS report for process zeroare totally bogus for AIX 3.1. The reason why RSS is so big is that thekernel segment zero is counted twice. For AIX 3.2, this has beenchanged, but the whole story is still not known. The RSS value forprocess 0 will report a very small number of the swapper private datasegment. It does not report the size of the kernel segment 0, where theswapper code lives.

In summary, ps is not a very good tool to measure system memory usage.It can give you some idea where some of the memory goes, but it leavestoo many questions unanswered about the total usage.


Last Modified Thursday June 30, 1994 -webmaster@acs.ncsu.edu