Re: EMN0 process memory leak.
Date: Wed, 4 Mar 2009 08:58:13 -0800 (PST)
Message-ID: <680d4e5b-7fdb-4bbc-8884-983f46a1c0c0_at_z9g2000yqi.googlegroups.com>
On 4 Mar, 13:39, johnbhur..._at_sbcglobal.net wrote:
> On Mar 4, 6:39 am, "Ralph.in..._at_googlemail.com"
>
>
>
>
>
> <Ralph.in..._at_googlemail.com> wrote:
> > Hi All,
>
> > Oracle 9.2.0.8, running on Solaris 9 64 bit
>
> > We use advanced queuing to trickle (800 per minute) real time
> > transactions into a datamart. This has been live for a month and is
> > working great. Apart from the fact we have noticed that the EMN0
> > process is now at 1.8g. This is a 24x7 database so restarting the DB
> > is a last resort. We have an SR open with oracle ... but I am after a
> > couple of swift answers from here...
>
> > The process we have implemented looks like this.
>
> > Trigger puts payload onto a non-persistent queue, which invokes a
> > callback, before placing a message on persistent queue from where it
> > is sent across a dblink into a destination queue on the Datamart.
>
> > The server still has plenty of RAM spare, but I am concerned that we
> > will imminently hit a process limit at 2g. Is this the case? If I kill
> > the process, what will be the impact on any transactions? ( I don't
> > want to loose any data and don't want the firing of the trigger to
> > hang if EMN0 is not there ... I doubt this will happen). Oracle will
> > restart the process, but what happens in the interim.
>
> > We have tried this in another environment (and EMN0 does restart),
> > though not one that was under load...(we are working on getting hold
> > of the stress harness to test this...)
>
> > If anybody has any light they could shed on this, that would be a
> > help.
>
> > Cheers
>
> > Ralph
>
> With a 64 bit install of oracle on a 64 bit os you "shouldn't" run
> into problems related to 2 gig. Used to be that one would get quality
> support from oracle on solaris ... keep your fingers crossed.
>
> I would think about scheduling downtime real soon for a bounce while
> you keep trying to push support.
>
> Good luck.- Hide quoted text -
>
> - Show quoted text -
Thanks for that...
We managed to get hold of the test harness and had some interesting results which I shall share here just incase anybody else hits this issue.
Basically when EMN0 was killed (kill -9 was the only way) when under load, all of the server processes trying to insert into the table with the trigger on (the trigger that enques to the non-presisitent queue) hung with a "waiting for EMN process to spawn" event. So the answer is "Processes that enqueue to non-persistent (and probably persisitent) queues will wait about if EMN is not present until it is back ...which can be up to 3.5 minutes", which is bad news for me, as it means I'll be getting up at some ungodly hour to kill the thing...unless anybody can think of a way to pursuade pmon (I think...) to create me a new EMN0 process "on demand"?
Cheers
Ralph Received on Wed Mar 04 2009 - 10:58:13 CST