This content has been marked as final. Show 53 replies
Search for swapfs in the following presentation:
Just been reading your entries with interest. Can someone summarise what the current agreed understanding is? From what i can garner:
1) SGA_MAX_SIZE is set so that you can dynamically change SGA_TARGET as per need, upto the SGA_MAX_SIZE.
2) Some OS, know that the difference between SMS and ST, is free memory and hence allocates that memory to other resources. Is this clever or dangerous, what if you change the SGA_TARGET to higher amount? Can someone list the OS's that actually do this?
3) If SGA_MAX_SIZE is not set, what will be the affect on 10gR1 database, can you still dynamically set SGA_TARGET (if you have the memory available)?
Thanks guys (great reading by the way!)
3) If SGA_MAX_SIZE is not set, what will be thehttp://download.oracle.com/docs/cd/B19306_01/server.102/b14231/create.htm#sthref376 >>
affect on 10gR1 database, can you still dynamically
set SGA_TARGET (if you have the memory available)?
If you do not specify SGA_MAX_SIZE, then Oracle Database selects a default value that is the sum of all components specified or defaulted at initialization time. If you do specify SGA_MAX_SIZE, and at the time the database is initialized the value is less than the sum of the memory allocated for all components, either explicitly in the parameter file or by default, then the database ignores the setting for SGA_MAX_SIZE.
2) Some OS, know that the difference between SMS andSo far the only system support this seems Solaris with DISM
ST, is free memory and hence allocates that memory to
other resources. Is this clever or dangerous, what if
you change the SGA_TARGET to higher amount? Can
someone list the OS's that actually do this?
WOW!Excellent guys. Worth of printing this entire thread.
OK, I know I'm necroing a post that first started over a year ago, but I have not been able to find a more recent post on this topic of this quality.
I have recently had to adjust the memory allocation on a Linux server running 3 Oracle 10gR2 databases. Memory was over committed and the server was experiencing heavy swapping under load. Restarting the databases at this time would be politically difficult.
I adjusted the sga_target values for all 3 databases, reducing them all to fit within the physical RAM of the machine (along with all the other stuff running on that server). Swapping reduced dramatically and became minimal/normal. The amount of space allocated on the swap device remained the same.
My conclusion is that while the extra memory (ie. SGA_MAX_SIZE - SGA_TARGET) may be still "allocated" by the operating system, since it is not being used any more it has been swapped out and is sitting there on disk happily idle. This is just a theory, I'd love to experiment a bit more and will do so on a test system when I have time. The whole question of what "allocating" means is also interesting.
Now, having inactive memory sitting in the swap is not an ideal situation to be in, its certainly a lot better than having active memory in swap. There could also be situations where there is a need for this type of configuration (for example in the first reply to the original question).
Having come across this thread on a link from another thread ... and not having read all the postings in this thread ...
How do you check the memory usage on your RH Linux server ? Using "top" or "vmstat" ? How do you differentiate between paging and swapping -- that was occurring when the aggregate SGA_TARGET exceeded physical RAM ?
This is a very, very nice post.
But, after this three years has anything changed?
A very helpful post indeed. This was too old but thought of updating it anyways.
I recently came across this problem in our Oracle 10.2.0.4 database running over Solaris 10. Swap Space utilisation was indeed high when SMS > ST on Solaris. Setting SMS = ST resolved the high swap utilization.
Below Metalink Docs have the details and recommendations:
*Solaris Server Using Excessive Swap Space When There is Plenty of Free RAM [ID 761960.1]*
*Solaris[TM] Operating System: DISM double allocation of memory [ID 1010818.1]*