> This is what Oracle says about swap for 11gR2. The > comment about > subtracting ISM is not > correct. A simple test shows that ISM does consume > swap (even if it's > not DISM). Think > about what happens when a memory segment is created > (before it goes to > ISM), if someone > happens to attach in non-ISM mode and when everyone > detaches from the > segment and it > ceases to be ISM). In the first and last stage swap > space is *required* > and the VM system > reserves the space needed when the segment is first > created.
I agree with you. In our case disabling the use of DISM really helped to make the platform more stable and helped with overall memory usage. By the way, we using Oracle 10.2.0.4. No use of Oracle 11gR2 yet. We have 192GB of physical memory and 96GB of swap device. The SGA/PGA sizes of all the Oracle DB's fit well within the 192GB leaving a consistent ~50GB spare. Memory consumption stays stable on the platform and doesn't go up and down. This is the nature of the Oracle DB's allocating memory at start-up. > > I would be cautious about Oracle assurances... Yep > > Jim > --- > > > go to the following for full list of available > oracle book. > > http://www.oracle.com/pls/db112/homepage > > > > which links to the 11gr2 install guide > > Db install guides > > > http://www.oracle.com/pls/db112/portal.portal_db?selec > ted=11&frame= > > > > which links to the following section on memory > > > http://download.oracle.com/docs/cd/E11882_01/install.1 > 12/e17163/pre_install.htm#sthref62 > > > > > > > > ------ > > 2.2.1 Memory Requirements > > > > The following are the memory requirements for > installing Oracle > > Database 11g Release 2. > > > > * > > > > At least 4 GB of RAM > > > > To determine the RAM size, enter the > following command: > > > > # /usr/sbin/prtconf | grep "Memory size" > > > > If the size of the RAM is less than the required > size, then you must > > install more memory before continuing. > > > > * > > > > The following table describes the > relationship between installed > > RAM and the configured swap space recommendation: > > > > Note: > > On Solaris, if you use non-swappable memory, > like ISM, then you > > should deduct the memory allocated to this space > from the available > > RAM before calculating swap space. > > RAM Swap Space > > Between 4 GB and 16 GB Equal to the size > of RAM > > More than 16 GB 16 GB > > > > On 10/29/2010 2:01 PM, Jim Mauro wrote: > > Thanks Mike. Good point on the script. > > > > Indeed, use of speculative tracing would be a > better > > fit here. I'll see if I can get something together > and > > send it out. > > > > Thanks, > > /jim > > > > On Oct 29, 2010, at 4:45 PM, Mike Gerdts wrote: > > > >> On Fri, Oct 29, 2010 at 2:50 PM, Robin > Cotgrove<ro...@rjcnet.co.uk> wrote: > >>> Sorry guys. Swap is not the issue. We've had this > confirmed by Oracle and I can clearly see there is > 96GB of swap awailable on the system and ~50GB of > main memory. > >> By who at Oracle? Not everyone is equally > qualified. I would tend to > >> trust Jim Mauro (who co-wrote the books[1] on > Solaris internals, > >> performance,& dtrace) over most of the people you > will get to through > >> normal support channels. > >> > >> 1. http://www.amazon.com/Jim-Mauro/e/B001ILM8NC/ > >> > >> How do you know that available swap doesn't > momentarily drop? I've > >> run into plenty of instances where a system has > tens of gigabytes of > >> free memory but is woefully short on reservable > swap (virtual memory, > >> as Jim approximates). Usually "vmstat 1" is > helpful in observing > >> spikes, but as I said before this could miss very > short spikes. If > >> you've already done this to see that swap is > unlikely to be an issue, > >> knowing that would be useful to know. If you are > measuring the amount > >> of reservable swap with "swap -l", you are doing > it wrong. > >> > >> I do agree that there can be other shortfalls that > can cause this. > >> This may call for speculative tracing of stacks > across the fork entry > >> and return calls, displaying results only when the > fork fails with > >> EAGAIN. Jim's second script is similar to what I > suggest, except that > >> it doesn't show the code path taken between > syscall::forksys:entry and > >> syscall::forksys:return. > >> > >> Also, I would be a little careful running the > second script as is for > >> long periods of time if you have a lot of forksys > activity with unique > >> stacks. I think that as it is @ks may grow rather > large over time > >> because the successful forks are not cleared. > >> > >> -- > >> Mike Gerdts > >> http://mgerdts.blogspot.com/ > >> _______________________________________________ > >> dtrace-discuss mailing list > >> dtrace-discuss@opensolaris.org > > _______________________________________________ > > dtrace-discuss mailing list > > dtrace-discuss@opensolaris.org > > > -- > Oracle <http://www.oracle.com> > James Litchfield | Senior Consultant > Phone: +1 4082237059 <tel:+1%204082237059> | Mobile: > +1 4082180790 > <tel:+1%204082180790> > Oracle Oracle ACS > California > Green Oracle <http://www.oracle.com/commitment> > Oracle is committed to > developing practices and products that help protect > the environment > <div id="jive-html-wrapper-div"> > > This is what Oracle says about swap for 11gR2. > The comment about > subtracting ISM is not<br> > correct. A simple test shows that ISM does consume > swap (even if > it's not DISM). Think<br> > about what happens when a memory segment is created > (before it goes > to ISM), if someone<br> > happens to attach in non-ISM mode and when everyone > detaches from > the segment and it<br> > ceases to be ISM). In the first and last stage swap > space is > *required* and the VM system<br> > reserves the space needed when the segment is first > created.<br> > <br> > I would be cautious about Oracle assurances...<br> > <br> > Jim<br> > ---<br> > <br> > <blockquote type="cite">go to the following for > full list of > available oracle book. <br> > <a moz-do-not-send="true" > class="moz-txt-link-freetext" > > ref="http://www.oracle.com/pls/db112/homepage";>http:// > www.oracle.com/pls/db112/homepage</a> > <br> > <br> > which links to the 11gr2 install guide <br> > Db install guides <br> > <a moz-do-not-send="true" > class="moz-txt-link-freetext" > ref="http://www.oracle.com/pls/db112/portal.portal_db? > selected=11&frame=">http://www.oracle.com/pls/db11 > 2/portal.portal_db?selected=11&frame=</a> > <br> > <br> > which links to the following section on memory > <br> > <a moz-do-not-send="true" > class="moz-txt-link-freetext" > ref="http://download.oracle.com/docs/cd/E11882_01/inst > all.112/e17163/pre_install.htm#sthref62">http://downlo > ad.oracle.com/docs/cd/E11882_01/install.112/e17163/pre > _install.htm#sthref62</a> > <br> > <br> > <br> > ------ <br> > 2.2.1 Memory Requirements <br> > <br> > The following are the memory requirements for > installing Oracle > Database 11g Release 2. <br> > <br> > * <br> > <br> > At least 4 GB of > RAM <br> > <br> > To determine the RAM > size, enter the following command: <br> > <br> > # /usr/sbin/prtconf | grep "Memory size" <br> > <br> > If the size of the RAM is less than the required > size, then you > must install more memory before continuing. <br> > <br> > * <br> > <br> > The following > table describes the relationship between > installed RAM and the configured swap space > recommendation: <br> > <br> > Note: <br> > On Solaris, if > you use non-swappable memory, like ISM, then > you should deduct the memory allocated to this > space from the > available RAM before calculating swap space. > <br> > > RAM Swap Space <br> > Between 4 GB and > 16 GB Equal to the size of > RAM <br> > More than 16 > GB 16 GB </blockquote> > <br> > <br> > <br> > On 10/29/2010 2:01 PM, Jim Mauro wrote: > <blockquote > > ite="mid:45d35217-5bfa-40b3-9bb4-cbdc52813...@oracle.c > om" > type="cite"> > <pre wrap="">Thanks Mike. Good point on the script. > > Indeed, use of speculative tracing would be a better > fit here. I'll see if I can get something together > and > send it out. > > Thanks, > /jim > > On Oct 29, 2010, at 4:45 PM, Mike Gerdts wrote: > > </pre> > <blockquote type="cite"> > <pre wrap="">On Fri, Oct 29, 2010 at 2:50 PM, Robin > Cotgrove <a class="moz-txt-link-rfc2396E" > href="mailto:ro...@rjcnet.co.uk";><ro...@rjcnet.co. > k></a> wrote: > </pre> > <blockquote type="cite"> > <pre wrap="">Sorry guys. Swap is not the issue. > We've had this confirmed by Oracle and I can clearly > see there is 96GB of swap awailable on the system > and ~50GB of main memory. > /pre> > </blockquote> > <pre wrap=""> > By who at Oracle? Not everyone is equally qualified. > I would tend to > rust Jim Mauro (who co-wrote the books[1] on Solaris > internals, > performance, & dtrace) over most of the people > you will get to through > normal support channels. > > 1. <a class="moz-txt-link-freetext" > href="http://www.amazon.com/Jim-Mauro/e/B001ILM8NC/";>h > ttp://www.amazon.com/Jim-Mauro/e/B001ILM8NC/</a> > > How do you know that available swap doesn't > momentarily drop? I've > run into plenty of instances where a system has tens > of gigabytes of > free memory but is woefully short on reservable swap > (virtual memory, > as Jim approximates). Usually "vmstat 1" is helpful > in observing > spikes, but as I said before this could miss very > short spikes. If > you've already done this to see that swap is unlikely > to be an issue, > knowing that would be useful to know. If you are > measuring the amount > of reservable swap with "swap -l", you are doing it > wrong. > > I do agree that there can be other shortfalls that > can cause this. > This may call for speculative tracing of stacks > across the fork entry > and return calls, displaying results only when the > fork fails with > EAGAIN. Jim's second script is similar to what I > suggest, except that > it doesn't show the code path taken between > syscall::forksys:entry and > syscall::forksys:return. > > Also, I would be a little careful running the second > script as is for > long periods of time if you have a lot of forksys > activity with unique > stacks. I think that as it is @ks may grow rather > large over time > because the successful forks are not cleared. > > -- > Mike Gerdts > <a class="moz-txt-link-freetext" > href="http://mgerdts.blogspot.com/";>http://mgerdts.blo > gspot.com/</a> > _______________________________________________ > dtrace-discuss mailing list > <a class="moz-txt-link-abbreviated" > href="mailto:dtrace-discuss@opensolaris.org";>dtrace-di > sc...@opensolaris.org</a> > </pre> > </blockquote> > <pre wrap=""> > _______________________________________________ > dtrace-discuss mailing list > <a class="moz-txt-link-abbreviated" > href="mailto:dtrace-discuss@opensolaris.org";>dtrace-di > sc...@opensolaris.org</a> > </pre> > </blockquote> > <br> > <br> > <div class="moz-signature">-- <br> > <a href="http://www.oracle.com"; > target="_blank"><img > src="cid:part1.03060504.05020101@oracle.com" > alt="Oracle" > border="0" height="26" width="114"></a><br> > nt size="2" color="#666666" face="Verdana, Arial, > Helvetica, > sans-serif">James Litchfield | Senior > Consultant<br> > Phone: <a href="tel:+1%204082237059">+1 > 4082237059</a> | > Mobile: <a href="tel:+1%204082180790">+1 > 4082180790</a> <br> > <font color="#ff0000">Oracle</font> Oracle > ACS<br> > California </font> > r> > <a href="http://www.oracle.com/commitment"; > target="_blank"><img > src="cid:part2.07030704.04000406@oracle.com" > alt="Green > Oracle" align="abscenter" border="0" > height="28" width="44"></a> > <font size="1" color="#4b7d42" face="Verdana, > Arial, Helvetica, > sans-serif">Oracle is committed to developing > practices and > products that help protect the > environment</font> > <!-- This signature was generated by the > MyDesktop Oracle Business Signature utility version > 3.6.0 --> > <!-- Visit http://mydesktop.oracle.com/ and try > it for yourself --> > </div> > </div>_______________________________________________ > dtrace-discuss mailing list > dtrace-discuss@opensolaris.org -- This message posted from opensolaris.org _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
