Server Performance

[Don Morris_1]

I think you've been dramatically misinformed.

Disk swap is used *before* pseudo-swap in the default reservation algorithm. The only time that changes is when you're using the mlock interfaces, and for kernel dynamic allocations [which are implicitly mlock'd since HP-UX doesn't swap out kernel pages].

Now if you're running Oracle, it wouldn't surprise me if you don't realize this -- since Oracle usually mlock's the SGA if it can. So you can get a big memory swap reservation that matches physical consumption of the SGA. But that doesn't mean everything _else_ on the system will skip the device swap for reservation.

Not to mention, pseudo-swap doesn't "consume free memory" in any way shape or form. Pseudo-swap resources are independent of free RAM. You can completely exhaust one without touching the other.

If you completely run out of kernel memory (which would likely exhaust memory swap due to the stealing... unless you've got a bunch of Ejectable memory on v3, granted) then yes -- you can start to get hangs. Kernel memory exhaustion will do that.

[Ilkka Seittenranta]

Disk swap newer used first if pseudoswap is enabled, see any of you HP-UX. The swapinfo show how memory and disk is used, like this one:

Kb Kb Kb PCT START/ Kb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 8388608 364 8386836 0% 0 - 1 /dev/vg00/lvol2
reserve - 1558364 -1558364
memory 4163584 1775200 2388384 43%

The memory is pseudoswap-area and it used first. There is now way to change priority of swap-areas, because pseudoswap-area is not in /etc/fstab like others!

If you disable pseudoswap then there is only dev-types in the swapinfo.

[Don Morris_1]

Listen to what I said. Disk swap is preferred over pseudo-swap in the *reservation* algorithm unless the pages are locked (mlock or kernel memory).

Swap is first reserved to back virtual objects on HP-UX (and most Unix OSs) by default. This keeps the kernel from having to do random process killing if there isn't enough swap when actual paging occurs. If an object has disk swap reservations and is chosen for paging, *then* swap will be allocated at the time of paging and in the amount actually paged. This is the "Used" part of swap.

In the swapinfo you showed, a little is Used -- a bunch more is Reserved from disk swap (as it should be). Yes, pseudo-swap also shows use -- from kernel/memory locked objects. All normal. It doesn't mean that disk swap won't be preferred on new non-mlock reservations...

You can't change the priority of pseudo-swap because there's no selection to it. Priority isn't used at reservation time, only at allocation time. Pseudo-swap isn't allocated because there's no point in "paging" a RAM page from itself... to itself.

Seriously -- please read the Memory Management white paper if you haven't before at:

http://docs.hp.com/en/1218/mem_mgt.html

It is a bit out of date being aimed at 11.11 original release (so most of the locks and lists it refers to directly don't exist as such), but the concepts are solid.

[Ilkka Seittenranta]

That's right it work that way.

But I find that there is something under, when pseudoswap is enabled and applications stop respond and maybe some time continue "without" problems.

Then one way to find what is wrong is disable pseudoswap. What I see is after this change real messages arriving like "not enough semaphores", "out of memory" and so on.

The answer is change parameters, increase swapspace or really by more memory.

It's not easy calculate some kernel parameter or how must memory needed if pseudoswap is enabled.

[Don Morris_1]

What you've described is oversubscribing the box. If you're going to cause extreme physical memory pressure and have the virtual address space to create the object to do so (i.e. have enough total swap, disk + pseudoswap) you can cause the system to thrash in paging [the perceived hangs]. Removing virtual address space from the system will cause allocation failures earlier -- as malloc(), fork(), etc. fail before getting underlying physical memory.

You'd get the same effect with adding disk swap identical to the pseudoswap you removed -- it has nothing to do with pseudoswap itself. What _will_ be different in that case is that the thrashing (may, depends a bit on workload) may be gentler since vhand will find many objects backed by device swap and hence can page them out. Target rich environment and all.

So yes -- reducing the application load or increasing physical memory if you're thrashing the box is the right answer.

Not sure what you're referring to with the kernel parameter thing, sorry.