| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle Eats RAM, none left for Gods
On Mon, 26 Apr 1999 18:18:59 GMT, JoshNarins
<joshnarins_at_my-dejanews.com> 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
![]() |
![]() |