RE: [squid-users] Tcp connection failed problem

Hi, I'm coming back later than what I had planned :-)

My investigations didn't gave me more than what I already had.
I increased the syn backlog, no results but according to the
monitoring I've set up, one point is sure now (like you were
saying), it's not a squid problem, but an OS or even hardware
limitations (maybe the nework card : a 100 Mb card).

So I decided to completely rebuild new squid boxes : new Linux
(FC 3), new kernel (2.6.10) and new hardware (Bi-Xeon 3 Ghz +
6*.36.5 Go Ultra 320 + 2 GB RAM + gigabit network card). So I
have a few questions concerning the new configuration :
- I plan to set up three RAID 1 logical disks, 1 for the OS, and
two for the cache dir, what would be the recommandation for such a
hardware confuiguration?
- how many cache dir do you recommend to use? If several, each one
on a hard drive?
- what file system should I use for the cache dir, ext2, ext3 or
reiserfs? with diskd, aufs?

Thanx in advance.

        P-E

-----Message d'origine-----
De : SXB6300 Mailing
Envoyé : lundi 7 mars 2005 08:24
À : 'Henrik Nordstrom'
Cc : squid-users@squid-cache.org
Objet : RE: [squid-users] Tcp connection failed problem

Hi Henrik,

I'll investigate today the points you've mentionned and give you
a feedback as soon as I can.

I can already answer some points : I don't think it's a cpu overload
problem, because these messages appear on very different boxes (from
bi-PIII 600 Mhz to PIV Xeon 2.8 Ghz) with sometimes the same amount
of trafic.
I've already made some tcpdump traces on both the child and the parent.
When I get those "tcp connection ... failed" messages, I see the syn
packet on the child, but it doesn't arrive to the parent. So it would
look like packet loss but I'm a bit sceptic 'cause I also get those
messages on a child whose parent is directly on the same network switch.

What ever, thanx for taking time answering me.
Regards,

        Pierre-E

-----Message d'origine-----
De : Henrik Nordstrom [mailto:hno@squid-cache.org]
Envoyé : samedi 5 mars 2005 03:44
À : SXB6300 Mailing
Cc : squid-users@squid-cache.org
Objet : Re: [squid-users] Tcp connection failed problem

On Fri, 4 Mar 2005, SXB6300 Mailing wrote:

> On every child of one level, I get the message : TCP connection to
> parent/8080 failed

This indicates one of two things:

a) The TCP connection to the parent was refused by the parent.

b) The TCP connection to the parent timed out for some reason.

'a' has a number of sub-alternatives

    - parent overloaded, causing it to stop accepting new connections
(logged)

    - parent temporarily overloaded and too low syn backlog setting in your
OS.

    - parent crashed (logged)

    - parent effectively syn-flooded (usually logged in the system logs,
not the cache.log). This is also related to the syn backlog mentioned
above.

    - firewall between the child and the parent rejecting the request for
some reason. Supricingly often this is the case.

'b' is a bit fuzzier and mostly relates to networking and packet loss.

If you are using linux iptables then watch out for conntrack table
limitations. If this is your problem it will be logged in the system logs
(usually /var/log/messages) on the failing server (can be either of the
two).

> I'm quite worried about this problem because I've seen other person
> having this problem but no clue on how to resolve it.

In Squid's eyes it is a basic network failure.

> What's more, I'd like to load balance our internet proxies but with this
> problem, it's not possible. 'Cause that would say configuring only one
> parent proxy on the children (the virtual address), and as we use
> never_direct on the children, during connection failures that would
> result in a "unable to relay" message for the users.

The childs will try a number of times before giving up, and if you give
them more than one parent then changes are increased significantly that
they will succeed. Unless the problem is local to the childs themselves.
(i.e. conntrack table full or similar).

Regards
Henrik
Received on Mon Mar 21 2005 - 01:00:30 MST