Search squid archive

Re: Re: squid 3.2.0.14 with TPROXY => commBind: Cannot bind socket FD 773 to xxx.xxx.xxx.xx: (98) Address

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

 



Hi, Amos,

I'm working on the same project with Plamen.

>> squidclient mgr:info |grep HTTP
>> HTTP/1.1 200 OK
>>         Number of HTTP requests received:       1454792
>>         Average HTTP requests per minute since start:   116719.5
>
>
> Nice. With stats like these would you mind supplying the data necessary for
> an entry in this page?
>  http://wiki.squid-cache.org/KnowledgeBase/Benchmarks
> (see section 2 for how to calculate the datum).

The moment we manage to fix this issue and are able to run squid for
more than few minutes without commBind problem, I promise to submit
benchmarks for two times bigger setup. Just we have to iron out this
issue. :-)

> Unfortunately all I can do is point you at the known reasons for the
> message.
> The things to figure out is whether there is some limit in TPROXY kernel
> code itself (the socket match module is the critical point I think) about
> how many sockets it can manage. Or if some of the traffic is coming an
> excessive amounts from any particular IPs and reducing the amount of
> outgoing connections that can be used for it.

Before digging deeper into the TPROXY kernel code, I'd like to clarify
one aspect of squid's behaviour. Do you pass a port number (anything >
0) in inaddr.ai_addr during the bind call? Sorry, I couldn't trace it
myself, as I didn't do much C/C++ programming since early 90's :-)

Is it Squid or the kernel who decides what port to be used?

I believe the kernel will return EADDRNOTAVAIL in case of exhausted
ports for the specific IP. And the commBind errors will cite one and
the same IP, which is not the case. All random IPs are there in the
log. Very few IP's has more (100-200) error log lines. Most IPs will
be mentioned just 1,2,3 times.

EADDRINUSE error is a clear indication that this same IP:port pair is
already in use. Or someone else listens to 0.0.0.0:<same_port>.

It'll be of great help if we manage to log the port number together
with the address in order too look for possible collisions with other
processes running on the machine (incl all other squid workers).

Thank you in advance for your support!

Best,
Niki




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

  Powered by Linux