swapped out

[adarsh_4]

i have open vms7.3 and at times it go slow. i did a show system and i have copied it to the attachment. it says something about swapped out. what can be the problem and how can we solve it

[Hein van den Heuvel]

Well, it looks like those processes are swapped out as the system tried to free up memory. The processes that are not swapped out are trimmed down to bare bones.

Next command you want to use is SHWO MEMORY/FULL.

It looks like the memory is totally overcommited. How much is there? What is it used by?

My guess? You have some large (RDB?) global sections still stuck in memory waiting for a Database to shut down or something like that.

Maybe that INSTALL LIST /GLOBAL can identify some good sized chunks of pages under the pgltcnt columns? check also for pending delete?

Or maybe on the last reboot the system came up with a good chunk of memory missing?

Hope this helps,
Hein.

[Jon Pinkley]

Short answer: You need more memory.

You have many processes in COMO (Waiting for CPU, but outswapped) and RWMPB (Resource Wait, Modified Pagewriter Busy).

Solution: Buy more memory, or reduce the load.

Jon

[adarsh_4]

thanks for the advise.

[Robert Gezelter]

dharsh,

As Hein and Jon have noted, it is quite possible that there is simply a need for more memory than there is presently in the system.

However, the original post did not specify the hardware or architecture involved.

It also mentioned nothing about what images are being run on this system.

Before purchasing additional memory, I would investigate tuning the system. I have seen many situations where there are things that can be done to the system software configuration to address this problem.

As Hein mentioned, a SHOW MEMORY/FULL is certainly a starting point. A look at the images being run by different users is also an important step.

I once had a client who had almost the precisely same problem. System performance was unacceptable, and they were getting ready to ask upper (non-IT) management for significant funds to increase memory capacity or purchase a large system.

However, they decided to ask me to take a look at the system. I found a large number of users running the same, multi-thousand page image. I checked the image, installed it, and then watched all of the swapping and paging stop as if by magic.

Needless to say, the memory expansion project never happened.

The moral of the tale: Tune before purchasing hardware, then one better knows if one actually NEEDS the extra hardware.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert]

May be a process took A LOT of memory and then finsihed and this before you looked.
Check in accounting/full the field "peak working set".

Wim

[The Brit]

Adarsh,
I would also check to see if automatic memory reclaimation is turned on. (check value of sys param PFRATL, if = 0 then mem reclaimation is turned off.) Set PFRATL to a value >0 (i.e. 1 or 2).

This will have the affect of reducing the Working sets of processes which have more than they need, and putting those pages back on the free list.

Dave.

[adarsh_4]

that problem i have is that i cant log in the system to see what is going on when it starts to freeze. i only manage to get the sh system command running. how can i know what is chewing up the memory after i restart the system and its working fine.

[Robert Gezelter]

adarsh,

I have seen similar problems. The system is not actually frozen, just bogged down.

One useful piece of information would be the precise hardware configuration. There are several avenues to address this.

One is to check the question I posed earlier: Are the various users running the same image (or a small number of images)? Is that image installed, so that memory is used more efficiently?

If one must reboot at the point of failure, taking the steps to record a crash dump will allow analysis of precisely what happened, and what steps can be taken to prevent it from happening in the future.

- Bob Gezelter, http://www.rlgsc.com

[Jon Pinkley]

adarsh,

How frequently does this happen?

Does the system eventually recover on its own, or do you have to crash/restart it?

When did you first notice the problem? Was something changed before you noticed the problem?

Is there a pattern? I.e. does it correlate to a specific time of the day, day of the week, or day of the month, possibly when extra work is being done? Does it occur when doing a specific job (for example backups of RdB)?

What type of system is this?

$ write sys$output f$getsyi("HW_NAME")

What does the following command show?

$ show memory/all/full

Please paste the output of the above commands into notepad, save as a .txt file, and attach to a note here.

Does the system eventually recover on its own, or do you have to crash/restart it?

If you are resorting to restarting the system, a good crash dump forced while the system is thrashing should be able to provide some useful info.

Alternatively if the system does eventually recover on its own, turning on image accounting so it will be active the next time the system experiences problems will at least let you look that the things that exited just before the system recovered.

Once the system's memory is overcommitted, and it has to use the page/swap files to "warehouse" processes memory, things quickly become unbearably slow, as the system is getting little real work done. It spends its resources trying to preserve to contents of users working sets by copying memory to and from the page/swap files, and disk access is orders of magnitude slower than memory access.

Jon