+1 I have seen many instancesof this. It is trivial to add swap, but I'm simply tired of the number of times DBA's have protested "we have enough" or even tried FUD like "Oracle won't support us if we add more" (yes, I had that one within the lasr year). Just do it!
As has already been pointed out, Solaris has a swap reservation model. It's a bit like car insurance: you have to have it to drive on the road, but you hope you'll never need it. Solaris won't let you drive underinsured. On 29 Oct 2010, at 22:29, James Litchfield <jim.litchfi...@oracle.com> wrote: > 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 would be cautious about Oracle assurances... > > 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?selected=11&frame= >> >> which links to the following section on memory >> http://download.oracle.com/docs/cd/E11882_01/install.112/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_sig_logo.gif> > James Litchfield | Senior Consultant > Phone: +1 4082237059 | Mobile: +1 4082180790 > Oracle Oracle ACS > California > <green-for-email-sig_0.gif> Oracle is committed to developing practices and > products that help protect the environment > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss@opensolaris.org
_______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
