|
Citando Amos Jeffries <squid3@xxxxxxxxxxxxx>:
CONNECT requests with tunnels can be particularly long lived, mobiles
and their applications stay active for weeks on end with few outward
signs of what is happening inside the encrypted tunnel. The only way to
be sure the connection is finished with is when one of the client or
server remote endpoints closes it.
* The port 55815 connection _was_ closed sometimes within 15 mintes of
the lsof being run.
* The port 52288 connection is still being used.
Given the timespan between those messages and the lsof, it is also
possible they were closed and reopened in between. If you have a lot of
ports in active use, then re-use of closed ones becomes more likely.
Though I suspect it is just persistence doing what it is designed to do.
You will need a more detailed trace of the entire time period to know.
11 more hours have passed since my last "lsof" and cause it's Sunday I'm sure that no device have been connected to 192.168.x.x network at least for 15 hours.
Right now lsof output is the same as 11 hours before:
squid 32490 proxy 12u IPv6 4065613 0t0 TCP 172.16.10.22:3126->192.168.93.113:55815 (CLOSE_WAIT)
squid 32490 proxy 14u IPv6 4097822 0t0 TCP 172.16.10.22:3126->192.168.90.207:52288 (ESTABLISHED)
...
Squid is still using file descriptors 12 and 14 (and a lot of others) for the same connections as yesterday, although the mobile devices it was connected to have not been online in our network for at least 15 hours.
Is it by design?
Raising file descriptors limit is the only solution?
The maximum number of file descriptors in my installation is set to 65535. Is there any drawback to increasing this number let's say by a factor of ten?
Regards,
André
|
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
