[squid-users] TCP out of memory
Vieri
rentorbuy at yahoo.com
Tue Jan 9 09:40:19 UTC 2018
________________________________
From: Amos Jeffries <squid3 at treenet.co.nz>
>
> 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
More information about the squid-users
mailing list