Re: memory leak/overuse

"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.

Just to clarify: whilst the number of dispatchers can be increased at any time with an 'alter system' command, that requires manual intervention (compared with the mts shared server processes, which are added to and removed from automatically and dynamically, up to a maximum limit you specify).

Adding extra dispatchers dynamically is in any case a bit dubious: it has no effect on existing connections (since they are already connected to existing dispatchers). Only new connections can make use of the new dispatchers.

I'd also just mention that the uga for mts connections should most definitely not be allowed to start chewing up shared pool space: if 8.0 or above, configure a large pool, and they'll be allocated memory from there.

But I'd agree with Sybrand that MTS is really a very efficient mechanism. especially by the time you get to 8i or above, and is the way I'd be going with things.

Regards
HJR Received on Thu May 02 2002 - 17:15:06 CDT