On 11/08/2016 11:17 p.m., Eugene M. Zheganin wrote: > Hi. > > On 30.06.16 17:19, Amos Jeffries wrote: >> >> Okay, I wasn't suggesting you post it here. Its likely to be too big for >> that. >> >> I would look for the messages about the large object, and its FD. Then, >> for anthing about why it was closed by Squid. Not sure what tha would be >> at this point though. >> There are some scripts in the Squid sources scripts/ directory that >> might help wade through the log. Or the grep tool. >> >> > I enabled logLevel 2 for all squid facilities, but so far I didn't > fugura out any pattern from log. The only thing I noticed - is that for > large download the Recv-Q value reported by the netstat for a particular > squid-to-server connection is extremely high, so is the Send-Q value for > a connection from squid to client. I don't know if it's a cause or a > consequence, but from my point of view this may indicate that buffers > are overflown for some reason, I think this may cause, in turn, RSTs and > connection closing - am I right ?. I still don't know whether it's a > squid fault of may be it's local OS misconfiguration. Er. That indicates buffers are probably full, but not necessarily overflown. If the Send-Q is high that means the client is not reading what Squid has sent. If the client stays hung like that for too long (15min IIRC) Squid will give up on it and close the connections so it can move on to handle other more responsive clients. TCP has a much shorter timeout than Squid, so it may not be Squid aborting, but the TCP stack. Either way its for the same reason - client is not read(2)'ing the traffic. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
