On Thu, Dec 10, 2015 at 10:07 PM, Alex Rousskov <rouss...@measurement-factory.com> wrote: > On 12/10/2015 11:25 AM, Francesco Chemolli wrote: >> >> Well, slow in starting up, not in operating, hopefully. > > Yes, I expect runtime performance to negligibly(?) improve during warmup > (on correctly configured deployments) due to pre-allocation of all > shared memory used during runtime. > > >> 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.. > > Excellent idea! And we can improve it by warning if the combined > mlock(2) _delay_ exceeds some hard-coded value. > > I wonder what that warning should say to avoid a [usually wrong] > implication that memory locking should be turned off. How about > something like this: > > """ > 2015/12/09 11:24:51| Total mlock() delay exceeded 5.3 seconds. See > shared_memory_locking in squid.conf.documented. > """ > > We can set level-1 reporting threshold at 5 or even 10 seconds. We do > not need to add a shared_memory_locking parameter to disable this > reporting (while still locking), do we?
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" 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". -- Francesco _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev