Search squid archive

Re: not working tproxy in squid 3.2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/04/2013 7:40 p.m., Oleg wrote:
On Wed, Mar 20, 2013 at 11:35:21AM +0200, Eliezer Croitoru wrote:
On 3/19/2013 9:24 PM, Oleg wrote:
On Tue, Mar 19, 2013 at 08:49:25PM +0200, Eliezer Croitoru wrote:
Hey Oleg,

I want to understand couple things about the situation.
what is the problem? a memory leak?
   1 problem - memory leak;
   2 problem - tproxy doesn't work in squid 3.2.

I can think of a way you can configure squid to do cause them both.
   I think this is a bug in a software, if we can do memory leak and crash
with bad config.

In your case with kernel limits of 800MB per-process this config will guarantee it gets killed quickly. No memory leak required:

  cache_mem 900 MB


How do you see the memory leak? and where?
   I just start squid, start top and wait about a hour when squid grow from
40MB to 800MB and kernel kills it.

From your config I see Squid is using its default 256 MB of cache_mem. So you should expect to see at least 300MB of Squid RAM usage normally.


the more details you can give on the scenario and point with your
finger on the problem I will be happy to assist us finding the
culprit.

What linux distro are you using?
   Debian 6 and also tried debian 7.
My opinion is that you dont need to test on 7 or do special tests
but it helped us to understand the nature of the problem.

The difference between 6 and 7 is the kernel version. Some Kernels are known to have TPROXY bugs. Also, the Debian kernels had non-working TPROXY for many releases after the apparently identical upstream kernel version was working very well. This affects Debian 6 for certain I'm not sure about 7.

Try to not use the filtering helper by using only defaults and tproxy.
and also try to use this script with trpoxy on port 3129 and
http_port 127.0.0.1:3128

##start of script
#!/bin/sh  -x
echo "loading modules requierd for the tproxy"
modprobe ip_tables
modprobe xt_tcpudp
modprobe nf_tproxy_core
modprobe xt_mark
modprobe xt_MARK
FATAL: Module xt_MARK not found.

I would guess this is related to the problem.

Theory: without MARK support in the kernel the TPROXY connections are looping through Squid until the active connection state consumes 800MB and gets killed.
Can you verify that at all?

Amos




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux