swap spce problem

[Wei_9]

We had a problem with our swap space (100% full). However, when using swapinfo, it indicated that the system only uses the pseudo-swap without using actual disk device swap.

Could you explain when the system only uses the pseudo-swap. BTW, when we recycle one of the Tuxedo applications on the system, the swap space is back to normal (65%).

Thank you in advance.


swapinfo -mat
Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 256 0 256 0% 0 - 1 /dev/vg00/lvol2
dev 4096 58 4038 1% 0 - 0 /dev/vg00/swap2
reserve - 4294 -4294
memory 6241 5348 893 86%
total 10593 9700 893 92% - 0 -

[Don Morris_1 · Accepted solution]

Sure.

The key is that HP-UX processes must reserve the swap that they require when they request virtual space (there are some exceptions [lazy swap, etc.] -- I'm just trying to give the high level here).

So if a process creates an anonymous mmap object (or malloc, etc.) of 64Mb and never touches a page of it -- that still gets 64Mb of swap reservation. This is done so that *if* all of the space is used and any/all of the space needs to be swapped out by the system, the space is guaranteed to be there.

In the case of your system -- all the disk swap is already reserved, so the kernel is using accounting tricks to do memory swap. Simply put, this means that the "swap" reserved for a physical page of memory is the page itself. If you didn't have this enabled, you would have had processes reporting allocation failures (or handling them depending on their coding) 5,348Mb ago.

So you can in fact have the swap space 100% reserved without a single page out on disk (which it sounds like is your problem). This means that you have large virtual sizes in use with relatively small physical needs (the system never gets to the point where it has to push pages out). If you want to run this workload as is... you'll need to add more swap (either real [disk/file] or pseudo [RAM]). Another option is that there's a poorly written executable out there eating too much virtual space. top / ps / Glance / pstat will help you track virtual usage by processes. You may also want to lower your fencepost limits (maxdsiz, maxssiz, shmmax) to force processes to use lower limits and try to catch a memory leak.

There may be no leak and nothing else you can do -- you may just need more virtual space for the workload you want to run.