Re: Half-closed connections eat 100% cpu

On 5 Jul 2001, at 19:15, Henrik Nordstrom <hno@hem.passagen.se> wrote:

> Adrian Chadd wrote:
>
> > Those sockets shouldn't make it into the poll array.
> > The defererd read code should prevent it.
>
> These sockest should be read once/second.
>
> > That said, I see it too, and I turn off half_closed_clients.
>
> Any clue on how to trigger it?

 not quite.
 I've seen it under high loads, less under light loads too.
 I've also noticed that spikes in cpu-burn are usually pretty short,
 I'd even think of 1 sec periods. Initially I thought it happens only
 when box is overloaded and it takes over 1 sec time to process one
 comm_poll run, but it seems not so.
 Last time I was digging into it I think I found that some conditions
 in clientReadRequest() were not handled for half-closed's, but I'm
 not sure, too much codepaths to look into for me.

 My guesses:
 It seems that 1sec defer occurs only if there was something read from
 socket. So I'd guess that if you connect and without sending any request
 half-close the request path, squid should burn cpu. Maybe could happen
 irl if clients pre-open connections to proxy, but don't use them up.

 If client sends incomplete request, squid keeps trying to read from
 socket, should defer. Typical read requests from sockets during cpu100%
 are less than socket buffer size which hints that partial request is
 there and defering fails somehow.
 Sometimes 0-byte reads are requested, not sure why, but they also cause
 clientReadRequest() do nothing, looks like half-closed, but skips defer.
 Maybe delay-pools are also involved here (0-byte reads?).

 Lately I saw cpu100% on sockets that shortly become idle serverside
 sockets. Kind of different problem.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Fri Jul 06 2001 - 04:39:23 MDT