#include <hallo.h> * Daniel Pittman [Thu, Aug 19 2010, 06:28:01PM]: > Eduard Bloch <e...@gmx.de> writes: > > >> > 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 > > > > .oO( https://flattr.com/thing/51105/Apt-Cacher-NG is the place to say > > Thanks! ) > > I will try again to work out how to drive that in a bit. :) > > >> > machine running apt-cacher-ng we hit trouble with memory exhaustion. > >> > >> [...] > >> > >> > It turns out that the troublesome setting is: > >> > MaxStandbyConThreads: 2 > >> > > >> > With that enabled, memory leak, with it commented out, nothing. > >> > >> Sadly, this turns out to be untrue: with this setting enabled I can > >> reproduce > >> the leak using a local loop of 'aptitude update' calls; with it disabled > >> the > >> problem hides from that, but still shows up as our remote machines perform > >> their updates through the day. > > > > I found a couple of issues which might cause the leak. I will send you a > > current development snapshot tonight. > > Thanks.
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. > > In the meantime, could you please check which resources are leaked? > > OK: Top gives me this: > 20471 apt-cach 20 0 1451m 4612 1080 S 0 0.2 0:03.47 apt-cacher-ng > > So, at 1.4GB we have reproduced the issue, whatever it is. OK... > > File handles? lsof -n | grep apt-ca > > Nothing untoward from lsof that I can see: ... > apt-cache 20471 apt-cacher-ng 4w REG 0,25 7549180 > 12976454 /var/log/apt-cacher-ng/apt-cacher.log > apt-cache 20471 apt-cacher-ng 5u IPv6 347670112 > TCP *:3142 (LISTEN) > apt-cache 20471 apt-cacher-ng 6u IPv4 347670113 > TCP *:3142 (LISTEN) > apt-cache 20471 apt-cacher-ng 7u unix 0xffff8103f50c6680 > 347670114 /var/run/apt-cacher-ng/socket Agreed. > What does look to leak is anonymous memory: > > r...@fitz-deb01:~# /tmp/proc-maps 20471 > Backed by file: > Executable r-x 3644 > Write/Exec (jump tables) rwx 0 > RO data r-- 36 > Data rw- 92 > Unreadable --- 20460 > Unknown 0 > Anonymous: > Writable code (stack) rwx 311308 > Data (malloc, mmap) rw- 1019932 > RO data r-- 0 > Unreadable --- 131352 > Unknown 0 > > I attached the code for proc-maps, but it basically just sums memory > allocations. On the same hunch /proc/.../maps and /proc/.../smaps are both > attached, although I don't think they tell much more than the summary above. That's a nice script. I did a lot of stress-testing in the last few days/hours, and at the moment "watch proc-maps $(pidof apt-cacher-ng)" remains almost stable (with low numbers) for quite a long period of time. Regards, Eduard. -- In den ersten Jahrhunderten gab es sechzig Evangelien, die fast alle gleich unverdaulich waren. Man verfarf sechsundfünfzig wegen ihrer Kindlichkeit und Albernheit. Gäbe es hierfür keinerlei Anhaltspunkte bei denjenigen, die man behalten hat? -- Denis Diderot -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
