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. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
