QUESTION: Multi-instance memory requirements on Linux

Question

Hi, all.
I've been out of the loop on Oracle technical details for awhile, and need to re-educate myself on a few things. I'm hoping someone can point me to a book in the online docs which discusses my question.
Oracle db 10.2.0.2, on Redhat Linux 2.6.9-67.0.0.0.1. This server is a virtual machine, on a VMWare ESX server.
My question concerns the utilization of memory resources in a multi-instance environment.
I currently have 2 instances/dbs on this server. Each was configured with an SGA_TARGET of approximately 900MB. java_pool_size, large_pool_size and shared_pool_size are also assigned values in the pfile, which I believe supersedes SGA_TARGET.
I am tasked with determining if the server can handle a third instance. It's unclear how much load the database will see, so I don't yet know how much memory I will want to allocate to the shared pool for the buffer cache, etc.
I wanted to see how much memory was being used by the existing instances, so on the server I attempted to capture memory usage information both before, and after, the startup of the second instance.
I used 'top' for this, and found that the server has a total of 3.12GB of physical memory. Currently there's about 100MB free physical memory.
the information from 'top' also indicated that physical memory utilization had actually decreased after I started the second instance:
Before second instance was started:
Mem: 3115208k total, 3012172k used, 103036k free, 46664k buffers
Swap: 2031608k total, 77328k used, 1954280k free, 2391148k cached
After second instance was started:
Mem: 3115208k total, 2989244k used, 125964k free, 47144k buffers
Swap: 2031608k total, 89696k used, 1941912k free, 2320184k cached
Logging into the instance, I ran a 'show SGA', and got an SGA size of about 900MB (as expected). But before I started the instance, there wasn't anywhere near than amount of physical memory available.
The question I need to answer is whether this server can accomodate a third instance. I gather that the actual amount of memory listed in SGA_TARGET won't be allocated until needed, and I also understand that virtual memory will be used if needed.
So rather than just asking for 'the answer', I'm hoping someone can point me to a resource which will help me better understand *NIX memory usage behavior in a multi-instance environment...
Thanks!!
DW

Answer 1

Each was configured with an SGA_TARGET of approximately 900MB. java_pool_size, large_pool_size and shared_pool_size are also assigned values in the pfile, which I believe supersedes SGA_TARGET.
Not quite. If you set non-zero values for those parameters as well as setting SGA_TARGET, then they act as minimum values that have to be maintained before extra free memory is distributed automatically amongst all auto-tuned memory pools. If you've set them as well as SGA_TARGET, you've possibly got a mish-mash of memory settings that aren't doing what you expected. If it was me, I'd stick either to the old settings, or to the new, and try not to mix them (unless your application is very strange and causes the auto-allocate mechanism to apportion memory in ways you know are wrong, in which case setting a floor below which memory allocations cannot go might be useful).
3GB of physical memory is not much these days. The general rule is that your total SGAs should not make up more than about 50% of physical memory, because you probably need most of the other 50% for PGA use. But if your users aren't going to be doing strenuous sorting (for example), then you can shrink the PGA requirement and nudge the SGA allowance up in its place.
At 900MB per SGA, you can have two SGAs and not much user activity. That's 1800MB SGA plus, say, 200MB each PGA = 2200MB, leaving about 800MB for contingencies and Linux itself. That's quite tight and I personally wouldn't try to squeeze another instance of the same size into that, not if you want performance to be meaningful.
Your top figures seem to me to suggest you're paging physical memory out to RAM already, which can't be good!