Pseudo Swap

[Sachin Soni_1]

I have one doubt about pseudo swap space.
as if i type swapinfo , it shows my currently configured LV i.e.lvol2.
but it shows 0% used , while it shows "memory" used 60%.
does it mean it is not using swap space.
and do you think ,disabling pseudo swap will improve perfomance..

thanx in avance.
sachin

[James R. Ferguson]

Hi Sachin:

When enabled, pseudo-swap merely allows more processes to run in memory than *could* be supported by the swap devices if they were 100% utilized. This allows the O/S to recognize more swap space and thereby allow additional processes to start when all of physical swap has been reserved. There is no performance degradation if you are not swapping in the first place.

The memory utilization you are reporting does not suggest a problem,

...JRF...

[A. Clay Stephenson]

Hi Sachin:

Swapinfo in the memory row/USED position is a little misleading in that it also includes memory used for other purposes (e.g. buffer cache) and thus is unavailable for paging. Setting swapmem_on on or off is not really a performance paramter but rather a resource parameter.

Clay

[Sachin Soni_1]

Hi james,
as you said it allows to use memory area as a swap , when swap area is 100%----right..?
but if i see o/p of swapinfo it shows primary swap as 0% used..
??

Sachin

[Jim Turner]

Hi Sachin,

pseudo = false

pseudoswap is a figment of the kernel's imagination. It physically exists nowhere and uses no memory or disk resources. Pseudoswap can never be utilized as active swap space. As has been explained previously, pseudoswap is "dummy" swap for procs to reserve when they fork. This programatic sleight-of-hand eliminates (or at the least delays) the possibility of procs refusing to fork for want of swap space to reserve even if not one ounce of real swap is in active use.

I welcome more accurate examples from my royal friends, but I have never in my experience seen an instance where enabling pseudoswap has been harmful as long as you have enough real, physical swap configured to satisfy your actual needs.

Cheers,
Jim

[Mladen Despic]

Sachin,

I have had some experience with pseudo-swap being a problem on our database server. Our problem had to do with pseudo-swap hitting 100% for no obvious reason. We had opened support calls with HP and Sybase. HP recommended that we disable pseudo-swap as the database locks large amounts of memory, which competes with pseudo-swap reservations. HP also commented that Oracle recommends disabling pseudo-swap for their database. Sybase confirmed the same recommendation for their database.

Now, I'm not a database expert, nor do I have much experience with this stuff, but I wanted to share this story, and if anyone would like to shed some more light on pseudo-swap, I would be interested to hear about it.

I've read some HP documentation on the subject as well, and I can point to the file: /usr/share/doc/mem_mgt.txt, but I don't know if this would answer all the questions. Here are some relevant paragraphs from this file (I found the last paragraph interesting):

Reservation of Pseudo-Swap Space

Approximately 3/4 of available system memory is available as
pseudo-swap space if the tunable parameter swapmem_on is set to 1.
Pseudo-swap is tracked in the global pseudo swap reservation counters
swapmem_max (enabled pseudo-swap) and swapmem_cnt (currently
available pseudo-swap). If physical swap space is exhausted and no
additional file-system swap can be acquired, pseudo swap space is
reserved for the process by decrementing swapmem_cnt.

...

Because the swapper competes with the operating system for use of
memory, swapmem_cnt can also be decremented by the operating
system for any dynamically allocated memory.

...

Pseudo Swap and Lockable Memory
-------------------------------

Because pseudo swap is related to system memory usage, the swap
reservation scheme reflects lockable memory policies.

Although the system is not necesarily allocating additional memory
when a process locks itself into memory, locked pages are no longer
available for general use. This causes swapmem_cnt to be decremented
to account for the pages. swapmem_cnt is also decremented by the size
of the entire process if that process gets plocked in memory

[Jim Turner]

Apparently there are problems with the way HP-UX handles pseudoswap reservation that seem to be exacerbated by database software. In such cases, it might be wise to disable pseudoswap.

HOWEVER, let me say unequivocally that pseudoswap does not consume any physical memory! The phrase "Approximately 3/4 of available system memory is available as
pseudo-swap space" simply indicates a mathematical computation to determine a figure (in megabytes) to be used by the kernel when lying to itself about the amount of swap that is available for reservation. Not one byte of memory is really used for swap. I mean really, what sense would it make to page-out memory to another location in memory? HP should have called it "pseudoreserve" or something -- anything to make it less confusing.

Maybe Bill Hassell can shed some light on the subject if he happens across this post.

Cheers,
Jim

[Bill Hassell]

Most flavors of operating system treat swap space as additional storage space beyond RAM. HP-UX defines the virtual memory space as the size of swap. In it's simplest implementation, when processes need more RAM than is available, processes that are sleeping or waiting terminal I/O or otherwise deactivated, will be moved to swap space.

Prior to 10.00, the entire process would be stopped and moved to swap--that's swapping. Starting with 10.00, processes are deactivated when memory 'pressure' gets too high. Then deactivated processes will have pages removed to swap space. This significantly improves performance when a big process is deactivated so that a copy of vi can run...only the space needed for vi will be removed. Once the big process is needed, only the few pages are returned to start running again.

Prior to the kernel parameter (arrived about 9.04) swapmem_on, there had to be an exact 1:1 relationship between processes in RAM and a reserved area in swap space. So 1000 megs of RAM for processes means 1000 megs of swap space must exist. If only 500 megs of swap space exists, then new processes will not run after 500 megs of processes are in RAM--even though there is 500 megs of free RAM. HP-UX virtual memory is 500 megs, regardless of how much RAM is available.

This is by design and still exists at 10.xx and higher. So if you turn swapmem_on=0, then for 1000 megs of RAM you need 1000 megs of swap will be needed and none of it will ever be used. (small detail: memory mapped files will use some small space in swap). SO to run more processes than you have RAM, you must add more swap than RAM.

However, with swapmem_on=1, the rule about 1:1 mapping between processes and swap space is removed and up to 75% of RAM is free to contain processes without a reserved area in RAM. Now virtual memory is defined as apx. 75% RAM + swap space. Now, processes may be rolled into RAM without a reserved area in swap. But this means that processes that go in after swap space is full will be locked into RAM (cause there's no place to go).

There have been reports that some database programs see performance bottlenecks with swapmem_on=1, but the mechanism has not been explained very well. Like all performance tuning, you'll need to create a repeatable test scenario to verify changes.