I just ran mgr:mem on another server that's been up for a while and does heavy
traffic.
Its table of allocations accounts for about 550 MB total (which seems about
like what the server should reasonably be using given my config). But my squid
process on that server has, after a few days, grown
Some new stuff has been logged by valgrind overnight- it's at the bottom of
this e-mail. Looks like mostly dupes but I see some that might be new.
However I still don't see any accounting for the amount of leakage I'm seeing.
Right now, squid on one of my servers is using a whopping 5GB of
I don't think Eliezer meant reloading per se as much as my question
which was reloading every 5 minutes.
I reload very frequently as well- not on a timer but triggered by events, and
it can happen as often as every minute. I understand that it's not optimal but
I don't see it causing
Yeah that sounds like reason enough to get away from HUP reloading- I don't
have that issue on my systems.
On Sep 27, 2012, at 12:17 PM, E.S. Rosenberg e...@g.jct.ac.il wrote:
2012/9/27 t...@raynersw.com t...@raynersw.com:
I don't think Eliezer meant reloading per se as much as my question
(maybe tcr can explain how he came up with 100ms).
[root@sierra ~]# time service squid reload
real0m0.014s
user0m0.007s
sys 0m0.005s
My configuration includes an 18,000 line ACL file, so it's pretty big.
-Ty
Jenny as far as I can tell from your mail you are running a restart
(service squid3 restart or /etc/init.d/squid3 restart) and not a
reload, reloads in my experience are very fast, they fix almost
everything and are close to unfelt by the users, I have had streams
running in a browser while I
Eli, sockets are being closed and reopened on reconfigure as well
I just tested, and this is false. I opened a 100MB test file download through a
proxy, reloaded the proxy multiple times, and the download kept chugging.
If I'd blacklisted my IP as part of that reload, I don't know if it would
. It's a real leak.
Amos identified some leaks from my valgrind output and when those make it into
a daily build I'll try again and report my findings.
Thanks
-Ty
On Sep 27, 2012, at 5:57 PM, Marcus Kool marcus.k...@urlfilterdb.com wrote:
On 09/27/2012 03:39 PM, t...@raynersw.com wrote
yet it only knows about 1 of those GB.
Thanks
-Ty
On Sep 26, 2012, at 11:32 AM, Eliezer Croitoru elie...@ngtech.co.il wrote:
On 9/26/2012 8:11 PM, t...@raynersw.com wrote:
Reposting this because I posted the original via the nabble site and it
didn't get mailed out to the list
Thanks. The thing is, I don't even think an iptables ACL will fix this leak,
because I have other squid processes running without a lengthy ACL (using an
auth program instead) and they too exhibit the leak.
Squid on most of my servers is from the standard CentOS 6.3 package.
Compilation
And as an aside- I have no idea what I did to post this at the end of somebody
else's thread instead of making a new topic, but that was clearly my bad.
-Ty
wiki, I will use that along with the valgrind one from Amos.
On Sep 26, 2012, at 3:41 PM, Eliezer Croitoru elie...@ngtech.co.il wrote:
On 9/27/2012 12:13 AM, t...@raynersw.com wrote:
Just wish I had some squid development experience so I could easily get into
a debugging environment
Running into a problem.
Installed valgrind and valgrind-devel packages via yum.
Tried to build squid with:
./configure --prefix=/usr/local/squid --with-valgrind-debug
--sysconfdir=/etc/squid --with-logdir=/var/log/squid
--with-pidfile=/var/run/squid.pid --with-swapdir=/srv/proxy/cache
Never mind. The problem was that I didn't have gcc-c++ installed. Not sure why
it threw the valgrind header error message but oh well. I am building now. Will
hopefully have some valgrind data soon.
Thanks
-Ty
14 matches
Mail list logo
