Physical Memory management - Performance problems

[Hugo Martins]

I have a HP DS25 server running Tru64 5.1B.
My software run some java applications (everything on the server) sending them to several X clients (pc workstations running Exceed, linux workstations, ...).
I am monitoring the system activity with 'dxsysinfo'.
I have noticed that when I start to launch java applications, "In-use memory" starts to grow (as it would be expected).
But when "In-use memory" reaches 50%, then it suddenly drops and get stuck to around 25 %, starting to use swap a lot more!
After that moment, the java applications behaviour in the workstations drops in terms of performance (freezing for a long time), I believe because of the greater swapping.
Why does the system don´t allow a greater occupancy of physical memory? Why at some moment it drops to 25% usage, and get stuck to that value?
Is it possible to change that policy, for instance, changing some kernel parameters?

[Ivan Ferreira]

Please post the output of:

sysconfig -q vm vm_swap_eager
sysconfig -q vm |grep free

And when the "problem" starts:
swapon -s
vmstat 5 (At least 20 samples)

[Hugo Martins]

Here I send the log you ask for.
Thank you for the help.

Hugo

[Ivan Ferreira]

You can try changing the swap allocation mode to avoid the "reservation" of space.

Set vm_swap_eager to 0, to do that, do the following. Create a file called /tmp/sysconfig.stanza like this:

vm:
vm_swap_eager = 0

Run the command:

sysconfigdb -m -f /tmp/sysconfig.stanza

Reboot the system.

From the output I can see that your system is swapping, if your system continues swapping after this modification, probably you don't have enough RAM memory to support your load, or some application is using more memory than normal.

[Hein van den Heuvel]

It looks like dxsysinfo is confused or gives confusing output (I never use the tool). Try alternatives: collect+collgui; the vmstat you show; or vmubc perhaps.

The VMSTAT output clearly shows a system which ran out of free memory, and the performance knee you describe matches that.
Free pages dropping to a fre hundred, and pout starting at the same time indicated overcommited memory.

You can probably gain a little room by lowering vm: ubc_min from the 10 it appears to be down to 3 or 4, but that in turn may hurt performance.

You need either to - buy more memory! - reduce the load, or - reduce the java memory usage by setting lower per process upper limites and chosing a more aggressive garbage collecting method/setting.

Normally I like lazy swapping (eager=0), but here I don;t think it will help, and it may put the system stability at risk if the memory remains overcommited.

Hth,

Hein van den Heuvel
HvdH Performance Consulting