login at console and rlogin fails-Possible cause: insufficient memory

[Pasarakoda Dharmarao]

Hi all,
This subject was entered in the "lvm" area, by mistake.
Nevertheless some of friends answered or helped, thanks a lot.
Please refer there for information related to system.
Just to add on-->
I installed the Glanceplus. Increase the SWAP (device)
space to 1 Gbyte equal to the RAM size. And also maxswapchnk related parameters changed for better.
Now the problem "RAM FULL" is occuring 6th day instead of 3rd day. Some process is suddenly grabbing the Cache buffer (6th day--time ?) and the memory is full.
Presently the applications are able to use the database server. But soon could give problem.
I did not want to play with the DBC_max_pct kernel parameter (could be last resort).
Can any one help, to catch the problem that is suddenly grabbing the cache buffer (using glanceplus--first time) ?.
Am I using the wrong tool ?.
A day before(18.09, 18:00hrs) some values that I noted manually are as follows:-->
System Memory--- 81.6 Mb
Buffer Cache 220.7 Mb
User Memory 549.7 Mb
free Memory 171.9 Mb

Total VM 34.4 Mb
Active VM 18.2 Mb
Phy. Mem 1024 Mb.

the usage of RAM--86% was constant for 5 days.
I am sure the effect is not dependant on day and date.
It is a question of length of time.
And next day the values are in the attachment.
It is a Sybase database server, with two sybase server process runing on it.
Sometimes application-process also grab directly to access the data.

I try to attach a tar file. I hope is readable by friends.
I will be thankful if some one can help.
Best regards,
./Rao

[Eileen Millen]

This will show what is using the memory.

UNIX95= ps -e -o vsz=Kbytes -o pid,args=Command-Line | sort -rnk1

It is a command all on one line.
It might get wrapped around and show up as 2 lines.


I had a problem with Measureware scopeaux having a memory leak on one of my systems. Installing the latest version of Measureware fixed the problem. Glanceplus could also take a lot of memory if left running.

Eileen

[Bill Hassell]

You wrote:
> Now the problem "RAM FULL" is occuring 6th day instead of 3rd day.

This isn't an HP-UX error message, it is coming from some application. RAM FULL is simply no enough information. HP-UX is a virtual memory machine and does not run out of simple process RAM until both RAM and swap are fully occupied. The buffer cache is dynamic and will back off from dbc_max down to dbc_min when processes need space.


> Some process is suddenly grabbing the Cache buffer (6th day--time ?) and the memory is full.

Processes do not use the buffer cache at all. It is used and managed only by the filesystem code. The cache will grow only when there is enough room and processes are not affected.

> Presently the applications are able to use the database server. But soon could give problem.

Probably an accurate prediction, but until RAM FULL is better defined, it will not be possible to suggest a solution.

> I did not want to play with the DBC_max_pct kernel parameter (could be last resort).

This is not the problem as mentioned above. The buffer cache will back off as processes need more space. Most likely the problem is due to shared memory fragmentation or a much too small value for maxdsiz.

To verify that you are not using all your swap space (another reason for RAM FULL), run the program: swapinfo -tm