[310] in Release_7.7_team
[jf@MIT.EDU : share memory on SUN ]
daemon@ATHENA.MIT.EDU (Dorothy Bowe)
Fri May 19 13:27:08 1995
To: release-team@MIT.EDU
Date: Fri, 19 May 1995 13:26:55 EDT
From: Dorothy Bowe <dot@MIT.EDU>
I don't know if this helps, but here's the answer I got from Joe
F. regarding shared memory on the Suns.
dot
------- Forwarded Message
From: jf@MIT.EDU
To: dot@MIT.EDU
Cc: phils@MIT.EDU
Date: Thu, 18 May 1995 18:57:05 -0400
Subject: Re: share memory on SUN
Dot,
I know a little bit about the specifics. Phil may have
further information. Our needs are for the oracle database engine
to which (we access it from GIS software that is local and over
the net). Most database managers that support multiusers with
various levels of locking use variations of the system V
'shared memory' concepts whereby different user applications
can access the same segments of database tables without the
big performance hits that would come from the system calls that
an operating system normally requires to allow different
user applications to access another process's memory (namely
the tables the database engine retrieves). Since these database
managers cache the table segments, the shared memory strategy
is all the more important. For Oracle on corot (an rs/6000),
I believe we allow it dedicated control of 16 Mb of RAM for caching
and database engine stuff with this shared memory option turned on.
-- Joe F.
------- End of Forwarded Message
