Varnish nighmare after upgrading : need help
raph at futomaki.net
Thu Nov 23 20:57:46 UTC 2017
> On 14/11/2017 23:41, Guillaume Quintard wrote:
>> Let's look at the usual suspects first, can we get the output of "ps
>> aux |grep varnish" and a pastebin of "varnishncsa -1"?
>> Are you using any vmod?
>> man varnishncsa will help craft a format line with the response time
>> (on mobile now, I don't have access to it)
A short following of the situation and what seems to mitigate the
problem/make this platform works.
After lot of testing and A/B testing, the solution for us was to make
more smaller instances.
We basically double all the servers(vms) , but in the other hand divide
by two (or more) the ram, and the memory allocated to varnish.
We also revert using malloc with little ram (4G) , 12g on the vm(s). We
also make scheduled task to flush the cache (restarting varnish).
This is a completely counter intuitive, because nuking some entries
seems better to handle a big cache with no nuke.
In my understating it means that our hot content remains in the cache,
and nuking object is OK. This may also means that our ttl in objects are
Anyway it seems working. Thanks a lot for the people who help us. (and
I'm sure we can find a way to re-tribute this).
PS : in the battle we upgrade to 5.2 (seems ok), just a quick question
on varnihstat. I read the changelog and understand that the varnishstat
communication with varnish have change. I have just a little glith. When
launching varnishstat the hitrate counter and average reset randomly at
the beginning, and after a while stabilize. This is a bit annoying
because we often want to have a quick view on the hitrate.
More information about the varnish-misc