I faced the same situation recently, when I replaced our old proxy server with a new debian 6 stable box.
I circumvented the problem by replacing the squid3 binary with the latest 3.1.23, adapted to the debian configuration; now it's rock solid using never more 1G ram even under heavy load (while previously using all our virtual machine assigned 12G ...) > I'm having the same issue when enable "delay_pools". I don't think this bug is delay-pools-related (see below); I do use them, but I've tried disabling them: the squid process always grows in memory size, even if slowly than using delay pools. > Upstream expect this bug to be fixed in the current squid3 packages > available in Wheezy. > > While its not possible to determine with certainty from the information > provided whether this is a known leak or not, there are a number of > leaks and resource over-allocations fixed between 3.1.6 and 3.1.20. I think that's true. I browsed the squid 3.1 bugs, searching for a solution, and I've found a memory leak (solved in 3.1.10 afair) about uploading files. Anyway I can assure - well almost 99% - problem does not affect 3.1.23 version. I can also say it is not related to disk caching since I disabled it. > a notable difference is that the problem server (a physical machine) > runs the amd64 port, while the working VM server runs the i386 Sounds bad... is it the only difference? Maybe they serve different requests and/or clients. Ciao, Rggb -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
