Maximum shared memory segment size
in [Solaris]
|
From: Alex Vinokur on 29 Sep 2009 06:12 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
From: hume.spamfilter on 29 Sep 2009 08:56 Alex Vinokur <alexvn(a)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/
From: Canuck57 on 29 Sep 2009 23:34 <hume.spamfilter(a)bofh.ca> wrote in message news:h9t06k$7cj$2(a)Kil-nws-1.UCIS.Dal.Ca... > Alex Vinokur <alexvn(a)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.
From: Richard B. Gilbert on 30 Sep 2009 09:22 Michael Vilain wrote: > In article <3lAwm.26134$bP1.893(a)newsfe24.iad>, > "Canuck57" <fred(a)nospam.com> wrote: > >> <hume.spamfilter(a)bofh.ca> wrote in message >> news:h9t06k$7cj$2(a)Kil-nws-1.UCIS.Dal.Ca... >>> Alex Vinokur <alexvn(a)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!
From: Canuck57 on 1 Oct 2009 19:08 "Michael Vilain" <vilain(a)NOspamcop.net> wrote in message news:vilain-757B1D.21501429092009(a)individual.net... > In article <3lAwm.26134$bP1.893(a)newsfe24.iad>, > "Canuck57" <fred(a)nospam.com> wrote: > >> <hume.spamfilter(a)bofh.ca> wrote in message >> news:h9t06k$7cj$2(a)Kil-nws-1.UCIS.Dal.Ca... >> > Alex Vinokur <alexvn(a)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.
|
Pages: 1 Prev: Jumpstart on Solaris 10 - things to start Next: cron not executing crontab for 'bad user' |