Hi,

SunOS 5.10 Generic_127111-11 sun4v sparc SUNW,SPARC-Enterprise-T5220


Total shared memory size can be obtained via getrctl().

That value on our system = 15 GB.

But we need shared memory segment size > 15 GB.


Are there any alternatives?'


Thanks

Alex Vinokur <alexvn@users.sourceforge.net> wrote:
> But we need shared memory segment size > 15 GB.
> Are there any alternatives?'

Yes, you can tune max-shm on a per-project basis by modifying /etc/project.
ie, on our dev Oracle box:

# cat /etc/project 
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
user.oracle:100:Oracle::dba:project.max-shm-memory=(priv,17179869184,deny)


This gives a 16G max-shm to the oracle user.  (You need to log out and
back into the user to make the changes visible...)

Make sure that max-shm is less than the maximum real memory in the machine.
I believe bad things happen if you let it go above that.

-- 
Brandon Hume    - hume -> BOFH.Ca, http://WWW.BOFH.Ca/

<hume.spamfilter@bofh.ca> wrote in message 
news:h9t06k$7cj$2@Kil-nws-1.UCIS.Dal.Ca...
> Alex Vinokur <alexvn@users.sourceforge.net> wrote:
>> But we need shared memory segment size > 15 GB.
>> Are there any alternatives?'
>
> Yes, you can tune max-shm on a per-project basis by modifying 
> /etc/project.
> ie, on our dev Oracle box:
>
> # cat /etc/project
> system:0::::
> user.root:1::::
> noproject:2::::
> default:3::::
> group.staff:10::::
> user.oracle:100:Oracle::dba:project.max-shm-memory=(priv,17179869184,deny)
>
>
> This gives a 16G max-shm to the oracle user.  (You need to log out and
> back into the user to make the changes visible...)
>
> Make sure that max-shm is less than the maximum real memory in the 
> machine.
> I believe bad things happen if you let it go above that.

