Low Ram in ST06

I have an interesting problem which is stretching my knowledge and want to ask for your opinions/advice.

I have 2 application servers running on separate ESX farms. The OS is Linux (GNU SLES-9 x86_6) and 24Gb or RAM available. The SAP application is ECC6 on a very recent kernel 700_REL disp+work 315.
In ST06 at approx 01:00 I see a big drop off of Free RAM from 15Gb to 100Mb in one application server, RAM is still at around 100Mb free at 08:00.

In st02 the application believes it is using only 6Gb of the available 24Gb.
SAP Memory Curr.Use % CurUse[KB] MaxUse[KB] In Mem[KB]
Extended memory 25.81 6,361,088 9,895,936 24,641,536
TOP at the OS shows
Mem: 24108M total, 10006M used, 14102M free,

During our night hours, the BW jobs run in the early evening, so cannot be the issue. We have some large hitters with our MRP runs in the early hours and a small amount of Users in Australasia, but I do not believe they will consume more RAM than our busy daytime users.

The OS level people are pointing the finger at Basis, but I cannot believe this.

I think best would be to log on to system at specified time and check with top which process / processes are consuming the memory
- If some dw process then check the pid and compare it with SM50 to check directly what sap transaction/job/user is doing that - that will point you to right direction
- If DB (what DB is that?) then check with some DB tools, or check the backup process (maybe you should check it anyways - on oracle backup is consuming quite lot of resources on larger DBs)

Or you can check with linux guys if they have some memory related history of processes, if not they can setup some cronjob which will make a snapshots during specified time period

This is now resolved. The VM team had been overall locating RAM on the VM, using the logic that not all the applications would call MAX RAM at the same time. However they also had not 'fully reserved' the RAM allocated to SAP. I got them to move some smaller applications out of the VM host, then restarted SAP and the box. The RAM has been stable now for nearly a week.

Thanks David,
The db is oracle but runs on a separate server, the server with the problems is a dialog instance only. The backup starts at 20:00 and finishes by 22:00 in the evening and which is well before the RAM problems.I looked in st03n at all the jobs that ran between 00:00 and 02:00 but didn't see anything with a particularly large memory consumption.
Yours Mark

Your suspicions concur with mine regarding the outside process. The server is in a VM and I suspect that our linux guys are robbing us of RAM, however I don't know how to prove it and they don't accept that this is the case.

Good day Mark.
Trying to conclusively prove a negative condition is not usually a productive use of time; argue that point to your Mgt. and let them decide if you should carry on fishing or whether o/s support should provide some further concrete evidence to support their position. If they 'know' SAP is using the RAM, let them show it to you in a screenshot (if no other way). I see you have a supporting screenshot - why don't they?
Regards.

Thanks for your input.
I still haven't resolved this, however I've done some more digging.
With SAP running, I have with the Linux OS Command TOP only approximately 200MB free RAM from an available 24GB.
When I stop SAP with nothing running but the OS I have 16Gb of RAM used of the 24Gb available.
So I reboot the server. Now I have all memory free except the small amount used by the OS.
I now start SAP and of the 24Gb available I have over 20Gb free. This starts to reduce as users start to run processes.
At some random time over the next few days I expect to see my RAM free reducing to very low amounts.

It looks like you have some kind of memory leak. You need to find out which process is eating up memory. From your results, it does not look to be a SAP process unless it is something like saposcol, sapccmsr or sapccm4x.

Copyright 1998-2015 Ziff Davis, LLC (Toolbox.com). All rights reserved. All product names are trademarks of their respective companies. Toolbox.com is not
affiliated with or endorsed by any company listed at this site.