Yes Wim, I am not too sure what is going on at this point with regard to
those delays I was seeing yesterday. All I know right now is that,
indirectly, I found out that my server was seriously misconfigured for
memory. I don't know if the delays I was seeing are related to that or
not (I would hazard a guess however that at least some of the delays
were due to disk swapping because all the measly 128Mb the machine
thought it had were used up)... I will be doing more testing to see what
happens. If this is a problem then it will still occur, but it will just
take longer to become apparent - since 512Mb of memory will take longer
to fill up.
It would help if we could nail down the circumstances surrounding this
condition. Obviously other people have experienced this same thing, so
it would be useful to pool experiences. I am going to run "top" for a
while now and see how my server behaves.
Thanks again
-Neil
Wim Kerkhoff wrote:
>
> I've seen your symptoms on my embperl stuff before too. At the time I
> probably wrote it off as the script being recompiled, something being
> written to disk, a network hickup, or something like that. I've seen it
> in a variety of scenarios, with various versions of Apache, Perl,
> Embperl, DBD::Oracle, DBD::Pg, and DBD::MySql over the last year or two
> (when I started using this shtuff).
>
> Neil Gunton wrote:
> >
> > Thanks, I didn't know about the "top" utility. It looks really useful. I
> > will use it to see if all my main memory is filled up if/when this
> > happens again. In fact, I may try some stress testing to purposely flush
> > out the problem.
> >
> > What makes you think that the problem is with DBI? That would be a
> > little worrying. This thing does look like some kind of leak now to me,
> > perhaps rather than anything to do directly with Embperl. I'll let the
> > list know what I find out from my testing.
> >
> > Gerald, if this is Perl not releasing resources on recompile, then that
> > is something I can handle. I just have to be careful to restart apache
> > when updating sources. Is this seen as a bug in Perl, I wonder, or is it
> > accepted behavior?
> >
> > Thanks again
> >
> > -Neil
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > We are seeing a larger memory leak in our application, and think it may be
> > > from the DBI layer or our use of it. We tried using Apache:leak, but are not
> > > sure if that works well with embperl - is that the best thing to use for
> > > tracking down the leaks?
> > >
> > > Also, "top" works well for monitoring the memory. "M" after it loads sorts
> > > by memory, and you can see the status of main and virtual memory. We saw the
> > > slowdown once main memory was filled.
> > >
> > > -----Original Message-----
> > > From: G.Richter [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, March 22, 2001 8:14 AM
> > > To: Neil Gunton
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: Caching question
> > >
> > > > Is it possible that there was some kind
> > > > of memory leak or other kind of buildup over time, as a result of the
> > > > rapidly changing html sources?
> > >
> > > Perl will not totaly release all resources when you recompile a script. So
> > > there is a very small memory leak, that occurs when a script is
> > > recompiled.Since recompiling doesn't occurs so often (compared to a normal
> > > requests), that shouldn't be a problem normaly.
> > >
> > > To see if this is really a memory issue, just watch the memory size of your
> > > httpd child processes (e.g. via ps xau | grep httpd). If it is a memory
> > > leak, we need to track down from where it comes. I don't expect that Embperl
> > > is the source, because I always test Embperl for memory leaks before I make
> > > a new release, but who knows....
> > >
> > > Gerald
>
> --
>
> Regards,
>
> Wim Kerkhoff, Software Engineer
> Merilus, Inc. -|- http://www.merilus.com
> Email: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
