It's off-topic, but FYI, the primary use of shared memory in Oracle is for a
buffer cache. The shared memory contains various stuff including latches, but
on a "normal" configuration the large majority of the memory will be buffered
data. Oracle does it's own buffer management. It's not unusual on large OLTP
configurations to see several hundred megabytes of shared memory in use. In
DSS-type scenarios, that figure can be much larger again. Off the top of my
head, 64MB should allow you to run a reasonably-sized OLTP-type workload, but
it is utterly dependent on your application. As usual, oversizing is as bad as
undersizing, since you obviously still need memory available for the
executables and their private data.
t
In message <[EMAIL PROTECTED]>,"Stephen C. Tweedi
e" writes:
> Hi,
>
> On Mon, 19 Apr 1999 23:55:50 +0200, "Earle R. Nietzel"
> <[EMAIL PROTECTED]> said:
>
> > I've read that many database engines such as Oracle and Sybase SQL Servers
> > need to have the static variable SHMMAX in shmparam.h pushed up a bit from
> > 32Mb to 64 Mb.
>
> > I'd like to know exactly why this is necessary because I have heard a few
> > different ideas.
>
> Because these applications use significant amounts of shared memory to
> communicate between the various client and server processes on the
> system.
>
> On 2.2, you can tune this at runtime via /proc/sys/kernel/shmmax. You
> don't need to recompile with a new SHMMAX define any more.
>
> --Stephen
> -
> Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
> To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
>
--
Tim Wright, Software Engineer, | Email: [EMAIL PROTECTED]
Sequent Computer Systems Inc., 15450, |
SW Koll Parkway, Beaverton, Oregon 97006 | Phone: +1-503-578-3822
"Law of Probability Dispersal: Whatever it is that hits the fan will not be
evenly distributed."
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
