Varnish nighmare after upgrading : need help

[Raphael Mazelier]

>
>
> On 14/11/2017 23:41, Guillaume Quintard wrote:
>> Hi,
>>
>> 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)
>>
>> Cheers,

Hi All,

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 
completly wrong.

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).

Best,

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.


--
Raphael Mazelier