Your message dated Thu, 26 Aug 2010 08:40:48 +0200
with message-id <20100826064048.ga5...@rotes76.wohnheim.uni-kl.de>
and subject line Re: Bug#593356: apt-cacher-ng: memory leak in Lenny backport
of 0.5.1 with "MaxStandbyConThreads: 2" enabled
has caused the Debian Bug report #593356,
regarding apt-cacher-ng: memory leak in Lenny backport of 0.5.1 with
"MaxStandbyConThreads: 2" enabled
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
593356: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593356
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: apt-cacher-ng
Severity: normal
G'day.
We use apt-cacher-ng in the office to reduce the cost of updates, for which it
works great. However, after moving from an Etch machine to a Lenny machine
running apt-cacher-ng we hit trouble with memory exhaustion.
In an effort to improve this, and since it looks like there have been a whole
lot of improvements, I backported (eg: compiled) the 0.5.1 package from
testing on Lenny and deployed that.
Sadly, our problem continued: we were filling 2GB of memory inside six hours,
with about thirty systems updating through the cache.
It turns out that the troublesome setting is:
MaxStandbyConThreads: 2
With that enabled, memory leak, with it commented out, nothing. I had
adjusted that because we use a container solution for the proxy host, and
I was happy to pay the cost of slower response while threads spool up in
return for potentially reclaiming some memory for other containers.
Anyway, so far the system looks to be stable with that disabled, and with it
enabled we see a huge leak from "while :; do aptitude update; done" on a
system with the Debian Lenny core, backports, and volatile enabled.
I can supply more details if you were interested, but figured that given the
backport and all you might not be interested in this report. Let me know
what, if anything, I can do to help further.
Finally, thanks again for this package: it is a world better than the other
cache alternatives we have tested, and makes my life vastly more pleasant by,
generally, just working. :)
Regards,
Daniel
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-openvz-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--- End Message ---
--- Begin Message ---
Version: 0.5.3
Hi,
> > As promised, have a look at the snapshot from
> > http://www.unix-ag.uni-kl.de/~bloch/acng/download/unreleased/. The i386
> > version is built against stable, amd64 against unstable.
> >
> > The regular tasks should work stable there ATM, only the new features
> > still need some polishing.
>
> OK. This appears to have resolved our problems, and not introduced any
> others, which is wonderful. I will continue to keep an eye on it, but for now
> it hopefully can close the issue.
Okay, t'y for testing. I consider this problem solved now in
0.5.3. (And FYI: rc1 had still a problem leading to crashes sometimes).
For the release matters, I think I will be able to isolate relevant
changes from 0.5.3 and port them down to the Testing version.
Regards,
Eduard.
--
<HE> <caro> Ganneff: passt auf, ich bin blond, habe keine ahnung von computern,
aber einen client kann ich einrichten, sogar alleine. *stolz guck*
--- End Message ---
