On Sun, Feb 15, 2009 at 06:33:41PM +0100, Henrik Nordstrom wrote:
In squid-3 it's --enable-valgdind-debug
I assume you meant valgrind, not valgdind :-)
If you get a valgrind report in cache.log (or stderr) when visiting the
memory statistics cahemgre page (mgr:mem) then it's compiled
mån 2009-02-16 klockan 14:27 +0100 skrev Steinar H. Gunderson:
I've reported dumps of these several times already. I'm not entirely sure
what more information you need.
Not sure either.
What I do know however is that valgrind traces in general gets very
unreliable unless Squid is built with
lör 2009-02-14 klockan 11:35 +0100 skrev Steinar H. Gunderson:
On Fri, Feb 13, 2009 at 09:20:24AM -0700, Alex Rousskov wrote:
Was --enable-valgrind used last time you reconfigured and rebuilt
Squid from scratch?
Yes. It didn't actually appear to do much, though.
In squid-3 it's
On Fri, Feb 13, 2009 at 09:20:24AM -0700, Alex Rousskov wrote:
Was --enable-valgrind used last time you reconfigured and rebuilt
Squid from scratch?
Yes. It didn't actually appear to do much, though.
Are you on 32- or 64-bit platform?
64-bit.
Would you be able to run Squid with full
On Fri, Feb 13, 2009 at 01:59:14PM -0700, Alex Rousskov wrote:
Sorry, I do not know much about pprof. The graph shows that 200MB out of
500MB was allocated to close callbacks for deferred reads (the current
suspect), right? Is there an indication that those objects were actually
leaked?
Well,
Steinar H. Gunderson wrote:
On Sun, Feb 08, 2009 at 12:38:42AM +0100, Steinar H. Gunderson wrote:
I'm using Squid 3.1.0.5 on my amd64 system (Debian unstable), and I'm having
problems that it seems to use RAM without bounds (about 1GB/week) even though
my cache_mem is only 128MB. I ran it
On Fri, Feb 13, 2009 at 09:01:35PM +1300, Amos Jeffries wrote:
A few things are still a little hidden due to the compiler optimizations
and valgrind behavior, would it be possible that you rebuild squid with
--disable-optimizations and also make sure that --enable-valgrind is
used. Then
On 02/13/2009 03:55 AM, Steinar H. Gunderson wrote:
On Fri, Feb 13, 2009 at 09:01:35PM +1300, Amos Jeffries wrote:
A few things are still a little hidden due to the compiler optimizations
and valgrind behavior, would it be possible that you rebuild squid with
--disable-optimizations
On Fri, Feb 13, 2009 at 11:55:28AM +0100, Steinar H. Gunderson wrote:
Here's a new run. I only let it run for a few minutes, though, so the numbers
are pretty small (and their relative sizes may not be representable for a
long-running Squid):
...and here's a pprof graph:
On 02/13/2009 01:40 PM, Steinar H. Gunderson wrote:
On Fri, Feb 13, 2009 at 11:55:28AM +0100, Steinar H. Gunderson wrote:
Here's a new run. I only let it run for a few minutes, though, so the numbers
are pretty small (and their relative sizes may not be representable for a
long-running
On Wed, Feb 11, 2009 at 01:34:23AM +0100, Henrik Nordstrom wrote:
To get an even better trace the best is to build Squid with valgrind
support (--with-valgrind-debug), let it run for a while under valgrind
and then view the memory statistics page.
squidclient mgr:mem
Thanks, that's a neat
On Sun, Feb 08, 2009 at 12:38:42AM +0100, Steinar H. Gunderson wrote:
I'm using Squid 3.1.0.5 on my amd64 system (Debian unstable), and I'm having
problems that it seems to use RAM without bounds (about 1GB/week) even though
my cache_mem is only 128MB. I ran it through valgrind, and it showed a
12 matches
Mail list logo
