Re: [squid-users] Squid CPU 100% infinite loop

Hi all,
some news and suggestions:
I have found the problem. In fact it's the problem mentionned on my last
mail, is right. Squid FD limit was reached, but squid doesn't mentionned
every time the freeze appear that it's a FD limit problem, then the
debug was so difficult.
Also, i think you must add a non portable check to check if squid FD
limit isn't greater than system ulimit (ulimit -n under OpenBSD). Squid
doesn't mention that and when this appear, it's also a freeze (squid FD
saturation) and no warning is mentionned in the logs. This check would
be at the squid start/reload.

What do you think about it ?

-- 
Best regards,
Loïc BLOT, 
UNIX systems, security and network expert
http://www.unix-experience.fr
Le jeudi 16 mai 2013 à 23:10 +0200, Loïc BLOT a écrit :
> Hi Alex,
> thanks for your reply. I have tried to analyse my logs, but... nothing
> and this is also disapointed because nothing special is in the logs, and
> when we look at them, all seems normal.
> 
> Can the FD system limit cause this problem ?  I have a  system FD limit
> of 2048 and squid limit of 1024. This evening squid said, out of
> descriptors when it runs in the pseudo "infinite loop" (before nothing
> was written with this entry in the logs when the event happened), then i
> have increased squid FD limit to 2048. At this moment, I have also
> checked FD sockets with netstat -anfinet|grep 3128 and i saw 1700
> connections to squid (and maybe nearly 1700 from squid himself). Then
> the FD limit was satured. To those FD, we must add FD for squidguard and
> DNS requests ? and also FD for logs ? Then theorical 5xFDx1700 =
> totalFD ? 
> Then consequently, squid runs with maxdesc and many connections are
> waiting and squid charge increase, am i right ?
> 
> This evening i have increased system limits for squid to 16386 and squid
> FD limit to 8192, if i'm right, tomorrow no problem will occur.
> Can you confirm to me what comportement can squid have when FD limit is
> reached ? (CPU charge ?)
> 
> Thanks for advance.