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