Xref: alice comp.databases.oracle.server:47292 Path: alice!news-feed.fnsi.net!news.idt.net!howland.erols.net!master.news.rcn.net!not-for-mail From: ToneCzar@erols.com (Chris Hamilton) Newsgroups: comp.databases.oracle.server Subject: Re: Oracle Eats RAM, none left for Gods Date: Mon, 26 Apr 1999 19:22:36 GMT Organization: City of Washington Pipe Band Lines: 45 Message-ID: <3724b844.20669401@news.erols.com> References: <7g2ame$r98$1@nnrp1.dejanews.com> Reply-To: toneczar@erols.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: BvZ9zEDhUtPu70Lbd+CvWFy1vfiHgi3EBjCNDifGQiE5fH7uS9vJpw== X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 26 Apr 1999 19:23:31 GMT X-Newsreader: Forte Agent 1.5/32.451 On Mon, 26 Apr 1999 18:18:59 GMT, JoshNarins wrote: >We had 100% RAM filled ( constantly 50-100M in swap ) and horrid performance >with Oracle8 and Solaris2.6 with 3G of RAM. > >We added a GIG of RAM. > >We STILL have 50-100M in swap. > >What configuration setting is allowing Oracle to consume all available memory? >OR, since we aren't running anything else on the machine, is using all memory >this way better than limiting what this greedy monster consumes. Are you sure its Oracle that's consuming the RAM. If I understand correctly, Solaris will consume any free RAM for its buffer cache and such. And some swap will always be used -- I don't recall the specifics, but it's normal Solaris behavior. We have 2 GB of RAM, and a 270 MB SGA. "top" shows 31 MB free, and 134 MB of swap in use. >Performace is better with the new RAM, but I still think Oracle's behaviour >is wrong. We used to page out under heavy stress. We haven't seen loads like >before yet (we saw mid 20s) and no one has complained yet withg the new RAM >HOWEVER When I started my current job, system loads of 30 and above were commonplace. After some careful tuning of the existing SQL (after identification of some hog statements), we've got the load down to 6 or so, and system response is zippy. In our case there was a trigger that was executing 100,000 times a day or so, but was using a less-than-optimum index path (using two single-column indexes and merging the results, "cost" of 170). Redoing the indexing for the table (putting those two columns into a concatenated index for a "cost" of 6) solved the problem. Check your SQL -- most performance problems originate there ... Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Christopher Hamilton Oracle DBA -- Wall Street Sports chris@wallstreetsports.com http://www.wallstreetsports.com/