Why is available swap 10% when free swap is 65%

[Brett Matheson]

Can anyone please explain to me why we have so much free swap space, yet such a small amount of available space? What is the extra Reserved swap space reserved for ?

Swap partition /dev/disk/dsk1b (default swap):
Allocated space: 1932685 pages (14.75GB)
In-use space: 658337 pages ( 34%)
Free space: 1274348 pages ( 65%)


Total swap allocation:
Allocated space: 1932685 pages (14.75GB)
Reserved space: 1735818 pages ( 89%)
In-use space: 658337 pages ( 34%)
Available space: 196867 pages ( 10%)

Thanks

[Venkatesh BL]

It could be because of the swap 'mode' set on the system. Check out the manpage of 'swapon' for useful info.

Also, searching this forum with the keywords would yield good results.

[Johan Brusche]

Brett,

Use the manpage for sys_attrs_vm and look for the explanation of the sysconfigtab parameter "vm_swap_eager".
Your system is using the default =1. If the environment does not need swap reservation in advance (you have 89% resereved now), then set vm_swap_eager=0 (and reboot).


__ Johan.

[Ralf Puchner]

Reading administration guide is a starter ;-)

[Joerg Schulenburg · Accepted solution]

Deliver Tru64 with eager=0 per default is a better starter! Or do you now a (real) situation where swap reservation in advance has a advantage?
One advantage is clearly, that you have to read the documentation to find out that eager=0 is your friend *sigh*.

[Brett Matheson]

Thanks for that Joerg. That was probably my main question - we were told that it was risky to change the allocation mode for our server (which is running Oracle databases).

[Victor Semaska_3]

The risk in changing from changing immediate mode to deferred mode according to section 3.6.3 of the System Administration Guide:

The operating system terminates a process if it attempts to write a modified virtual page to swap space that is depleted.

In other words, if you use deferred mode and the swap space isn't large enough, the OS will start deleting processes.

Vic

[Joerg Schulenburg]

>>In other words, if you use deferred mode and the swap space isn't large enough, the OS will start deleting processes.

What about immediate mode and the swap space isn't large enough. What happens, if the kernel or a driver needs some memory?
Isn't it that UNIX, Windows or whatever comes into big trouble if all physical memory and swap is consumed?
The immidiate mode does not prevent the trouble. But usable memory in immidiate mode is equal to swap whereas usable memory in deferred mode is physical memory + swap.
So who is coming in trouble first?

Happy swapping!

[Victor Semaska_3]

Joerq,

You should read that section in the SysAdmin Guide. Here's the URL to the doc.s:
http://h30097.www3.hp.com/docs/pub_page/doc_list.html

Later in the section it says:

If you use the immediate mode, swap space depletion prevents you from creating additional modifiable virtual address space. If you use the deferred mode, swap space depletion can result in one or more processes being involuntarily terminated.

So, if I understand it correctly, with immediate mode you won't be able to create any new process if you run out of swap space. With deferred mode, the OS will start deleting *existing* processes. We've had this happen once on a system with deferred mode. A process went 'nuts' and used up a lot of virtual space thus using all the swap space. The OS then started deleting processes like the SSH daemon sshd. Had to reboot to get the system working again.

Vic

[Joerg Schulenburg]

Dear Victor,

Please try this on your machine:
main(){
int i, *p;
for (i=0;;) {
p=(int *)malloc(1024*16);
if(p)printf("%i MB\n",(++i)/64);
else sleep(1);
}
}

In immediate mode on a ES45 16GB, 20GB swap it ends with
VMUBC showing Act=1144K Free=554K Swap.free=2 Swap.used=2500K.
Now try to login, or do call a command like kill. No chance.
The result is like this:
Unable to obtain requested swap space
bash: fork: Operation would block

Ok, its true, nothing is killed. But you cant
do anything on the system, where a lazy-system has no problems at all.
If you really want it, you dont need eager swap. The system (not necessarely the kernel) only have to control the sum of all virtual memory and let fail allocation if a limit (mem+swap) is reached, which is easy to program.
No swap-disk is needed for such a feature but it would also work with lazy swap.
Indeed it would prevent the system to decide which process to kill in the out-of-memory contition. Is that an advantage to come in the out-of-(v)memory condition if there is lot of memory free?
And needs the out of virtual memory condition to be coupled with swap?
I still think that immediate mode was
created in a weak hour of the kernel programmer.

Comments welcome :)