swapinfo showed 100% Memory Utilitzed, KCUSAGE -m does not show any failures

[Matthew Murdock]

During testing last week a developer intentionally pegged development server (HPUX 11.31, RX4640, 16gb ram), so he could see the effects on the server and os. Glance core dumped, swapinfo core dumped, and no external logins (ssh or telnet) could not be serviced by kernel ( I was using the console to login with), eventually swapinfo -a, and Glance did work, and showed 100% memory and swap used.

KCUSAGE -M does not show any 100% usages (failures). Makes me not want to trust kcusage output.  Im more concerned of NOT seeing the failures being reported.

[Bill Hassell]

'pegged' -- not very useful.

Massive network I/O?
Huge data transfers?
Gigantic memory grabs?

With swapinfo and glance failing, I'll take a wild guess that someone created big malloc programs and and ran them all at the same time until all free memeory and then all swap space became occupied. When you start using the swap area, a large amount of system overhead is required to properly allocate the space, page out and then reorganize memory. Since memory map changes require the monarch processor to spinlock all other activity, the system will appear to lock up all processes until all the changes are completed. The kernel activites are very limited and diagnostic messages can't be generated as the kernel is too busy with the load.

I have seen other OS's lock up in a similar manner when massive paging occurs.
In general, you want plenty of memory to prevent paging at all cost.