Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> Re: DB Block Buffers - Too Much ???
sean.hull_at_pobox.com wrote:
> The question: Can segments of shared memory be marked by an application
> as non-swappable, and does Oracle do this? Anybody know, or have pointers
> to good documents?
Yes, but it varies from platform to platform. GPG uses this technique so that unencrypted data won't get written to the swapfile. The source is available from http://www.gnupg.org/ . I don't know if Oracle actually does this, but I suspect not.
But the main problem in this case is, if you allocate more memory that you have physically, then *something* will always be paged out (by definition). So even if you manage to lock your SGA in main memory, you'll still take a performance hit, because that something else might well be your application, or Oracle binaries. In this case, it is worth shrinking the SGA, reducing the block buffers to avoid swapping. Oracle knows what was least recently used from its own perspective, and it know where to look: trust it to manage the SGA itself, rather than letting the OS do it.
Paging space is also used when no swapping occurs once a system reaches steady state, once all applications have been started and running for a while. For example, unused portions of shared libraries will be occupying virtual but not physical memory. A well-tuned system, under planned load, will not be hitting the swap file.
Obligatory off-topic yarn: I once encountered a system (BSD 4.3) configured with 32M main memory and 1G of swap (yes, really). The application it was running loaded huge datasets into malloc'd space, then processed its way through the data, relying on the OS to load the data into main memory as and when needed. No, I have no idea why they did this!
g
-- guy ruth hammond <grh_at_agency.com> | One is punished for being Technology Analysis & Consulting | weak, not for being cruel. 07879607148 http://www.agency.com | -- BaudelaireReceived on Sat Jun 24 2000 - 16:19:06 CDT