Bind 8.2.2-REL eating CPU time in tight loop (HP-UX 10.20)

[Mark_Andrews at iengines.com]

> On Thu, Nov 04, 1999 at 10:22:29PM +1100, Mark_Andrews at iengines.com wrote:
> > > Just a (stupid?) idea, but why is select dealing with descriptor 26 while
> > > later accept is used on descriptor 25??
> > 
> > 	No, it is saying check the first 26 file descriptors 0..25
> > 	for activity.  It finds activity on 2 file descriptors 24
> > 	and 25.  24 is a udp socket, 25 is a tcp socket listening
> > 	for connections.
> Uh, yes, I should have checked select() more carefully. Last time at
> dealt with select() was with regard to vgetty on HP-UX and memory seems
> to fade...
> 
> > 	What is interesting about this is the recvfrom is return
> > 	0 to the first call and accept is returning EAGAIN.  Select
> > 	has just returned 2 so neither of these conditions should
> > 	be occuring normally.
> > 
> > 	The recvfrom could be due to zero length udp packets and
> > 	the EAGAIN could be due to TCP sessions that are being
> > 	reset.  I suspect that you are under attack which named is
> > 	successfully repelling.  A packet trace may show some pattern.
> Hmm, I just had called ethereal and couldn't find anything in this
> regard.
> Also, I would have to look for an idea to "count" the calls to select,
> but as it seems, named takes 100% computer time if it can get it,
> so it doesn't seem to stay in select() for any amount of time, it
> just returns and loops.
> This behaviour reminds me of vgetty at that time, but this was 100%
> reproducable behaviour.
> 
> Ever tried to shut down your X before closing Netscape 4.x cleanly?
> It also suddenly starts to eat up CPU time, so maybe there is indeed
> something going on around closing TCP connections...
> At least as of now, I know a lot about the internals of Postfix, OpenSSL
> and some other things, but I never had a look into the bind internals...
> 
> Best regards,
> 	Lutz
	
	The alternative is that select() is broken (or breaks under
	load).  I am not aware of any such bug, but it wouldn't hurt
	to check with HP if they are aware of one and if so do they
	have a fix.

	Mark
--
Mark Andrews, Internet Engines Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at iengines.com