Further to my previous message: I tried using "top" and noticed
something bizarre. This machine has 512Mb of main memory, but the
numbers didn't seem to add up - it looked like it was only seeing about
128Mb. And moreover, I could see it starting to use swap space, which
simply should not happen with the kind of minimal load the machine is
under. So I went into the BIOS settings, couldn't see any switch for
memory, so I tried the option for "load settings for maximum
performance". And hey presto, at boot now the machine counts through all
512Mb (before it would just display the number, but not count up), and
when I use "top" now it shows the expected numbers for available memory.
So, your suggestion saved me a lot of hassle - because it appears that
all this time, I didn't even have all the memory I thought I did. The
number which was displayed at bootup was obviously misleading. Now it
counts up, and it's really there.
What a day.
Thanks a bundle, I am most grateful.
-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
>
> ---------------------------------------------------------------------
> 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]
