Re: [PATCH] immortal helpers

On Sun, 21 Feb 2010 22:27:06 +0100, Henrik Nordström
<henrik_at_henriknordstrom.net> wrote:
> lör 2010-02-20 klockan 18:25 -0700 skrev Alex Rousskov:
>
>> The reasons you mention seem like a good justification for this option
>> official existence. I do not quite get the "fork bomb" analogy because
>> we are not creating more than a configured number of concurrent forks,
>> are we? We may create processes at a high rate but there is nothing
>> exploding here, is there?
>
> With our large in-memory cache index even two concurrent forks is kind
> of exploding on a large server. Consider for example the not unrealistic
> case of a 8GB cache index.. I actually have some clients with such
> indexes.
>
> Thankfully having ample amounts of swap silently eats up this explosion,
> but it may be a little hard to explain why one needs orders of magnitude
> more swap than memory..
>
>> The forking/waitpid code in main.cc analyses the exit status of a kid.
>> Can we rely on that to cover your use case? I think we can ignore the
>> fact that some helpers are poorly written because we are not making
>> things worse for them (but may be making things better for well-written
>> ones).
>
> exit code checks should cover most crashing helpers.
>
> but does it matter to Squid other than for diagnostic purposes if the
> helper crashed or simply exited of free will?

Yes it does.

A helper crashing may never be able to handle any traffic (crash on
load/fork). This will lock Squid into a loop starting helpers and block the
requests which keep re-trying a crashing helper.

Other early-close cases involve helpers either running for a short time or
handling at least one request before closing. These helpers will be
annoying, but are not expected to halt traffic through squid. We can ignore
those cases and help people configure correctly as-needed just like we do
now.

Amos
Received on Mon Feb 22 2010 - 00:32:07 MST