0

We have Oracle database running on a 64-bit Windows Server 2003 Enterprise Edition, with 32GB RAM.

The database has been configured to use 10gb for SGA (target = max = 10GB) and 5GB for cache. Upon startup, the task manager would show around 12GB of free memory. On this server, the only application running is the database. During the day, we would see the free memory gone all the way down to 4MB.

We would like to find out what application is eating up the free memory. The memory usage does not add up on the task manager nor on perfmon. We suspect some process is taking up the free memory and not releasing it. How do we proceed?

Improve this question
0

2 Answers 2

Reset to default
1

Check the memory allocated for the kernel/drivers. May be you have a driver that is leaking. Is the server a VM? if it is a VM and you have a paravirtualization memory manager (like the one that comes with VMware Tools), the balloon driver can take some free memory to uset it for a different VM. Check if you are not overcommiting the memory on the host.

Improve this answer
1
  • If the server's a VM this is the most likely cause. The solution would be to set a memory reservation for the VM, equal to the total size of it's allocated RAM.
    – Chris Thorpe
    Mar 26, 2011 at 6:18
0

We suspect some process is taking up the free memory and not releasing it.

Sounds unlikely, if that was the case it should show up in Perfmon and Taskmanager.

What happens if you run a process which needs a lot of memory? (e.g. http://www.soft.tahionic.com/download-memalloc/index.html - I have not tried it) Can it allocate it without using the pagefile? If so then there is no other normal process using the memory and it's likely going to some behind-the-scenes opportunistic system use like caching.

I believe Windows does not empty memory once allocated until it something else requests it. Otherwise your costly RAM is just wasting away unused.

Now when a process needs new pages of RAM, the standby list is the last place the system looks. It looks first at either the zero page list, or the free page list, depending on what's to be done with the new page. Only if both of those are empty does the standby list get raided. So in the meantime, if a process faults to a page that it dropped recently enough that the page is still on the standby list, that page can be popped back into the working set, and the page fault resolved, without having to go to disk for it. The standby list could be viewed as a sort of a system-wide extension to everybody's working sets. Or to put it another way, it's a sort of a page cache. Because of this, plus the shared memory mechanism and a few other things, only about 10% of page faults usually require disk reads to resolve. Most are resolved in-memory." - http://arstechnica.com/civis/viewtopic.php?p=10593745#p10593745

Improve this answer

You must log in to answer this question.