Memory utilisation gradually increasing
FULLER, David
FULLERD at parliament.uk
Wed Aug 1 11:05:25 UTC 2018
That’s great, thanks. Does the first VCL listed (labelled boot in column 4 – ‘available cold/cold 0 boot’) need to stay loaded and is there a recommended amount of VCLs to keep loaded?
From: Dridi Boukelmoune <dridi at varni.sh>
Date: Tuesday, 31 July 2018 at 10:03
To: "FULLER, David" <FULLERD at parliament.uk>
Cc: Guillaume Quintard <guillaume at varnish-software.com>, varnish-misc <varnish-misc at varnish-cache.org>
Subject: Re: Memory utilisation gradually increasing
On Mon, Jul 30, 2018 at 2:50 PM, FULLER, David <FULLERD at parliament.uk> wrote:
> Thanks Dridi,
>
> After further investigation I found that we do have a python/cron job running that checks for backend changes and if so does a vcl.load. This has resulted in a growing number of VCLs being loaded, as you suspected. After a redeploying the Varnish container this morning and then monitoring varnishadm we have gone from around 30 VCLs loaded to over 200 in a few hours. Is there a way to limit the number of VCLs that can be loaded, with older ones being dropped as new ones are loaded?
For Varnish 6.0 we released a new varnishreload script, see its usage:
https://github.com/varnishcache/pkg-varnish-cache/blob/0ad2f22629c4a368959c423a19e352c9c6c79682/systemd/varnishreload#L46-L74<https://github.com/varnishcache/pkg-varnish-cache/blob/0ad2f22629c4a368959c423a19e352c9c6c79682/systemd/varnishreload#L46-L74>
The main goals were to unify the reload script on all the platforms we
support and simplify the logic by only supporting the privileged
"service manager" use case. As a result it was also easy to add the -m
option to discard old reloads if have more than "maximum" reload VCLs.
In other words, it's up to the python script scheduled by your cron
job to keep track of reloads and discard older ones according to your
policy.
Dridi
UK Parliament Disclaimer: This e-mail is confidential to the intended recipient. If you have received it in error, please notify the sender and delete it from your system. Any unauthorised use, disclosure, or copying is not permitted. This e-mail has been checked for viruses, but no liability is accepted for any damage caused by any virus transmitted by this e-mail. This e-mail address is not secure, is not encrypted and should not be used for sensitive data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180801/e4378699/attachment.html>
More information about the varnish-misc
mailing list