Who is using swap space?

[Alexey Borchev]

Swap space usage decreased:

Currently
In-use space 11551 pages ( 0%)

Oracle instance was re-started during weekend. (Cold backup)

Imho, some Oracle processes where swapped-out, then loaded back into memory, but swap space was still reserved for the process.
Swap space was released when process terminated.

[Joerg Schulenburg]

You can switch off swap editing /etc/sysconfigtab removing swapdevice entry.
You can add swap space on runtime if you need it again.
I thought that you can identify swapping process only indirect by looking for large
vsz-rss (ps aux), high syscall and idle activity.
I have problems using more than 16GB on
a 128GB GS1280 with 32 CPUs without swapping,
where the vm system
does strange things (see http://www.uni-magdeburg.de/urzs/marvel/vmbug3.html)

[Joerg Schulenburg]

>>As far as i understand, Trunix will not swap out filesystem cache - it will shrink it instead.

My experiences are otherwise. Tru64 takes swap instead of shrinking UBC.

>>Why Unix does not read it back into memory?

Unix does, Tru64 does not :(
I think the philosophy behint is, that the
pages read from the swap are cached and if
memory again is low only cached pages has to
be released.

>>swap usage is slightly decreased. May be some swapped out processes was terminated?

Probably. and because of reduced ubc_maxpercent new
processes are not swapped out again.

Did you mention your hardware?
NUMA?
What tells vmstat -R?

[Alexey Borchev]

GS1280, 8 CPU, 32 GB mem.

vmstat -R see in attachment.

[Alexey Borchev]

>>>>As far as i understand, Trunix will not swap out filesystem cache - it will shrink it instead.
>>My experiences are otherwise. Tru64 takes swap instead of shrinking UBC.
- How did You observed this? The behaviour seems absolutely rediculose, unless ubc_min_percent hit.

>>>>Why Unix does not read it back into memory?

>>Unix does, Tru64 does not :(
I think the philosophy behint is, that the
pages read from the swap are cached and if
memory again is low only cached pages has to
be released.
- Yes, i see the point. So, next time instead of swapping out, kernel will just discard the pages (if they are not "dirty").

[Joerg Schulenburg]

>>How did You observed this? The behaviour seems absolutely rediculose, unless ubc_min_percent hit.

I did vmstat -R 1 (or 10 instead of 1) and vmubc -tty -swap -memory (please look at the webpage mentioned in my GS1280 swap thread threadId=859125 for details). Read a big file to fill the UBC,
started a memory consuming testprogram and
swapping started before ubc_minpercent and borrowpercent was hit. I am not quite sure if
actu was not lowered or not lowered enough to
avoid swapping. I will have a look to my logfiles or repeat the experiment later, because I dont have time now and put the original data to my mentioned webpage.

Your attachement:
a snapshot is not enough, do a vmstat -R 60 (or so). vmubc would be good too.
Have a look to the free pages of each RAD. Looks like RAD0 and RAD1 where
temporary out of memory (high acti and pout).
If so, you triggered a kernel bug or
however HP call that misbehaviours (see my thread). But its not for sure, not enough data from you (and HPs engineers) to find out, what exactly goes wrong.