Search squid archive

Re: TCP out of memory

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

 



________________________________
From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
>
> I have only taken a brief look, but so far it looks like the problematic 

> sockets are not participating in any ICAP activity.

Do you see that from the cache.log, or from ":filedescriptors"?
If I list my current filedescriptors right now, I get this:

# squidclient mgr:filedescriptors | grep "127.0.0.1:1344"
20 Socket  899      25*   10001  127.0.0.1:1344        127.0.0.1
30 Socket    0   71648    72210  127.0.0.1:1344        127.0.0.1
38 Socket  900       0*    2564  127.0.0.1:1344        127.0.0.1
102 Socket    0   67222    67689  127.0.0.1:1344        127.0.0.1
107 Socket    0  102679   203677  127.0.0.1:1344        127.0.0.1
113 Socket    0   67222    67709  127.0.0.1:1344        127.0.0.1
115 Socket  886       0*    2588  127.0.0.1:1344        127.0.0.1
116 Socket  873      25*   10395  127.0.0.1:1344        127.0.0.1
129 Socket    0  114892   144095  127.0.0.1:1344        127.0.0.1
134 Socket  900      25*    8863  127.0.0.1:1344        127.0.0.1
160 Socket    0   67222    67687  127.0.0.1:1344        127.0.0.1
165 Socket    0   77833    78401  127.0.0.1:1344        127.0.0.1
166 Socket    0   67222    67702  127.0.0.1:1344        127.0.0.1
175 Socket    0   67222    67698  127.0.0.1:1344        127.0.0.1
176 Socket    0   67222    67698  127.0.0.1:1344        127.0.0.1
212 Socket    0   67222    67742  127.0.0.1:1344        127.0.0.1
213 Socket  878       0*    2533  127.0.0.1:1344        127.0.0.1
226 Socket  873       0*    2531  127.0.0.1:1344        127.0.0.1
236 Socket    0   78332   180786  127.0.0.1:1344        127.0.0.1
244 Socket    0   67222    67698  127.0.0.1:1344        127.0.0.1
281 Socket    0   67222    67685  127.0.0.1:1344        127.0.0.1
285 Socket    0   78253   149568  127.0.0.1:1344        127.0.0.1
298 Socket    0   77833    78451  127.0.0.1:1344        127.0.0.1
305 Socket    0   74366   168309  127.0.0.1:1344        127.0.0.1
307 Socket    0  114519   115068  127.0.0.1:1344        127.0.0.1
326 Socket    0   67222    67698  127.0.0.1:1344        127.0.0.1
327 Socket    0   67222    67687  127.0.0.1:1344        127.0.0.1
365 Socket    0   70248   114918  127.0.0.1:1344        127.0.0.1
372 Socket    0   67222    67698  127.0.0.1:1344        127.0.0.1
390 Socket    0   77833    78483  127.0.0.1:1344        127.0.0.1
404 Socket    0   90022    90703  127.0.0.1:1344        127.0.0.1
464 Socket    0   78253   144095  127.0.0.1:1344        127.0.0.1
472 Socket    0   67222    67698  127.0.0.1:1344        127.0.0.1
480 Socket  891       0*    2514  127.0.0.1:1344        127.0.0.1
491 Socket    0   67222    67685  127.0.0.1:1344        127.0.0.1
509 Socket    0   67222    67687  127.0.0.1:1344        127.0.0.1
512 Socket    0   67222    67703  127.0.0.1:1344        127.0.0.1
528 Socket    0  131176   155548  127.0.0.1:1344        127.0.0.1
536 Socket    0   70111   134058  127.0.0.1:1344        127.0.0.1
547 Socket    0   67222    67689  127.0.0.1:1344        127.0.0.1
554 Socket    0  131860   152673  127.0.0.1:1344        127.0.0.1
570 Socket    0   67222    67707  127.0.0.1:1344        127.0.0.1
572 Socket  893       0*    2706  127.0.0.1:1344        127.0.0.1
596 Socket    0   78390   114864  127.0.0.1:1344        127.0.0.1
602 Socket    0   67222    67691  127.0.0.1:1344        127.0.0.1
624 Socket    0   72678    73442  127.0.0.1:1344        127.0.0.1
631 Socket    0   71646    72250  127.0.0.1:1344        127.0.0.1
635 Socket    0  104333   104896  127.0.0.1:1344        127.0.0.1
641 Socket    0   67222    67687  127.0.0.1:1344        127.0.0.1
646 Socket    0   67222    67698  127.0.0.1:1344        127.0.0.1
662 Socket    0   67222    67698  127.0.0.1:1344        127.0.0.1
674 Socket    0   67222    67691  127.0.0.1:1344        127.0.0.1
678 Socket    0   67222    67687  127.0.0.1:1344        127.0.0.1
687 Socket    0   67222    67702  127.0.0.1:1344        127.0.0.1
730 Socket    0   67222    67691  127.0.0.1:1344        127.0.0.1
767 Socket    0   74465   152811  127.0.0.1:1344        127.0.0.1
772 Socket    0   67217    67747  127.0.0.1:1344        127.0.0.1
815 Socket    0   77864    78246  127.0.0.1:1344        127.0.0.1
848 Socket    0   67222    67743  127.0.0.1:1344        127.0.0.1
865 Socket    0   67222    67747  127.0.0.1:1344        127.0.0.1
890 Socket    0   67222    67699  127.0.0.1:1344        127.0.0.1
943 Socket    0   77833    78501  127.0.0.1:1344        127.0.0.1
1008 Socket    0   74212    78383  127.0.0.1:1344        127.0.0.1
1018 Socket    0   74466    90630  127.0.0.1:1344        127.0.0.1
1099 Socket    0   67222    67687  127.0.0.1:1344        127.0.0.1
1124 Socket    0   67222    67683  127.0.0.1:1344        127.0.0.1
1167 Socket    0   67222    67687  127.0.0.1:1344        127.0.0.1
1273 Socket    0   67258    67879  127.0.0.1:1344        127.0.0.1
1337 Socket    0   74243    78265  127.0.0.1:1344        127.0.0.1


Both Nread and Nwrite seem to be well over 0.

> That implies they > are possibly TCP connections which never complete their opening 
> sequence, or at least the result of connection attempts does not make it 
> back to the ICAP code somehow.


ICAP and Squid are both on localhost. I'd like to find out why this is happening.


I believe I already posted a tcpdump trace of the ICAP traffic, but I don't know if you had a chance to take a look at it. I had a quick look, but I'm not familiar with the ICAP protocol. In any case, I probably would see a lot of OPTIONS, REQMOD, RESPMOD methods, but I don't know if I would clearly detect initial TCP issues.


Anyway, here's a dumb question. Can't Squid "tell" when a TCP connection to an ICAP server has never completed correctly after x timeout, and close it down/reset it?
I'm using default values in squid.conf for the following:
connect_timeout
icap_connect_timeout
peer_connect_timeout

The docs say:
#  TAG: icap_connect_timeout
#       This parameter specifies how long to wait for the TCP connect to
#       the requested ICAP server to complete before giving up and either
#       terminating the HTTP transaction or bypassing the failure.


BTW I guess it's just a typo error because instead of an "HTTP transaction" I should read "ICAP transaction", right? 

Anyway, I have "bypass=0" for the ICAP service so I guess it should honor connect_timeout.
The default is connect_timeout 1 minute. 


With a 1-minute timeout it may be hard to see the sockets close when there's plenty of traffic, but I think I should see a substantial drop of open sockets when traffic is low (eg. at night). However, I don't see it.


What could I try?

Thank you very much for your time.

Vieri
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




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

  Powered by Linux