[squid-dev] [RFC] Fix shared memory initialization, cleanup. Ensure its usability.

[Kinkie]

Agreed. Thanks
On Dec 11, 2015 17:41, "Alex Rousskov" <rousskov at measurement-factory.com>
wrote:

> On 12/10/2015 02:23 PM, Kinkie wrote:
> > On Thu, Dec 10, 2015 at 10:07 PM, Alex Rousskov wrote:
> >> On 12/10/2015 11:25 AM, Francesco Chemolli wrote:
> >>> And it is actually pretty detectable: let’s choose an arbitrary size
> >>> of the shared segment and output a warning message to cache.log. This
> >>> won’t help with the speed, but it might help with the confusion..
>
>
> >> 2015/12/09 11:24:51| Total mlock() delay exceeded 5.3 seconds. See
> >> shared_memory_locking in squid.conf.documented.
>
>
> > I was thinking more of something _before_ the delay:
> > e.g. if shared memory is > 100mb, then
> > "locking XXX mbytes of shared memory. On some systems this may require
> > a long time. Squid is not dead, it's just thinking"
>
>
> I think the post-event warning is better:
>
> * It is difficult to guess which segment sizes will cause significant
> delays in a given environment.
>
> * Squid allocates many segments and a few large segments. Warning the
> admin before each large allocation would create a lot of noise. Not
> warning the admin before some large allocations would kind of defeat the
> idea of the preemptive warning itself.
>
> * There is a possibility that the significant (from admin point of view)
> startup delay is caused by the _cumulative_ effect of locking various
> shared memory segments and not by any single segment.
>
> * Warning folks about something that has not happened yet and may never
> happen increases log noise. In this particular case, we _can_ warn when
> we know that startup was significantly delayed because of locking,
> reducing that noise.
>
> * There is a good chance that somebody concerned about startup delays
> will notice the first line printed _after_ the delay.
>
>
> Are you sure that preemptive per-segment warnings are better than an
> acknowledgement of the problem after it happens? Do you think the latter
> is likely to be missed by admins investigating startup delays?
>
>
> > and then when it's done "shared memory locking of X Mb done in Y
> > seconds. This may be normal depending on the size of the shared memory
> > area".
>
> I would rather put explanations in squid.conf.documented so that we do
> not have to risk misleading folks when discussing complex issues using a
> one-line statement. Besides, we need to point folks to options
> controlling this behavior (in case they do not think that slow startup
> is "normal" for them).
>
>
> Thank you,
>
> Alex.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-dev/attachments/20151213/b5079a63/attachment.html>