Bug 41125

Summary: squid-2.4.STABLE7 loop on poll() - SMP kernel
Product: Base System Reporter: Henri Hennebert <hlh>
Component: kernAssignee: Adrian Chadd <adrian>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.6-STABLE   
Hardware: Any   
OS: Any   

Description Henri Hennebert 2002-07-29 16:40:01 UTC 
I'm running squid 2.4.STABLE7 (configured and compiled 'by hand' - not from
ports) on a SMP configuration. All seems normal until squid start to loop
and use 100% of a CPU. After a while, all return to normal and top shows
squid in poll state. Then 100% again...

I truss squid several times for 4-5 secs when in 100% CPU and get
the following result:

--- snip ---
poll(0xbfbfc13c,0x4b,0x0)			 = 2 (0x2)
read(0x43,0x961f000,0xfff)			 = 0 (0x0)
read(0x71,0x96e1000,0xfff)			 = 0 (0x0)
gettimeofday(0x8164efc,0x0)			 = 0 (0x0)
gettimeofday(0x8164efc,0x0)			 = 0 (0x0)
poll(0xbfbfc13c,0x4b,0x0)			 = 2 (0x2)
read(0x43,0x961f000,0xfff)			 = 0 (0x0)
read(0x71,0x96e1000,0xfff)			 = 0 (0x0)
gettimeofday(0x8164efc,0x0)			 = 0 (0x0)
gettimeofday(0x8164efc,0x0)			 = 0 (0x0)
poll(0xbfbfc13c,0x4b,0x0)			 = 2 (0x2)
read(0x43,0x961f000,0xfff)			 = 0 (0x0)
read(0x71,0x96e1000,0xfff)			 = 0 (0x0)
gettimeofday(0x8164efc,0x0)			 = 0 (0x0)
gettimeofday(0x8164efc,0x0)			 = 0 (0x0)
poll(0xbfbfc13c,0x4b,0x0)			 = 2 (0x2)
read(0x43,0x961f000,0xfff)			 = 0 (0x0)
read(0x71,0x96e1000,0xfff)			 = 0 (0x0)
gettimeofday(0x8164efc,0x0)			 = 0 (0x0)
gettimeofday(0x8164efc,0x0)			 = 0 (0x0)
SIGNAL 27
SIGNAL 27
gettimeofday(0x8164efc,0x0)			 = 0 (0x0)
gettimeofday(0x281c282c,0x0)			 = 0 (0x0)
sigprocmask(0x3,0x281c28b8,0x0)			 = 0 (0x0)
sigaltstack(0x281de9e0,0x0)			 = 0 (0x0)
sigreturn(0x81f6064)				 = 0 (0x0)
poll(0xbfbfbf14,0x1,0x0)			 = 0 (0x0)
poll(0xbfbfc13c,0x4b,0x0)			 = 2 (0x2)
read(0x43,0x961f000,0xfff)			 = 0 (0x0)
read(0x71,0x96e1000,0xfff)			 = 0 (0x0)
--- snip ---

During the same 100% period, the other truss sampling show
poll call return 3, 4, 3, 2, ...

Squid is using 3 cache dirs with async io (aufs). I try
sync io (ufs) and disk daemon (diskd) to no avail.

It seems that it's not related to the squid load (average 120 req/min).
The 100% period is at least 4-5 minutes long.

I never encounter this situation when running squid on a mono-
processor config (at least since FreeBSD 3.2 and squid-2.2).

Is it a problem with SMP / poll() ?
Comment 1 Tom Hukins freebsd_committer freebsd_triage 2002-08-05 18:10:47 UTC 
Responsible Changed
From-To: freebsd-bugs->adrian

Over to squid Port MAINTAINER - this problem may not be due to Squid itself, 
but it seems like a good place to start
Comment 2 Henri Hennebert 2002-08-08 09:38:54 UTC 
HOOPS - SORRY -

I find somthing similar in the Squid Bugzilla (Bug #354).

I turn half_closed_clients to off in squid.conf

The problem seems to be solved - I'll post a follow-up
Tomorrow.

Sorry for the disturbance.

Henri
Comment 3 Henri Hennebert 2002-08-09 14:30:45 UTC 
Afer One day with parameter

half_closed_clients off

The problem has disappeared

Henri
Comment 4 Adrian Chadd freebsd_committer freebsd_triage 2003-01-31 08:52:23 UTC 
You shouldn't run aufs under freebsd _at all_ - unless there's been
a big change lately wrt threading aufs will run on a single CPU.

Please run diskd - at least the disk processes will be scheduleable
on the other CPU. It'll handle load quite a lot better.

Also, yes, turn half_closed_clients off - I believe we'll be attacking
that in squid-3 but thats a way off being production-ready.




Adrian
Comment 5 Jonathan Noack 2003-09-15 23:38:04 UTC 
A fix was reported to have resolved the issue and there haven't been any
further reports in over a year.  Please close...
Comment 6 Kirill Ponomarev freebsd_committer freebsd_triage 2004-06-23 13:22:58 UTC 
State Changed
From-To: open->closed

Fixed very long time ago.