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

[Kinkie]

On Thu, Dec 10, 2015 at 10:07 PM, Alex Rousskov
<rousskov at 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