Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: memory leak/overuse

Re: memory leak/overuse

From: Leon <lrzhemov_at_shaw.ca>
Date: 2 May 2002 16:32:39 -0700
Message-ID: <dac2c664.0205021532.4602f72@posting.google.com>


Sybrand Bakker <postbus_at_sybrandb.demon.nl> wrote in message news:<gkt2duca1488spmdlsian7potv976qdgiq_at_4ax.com>...
> On 2 May 2002 01:10:55 -0700, lrzhemov_at_SHAW.CA (Leon) wrote:
>
> >Sybrand Bakker <postbus_at_sybrandb.demon.nl> wrote in message news:<ulm0du8btjam14ev50bloe6bcivqg75ga0_at_4ax.com>...
> >> On 1 May 2002 13:40:59 -0700, lrzhemov_at_shaw.ca (Leon) wrote:
> >>
> >> >Hi,
> >> >
> >> >I am having problem with memory usage on linux
> >> >output from top:
> >> >---------------------------------------------------------------
> >> >Mem: 1036292K av, 1033164K used, 3128K free, 1409644K shrd, 204304K
> >> >buff
> >> >Swap: 2048136K av, 7752K used, 2040384K free 34112K cached
> >> >---------------------------------------------------------------
> >> >Under havy usage 200 connections from web server number of buff goes
> >> >to 20MB and swap used goes to 130 MB.
> >> >
> >> >System hangs
> >> >
> >> >No error messages in alert file.
> >> >
> >> >With database reboot memory gets free back to normal.
> >> >
> >> >Could you please suggest how to identify to reason for this memory
> >> >leak, how to fix a problem without rebooting DB
> >> >
> >> >Thanks
> >> >Leon
> >>
> >>
> >> If you are using dedicated server connections to the database (which
> >> you could easily check using v$session_connect_info) at this number of
> >> users you definitely need to setup MultiThreaded Server. MTS consists
> >> of a few dispatchers and a variable number of shared servers (much
> >> less than the 200 you mention) and hence will use less memory. You
> >> will need to increase your shared pool though as the uga and pga are
> >> relocated to the shared pool with MTS.
> >> More than 50 connections is definitely a reason to go for mts.
> >> You set up mts in the mts_dispatchers parameter in init<sid>.ora
> >>
> >> Hth
> >>
> >> Sybrand Bakker, Senior Oracle DBA
> >>
> >> To reply remove -verwijderdit from my e-mail address
> >
> >Hi Sybrand,
> >
> >Thanks for your feedback. I agree MTS will limit number of dedicated
> >servers and therefore memory usage.
> >
> >But I am not sure that MTS will dispatch clients better then weblogic
> >application server. In case if I need to choose between web server
> >connection pooling dispatcher and the database to limit customer
> >connections I would choose web server.
> >Please let me know if you think MTS will work better.
> >In case if weblogic is OK I just need to know how fat single user
> >connection could be and set up limit on weblogic servers accordingly.
> >
> >Thanks
> >Leon Rzhemovskiy
> >Database Architect
>
> Hi Leon,
>
> If you have weblogic connection pooling running, why do you still have
> numerous sessions against the database? Normally, webserver connection
> pooling will limit the number of simultaneous sessions.
> Another common problem of this webserver connections is they don't
> terminate gracefully, so the dedicated server process remains running.
> There are various options to get rid of those orphaned processes, but
> they either don't work or work too slowly, so IMO you finally have to
> resort to MTS anyway. Until now I have seen no serious inefficiencies
> in mts dispatchers, and their number can grow dynamically.
>
> Hth
>
> Sybrand Bakker, Senior Oracle DBA
>
> To reply remove -verwijderdit from my e-mail address

Thanks again. I will implement MTS. Will see the result. Another finding is:
Doing consistent export on a table in "recycled" pool reduce number of available memory (buff) by 100 MB. Regular export only 10MB Do you know any problems with consistent export or recycled poll that may do something like that?

Thanks
Leon Received on Thu May 02 2002 - 18:32:39 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US