Oracle DBA almost always set this far too aggressively for their own good 
and lazyness (*they don't like limits).  Also look at what apps are running. 
It doesn't take too many instances of Java at 1GB each to upset the apple 
cart.  eg. -Xm1024.

For a 16GB machine running nothing but oracle I would set it to 10 or 12 GB. 
Leaving the rest for the application and OS.  Leave the OS with a generious 
amount for page/swap as not to thrash.  Solaris never wastes memory.

I have seen it where the share mem is so over allocated it squeezes out 
applications into swap and the DBA in his stupidity says it isn't the DB. 
Yet getting the Java and DB folks realizing it is a shared thing memory is, 
and not getting too greedy goes a long way in a balanced system.  Especially 
since some are arrogant idiots.

If you need a shared memory at or near your physical, buy more memory or 
suffer from a poorly tuned/configured machine.  But question it, as most 
likely it is a lazy DBA over allocating as he could be bottered to tune it 
up. 

In article <3lAwm.26134$bP1.893@newsfe24.iad>,
 "Canuck57" <fred@nospam.com> wrote:

> <hume.spamfilter@bofh.ca> wrote in message 
> news:h9t06k$7cj$2@Kil-nws-1.UCIS.Dal.Ca...
> > Alex Vinokur <alexvn@users.sourceforge.net> wrote:
> >> But we need shared memory segment size > 15 GB.
> >> Are there any alternatives?'
> >
> > Yes, you can tune max-shm on a per-project basis by modifying 
> > /etc/project.
> > ie, on our dev Oracle box:
> >
> > # cat /etc/project
> > system:0::::
> > user.root:1::::
> > noproject:2::::
> > default:3::::
> > group.staff:10::::
> > user.oracle:100:Oracle::dba:project.max-shm-memory=(priv,17179869184,deny)
> >
> >
> > This gives a 16G max-shm to the oracle user.  (You need to log out and
> > back into the user to make the changes visible...)
> >
> > Make sure that max-shm is less than the maximum real memory in the 
> > machine.
> > I believe bad things happen if you let it go above that.
> 
> Oracle DBA almost always set this far too aggressively for their own good 
> and lazyness (*they don't like limits).  Also look at what apps are running. 
> It doesn't take too many instances of Java at 1GB each to upset the apple 
> cart.  eg. -Xm1024.
> 
> For a 16GB machine running nothing but oracle I would set it to 10 or 12 GB. 
> Leaving the rest for the application and OS.  Leave the OS with a generious 
> amount for page/swap as not to thrash.  Solaris never wastes memory.
> 
> I have seen it where the share mem is so over allocated it squeezes out 
> applications into swap and the DBA in his stupidity says it isn't the DB. 
> Yet getting the Java and DB folks realizing it is a shared thing memory is, 
> and not getting too greedy goes a long way in a balanced system.  Especially 
> since some are arrogant idiots.
> 
> If you need a shared memory at or near your physical, buy more memory or 
> suffer from a poorly tuned/configured machine.  But question it, as most 
> likely it is a lazy DBA over allocating as he could be bottered to tune it 
> up. 

The first thing I heard in a system performance and tuning class back in 
1984 was "No amount of tuning will fix a poorly designed application.  
System tuning can help a mistuned system but won't do much for an 
underconfigured system."  From there, we proceeded to examine what to 
look for to determine where bottlenecks were in the system and how to 
resolve them.  Since this was VMS, the answer was usually "buy more 
memory".

Nice to know somethings haven't changed, even 25 years later.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...
[I filter all Goggle Groups posts, so any reply may be automatically by ignored]

Michael Vilain wrote:
> In article <3lAwm.26134$bP1.893@newsfe24.iad>,
>  "Canuck57" <fred@nospam.com> wrote:
> 
>> <hume.spamfilter@bofh.ca> wrote in message 
>> news:h9t06k$7cj$2@Kil-nws-1.UCIS.Dal.Ca...
>>> Alex Vinokur <alexvn@users.sourceforge.net> wrote:
>>>> But we need shared memory segment size > 15 GB.
>>>> Are there any alternatives?'
>>> Yes, you can tune max-shm on a per-project basis by modifying 
>>> /etc/project.
>>> ie, on our dev Oracle box:
>>>
>>> # cat /etc/project
>>> system:0::::
>>> user.root:1::::
>>> noproject:2::::
>>> default:3::::
>>> group.staff:10::::
>>> user.oracle:100:Oracle::dba:project.max-shm-memory=(priv,17179869184,deny)
>>>
>>>
>>> This gives a 16G max-shm to the oracle user.  (You need to log out and
>>> back into the user to make the changes visible...)
>>>
>>> Make sure that max-shm is less than the maximum real memory in the 
>>> machine.
>>> I believe bad things happen if you let it go above that.
>> Oracle DBA almost always set this far too aggressively for their own good 
>> and lazyness (*they don't like limits).  Also look at what apps are running. 
>> It doesn't take too many instances of Java at 1GB each to upset the apple 
>> cart.  eg. -Xm1024.
>>
>> For a 16GB machine running nothing but oracle I would set it to 10 or 12 GB. 
>> Leaving the rest for the application and OS.  Leave the OS with a generious 
>> amount for page/swap as not to thrash.  Solaris never wastes memory.
>>
>> I have seen it where the share mem is so over allocated it squeezes out 
>> applications into swap and the DBA in his stupidity says it isn't the DB. 
>> Yet getting the Java and DB folks realizing it is a shared thing memory is, 
>> and not getting too greedy goes a long way in a balanced system.  Especially 
>> since some are arrogant idiots.
>>
>> If you need a shared memory at or near your physical, buy more memory or 
>> suffer from a poorly tuned/configured machine.  But question it, as most 
>> likely it is a lazy DBA over allocating as he could be bottered to tune it 
>> up. 
> 
> The first thing I heard in a system performance and tuning class back in 
> 1984 was "No amount of tuning will fix a poorly designed application.  
> System tuning can help a mistuned system but won't do much for an 
> underconfigured system."  From there, we proceeded to examine what to 
> look for to determine where bottlenecks were in the system and how to 
> resolve them.  Since this was VMS, the answer was usually "buy more 
> memory".
> 
> 

It's good advice IF and only IF you are doing a lot of paging/swapping.
RAM is much faster than disk!  ISTR that on a VAX your virtual memory 
could be four to six times the size of physical.  Trying for more 
usually meant performance going down the toilet!

"Michael Vilain" <vilain@NOspamcop.net> wrote in message 
news:vilain-757B1D.21501429092009@individual.net...
> In article <3lAwm.26134$bP1.893@newsfe24.iad>,
> "Canuck57" <fred@nospam.com> wrote:
>
>> <hume.spamfilter@bofh.ca> wrote in message
>> news:h9t06k$7cj$2@Kil-nws-1.UCIS.Dal.Ca...
>> > Alex Vinokur <alexvn@users.sourceforge.net> wrote:
>> >> But we need shared memory segment size > 15 GB.
>> >> Are there any alternatives?'
>> >
>> > Yes, you can tune max-shm on a per-project basis by modifying
>> > /etc/project.
>> > ie, on our dev Oracle box:
>> >
>> > # cat /etc/project
>> > system:0::::
>> > user.root:1::::
>> > noproject:2::::
>> > default:3::::
>> > group.staff:10::::
>> > user.oracle:100:Oracle::dba:project.max-shm-memory=(priv,17179869184,deny)
>> >
>> >
>> > This gives a 16G max-shm to the oracle user.  (You need to log out and
>> > back into the user to make the changes visible...)
>> >
>> > Make sure that max-shm is less than the maximum real memory in the
>> > machine.
>> > I believe bad things happen if you let it go above that.
>>
>> Oracle DBA almost always set this far too aggressively for their own good
>> and lazyness (*they don't like limits).  Also look at what apps are 
>> running.
>> It doesn't take too many instances of Java at 1GB each to upset the apple
>> cart.  eg. -Xm1024.
>>
>> For a 16GB machine running nothing but oracle I would set it to 10 or 12 
>> GB.
>> Leaving the rest for the application and OS.  Leave the OS with a 
>> generious
>> amount for page/swap as not to thrash.  Solaris never wastes memory.
>>
>> I have seen it where the share mem is so over allocated it squeezes out
>> applications into swap and the DBA in his stupidity says it isn't the DB.
>> Yet getting the Java and DB folks realizing it is a shared thing memory 
>> is,
>> and not getting too greedy goes a long way in a balanced system. 
>> Especially
>> since some are arrogant idiots.
>>
>> If you need a shared memory at or near your physical, buy more memory or
>> suffer from a poorly tuned/configured machine.  But question it, as most
>> likely it is a lazy DBA over allocating as he could be bottered to tune 
>> it
>> up.
>
> The first thing I heard in a system performance and tuning class back in
> 1984 was "No amount of tuning will fix a poorly designed application.
> System tuning can help a mistuned system but won't do much for an
> underconfigured system."  From there, we proceeded to examine what to
> look for to determine where bottlenecks were in the system and how to
> resolve them.  Since this was VMS, the answer was usually "buy more
> memory".
>
> Nice to know somethings haven't changed, even 25 years later.

The only thing that has changed in 25 years is the average level of 
incompetance has risen and more and more.

I find your memory humourious, very often misdiagnosed part of the system.