From t.winkelmann at ffh.de  Wed Jul  4 08:43:44 2018
From: t.winkelmann at ffh.de (Winkelmann, Thomas (RADIO TELE FFH - Online))
Date: Wed, 4 Jul 2018 10:43:44 +0200
Subject: Connection resets / timout with Varnish 6.0 and HTTP/2
Message-ID: <8A76B2DB46634944BEEBB218DAE22BC2654F79598F@exchange-srv2.office.radioteleffh.de>

Hello everbody,

finally we got Varnish 6.0 + Vmods + Hitch TLS running on Ubuntu. So far everything works fine, also HTTP/2 Support.
But as soon as we are receiving some more requests (approx. > 500req/s) varnish does not deliver all requests anymore. The syslog is flooded with messages like:

Jul  4 08:04:05 cache1-vm hitch[5480]: 20180704T080405.289397 [ 5502] {backend-connect}: Connection refused
Jul  4 08:04:05 cache1-vm hitch[5480]: 20180704T080405.290213 [ 5502] {backend-connect}: Connection refused
...

Jul  4 07:57:29 cache1-vm hitch[5480]: 20180704T075729.837457 [ 5504] xxx.xxx.xxx.xxx:5835 :0 1469:1470 backend connect timeout
Jul  4 07:57:29 cache1-vm hitch[5480]: 20180704T075729.851809 [ 5510] xxx.xxx.xxx.xxx:54396 :0 7190:7191 backend connect timeout
...

Jul  4 07:57:31 cache1-vm hitch[5480]: 20180704T075731.488096 [ 5510] {backend} Socket error: Connection reset by peer

We had some similar problems in the past with HTTPS. We could solve them by adding:

net.ipv4.ip_local_port_range = 4096 64999
net.ipv4.tcp_tw_reuse = 1

to /etc/sysctl.conf But this seems to be not the problem here.

As soon as we remove alpn-protos = "h2,http/1.1" from hitch.conf everything is working normally.

Are there any limitations regarding HTTP/2 within varnish?

Our config:

[Service]
Type=simple
LimitNOFILE=131072
LimitMEMLOCK=82000
ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -a '[::1]:6086,PROXY' -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -p thread_pools=2 -p thread_pool_min=200 -p thread_pool_max=5000 -p timeout_idle=100 -p send_timeout=3600 -p feature=+http2 -s malloc,2g
ProtectSystem=full
ProtectHome=true
PrivateTmp=true
PrivateDevices=true

Also DefaultLimitNOFILE is set to 250000 in /etc/systemd/system.conf.

Hitch config:

# Listening
frontend = "[*]:443"
ciphers  = "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"
# TLS 1.0 wird gebraucht, damit alte Server (intranet-srv) eine Verbindung aufbauen k?nnen
tls-protos = TLSv1.1 TLSv1.2 TLSv1.0

# Send traffic to the Varnish backend using the PROXY protocol
backend        = "[::1]:6086"
write-proxy-v2 = on
alpn-protos = "h2,http/1.1"

# Number of processes
workers = 8

We already searched on the varnish github account for similar problem, but did not found anything...

Thanks,
Thomas

________________________________
RADIO / TELE FFH GmbH & Co. Betriebs-KG
FFH-Platz 1, 61111 Bad Vilbel
HRA - Nr. 26092 Frankfurt/Main
USt.IdNr. DE 112152620
Gesch?ftsf?hrer / Programmdirektor: Hans-Dieter Hillmoth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180704/22f68e16/attachment.html>

From dridi at varni.sh  Fri Jul  6 12:34:17 2018
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Fri, 6 Jul 2018 14:34:17 +0200
Subject: Connection resets / timout with Varnish 6.0 and HTTP/2
In-Reply-To: <8A76B2DB46634944BEEBB218DAE22BC2654F79598F@exchange-srv2.office.radioteleffh.de>
References: <8A76B2DB46634944BEEBB218DAE22BC2654F79598F@exchange-srv2.office.radioteleffh.de>
Message-ID: <CABoVN9AtJ9Li-MozbedBbUJvEFC=5M5ViEdAci=APXwtL35CoQ@mail.gmail.com>

Hello Thomas,

On Wed, Jul 4, 2018 at 10:43 AM, Winkelmann, Thomas (RADIO TELE FFH -
Online) <t.winkelmann at ffh.de> wrote:
> Hello everbody,
>
> finally we got Varnish 6.0 + Vmods + Hitch TLS running on Ubuntu. So far
> everything works fine, also HTTP/2 Support.
>
<snip>
>
> We had some similar problems in the past with HTTPS. We could solve them by
> adding:
>
> net.ipv4.ip_local_port_range = 4096 64999
> net.ipv4.tcp_tw_reuse = 1
>
> to /etc/sysctl.conf But this seems to be not the problem here.

Thanks again for reporting both your problem and solution.

> As soon as we remove alpn-protos = "h2,http/1.1" from hitch.conf everything
> is working normally.
>
> Are there any limitations regarding HTTP/2 within varnish?
>
<snip>
>
> We already searched on the varnish github account for similar problem, but
> did not found anything...

You may have run into a known worker thread leak [1] that could be
caused by either misbehaving browsers or bugs in our h2 stack. Leaking
too many threads may put your varnish in a deadlock [2] situation that
we have yet to fix (but much less likely in the absence of the
aforementioned leak).

Could you please try building from source my 6.0 branch [3] that is
work in progress towards a 6.0.1 release? You may still run into a
crash but I'm waiting for a test case to be written before resuming
the back-porting effort.

You will likely need to rebuild your modules too, because unless I'm
confusing you with someone else I'm pretty sure you were referring
to our varnish-modules [5] collection of VMODs.

Thanks,
Dridi

[1] https://github.com/varnishcache/varnish-cache/issues/2623
[2] https://github.com/varnishcache/varnish-cache/issues/2418
[3] https://github.com/dridi/varnish-cache/tree/6.0
[4] https://github.com/varnishcache/varnish-cache/issues/2572#issuecomment-402075064
[5] https://github.com/varnish/varnish-modules

From t.winkelmann at ffh.de  Thu Jul 12 11:00:10 2018
From: t.winkelmann at ffh.de (Winkelmann, Thomas (RADIO TELE FFH - Online))
Date: Thu, 12 Jul 2018 13:00:10 +0200
Subject: AW: Connection resets / timout with Varnish 6.0 and HTTP/2
In-Reply-To: <CABoVN9AtJ9Li-MozbedBbUJvEFC=5M5ViEdAci=APXwtL35CoQ@mail.gmail.com>
References: <8A76B2DB46634944BEEBB218DAE22BC2654F79598F@exchange-srv2.office.radioteleffh.de>
 <CABoVN9AtJ9Li-MozbedBbUJvEFC=5M5ViEdAci=APXwtL35CoQ@mail.gmail.com>
Message-ID: <8A76B2DB46634944BEEBB218DAE22BC2654F7959E5@exchange-srv2.office.radioteleffh.de>

Hello Dridi,

we just managed to clone your git tree and successfully build varnish from source. But the vmods are not found...

>Message from VCC-compiler:
>Could not load VMOD vsthrottle
>        File name: libvmod_vsthrottle.so
>        dlerror: libvarnishapi.so.1: cannot open shared object file: No such file or directory

They were compiled to /usr/local/lib/varnish/vmods/, but varnish seems to search in another directory?

As soon as I have running vsthrottle I can put some traffic to the server...

Thanks,
Thomas

-----Urspr?ngliche Nachricht-----
Von: Dridi Boukelmoune [mailto:dridi at varni.sh]
Gesendet: Freitag, 6. Juli 2018 14:34
An: Winkelmann, Thomas (RADIO TELE FFH - Online)
Cc: varnish-misc at varnish-cache.org
Betreff: Re: Connection resets / timout with Varnish 6.0 and HTTP/2

Hello Thomas,

On Wed, Jul 4, 2018 at 10:43 AM, Winkelmann, Thomas (RADIO TELE FFH -
Online) <t.winkelmann at ffh.de> wrote:
> Hello everbody,
>
> finally we got Varnish 6.0 + Vmods + Hitch TLS running on Ubuntu. So
> far everything works fine, also HTTP/2 Support.
>
<snip>
>
> We had some similar problems in the past with HTTPS. We could solve
> them by
> adding:
>
> net.ipv4.ip_local_port_range = 4096 64999 net.ipv4.tcp_tw_reuse = 1
>
> to /etc/sysctl.conf But this seems to be not the problem here.

Thanks again for reporting both your problem and solution.

> As soon as we remove alpn-protos = "h2,http/1.1" from hitch.conf
> everything is working normally.
>
> Are there any limitations regarding HTTP/2 within varnish?
>
<snip>
>
> We already searched on the varnish github account for similar problem,
> but did not found anything...

You may have run into a known worker thread leak [1] that could be caused by either misbehaving browsers or bugs in our h2 stack. Leaking too many threads may put your varnish in a deadlock [2] situation that we have yet to fix (but much less likely in the absence of the aforementioned leak).

Could you please try building from source my 6.0 branch [3] that is work in progress towards a 6.0.1 release? You may still run into a crash but I'm waiting for a test case to be written before resuming the back-porting effort.

You will likely need to rebuild your modules too, because unless I'm confusing you with someone else I'm pretty sure you were referring to our varnish-modules [5] collection of VMODs.

Thanks,
Dridi

[1] https://github.com/varnishcache/varnish-cache/issues/2623
[2] https://github.com/varnishcache/varnish-cache/issues/2418
[3] https://github.com/dridi/varnish-cache/tree/6.0
[4] https://github.com/varnishcache/varnish-cache/issues/2572#issuecomment-402075064
[5] https://github.com/varnish/varnish-modules

RADIO / TELE FFH GmbH & Co. Betriebs-KG
FFH-Platz 1, 61111 Bad Vilbel
HRA - Nr. 26092 Frankfurt/Main
USt.IdNr. DE 112152620
Gesch?ftsf?hrer / Programmdirektor: Hans-Dieter Hillmoth

From t.winkelmann at ffh.de  Thu Jul 12 11:24:56 2018
From: t.winkelmann at ffh.de (Winkelmann, Thomas (RADIO TELE FFH - Online))
Date: Thu, 12 Jul 2018 13:24:56 +0200
Subject: AW: Connection resets / timout with Varnish 6.0 and HTTP/2
In-Reply-To: <8A76B2DB46634944BEEBB218DAE22BC2654F794473@exchange-srv2.office.radioteleffh.de>
References: <8A76B2DB46634944BEEBB218DAE22BC2654F79598F@exchange-srv2.office.radioteleffh.de>
 <CABoVN9AtJ9Li-MozbedBbUJvEFC=5M5ViEdAci=APXwtL35CoQ@mail.gmail.com>
 <8A76B2DB46634944BEEBB218DAE22BC2654F794473@exchange-srv2.office.radioteleffh.de>
Message-ID: <8A76B2DB46634944BEEBB218DAE22BC2654F7959E6@exchange-srv2.office.radioteleffh.de>

We could fix the problem by running ldconfig.

See: https://ma.ttias.be/varnish-varnishhistvarnishtop-error-while-loading-shared-libraries-libvarnishapi-so-1-cannot-open-shared-object-file/

In which way do you prefer to reveice the crash reports? Or which log files are helpful for you to get the h2 bug fixed?

-----Urspr?ngliche Nachricht-----
Von: Winkelmann, Thomas (RADIO TELE FFH - Online)
Gesendet: Donnerstag, 12. Juli 2018 13:00
An: 'Dridi Boukelmoune'
Cc: 'varnish-misc at varnish-cache.org'
Betreff: AW: Connection resets / timout with Varnish 6.0 and HTTP/2

Hello Dridi,

we just managed to clone your git tree and successfully build varnish from source. But the vmods are not found...

>Message from VCC-compiler:
>Could not load VMOD vsthrottle
>        File name: libvmod_vsthrottle.so
>        dlerror: libvarnishapi.so.1: cannot open shared object file: No
>such file or directory

They were compiled to /usr/local/lib/varnish/vmods/, but varnish seems to search in another directory?

As soon as I have running vsthrottle I can put some traffic to the server...

Thanks,
Thomas

-----Urspr?ngliche Nachricht-----
Von: Dridi Boukelmoune [mailto:dridi at varni.sh]
Gesendet: Freitag, 6. Juli 2018 14:34
An: Winkelmann, Thomas (RADIO TELE FFH - Online)
Cc: varnish-misc at varnish-cache.org
Betreff: Re: Connection resets / timout with Varnish 6.0 and HTTP/2

Hello Thomas,

On Wed, Jul 4, 2018 at 10:43 AM, Winkelmann, Thomas (RADIO TELE FFH -
Online) <t.winkelmann at ffh.de> wrote:
> Hello everbody,
>
> finally we got Varnish 6.0 + Vmods + Hitch TLS running on Ubuntu. So
> far everything works fine, also HTTP/2 Support.
>
<snip>
>
> We had some similar problems in the past with HTTPS. We could solve
> them by
> adding:
>
> net.ipv4.ip_local_port_range = 4096 64999 net.ipv4.tcp_tw_reuse = 1
>
> to /etc/sysctl.conf But this seems to be not the problem here.

Thanks again for reporting both your problem and solution.

> As soon as we remove alpn-protos = "h2,http/1.1" from hitch.conf
> everything is working normally.
>
> Are there any limitations regarding HTTP/2 within varnish?
>
<snip>
>
> We already searched on the varnish github account for similar problem,
> but did not found anything...

You may have run into a known worker thread leak [1] that could be caused by either misbehaving browsers or bugs in our h2 stack. Leaking too many threads may put your varnish in a deadlock [2] situation that we have yet to fix (but much less likely in the absence of the aforementioned leak).

Could you please try building from source my 6.0 branch [3] that is work in progress towards a 6.0.1 release? You may still run into a crash but I'm waiting for a test case to be written before resuming the back-porting effort.

You will likely need to rebuild your modules too, because unless I'm confusing you with someone else I'm pretty sure you were referring to our varnish-modules [5] collection of VMODs.

Thanks,
Dridi

[1] https://github.com/varnishcache/varnish-cache/issues/2623
[2] https://github.com/varnishcache/varnish-cache/issues/2418
[3] https://github.com/dridi/varnish-cache/tree/6.0
[4] https://github.com/varnishcache/varnish-cache/issues/2572#issuecomment-402075064
[5] https://github.com/varnish/varnish-modules

RADIO / TELE FFH GmbH & Co. Betriebs-KG
FFH-Platz 1, 61111 Bad Vilbel
HRA - Nr. 26092 Frankfurt/Main
USt.IdNr. DE 112152620
Gesch?ftsf?hrer / Programmdirektor: Hans-Dieter Hillmoth

From guillaume at varnish-software.com  Thu Jul 12 12:21:38 2018
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Thu, 12 Jul 2018 05:21:38 -0700
Subject: Connection resets / timout with Varnish 6.0 and HTTP/2
In-Reply-To: <8A76B2DB46634944BEEBB218DAE22BC2654F7959E6@exchange-srv2.office.radioteleffh.de>
References: <8A76B2DB46634944BEEBB218DAE22BC2654F79598F@exchange-srv2.office.radioteleffh.de>
 <CABoVN9AtJ9Li-MozbedBbUJvEFC=5M5ViEdAci=APXwtL35CoQ@mail.gmail.com>
 <8A76B2DB46634944BEEBB218DAE22BC2654F794473@exchange-srv2.office.radioteleffh.de>
 <8A76B2DB46634944BEEBB218DAE22BC2654F7959E6@exchange-srv2.office.radioteleffh.de>
Message-ID: <CAJ6ZYQxzESkOJPDBDU887rGej1jh7F6ZL28x+=9JJH9up-bwbQ@mail.gmail.com>

Hi Thomas,

You can use the vcl_path parameter to adjust where varnish will look for
the vmod files.

Cheers,

-- 
Guillaume Quintard

On Thu, Jul 12, 2018 at 4:24 AM, Winkelmann, Thomas (RADIO TELE FFH -
Online) <t.winkelmann at ffh.de> wrote:

> We could fix the problem by running ldconfig.
>
> See: https://ma.ttias.be/varnish-varnishhistvarnishtop-error-
> while-loading-shared-libraries-libvarnishapi-so-1-
> cannot-open-shared-object-file/
>
> In which way do you prefer to reveice the crash reports? Or which log
> files are helpful for you to get the h2 bug fixed?
>
> -----Urspr?ngliche Nachricht-----
> Von: Winkelmann, Thomas (RADIO TELE FFH - Online)
> Gesendet: Donnerstag, 12. Juli 2018 13:00
> An: 'Dridi Boukelmoune'
> Cc: 'varnish-misc at varnish-cache.org'
> Betreff: AW: Connection resets / timout with Varnish 6.0 and HTTP/2
>
> Hello Dridi,
>
> we just managed to clone your git tree and successfully build varnish from
> source. But the vmods are not found...
>
> >Message from VCC-compiler:
> >Could not load VMOD vsthrottle
> >        File name: libvmod_vsthrottle.so
> >        dlerror: libvarnishapi.so.1: cannot open shared object file: No
> >such file or directory
>
> They were compiled to /usr/local/lib/varnish/vmods/, but varnish seems to
> search in another directory?
>
> As soon as I have running vsthrottle I can put some traffic to the
> server...
>
> Thanks,
> Thomas
>
> -----Urspr?ngliche Nachricht-----
> Von: Dridi Boukelmoune [mailto:dridi at varni.sh]
> Gesendet: Freitag, 6. Juli 2018 14:34
> An: Winkelmann, Thomas (RADIO TELE FFH - Online)
> Cc: varnish-misc at varnish-cache.org
> Betreff: Re: Connection resets / timout with Varnish 6.0 and HTTP/2
>
> Hello Thomas,
>
> On Wed, Jul 4, 2018 at 10:43 AM, Winkelmann, Thomas (RADIO TELE FFH -
> Online) <t.winkelmann at ffh.de> wrote:
> > Hello everbody,
> >
> > finally we got Varnish 6.0 + Vmods + Hitch TLS running on Ubuntu. So
> > far everything works fine, also HTTP/2 Support.
> >
> <snip>
> >
> > We had some similar problems in the past with HTTPS. We could solve
> > them by
> > adding:
> >
> > net.ipv4.ip_local_port_range = 4096 64999 net.ipv4.tcp_tw_reuse = 1
> >
> > to /etc/sysctl.conf But this seems to be not the problem here.
>
> Thanks again for reporting both your problem and solution.
>
> > As soon as we remove alpn-protos = "h2,http/1.1" from hitch.conf
> > everything is working normally.
> >
> > Are there any limitations regarding HTTP/2 within varnish?
> >
> <snip>
> >
> > We already searched on the varnish github account for similar problem,
> > but did not found anything...
>
> You may have run into a known worker thread leak [1] that could be caused
> by either misbehaving browsers or bugs in our h2 stack. Leaking too many
> threads may put your varnish in a deadlock [2] situation that we have yet
> to fix (but much less likely in the absence of the aforementioned leak).
>
> Could you please try building from source my 6.0 branch [3] that is work
> in progress towards a 6.0.1 release? You may still run into a crash but I'm
> waiting for a test case to be written before resuming the back-porting
> effort.
>
> You will likely need to rebuild your modules too, because unless I'm
> confusing you with someone else I'm pretty sure you were referring to our
> varnish-modules [5] collection of VMODs.
>
> Thanks,
> Dridi
>
> [1] https://github.com/varnishcache/varnish-cache/issues/2623
> [2] https://github.com/varnishcache/varnish-cache/issues/2418
> [3] https://github.com/dridi/varnish-cache/tree/6.0
> [4] https://github.com/varnishcache/varnish-cache/
> issues/2572#issuecomment-402075064
> [5] https://github.com/varnish/varnish-modules
>
> RADIO / TELE FFH GmbH & Co. Betriebs-KG
> FFH-Platz 1, 61111 Bad Vilbel
> HRA - Nr. 26092 Frankfurt/Main
> USt.IdNr. DE 112152620
> Gesch?ftsf?hrer / Programmdirektor: Hans-Dieter Hillmoth
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180712/053949dd/attachment-0001.html>

From hugues at betabrand.com  Tue Jul 17 23:35:23 2018
From: hugues at betabrand.com (Hugues Alary)
Date: Tue, 17 Jul 2018 16:35:23 -0700
Subject: Assert error in ban_lurker_getfirst()
Message-ID: <CAL_utwaQxLNYji3na_PjLuxptekULykAbGUJW2N2oh+0u1BBow@mail.gmail.com>

Hi there,

Today the varnish child panicked:

varnish> panic.show
200
Panic at: Tue, 17 Jul 2018 23:24:28 GMT
Assert error in ban_lurker_getfirst(), cache/cache_ban_lurker.c line 177:
  Condition((oc->flags & OC_F_BUSY) == 0) not true.
version = varnish-6.0.0 revision a068361dff0d25a0d85cf82a6e5fdaf315e06a7d,
vrt api = 7.0
ident = Linux,4.14.22+,x86_64,-junix,-smalloc,-sdefault,-hcritbit,epoll
now = 582423.461242 (mono), 1531869856.455080 (real)
Backtrace:
  0x561f9e331957: varnishd(+0x4a957) [0x561f9e331957]
  0x561f9e396730: varnishd(VAS_Fail+0x40) [0x561f9e396730]
  0x561f9e3154e9: varnishd(ban_lurker+0xba9) [0x561f9e3154e9]
  0x561f9e350747: varnishd(+0x69747) [0x561f9e350747]
  0x7fb783eda494: /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)
[0x7fb783eda494]
  0x7fb783c1cacf: /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)
[0x7fb783c1cacf]
errno = 110 (Connection timed out)
thread = (ban-lurker)
thr.req = (nil) {
},
thr.busyobj = (nil) {
},

Any idea about what could have happened?

Cheers,
-Hugues
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180717/da351b8c/attachment.html>

From igzivkov at gmail.com  Thu Jul 19 08:32:20 2018
From: igzivkov at gmail.com (Igor Zivkovic)
Date: Thu, 19 Jul 2018 10:32:20 +0200
Subject: Escaping double quotes in probe request
Message-ID: <3fce8e49-7937-20fe-47bf-bee3410e0c15@gmail.com>

Hello,

Is there a way to escape double quotes in probe requests? I need to send 
a JSON request and I've tried %22 but checking the packets with tcpdump 
it seems Varnish doesn't convert escapes back to double quotes. For 
example:

   .probe = {
     .request =
       "POST /probe.php HTTP/1.1"
       "Host: virtualhost.example.com"
       "Content-Type: application/json"
       "Connection: close"
       ""
       "{%22key%22:%22value%22}";
   }

Thanks,
Igor

From Tom.Anheyer at berlinonline.de  Mon Jul 23 07:27:17 2018
From: Tom.Anheyer at berlinonline.de (Anheyer, Tom)
Date: Mon, 23 Jul 2018 07:27:17 +0000
Subject: vmod_var memory alloc assert -> panic again
Message-ID: <8AE07C2AEF8F2D4CA8887FDC94F779B01222E981@klnsmxmbxp005.DMSYS.de>

Hello,

In the last few days we observe some cache resets. These are triggered by mod_var while allocation memory. I have seen different bug reports regarding to this issue in the last years but no stable  solution.

We use varnish 6.0, varnish_modules 0.15  with the default workspace settings.

Is their a way to debug the workspace memory usage?
Any other solution?


Panic at: Sat, 21 Jul 2018 07:28:58 GMT
Assert error in vh_get_var_alloc(), vmod_var.c line 112:
  Condition((v) != 0) not true.
version = varnish-6.0.0 revision a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, vrt api = 7.0
ident = Linux,4.4.0-130-generic,x86_64,-junix,-smalloc,-sdefault,-hcritbit,epoll
now = 1355228.763723 (mono), 1532158138.334678 (real)
Backtrace:
  0x438fb8: /usr/sbin/varnishd() [0x438fb8]
  0x495e50: /usr/sbin/varnishd(VAS_Fail+0x40) [0x495e50]
  0x7fbf837bc244: ./vmod_cache/_vmod_var.DILAEPESJTTNHFSZENLGFJXNZZCJCQJX(+0x1244) [0x7fbf837bc244]
  0x7fbf837bc27e: ./vmod_cache/_vmod_var.DILAEPESJTTNHFSZENLGFJXNZZCJCQJX(vmod_set_string+0x2e) [0x7fbf837bc27e]
  0x7fbf884913e8: vcl_git-6b53c70-Tom-Anheyer-2018-07-21-080805-0200.1532153312.713054419/vgc.so(VGC_function_vcl_recv+0x3e8) [0x7fbf884913e8]
  0x4489eb: /usr/sbin/varnishd() [0x4489eb]
  0x44b60a: /usr/sbin/varnishd(VCL_recv_method+0x5a) [0x44b60a]
  0x43d006: /usr/sbin/varnishd(CNT_Request+0x876) [0x43d006]
  0x45f0b7: /usr/sbin/varnishd() [0x45f0b7]
  0x4553bf: /usr/sbin/varnishd() [0x4553bf]
thread = (cache-worker)
thr.req = 0x7fbf80017020 {
  vxid = 262146, transport = HTTP/1 {
    state = HTTP1::Proc
  }
  step = R_STP_RECV,
  req_body = R_BODY_NONE,
  restarts = 0, esi_level = 0,
  sp = 0x7fbf8000e220 {
    fd = 47, vxid = 262145,
    t_open = 1532158138.334194,
    t_idle = 1532158138.334194,
    ws = 0x7fbf8000e260 {
      id = \"ses\",
      {s, f, r, e} = {0x7fbf8000e298, +96, (nil), +352},
    },
    transport = HTTP/1 {
      state = HTTP1::Proc
    }
    client = 212.45.XXX.XXX 55442 :8080,
  },
  worker = 0x7fbf8bc41de0 {
    ws = 0x7fbf8bc41e88 {
      id = \"wrk\",
      {s, f, r, e} = {0x7fbf8bc41190, +0, (nil), +2040},
    },
    VCL::method = inside RECV,
    VCL::return = 0x0,
    VCL::methods = {RECV},
  },
  ws = 0x7fbf80017168 {
    OVERFLOWED id = \"Req\",
    {s, f, r, e} = {0x7fbf80019098, +57176, (nil), +57184},
  },
  http_conn = 0x7fbf80019038 {
    fd = 47 (@0x7fbf8000e244),
    doclose = NULL,
    ws = 0x7fbf80017168 {
      [Already dumped, see above]
    },
    {rxbuf_b, rxbuf_e} = {0x7fbf80019098, 0x7fbf8001b034},
    {pipeline_b, pipeline_e} = {(nil), (nil)},
    content_length = -1,
    body_status = none,
    first_byte_timeout = 0.000000,
    between_bytes_timeout = 0.000000,
  },
  http[req] = 0x7fbf80017208 {
    ws = 0x7fbf80017168 {
      [Already dumped, see above]
    },
    hdrs {
      \"GET\",
      \"/?\",
      \"HTTP/1.1\",
      \"Accept-Encoding: gzip\",
      \"Accept: text/html,application/xhtml+xml,application/xml&q=0.9,*/*&q=0.8\",
      \"User-Agent: Mozilla/5.0 (compatible& Googlebot/2.1& +http://www.google.com/bot.html)\",
      \"Connection: keep-alive\",
      \"X-Remote-IP: 82.208.XXX.XXX\",
      \"X-SSL: no\",
      \"X-Forwarded-For: 212.45.XXX.XXX\",
      \"host: www.berlin.de\<http://www.berlin.de\>",
      \"x-portal: www.berlin.de\<http://www.berlin.de\>",
      \"X-Forwarded-Host: www.berlin.de\<http://www.berlin.de\>",
      \"x-url: ?\",
      \"X-Mobile: desk\",
      \"X-Forwarded-Port: 80\",
      \"X-Forwarded-Proto: http\",
      \"Cookie: DIY_SB=c3530564fad93659f2f381b0be9ba124; PHPSESSID=4f6ki8op43osu4b9i3gsri8g44; 69d3d602ff4d8aeb8f60fc3b111b8dcb=qp65g3okau0jna3h3ipcb5ss27; sid_1_1=a2aea5b171f159bd141fea5e2a9876d7; 8a07c13c411d47270329ee26b294320b=d1a6b8a1c34cd241d0df2762aaee1c17; ApplicationSessionId=fomikuvly3m45i34ycccxxw1; XTCsid=5aeb6d0fb32ccbaa221e2d71eef4dfab; zenid=deleted; session_id=517dc3b73d2a0232f7e7abe3975afb9e; TS01e85bed=01f0e93131a920f276c4ca6385e1aa503fb79a7b35d2098d70e1540b901273ef765d2411e24388b3b8fe030ea928c6ce8810eb726b; partnercode=0WEB; cookie_sec_light=\"\"; JSESSIONID=b230c635a84a1b47fbae19315f24d6a6b365; wishlist=\"\"; ARRAffinity=16a848b5f90db731fac8fe06b5f590dc1b20d0a1465ab9ae168f20b50b1b57bf; language=de-DE; fe_typo_user=66762b4fbff79343198fdfd631c08604; CMSSESSID2c33ccce182f=bccdeaf299cb6bb1ad2c1470e89b0f5f; 2a212043be0c0d476ce384c4dc2b3919=ksvetn2n6m54fnkgqj6vqa3k25; wpml_referer_url=https%3A%2F%2Fwww.triology.de%2Fde%2Freferenzen%2F; 9a4441501cf60b2de9ba5cec4695c188=3a56125bb771baf555826aaa44a67ec7; 6b134e99f4d4cef48239b38f5758fe7d=7c4d05901996da83adff9ee69b6ed2df; 4b960974e614a0d3a9f20e59c2075c23=1eb99e3a97589e7ba72d9f5ec024bccb; com.osiris4.core.Session.id=n82oqxbn3j4wajw9neb3; AL_SESS=AWlGhb3avIwrjuW_fJ_rh11opqwITRB0fdherNdq!oBRyxNx5LFqq_hpPq5fqFAKWH3A; is_mobile=0; sesam=jpcs9aq36qnul8sbns7vaj9ki6; frontend=77eoj47mufttd9cib7bguqjup3; .ASPXANONYMOUS=Pqm8q0tX1AEkAAAAZTdmMjdjNjYtYmMzYS00OWNjLWEwMjUtYzU1MGZjYzE3YTgw0; 4f585ad2d5bdfe8ff86e8dc498e26b8e=353e98d12ce4e7205311501b44dc784a; b9bf211d110c68ea40923af089e21e82=7b8b35d8a6f48b91960354c46ba94280; c035397e6f167b4df4c75737b46c145a=8lhshhho0b87f5u7mc26f89ff3; 8e7c036c46e1fe56d7b28223dfa9a8ca=2hl7vhlbgrss9vghegej5o2735; redirect_count=deleted; pll_language=de; laravel_session=qEeiUR3JWC9KLSEX7Z6oluEoe57aTUOsuLY1LHaG; ea83195f696e334c6155a605755c74be=f9fb404719cd27d44a918c307a4e4d35; c9d4ec90c55ce9b84c3fe44ca36925ab=7ea3a8a036c33119a5686ae58fe82f7e; 6d90de649030d0c32121458eafb460e6=89d2b89bce738e282d5bcdb61ea6629b; CONCRETE5=hn3abpfuupffmmm8p2405ln1b0; SimpleSAMLSessionID=128f7200ab3f8a638e3a8ec17d2a31e8; OJSSID=i40auksitjk9kcf1cj04tmg6a5; H_ITServ=mkv-gmbh.de#_aq2iurcv01k7jp7l4bc46135fs7; bf234a8af86033b1d02b6020cf5bb1b4=6981173e39e8a8d5d42780e273f6effa; SERVERID=wsap01; qtrans_front_language=de; mc_session_ids[multi][4]=dc0c2edd45c690dd65bb1c6a877ef52ad21978c2; mc_session_ids[multi][3]=9fa713410685d2f830dcac2befcb84105672724f; mc_session_ids[multi][2]=a9cf913eeca6711f5be36073348b484a39a76896; mc_session_ids[multi][1]=50af451ebc7dbefe5a26bd83cfdb4b7202cd56d2; mc_session_ids[multi][0]=135a4d446a0d7afa9c4015d90c1caa29a3b48dd1; mc_session_ids[default]=fc5c1339a787744f34b0b7d177b687c75c3f0b17; 8a36a9c9b1ae1ace69f9cbdcaec78f33=1hm5oshvd1rr3bqlt7hk8sa8b0; 67d7a8d8a508ace72eb96b11c1782ffd=63572a9cde154998ddd065a9ea4873be; f928b95a74589147afe5be4aeac0cf49=52432013dd5bf7a5521f84673b5419a9; f410342c31674a2a8a3fbe74704a36fe=aus9gcaldp347dgrv66ts1nag2; twp_session=6cca4650dfdc006078dbc236f253d4c6%7C%7C1532156662%7C%7C1532156302; fa6e138f925b8043a248e80087041649=2b45dc651f753abd3c81006111963875; a382e8ca43069b5cf2b1b71f8eac89b4=g81sa2b55lpng4r10mvkcacukq; wfvt_735686928=5b52d4372aeb9; lep7313sessionid=eb8cd8c85d981ba50491aa0925097860; 1639f822b2be4182f813e5edf85d7073=26726be64951f9926bf3ebde486e4c9e; ASP.NET_SessionId=yyj5rxmfi1zzfwdgy31e1dwn; EDEKA_LB=!/dvYru6LRnuYw8TBsfFthSBJVmbY57eqp+gDw2y8HCjwZd2xCHQ2taQUTmg/JrYMwWyL0cZ2ZXgGvqI=; session-1=13db08707f29b6ebb464ab9ce5714b208fe3a1f55eb398ecae8ef47e8f5b27df; b2d803b5335cdd46894231755923376c=e65941b22836ba608d2fd448ecf10888; I18N_LANGUAGE=\"de\"; a8d276248bbf1f591982252b40a661e1=7pb42flqokqn9ujeeidol59lk5; a5cfece4c5a67dda207ed8d080f8650c=9615f50ab2eae2aeab6215a711499646; 97aca91d7e78e476bf5438d76096b56b=ri80n755erjib0sr61b5it9o52; GaClientId=59b9e349-be7d-4d0d-a9fa-f83506a15c6b; flow_shop=3ec5e6a4005c826081e7f3b80c9cf586; cf7msm_check=1; userFrontendLangId=deleted; dccf082880fecab12971ba47a1c05c29=3b9674f8e102dba87543604fe5ce83e4; CMSPreferredCulture=en-029; 69ae9c5ca3430a65137c01159d69ad70=680762ad8dabdafc2beaf7aee775d61c; session=e9ddf1fc75de1c2651998fdff2441d93; eb6e65597a6a546bdd691711688022fb=1fsdnaf9u5ovu8doen59ca4d63; CMSCsrfCookie=gOoQSS+fd/++qQBQwOldZQjYeFLgOcrR8rVRydgg; 4069b6a736f2df9d9ed9ab3724f75428=ec1f0a9b81c2a31bc7d545d78b05f233; 712239bbb2669c7f510dce1e4353635b=da480fb4746d485e8f5f42eb4ba49909; blotenberg=afef15818d408ed9b51172de84d6fd98; AWSALB=4XFZ05jCCqAxq9FLrKvXMqUFsZ1dxp3kKnOTpZsRIhmOp2L7Yvj/ScBHpgDim2QfohYIFnVNa3SSDwlMW1lv5R3GwO+IsN1FDklxDLvqkclNc0U6HUteTQYxcnpO; 23c53be91f1cac691db4f6dc7ed2ae3c=c087ae481aa6bec69cc06d5bad569033; ci_session=a%3A4%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%22033a040176e2b4b29e530e1707528d1f%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A14%3A%2282.208.160.181%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A50%3A%22Mozilla%2F5.0+%28compatible%26+Googlebot%2F2.1%26+%2Bhttp%3A%2F%2Fww%22%3Bs%3A13%3A%22last_activity%22%3Bs%3A10%3A%221532156304%22%3B%7D1a6e2fd3071a7ba00271cdeb3e951bc2; 4e14f0f9e4d726f6edf4c9ebf796016d=355c1d780ebf1862124c980437c7da5a; ASPSESSIONIDQSQCDTBR=PIKPJCGBIFPCCHLGOPLBCNPH; 6989fede777391f26c0e595280bad2a0=7rpmn87ud7cbfcqd9v4l5efns7; NSC_L-0-65_80=ffffffff09e2cc5045525d5f4f58455e445a4a423660; 7ff64242f5ae6d774854212cf8666f77=6tttkst36lki1ea31s6vnk8da5; 133649766b2e2b53c635efea21953378=adc8333e6f6dd987b401263336b52700; TraminoCartSession=DBNp7TBrDJUrwyxNDPq; wordpress_lp_guest=ca37be337e00ee36d9f4b4f4f1711432; wp_learn_press_session_6e9bc03fc841319b6726c68a9aced716=2564da945b1690545422d9cb57b983f3%7C%7C1532329503%7C%7C7505717ac290302bde58847fd8f407ed; cabcfe0d73fd9eb3351ac3221af94e8c=edg34f9o2sjcpd2glqgv0ekal3; fe67ac19ab79a006ccb7fb25019bb38e=8479c8943f644bd0b306a4338f249547; JTLSHOP=ncp3jqnnk5s4ivkj9o2unctug4; 67f80beba5ad09e24ce8ad8db3927fbe=fc453e89b37fdec1c855df54927e2b79; beb453be7f14188ad12f432189419602=06be9ade8f0394e624013c7422b8f9c0; ASPSESSIONIDSWBCTCTR=BFDIEKGBCKMMDCKEFGCPAJBD; 8fe13cc2eb5590453da1b688ac870ed7=vq1qini7q6lfu5dlc67a122e0t; 073080493419c5c0e89964ee2bce49f2=3fcf949a4c6d72572a9006244c29029f; 5c0483c4110ea1ef92bfeea4b966e026=ececdad10ac6e1595db12fcf274b0ab6; CAKEPHP=8mc3gf56a5peibrun1374ef6f7; d2b6f6c6b5b08d0cac6fe65467ad418a=0a51d57499122dd58e12bc7aaeaf408b; BIGipServer~ASP~asp-common_80=rd3010o00000000000000000000ffff0a0a112ao80; f5b48d5f7dafd69a88287a9fc5a4dc39=pf9gb7rtog9mdu21fb9gnbddu2; 202775b2c81c14b657a48eda0763a87c=adbecdc27bed71916a6da1b8b39425aa; cookiesession1=6683AFC0OMAAWSQDLO13M0RBBOMZE704; ASPSESSIONIDSQTQASRA=HCIEKAEBJOFKAOJEJIFIIJAO; ASPSESSIONIDSUTQASRA=ICIEKAEBCMHLDAEBNEBHECNK; AWSELB=CB7D399B1E0EF9A7E9C544E32A45733DA532498A3754D3527BCB7BFDBEE825A0B702413A33C40FDC528E7B73F41410AFD657F852033EEB8A6A62BE346EC9A6C6BD74C28A35; HASSESSIONSCOPE=0; SESSIONSCOPETESTED=0; REDIRECTOR=dr2; pal=de; e68e769bd79f2af0caa6501613059c0f=faf5d566fe5a2d4991c74f8341b0f359; 4d22477e6616204b89f427bcfcbf6d57=311gbi01rnl6qq414sc4am9926; index_is_shown=1; c5bd7f6431fe230edaf4b9a93751a686=n753jcprn2vfhvb5ajcgk0fvj5; b770ad4bc12ababbdecc5e98a4095983=f480990fe9ae33a2b28c1f0d48ebcd11; e96d6a117eb3531698183d02aed1fefb=e7e94b47e67ab79804f0848f04878dbc; django_language=de\",
    },
  },
  vcl = {
    name = \"git-6b53c70-Tom-Anheyer-2018-07-21-080805-0200\",
    busy = 23,
    discard = 0,
    state = auto,
    temp = warm,
    conf = {
      srcname = {
        \"/etc/varnish/vcl.conf\",
        \"Builtin\",
        ?
      },
    },
  },
  vmods = {
    std = {Varnish 6.0.0 a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, 0.0},
    cookie = {Varnish 6.0.0 a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, 7.0},
    directors = {Varnish 6.0.0 a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, 0.0},
    vsthrottle = {Varnish 6.0.0 a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, 7.0},
    var = {Varnish 6.0.0 a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, 7.0},
  },
  flags = {
  },
  privs = 0x7fbf800171f0 {
    priv {p 0x7fbf80027040 l 0 f 0x7fbf837bc0e0} vcl 0x7fbf930d7480 id 7fbf80017020 vmod 7fbf886dac88
    priv {p 0x7fbf80027060 l 0 f 0x7fbf85dfc400} vcl 0x7fbf930d7480 id 7fbf80017020 vmod 7fbf886daf08
  },
},
thr.busyobj = (nil) {
},




Thanks in advance

tom anheyer

--

Tom Anheyer
Entwicklung & Technik

BerlinOnline Stadtportal GmbH & Co. KG
Alte Jakobstra?e 105
10969 Berlin
Germany

Tel.: +49 30 2327-5210
Fax: +49 30 2327-5596
E-Mail: tom.anheyer at berlinonline.de<mailto:tom.anheyer at berlinonline.de>

berlin.de<https://www.berlin.de> | berlinonline.net<https://www.berlinonline.net>

Amtsgericht Berlin-Charlottenburg, HRA 31951
Sitz der Gesellschaft: Berlin, Deutschland
Gesch?ftsf?hrer: Olf Dziadek
USt-IdNr.: DE219483549

Pers?nlich haftender Gesellschafter:
BerlinOnline Stadtportalbeteiligungsgesellschaft mbH
Amtsgericht Berlin-Charlottenburg, HRB 79077
Sitz der Gesellschaft: Berlin, Deutschland
Gesch?ftsf?hrer: Olf Dziadek

Eine Beteiligung von DuMont Berliner Verlag

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180723/e6795333/attachment-0001.html>

From greyhomeua at gmail.com  Mon Jul 23 09:16:09 2018
From: greyhomeua at gmail.com (Serhii Korobov)
Date: Mon, 23 Jul 2018 12:16:09 +0300
Subject: Question about refreshing expired cache in background
Message-ID: <CAPqYDr_5_7mw3ynd0PU4KURpTtbWq-jP76ciV0NrGF6tFmCCaQ@mail.gmail.com>

 Hi developers of Varnish

I read information about Varnish 4 release ( https://varnish-cache.org/li
sts/pipermail/varnish-announce/2014-April/000696.html ) and found there a
new feature http://prntscr.com/k8dgfk . I need an information about
refreshing expired cache in background.

As I know from developer guide, fetching new object in background thread is
available only in Grace Mode - http://book.varnish-
software.com/4.0/chapters/Saving_a_Request.html#grace-mode when object's
ttl has expired but grace period is not over yet.

Here are my questions:
1. When and how can I use background cache refreshing?
2. Why Grace Mode and cache invalidation via "ban" command doesn't work
together?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180723/ed082a33/attachment.html>

From guillaume at varnish-software.com  Mon Jul 23 19:56:47 2018
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Mon, 23 Jul 2018 12:56:47 -0700
Subject: Question about refreshing expired cache in background
In-Reply-To: <CAPqYDr_5_7mw3ynd0PU4KURpTtbWq-jP76ciV0NrGF6tFmCCaQ@mail.gmail.com>
References: <CAPqYDr_5_7mw3ynd0PU4KURpTtbWq-jP76ciV0NrGF6tFmCCaQ@mail.gmail.com>
Message-ID: <CAJ6ZYQwM8TnC3Z=Wb5wiMyg7L1eW37NBbhSNbJ4T5cc06hmjig@mail.gmail.com>

Hi,

1. You already answer that one: you get a background fetch when obj.ttl <=
0 but obj.ttl + obj.grace > 0.

2. that just hasn't been implemented yet, if I'm not mistaken (that would
be the softban feature)

-- 
Guillaume Quintard

On Mon, Jul 23, 2018 at 2:16 AM, Serhii Korobov <greyhomeua at gmail.com>
wrote:

> Hi developers of Varnish
>
> I read information about Varnish 4 release ( https://varnish-cache.org/li
> sts/pipermail/varnish-announce/2014-April/000696.html ) and found there a
> new feature http://prntscr.com/k8dgfk . I need an information about
> refreshing expired cache in background.
>
> As I know from developer guide, fetching new object in background thread
> is available only in Grace Mode - http://book.varnish-software
> .com/4.0/chapters/Saving_a_Request.html#grace-mode when object's ttl has
> expired but grace period is not over yet.
>
> Here are my questions:
> 1. When and how can I use background cache refreshing?
> 2. Why Grace Mode and cache invalidation via "ban" command doesn't work
> together?
>
> Thanks
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180723/d72e9f5f/attachment.html>

From guillaume at varnish-software.com  Mon Jul 23 22:20:53 2018
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Mon, 23 Jul 2018 15:20:53 -0700
Subject: vmod_var memory alloc assert -> panic again
In-Reply-To: <8AE07C2AEF8F2D4CA8887FDC94F779B01222E981@klnsmxmbxp005.DMSYS.de>
References: <8AE07C2AEF8F2D4CA8887FDC94F779B01222E981@klnsmxmbxp005.DMSYS.de>
Message-ID: <CAJ6ZYQzLOa7j_0+R7Ype3AYbwXRBv3KLQsdFs7bsVSwXXeK7hQ@mail.gmail.com>

Hi Tom,

You ran out of workspace ("OVERFLOWED") so you can try to double the
client_workspace parameter and see if that helps.

Note that it's not really a vmod_var issue, you just happen to have big
requests (should you be publishing such cookies, by the way?) and vmod_var
was the straw that broke the camel's back. If you do a lot of regex
manipulations that will count against the workspace, specially when
operating on long strings.

as to your original question about debugging, I may have something for you
if you are ready for some inline C!

First thing first, run varnishd with "-p vcc_allow_inline_c=true", or use
"varnishadm param.set vcc_allow_inline_c true".

Then the real fun begin, we need to tell the vcl shared library about the
ws struct layout and the VSLb function because it usually doesn't know
about these. Place this near the top of your vcl:

C{
struct ws {
unsigned magic;
#define WS_MAGIC 0x35fac554
char id[4]; /* identity */
char *s; /* (S)tart of buffer */
char *f; /* (F)ree/front pointer */
char *r; /* (R)eserved length */
char *e; /* (E)nd of buffer */
};

void VSLb(struct vsl_log *vsl, int, const char *fmt, ...);
}C

Then, whenever you need it, use this line:

C{ VSLb(ctx->vsl, 1, "WS: %ld %ld", ctx->ws->f - ctx->ws->s, ctx->ws->e -
ctx->ws->s); }C

that'll get you a VSL line in varnishlog looking like this:

1001 Debug           c WS: 96 57328

First number is the used amount of space, and the second one the total
amount.

You can use "varnishlog -q 'Debug:WS[1] > 1000.0' " to filter logs that are
using a bit too much workspace (don't forget to compare to a float, that's
one quirk of the vsl-query language (man vsl-query for more info)). You can
also use varnishncsa with "-F '%{VSL:Debug:WS[1]}x ' " to log just the
field you want.

Hope that helps.


-- 
Guillaume Quintard

On Mon, Jul 23, 2018 at 12:27 AM, Anheyer, Tom <Tom.Anheyer at berlinonline.de>
wrote:

> Hello,
> In the last few days we observe some cache resets. These are triggered by
> mod_var while allocation memory. I have seen different bug reports
> regarding to this issue in the last years but no stable  solution.
>
> We use varnish 6.0, varnish_modules 0.15  with the default workspace
> settings.
>
> Is their a way to debug the workspace memory usage?
> Any other solution?
>
> Panic at: Sat, 21 Jul 2018 07:28:58 GMT
> Assert error in vh_get_var_alloc(), vmod_var.c line 112:
>   Condition((v) != 0) not true.
> version = varnish-6.0.0 revision a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, vrt api = 7.0
> ident = Linux,4.4.0-130-generic,x86_64,-junix,-smalloc,-sdefault,-hcritbit,epoll
> now = 1355228.763723 (mono), 1532158138.334678 (real)
> Backtrace:
>   0x438fb8: /usr/sbin/varnishd() [0x438fb8]
>   0x495e50: /usr/sbin/varnishd(VAS_Fail+0x40) [0x495e50]
>   0x7fbf837bc244: ./vmod_cache/_vmod_var.DILAEPESJTTNHFSZENLGFJXNZZCJCQJX(+0x1244) [0x7fbf837bc244]
>   0x7fbf837bc27e: ./vmod_cache/_vmod_var.DILAEPESJTTNHFSZENLGFJXNZZCJCQJX(vmod_set_string+0x2e) [0x7fbf837bc27e]
>   0x7fbf884913e8: vcl_git-6b53c70-Tom-Anheyer-2018-07-21-080805-0200.1532153312.713054419/vgc.so(VGC_function_vcl_recv+0x3e8) [0x7fbf884913e8]
>   0x4489eb: /usr/sbin/varnishd() [0x4489eb]
>   0x44b60a: /usr/sbin/varnishd(VCL_recv_method+0x5a) [0x44b60a]
>   0x43d006: /usr/sbin/varnishd(CNT_Request+0x876) [0x43d006]
>   0x45f0b7: /usr/sbin/varnishd() [0x45f0b7]
>   0x4553bf: /usr/sbin/varnishd() [0x4553bf]
> thread = (cache-worker)
> thr.req = 0x7fbf80017020 {
>   vxid = 262146, transport = HTTP/1 {
>     state = HTTP1::Proc
>   }
>   step = R_STP_RECV,
>   req_body = R_BODY_NONE,
>   restarts = 0, esi_level = 0,
>   sp = 0x7fbf8000e220 {
>     fd = 47, vxid = 262145,
>     t_open = 1532158138.334194,
>     t_idle = 1532158138.334194,
>     ws = 0x7fbf8000e260 {
>       id = \"ses\",
>       {s, f, r, e} = {0x7fbf8000e298, +96, (nil), +352},
>     },
>     transport = HTTP/1 {
>       state = HTTP1::Proc
>     }
>     client = 212.45.XXX.XXX 55442 :8080,
>   },
>   worker = 0x7fbf8bc41de0 {
>     ws = 0x7fbf8bc41e88 {
>       id = \"wrk\",
>       {s, f, r, e} = {0x7fbf8bc41190, +0, (nil), +2040},
>     },
>     VCL::method = inside RECV,
>     VCL::return = 0x0,
>     VCL::methods = {RECV},
>   },
>   ws = 0x7fbf80017168 {
>     OVERFLOWED id = \"Req\",
>     {s, f, r, e} = {0x7fbf80019098, +57176, (nil), +57184},
>   },
>   http_conn = 0x7fbf80019038 {
>     fd = 47 (@0x7fbf8000e244),
>     doclose = NULL,
>     ws = 0x7fbf80017168 {
>       [Already dumped, see above]
>     },
>     {rxbuf_b, rxbuf_e} = {0x7fbf80019098, 0x7fbf8001b034},
>     {pipeline_b, pipeline_e} = {(nil), (nil)},
>     content_length = -1,
>     body_status = none,
>     first_byte_timeout = 0.000000,
>     between_bytes_timeout = 0.000000,
>   },
>   http[req] = 0x7fbf80017208 {
>     ws = 0x7fbf80017168 {
>       [Already dumped, see above]
>     },
>     hdrs {
>       \"GET\",
>       \"/?\",
>       \"HTTP/1.1\",
>       \"Accept-Encoding: gzip\",
>       \"Accept: text/html,application/xhtml+xml,application/xml&q=0.9,*/*&q=0.8\",
>       \"User-Agent: Mozilla/5.0 (compatible& Googlebot/2.1& +http://www.google.com/bot.html)\",
>       \"Connection: keep-alive\",
>       \"X-Remote-IP: 82.208.XXX.XXX\",
>       \"X-SSL: no\",
>       \"X-Forwarded-For: 212.45.XXX.XXX\",
>       \"host: www.berlin.de\ <http://www.berlin.de%5C>",
>       \"x-portal: www.berlin.de\ <http://www.berlin.de%5C>",
>       \"X-Forwarded-Host: www.berlin.de\ <http://www.berlin.de%5C>",
>       \"x-url: ?\",
>       \"X-Mobile: desk\",
>       \"X-Forwarded-Port: 80\",
>       \"X-Forwarded-Proto: http\",
>       \"Cookie: DIY_SB=c3530564fad93659f2f381b0be9ba124; PHPSESSID=4f6ki8op43osu4b9i3gsri8g44; 69d3d602ff4d8aeb8f60fc3b111b8dcb=qp65g3okau0jna3h3ipcb5ss27; sid_1_1=a2aea5b171f159bd141fea5e2a9876d7; 8a07c13c411d47270329ee26b294320b=d1a6b8a1c34cd241d0df2762aaee1c17; ApplicationSessionId=fomikuvly3m45i34ycccxxw1; XTCsid=5aeb6d0fb32ccbaa221e2d71eef4dfab; zenid=deleted; session_id=517dc3b73d2a0232f7e7abe3975afb9e; TS01e85bed=01f0e93131a920f276c4ca6385e1aa503fb79a7b35d2098d70e1540b901273ef765d2411e24388b3b8fe030ea928c6ce8810eb726b; partnercode=0WEB; cookie_sec_light=\"\"; JSESSIONID=b230c635a84a1b47fbae19315f24d6a6b365; wishlist=\"\"; ARRAffinity=16a848b5f90db731fac8fe06b5f590dc1b20d0a1465ab9ae168f20b50b1b57bf; language=de-DE; fe_typo_user=66762b4fbff79343198fdfd631c08604; CMSSESSID2c33ccce182f=bccdeaf299cb6bb1ad2c1470e89b0f5f; 2a212043be0c0d476ce384c4dc2b3919=ksvetn2n6m54fnkgqj6vqa3k25; wpml_referer_url=https%3A%2F%2Fwww.triology.de%2Fde%2Freferenzen%2F; 9a4441501cf60b2de9ba5cec4695c188=3a56125bb771baf555826aaa44a67ec7; 6b134e99f4d4cef48239b38f5758fe7d=7c4d05901996da83adff9ee69b6ed2df; 4b960974e614a0d3a9f20e59c2075c23=1eb99e3a97589e7ba72d9f5ec024bccb; com.osiris4.core.Session.id=n82oqxbn3j4wajw9neb3; AL_SESS=AWlGhb3avIwrjuW_fJ_rh11opqwITRB0fdherNdq!oBRyxNx5LFqq_hpPq5fqFAKWH3A; is_mobile=0; sesam=jpcs9aq36qnul8sbns7vaj9ki6; frontend=77eoj47mufttd9cib7bguqjup3; .ASPXANONYMOUS=Pqm8q0tX1AEkAAAAZTdmMjdjNjYtYmMzYS00OWNjLWEwMjUtYzU1MGZjYzE3YTgw0; 4f585ad2d5bdfe8ff86e8dc498e26b8e=353e98d12ce4e7205311501b44dc784a; b9bf211d110c68ea40923af089e21e82=7b8b35d8a6f48b91960354c46ba94280; c035397e6f167b4df4c75737b46c145a=8lhshhho0b87f5u7mc26f89ff3; 8e7c036c46e1fe56d7b28223dfa9a8ca=2hl7vhlbgrss9vghegej5o2735; redirect_count=deleted; pll_language=de; laravel_session=qEeiUR3JWC9KLSEX7Z6oluEoe57aTUOsuLY1LHaG; ea83195f696e334c6155a605755c74be=f9fb404719cd27d44a918c307a4e4d35; c9d4ec90c55ce9b84c3fe44ca36925ab=7ea3a8a036c33119a5686ae58fe82f7e; 6d90de649030d0c32121458eafb460e6=89d2b89bce738e282d5bcdb61ea6629b; CONCRETE5=hn3abpfuupffmmm8p2405ln1b0; SimpleSAMLSessionID=128f7200ab3f8a638e3a8ec17d2a31e8; OJSSID=i40auksitjk9kcf1cj04tmg6a5; H_ITServ=mkv-gmbh.de#_aq2iurcv01k7jp7l4bc46135fs7; bf234a8af86033b1d02b6020cf5bb1b4=6981173e39e8a8d5d42780e273f6effa; SERVERID=wsap01; qtrans_front_language=de; mc_session_ids[multi][4]=dc0c2edd45c690dd65bb1c6a877ef52ad21978c2; mc_session_ids[multi][3]=9fa713410685d2f830dcac2befcb84105672724f; mc_session_ids[multi][2]=a9cf913eeca6711f5be36073348b484a39a76896; mc_session_ids[multi][1]=50af451ebc7dbefe5a26bd83cfdb4b7202cd56d2; mc_session_ids[multi][0]=135a4d446a0d7afa9c4015d90c1caa29a3b48dd1; mc_session_ids[default]=fc5c1339a787744f34b0b7d177b687c75c3f0b17; 8a36a9c9b1ae1ace69f9cbdcaec78f33=1hm5oshvd1rr3bqlt7hk8sa8b0; 67d7a8d8a508ace72eb96b11c1782ffd=63572a9cde154998ddd065a9ea4873be; f928b95a74589147afe5be4aeac0cf49=52432013dd5bf7a5521f84673b5419a9; f410342c31674a2a8a3fbe74704a36fe=aus9gcaldp347dgrv66ts1nag2; twp_session=6cca4650dfdc006078dbc236f253d4c6%7C%7C1532156662%7C%7C1532156302; fa6e138f925b8043a248e80087041649=2b45dc651f753abd3c81006111963875; a382e8ca43069b5cf2b1b71f8eac89b4=g81sa2b55lpng4r10mvkcacukq; wfvt_735686928=5b52d4372aeb9; lep7313sessionid=eb8cd8c85d981ba50491aa0925097860; 1639f822b2be4182f813e5edf85d7073=26726be64951f9926bf3ebde486e4c9e; ASP.NET_SessionId=yyj5rxmfi1zzfwdgy31e1dwn; EDEKA_LB=!/dvYru6LRnuYw8TBsfFthSBJVmbY57eqp+gDw2y8HCjwZd2xCHQ2taQUTmg/JrYMwWyL0cZ2ZXgGvqI=; session-1=13db08707f29b6ebb464ab9ce5714b208fe3a1f55eb398ecae8ef47e8f5b27df; b2d803b5335cdd46894231755923376c=e65941b22836ba608d2fd448ecf10888; I18N_LANGUAGE=\"de\"; a8d276248bbf1f591982252b40a661e1=7pb42flqokqn9ujeeidol59lk5; a5cfece4c5a67dda207ed8d080f8650c=9615f50ab2eae2aeab6215a711499646; 97aca91d7e78e476bf5438d76096b56b=ri80n755erjib0sr61b5it9o52; GaClientId=59b9e349-be7d-4d0d-a9fa-f83506a15c6b; flow_shop=3ec5e6a4005c826081e7f3b80c9cf586; cf7msm_check=1; userFrontendLangId=deleted; dccf082880fecab12971ba47a1c05c29=3b9674f8e102dba87543604fe5ce83e4; CMSPreferredCulture=en-029; 69ae9c5ca3430a65137c01159d69ad70=680762ad8dabdafc2beaf7aee775d61c; session=e9ddf1fc75de1c2651998fdff2441d93; eb6e65597a6a546bdd691711688022fb=1fsdnaf9u5ovu8doen59ca4d63; CMSCsrfCookie=gOoQSS+fd/++qQBQwOldZQjYeFLgOcrR8rVRydgg; 4069b6a736f2df9d9ed9ab3724f75428=ec1f0a9b81c2a31bc7d545d78b05f233; 712239bbb2669c7f510dce1e4353635b=da480fb4746d485e8f5f42eb4ba49909; blotenberg=afef15818d408ed9b51172de84d6fd98; AWSALB=4XFZ05jCCqAxq9FLrKvXMqUFsZ1dxp3kKnOTpZsRIhmOp2L7Yvj/ScBHpgDim2QfohYIFnVNa3SSDwlMW1lv5R3GwO+IsN1FDklxDLvqkclNc0U6HUteTQYxcnpO; 23c53be91f1cac691db4f6dc7ed2ae3c=c087ae481aa6bec69cc06d5bad569033; ci_session=a%3A4%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%22033a040176e2b4b29e530e1707528d1f%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A14%3A%2282.208.160.181%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A50%3A%22Mozilla%2F5.0+%28compatible%26+Googlebot%2F2.1%26+%2Bhttp%3A%2F%2Fww%22%3Bs%3A13%3A%22last_activity%22%3Bs%3A10%3A%221532156304%22%3B%7D1a6e2fd3071a7ba00271cdeb3e951bc2; 4e14f0f9e4d726f6edf4c9ebf796016d=355c1d780ebf1862124c980437c7da5a; ASPSESSIONIDQSQCDTBR=PIKPJCGBIFPCCHLGOPLBCNPH; 6989fede777391f26c0e595280bad2a0=7rpmn87ud7cbfcqd9v4l5efns7; NSC_L-0-65_80=ffffffff09e2cc5045525d5f4f58455e445a4a423660; 7ff64242f5ae6d774854212cf8666f77=6tttkst36lki1ea31s6vnk8da5; 133649766b2e2b53c635efea21953378=adc8333e6f6dd987b401263336b52700; TraminoCartSession=DBNp7TBrDJUrwyxNDPq; wordpress_lp_guest=ca37be337e00ee36d9f4b4f4f1711432; wp_learn_press_session_6e9bc03fc841319b6726c68a9aced716=2564da945b1690545422d9cb57b983f3%7C%7C1532329503%7C%7C7505717ac290302bde58847fd8f407ed; cabcfe0d73fd9eb3351ac3221af94e8c=edg34f9o2sjcpd2glqgv0ekal3; fe67ac19ab79a006ccb7fb25019bb38e=8479c8943f644bd0b306a4338f249547; JTLSHOP=ncp3jqnnk5s4ivkj9o2unctug4; 67f80beba5ad09e24ce8ad8db3927fbe=fc453e89b37fdec1c855df54927e2b79; beb453be7f14188ad12f432189419602=06be9ade8f0394e624013c7422b8f9c0; ASPSESSIONIDSWBCTCTR=BFDIEKGBCKMMDCKEFGCPAJBD; 8fe13cc2eb5590453da1b688ac870ed7=vq1qini7q6lfu5dlc67a122e0t; 073080493419c5c0e89964ee2bce49f2=3fcf949a4c6d72572a9006244c29029f; 5c0483c4110ea1ef92bfeea4b966e026=ececdad10ac6e1595db12fcf274b0ab6; CAKEPHP=8mc3gf56a5peibrun1374ef6f7; d2b6f6c6b5b08d0cac6fe65467ad418a=0a51d57499122dd58e12bc7aaeaf408b; BIGipServer~ASP~asp-common_80=rd3010o00000000000000000000ffff0a0a112ao80; f5b48d5f7dafd69a88287a9fc5a4dc39=pf9gb7rtog9mdu21fb9gnbddu2; 202775b2c81c14b657a48eda0763a87c=adbecdc27bed71916a6da1b8b39425aa; cookiesession1=6683AFC0OMAAWSQDLO13M0RBBOMZE704; ASPSESSIONIDSQTQASRA=HCIEKAEBJOFKAOJEJIFIIJAO; ASPSESSIONIDSUTQASRA=ICIEKAEBCMHLDAEBNEBHECNK; AWSELB=CB7D399B1E0EF9A7E9C544E32A45733DA532498A3754D3527BCB7BFDBEE825A0B702413A33C40FDC528E7B73F41410AFD657F852033EEB8A6A62BE346EC9A6C6BD74C28A35; HASSESSIONSCOPE=0; SESSIONSCOPETESTED=0; REDIRECTOR=dr2; pal=de; e68e769bd79f2af0caa6501613059c0f=faf5d566fe5a2d4991c74f8341b0f359; 4d22477e6616204b89f427bcfcbf6d57=311gbi01rnl6qq414sc4am9926; index_is_shown=1; c5bd7f6431fe230edaf4b9a93751a686=n753jcprn2vfhvb5ajcgk0fvj5; b770ad4bc12ababbdecc5e98a4095983=f480990fe9ae33a2b28c1f0d48ebcd11; e96d6a117eb3531698183d02aed1fefb=e7e94b47e67ab79804f0848f04878dbc; django_language=de\",
>     },
>   },
>   vcl = {
>     name = \"git-6b53c70-Tom-Anheyer-2018-07-21-080805-0200\",
>     busy = 23,
>     discard = 0,
>     state = auto,
>     temp = warm,
>     conf = {
>       srcname = {
>         \"/etc/varnish/vcl.conf\",
>         \"Builtin\",
>         ?
>       },
>     },
>   },
>   vmods = {
>     std = {Varnish 6.0.0 a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, 0.0},
>     cookie = {Varnish 6.0.0 a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, 7.0},
>     directors = {Varnish 6.0.0 a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, 0.0},
>     vsthrottle = {Varnish 6.0.0 a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, 7.0},
>     var = {Varnish 6.0.0 a068361dff0d25a0d85cf82a6e5fdaf315e06a7d, 7.0},
>   },
>   flags = {
>   },
>   privs = 0x7fbf800171f0 {
>     priv {p 0x7fbf80027040 l 0 f 0x7fbf837bc0e0} vcl 0x7fbf930d7480 id 7fbf80017020 vmod 7fbf886dac88
>     priv {p 0x7fbf80027060 l 0 f 0x7fbf85dfc400} vcl 0x7fbf930d7480 id 7fbf80017020 vmod 7fbf886daf08
>   },
> },
> thr.busyobj = (nil) {
> },
>
>
> Thanks in advance
>
> tom anheyer
> --
>
> Tom Anheyer
> Entwicklung & Technik
>
> BerlinOnline Stadtportal GmbH & Co. KG
> Alte Jakobstra?e 105
> 10969 Berlin
> Germany
>
> Tel.: +49 30 2327-5210
> Fax: +49 30 2327-5596
> E-Mail: tom.anheyer at berlinonline.de
> berlin.de <https://www.berlin.de> | berlinonline.net <https://www.berlinonline.net>
>
> Amtsgericht Berlin-Charlottenburg, HRA 31951
> Sitz der Gesellschaft: Berlin, Deutschland
> Gesch?ftsf?hrer: Olf Dziadek
> USt-IdNr.: DE219483549
>
> Pers?nlich haftender Gesellschafter:
> BerlinOnline Stadtportalbeteiligungsgesellschaft mbH
> Amtsgericht Berlin-Charlottenburg, HRB 79077
> Sitz der Gesellschaft: Berlin, Deutschland
> Gesch?ftsf?hrer: Olf Dziadek
>
> Eine Beteiligung von DuMont Berliner Verlag
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180723/95418fdf/attachment-0001.html>

From greyhomeua at gmail.com  Wed Jul 25 06:11:10 2018
From: greyhomeua at gmail.com (Serhii Korobov)
Date: Wed, 25 Jul 2018 09:11:10 +0300
Subject: Question about refreshing expired cache in background
In-Reply-To: <CAJ6ZYQwM8TnC3Z=Wb5wiMyg7L1eW37NBbhSNbJ4T5cc06hmjig@mail.gmail.com>
References: <CAPqYDr_5_7mw3ynd0PU4KURpTtbWq-jP76ciV0NrGF6tFmCCaQ@mail.gmail.com>
 <CAJ6ZYQwM8TnC3Z=Wb5wiMyg7L1eW37NBbhSNbJ4T5cc06hmjig@mail.gmail.com>
Message-ID: <CAPqYDr-YVH+URsbU8u0q+T_HQvGYPYHZ3YSeQ3ZhHr-6zyJa6g@mail.gmail.com>

Hi About  softban feature/

2018-07-23 22:56 GMT+03:00 Guillaume Quintard <
guillaume at varnish-software.com>:

> Hi,
>
> 1. You already answer that one: you get a background fetch when obj.ttl <=
> 0 but obj.ttl + obj.grace > 0.
>
> 2. that just hasn't been implemented yet, if I'm not mistaken (that would
> be the softban feature)
>
> --
> Guillaume Quintard
>
> On Mon, Jul 23, 2018 at 2:16 AM, Serhii Korobov <greyhomeua at gmail.com>
> wrote:
>
>> Hi developers of Varnish
>>
>> I read information about Varnish 4 release ( https://varnish-cache.org/li
>> sts/pipermail/varnish-announce/2014-April/000696.html ) and found there
>> a new feature http://prntscr.com/k8dgfk . I need an information about
>> refreshing expired cache in background.
>>
>> As I know from developer guide, fetching new object in background thread
>> is available only in Grace Mode - http://book.varnish-software
>> .com/4.0/chapters/Saving_a_Request.html#grace-mode when object's ttl has
>> expired but grace period is not over yet.
>>
>> Here are my questions:
>> 1. When and how can I use background cache refreshing?
>> 2. Why Grace Mode and cache invalidation via "ban" command doesn't work
>> together?
>>
>> Thanks
>>
>>
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180725/41c3b42d/attachment.html>

From greyhomeua at gmail.com  Wed Jul 25 06:11:52 2018
From: greyhomeua at gmail.com (Serhii Korobov)
Date: Wed, 25 Jul 2018 09:11:52 +0300
Subject: Question about refreshing expired cache in background
In-Reply-To: <CAJ6ZYQwM8TnC3Z=Wb5wiMyg7L1eW37NBbhSNbJ4T5cc06hmjig@mail.gmail.com>
References: <CAPqYDr_5_7mw3ynd0PU4KURpTtbWq-jP76ciV0NrGF6tFmCCaQ@mail.gmail.com>
 <CAJ6ZYQwM8TnC3Z=Wb5wiMyg7L1eW37NBbhSNbJ4T5cc06hmjig@mail.gmail.com>
Message-ID: <CAPqYDr_dqYn09Lxni+7kDPkStJgbpHUW+nMg4QV02QNxF3-BYw@mail.gmail.com>

Hi

2018-07-23 22:56 GMT+03:00 Guillaume Quintard <
guillaume at varnish-software.com>:

> Hi,
>
> 1. You already answer that one: you get a background fetch when obj.ttl <=
> 0 but obj.ttl + obj.grace > 0.
>
> 2. that just hasn't been implemented yet, if I'm not mistaken (that would
> be the softban feature)
>
> --
> Guillaume Quintard
>
> On Mon, Jul 23, 2018 at 2:16 AM, Serhii Korobov <greyhomeua at gmail.com>
> wrote:
>
>> Hi developers of Varnish
>>
>> I read information about Varnish 4 release ( https://varnish-cache.org/li
>> sts/pipermail/varnish-announce/2014-April/000696.html ) and found there
>> a new feature http://prntscr.com/k8dgfk . I need an information about
>> refreshing expired cache in background.
>>
>> As I know from developer guide, fetching new object in background thread
>> is available only in Grace Mode - http://book.varnish-software
>> .com/4.0/chapters/Saving_a_Request.html#grace-mode when object's ttl has
>> expired but grace period is not over yet.
>>
>> Here are my questions:
>> 1. When and how can I use background cache refreshing?
>> 2. Why Grace Mode and cache invalidation via "ban" command doesn't work
>> together?
>>
>> Thanks
>>
>>
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180725/30fee7e9/attachment.html>

From greyhomeua at gmail.com  Wed Jul 25 06:17:25 2018
From: greyhomeua at gmail.com (Serhii Korobov)
Date: Wed, 25 Jul 2018 09:17:25 +0300
Subject: Question about refreshing expired cache in background
In-Reply-To: <CAJ6ZYQwM8TnC3Z=Wb5wiMyg7L1eW37NBbhSNbJ4T5cc06hmjig@mail.gmail.com>
References: <CAPqYDr_5_7mw3ynd0PU4KURpTtbWq-jP76ciV0NrGF6tFmCCaQ@mail.gmail.com>
 <CAJ6ZYQwM8TnC3Z=Wb5wiMyg7L1eW37NBbhSNbJ4T5cc06hmjig@mail.gmail.com>
Message-ID: <CAPqYDr9hb5qhZjT1O0vHpresPjs2hi6pWMRQrOQUN5jc4q+4CA@mail.gmail.com>

Hi
I have question about "softban feature". I did not find information about
that, except this message
https://varnish-cache.org/lists/pipermail/varnish-dev/2014-May/007836.html

I suppose this feature has not implemented yet. Am I right?

Thanks!

2018-07-23 22:56 GMT+03:00 Guillaume Quintard <
guillaume at varnish-software.com>:

> Hi,
>
> 1. You already answer that one: you get a background fetch when obj.ttl <=
> 0 but obj.ttl + obj.grace > 0.
>
> 2. that just hasn't been implemented yet, if I'm not mistaken (that would
> be the softban feature)
>
> --
> Guillaume Quintard
>
> On Mon, Jul 23, 2018 at 2:16 AM, Serhii Korobov <greyhomeua at gmail.com>
> wrote:
>
>> Hi developers of Varnish
>>
>> I read information about Varnish 4 release ( https://varnish-cache.org/li
>> sts/pipermail/varnish-announce/2014-April/000696.html ) and found there
>> a new feature http://prntscr.com/k8dgfk . I need an information about
>> refreshing expired cache in background.
>>
>> As I know from developer guide, fetching new object in background thread
>> is available only in Grace Mode - http://book.varnish-software
>> .com/4.0/chapters/Saving_a_Request.html#grace-mode when object's ttl has
>> expired but grace period is not over yet.
>>
>> Here are my questions:
>> 1. When and how can I use background cache refreshing?
>> 2. Why Grace Mode and cache invalidation via "ban" command doesn't work
>> together?
>>
>> Thanks
>>
>>
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180725/aec3e19a/attachment-0001.html>

From FULLERD at parliament.uk  Wed Jul 25 14:19:24 2018
From: FULLERD at parliament.uk (FULLER, David)
Date: Wed, 25 Jul 2018 14:19:24 +0000
Subject: Memory utilisation gradually increasing
Message-ID: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>

We currently have an issue with memory utilisation in Varnish 5.2.1, we are only using Reverse Proxy not the caching functionality.

We are running it in an AWS ECS Docker container, with 1GB of memory allocated.  Memory increases daily by around 8% until it tops out and site connectivity problems occur.  Redeploying the container resolves the problem and the cycle starts again.

When Varnish starts we have ?malloc? set at 100MB, from my understanding this setting is only relevant if caching is being used, which in our case it isn?t.

Has anyone seen a similar problem?

Thanks

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/20180725/10b144fd/attachment.html>

From guillaume at varnish-software.com  Wed Jul 25 14:59:55 2018
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Wed, 25 Jul 2018 07:59:55 -0700
Subject: Memory utilisation gradually increasing
In-Reply-To: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>
References: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>
Message-ID: <CAJ6ZYQxva00ptXmHDhB2+XVQddJOJE-hppJ-rn2KZ9Xxr7Thow@mail.gmail.com>

Hello David,

Have a look at varnishstat ("varnishstat -1 | grep -e g_space -e g_bytes").
When you are passing, varnish is going to consume Transient storage.

-- 
Guillaume Quintard

On Wed, Jul 25, 2018 at 7:19 AM, FULLER, David <FULLERD at parliament.uk>
wrote:

> We currently have an issue with memory utilisation in Varnish 5.2.1, we
> are only using Reverse Proxy not the caching functionality.
>
>
>
> We are running it in an AWS ECS Docker container, with 1GB of memory
> allocated.  Memory increases daily by around 8% until it tops out and site
> connectivity problems occur.  Redeploying the container resolves the
> problem and the cycle starts again.
>
>
>
> When Varnish starts we have ?malloc? set at 100MB, from my understanding
> this setting is only relevant if caching is being used, which in our case
> it isn?t.
>
>
>
> Has anyone seen a similar problem?
>
>
>
> Thanks
>
>
> 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.
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180725/d70f028b/attachment.html>

From n.premkumar.me at gmail.com  Wed Jul 25 16:49:29 2018
From: n.premkumar.me at gmail.com (Prem Kumar)
Date: Wed, 25 Jul 2018 22:19:29 +0530
Subject: Need some understanding on expiry thread
Message-ID: <CAC3PTxJVkCpYrhMbOQXVodORq6mKZ5MjmK-tjM6AYV54MemPaw@mail.gmail.com>

exp_expire(struct exp_priv *ep, double now)
{
..
 if (oc->timer_when > now)
                return (oc->timer_when);




  if (oc->exp_flags & OC_EF_POSTED) {
                oc->exp_flags |= OC_EF_REMOVE;
                oc = NULL;
        } else {


why do we need to set to oc to NULL after marking it as NULL. How does the
object will be removed from hash and free'd from respective storage backend.


Thanks,
Prem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180725/7e3a08e5/attachment.html>

From guillaume at varnish-software.com  Wed Jul 25 17:30:01 2018
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Wed, 25 Jul 2018 10:30:01 -0700
Subject: Memory utilisation gradually increasing
In-Reply-To: <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk>
References: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>
 <CAJ6ZYQxva00ptXmHDhB2+XVQddJOJE-hppJ-rn2KZ9Xxr7Thow@mail.gmail.com>
 <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk>
Message-ID: <CAJ6ZYQyRxCSUOJjLnKwu3+opEr1MkKfMcYh=pf_-_7HO+6=veg@mail.gmail.com>

Let's keep the mailing list in CC :-)

http://varnish-cache.org/docs/trunk/users-guide/storage-backends.html#transient-storage

You also have Reza's post:
https://info.varnish-software.com/blog/understanding-varnish-cache-memory-usage

Finally, memory is will also be consumed by workspaces (one per thread).

-- 
Guillaume Quintard

On Wed, Jul 25, 2018 at 8:32 AM, FULLER, David <FULLERD at parliament.uk>
wrote:

> Hi Guillaume,
>
>
>
> Thanks for the response, I?ve run the command you?ve suggested and get the
> following:
>
>
>
> / # varnishstat -1 | grep -e g_space -e g_bytes
>
> SMA.s0.g_bytes                                0          .   Bytes
> outstanding
>
> SMA.s0.g_space                        104857600          .   Bytes
> available
>
> SMA.Transient.g_bytes                         0          .   Bytes
> outstanding
>
> SMA.Transient.g_space                         0          .   Bytes
> available
>
>
>
> The Varnish container was redeployed this afternoon and currently shows
> memory utilisation around 3% so probably not illustrating the problem very
> well right now.
>
>
>
> Is there a way to limit the amount of transient storage and clear when hit
> without effecting performance?  Given that we aren?t caching are there any
> other settings we should look at to improve memory utilisation?
>
>
>
> Kind regards,
>
> David
>
>
>
>
>
>
>
> *From: *Guillaume Quintard <guillaume at varnish-software.com>
> *Date: *Wednesday, 25 July 2018 at 16:00
> *To: *"FULLER, David" <FULLERD at parliament.uk>
> *Cc: *"varnish-misc at varnish-cache.org" <varnish-misc at varnish-cache.org>
> *Subject: *Re: Memory utilisation gradually increasing
>
>
>
> Hello David,
>
>
>
> Have a look at varnishstat ("varnishstat -1 | grep -e g_space -e
> g_bytes"). When you are passing, varnish is going to consume Transient
> storage.
>
>
> --
>
> Guillaume Quintard
>
>
>
> On Wed, Jul 25, 2018 at 7:19 AM, FULLER, David <FULLERD at parliament.uk>
> wrote:
>
> We currently have an issue with memory utilisation in Varnish 5.2.1, we
> are only using Reverse Proxy not the caching functionality.
>
>
>
> We are running it in an AWS ECS Docker container, with 1GB of memory
> allocated.  Memory increases daily by around 8% until it tops out and site
> connectivity problems occur.  Redeploying the container resolves the
> problem and the cycle starts again.
>
>
>
> When Varnish starts we have ?malloc? set at 100MB, from my understanding
> this setting is only relevant if caching is being used, which in our case
> it isn?t.
>
>
>
> Has anyone seen a similar problem?
>
>
>
> Thanks
>
>
>
> 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.
>
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
>
> 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/20180725/cf64f091/attachment-0001.html>

From guillaume at varnish-software.com  Wed Jul 25 21:26:27 2018
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Wed, 25 Jul 2018 14:26:27 -0700
Subject: Need some understanding on expiry thread
In-Reply-To: <CAC3PTxJVkCpYrhMbOQXVodORq6mKZ5MjmK-tjM6AYV54MemPaw@mail.gmail.com>
References: <CAC3PTxJVkCpYrhMbOQXVodORq6mKZ5MjmK-tjM6AYV54MemPaw@mail.gmail.com>
Message-ID: <CAJ6ZYQyUZMfbPEM2_AbH1Krmj79FZn7Nv_voeVC3XV_VOsD1Ng@mail.gmail.com>

Hi,

There are people better suited to answer this, but hopefully, they'll yell
if I'm saying anything stupid.

After a cursory glance at the code, I'd say that objcores can be expired
either from the inbox or from the binheap and that if you find a "posted"
oc on the binheap, it's the inbox turf, so we null the oc to not handle it
in the rest of the function.

-- 
Guillaume Quintard

On Wed, Jul 25, 2018 at 9:49 AM, Prem Kumar <n.premkumar.me at gmail.com>
wrote:

> exp_expire(struct exp_priv *ep, double now)
> {
> ..
>  if (oc->timer_when > now)
>                 return (oc->timer_when);
>
>
>
>
>   if (oc->exp_flags & OC_EF_POSTED) {
>                 oc->exp_flags |= OC_EF_REMOVE;
>                 oc = NULL;
>         } else {
>
>
> why do we need to set to oc to NULL after marking it as NULL. How does the
> object will be removed from hash and free'd from respective storage backend.
>
>
> Thanks,
> Prem
>
> _______________________________________________
> varnish-misc mailing list
> varnish-misc at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180725/db27b867/attachment.html>

From n.premkumar.me at gmail.com  Thu Jul 26 02:01:52 2018
From: n.premkumar.me at gmail.com (Prem Kumar)
Date: Thu, 26 Jul 2018 07:31:52 +0530
Subject: Need some understanding on expiry thread
In-Reply-To: <CAJ6ZYQyUZMfbPEM2_AbH1Krmj79FZn7Nv_voeVC3XV_VOsD1Ng@mail.gmail.com>
References: <CAC3PTxJVkCpYrhMbOQXVodORq6mKZ5MjmK-tjM6AYV54MemPaw@mail.gmail.com>
 <CAJ6ZYQyUZMfbPEM2_AbH1Krmj79FZn7Nv_voeVC3XV_VOsD1Ng@mail.gmail.com>
Message-ID: <CAC3PTx+1buRH-dJWS8qnW9d_b8GZNKDxp2x=_MDOz=aPtWyLFw@mail.gmail.com>

Thanks.
But it is assigned to null and not being deleted from heap. moreover
HSH_Derefobjcore will not be called and not be freed ultimately.


Thank

On Thu, 26 Jul 2018 at 2:56 AM, Guillaume Quintard <
guillaume at varnish-software.com> wrote:

> Hi,
>
> There are people better suited to answer this, but hopefully, they'll yell
> if I'm saying anything stupid.
>
> After a cursory glance at the code, I'd say that objcores can be expired
> either from the inbox or from the binheap and that if you find a "posted"
> oc on the binheap, it's the inbox turf, so we null the oc to not handle it
> in the rest of the function.
>
> --
> Guillaume Quintard
>
> On Wed, Jul 25, 2018 at 9:49 AM, Prem Kumar <n.premkumar.me at gmail.com>
> wrote:
>
>> exp_expire(struct exp_priv *ep, double now)
>> {
>> ..
>>  if (oc->timer_when > now)
>>                 return (oc->timer_when);
>>
>>
>>
>>
>>   if (oc->exp_flags & OC_EF_POSTED) {
>>                 oc->exp_flags |= OC_EF_REMOVE;
>>                 oc = NULL;
>>         } else {
>>
>>
>> why do we need to set to oc to NULL after marking it as NULL. How does
>> the object will be removed from hash and free'd from respective storage
>> backend.
>>
>>
>> Thanks,
>> Prem
>>
>> _______________________________________________
>> varnish-misc mailing list
>> varnish-misc at varnish-cache.org
>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180726/5d001d7d/attachment.html>

From guillaume at varnish-software.com  Thu Jul 26 02:21:21 2018
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Wed, 25 Jul 2018 19:21:21 -0700
Subject: Need some understanding on expiry thread
In-Reply-To: <CAC3PTx+1buRH-dJWS8qnW9d_b8GZNKDxp2x=_MDOz=aPtWyLFw@mail.gmail.com>
References: <CAC3PTxJVkCpYrhMbOQXVodORq6mKZ5MjmK-tjM6AYV54MemPaw@mail.gmail.com>
 <CAJ6ZYQyUZMfbPEM2_AbH1Krmj79FZn7Nv_voeVC3XV_VOsD1Ng@mail.gmail.com>
 <CAC3PTx+1buRH-dJWS8qnW9d_b8GZNKDxp2x=_MDOz=aPtWyLFw@mail.gmail.com>
Message-ID: <CAJ6ZYQwz23gjmXwC218pa7mv3mHcX_q2+LLB_BYhLFPyeED0fA@mail.gmail.com>

assigned to null -> yes because you don't care about it, HSH_Derefobjcore
will be called from the mailbox in the next while iteration of exp_thread


-- 
Guillaume Quintard

On Wed, Jul 25, 2018 at 7:01 PM, Prem Kumar <n.premkumar.me at gmail.com>
wrote:

> Thanks.
> But it is assigned to null and not being deleted from heap. moreover
> HSH_Derefobjcore will not be called and not be freed ultimately.
>
>
> Thank
>
> On Thu, 26 Jul 2018 at 2:56 AM, Guillaume Quintard <
> guillaume at varnish-software.com> wrote:
>
>> Hi,
>>
>> There are people better suited to answer this, but hopefully, they'll
>> yell if I'm saying anything stupid.
>>
>> After a cursory glance at the code, I'd say that objcores can be expired
>> either from the inbox or from the binheap and that if you find a "posted"
>> oc on the binheap, it's the inbox turf, so we null the oc to not handle it
>> in the rest of the function.
>>
>> --
>> Guillaume Quintard
>>
>> On Wed, Jul 25, 2018 at 9:49 AM, Prem Kumar <n.premkumar.me at gmail.com>
>> wrote:
>>
>>> exp_expire(struct exp_priv *ep, double now)
>>> {
>>> ..
>>>  if (oc->timer_when > now)
>>>                 return (oc->timer_when);
>>>
>>>
>>>
>>>
>>>   if (oc->exp_flags & OC_EF_POSTED) {
>>>                 oc->exp_flags |= OC_EF_REMOVE;
>>>                 oc = NULL;
>>>         } else {
>>>
>>>
>>> why do we need to set to oc to NULL after marking it as NULL. How does
>>> the object will be removed from hash and free'd from respective storage
>>> backend.
>>>
>>>
>>> Thanks,
>>> Prem
>>>
>>> _______________________________________________
>>> varnish-misc mailing list
>>> varnish-misc at varnish-cache.org
>>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180725/78b2c1bc/attachment.html>

From n.premkumar.me at gmail.com  Thu Jul 26 14:18:59 2018
From: n.premkumar.me at gmail.com (Prem Kumar)
Date: Thu, 26 Jul 2018 19:48:59 +0530
Subject: Need some understanding on expiry thread
In-Reply-To: <CAJ6ZYQwz23gjmXwC218pa7mv3mHcX_q2+LLB_BYhLFPyeED0fA@mail.gmail.com>
References: <CAC3PTxJVkCpYrhMbOQXVodORq6mKZ5MjmK-tjM6AYV54MemPaw@mail.gmail.com>
 <CAJ6ZYQyUZMfbPEM2_AbH1Krmj79FZn7Nv_voeVC3XV_VOsD1Ng@mail.gmail.com>
 <CAC3PTx+1buRH-dJWS8qnW9d_b8GZNKDxp2x=_MDOz=aPtWyLFw@mail.gmail.com>
 <CAJ6ZYQwz23gjmXwC218pa7mv3mHcX_q2+LLB_BYhLFPyeED0fA@mail.gmail.com>
Message-ID: <CAC3PTxK8CTr1ov549OKPgoSMw-bcw2i44DGqr1U627aKPKmjww@mail.gmail.com>

Sorry to ask again.if the exp_inser add oc in to heap thru inbox with
insert flag during fetch.Assume if oc is expired and
And exp_expire will take the oc from binheap and mark as null as show in
last mail.
After it will skip the derefcoreobj().

Thanks,
Prem

On Thu, 26 Jul 2018 at 7:51 AM, Guillaume Quintard <
guillaume at varnish-software.com> wrote:

> assigned to null -> yes because you don't care about it, HSH_Derefobjcore
> will be called from the mailbox in the next while iteration of exp_thread
>
>
> --
> Guillaume Quintard
>
> On Wed, Jul 25, 2018 at 7:01 PM, Prem Kumar <n.premkumar.me at gmail.com>
> wrote:
>
>> Thanks.
>> But it is assigned to null and not being deleted from heap. moreover
>> HSH_Derefobjcore will not be called and not be freed ultimately.
>>
>>
>> Thank
>>
>> On Thu, 26 Jul 2018 at 2:56 AM, Guillaume Quintard <
>> guillaume at varnish-software.com> wrote:
>>
>>> Hi,
>>>
>>> There are people better suited to answer this, but hopefully, they'll
>>> yell if I'm saying anything stupid.
>>>
>>> After a cursory glance at the code, I'd say that objcores can be expired
>>> either from the inbox or from the binheap and that if you find a "posted"
>>> oc on the binheap, it's the inbox turf, so we null the oc to not handle it
>>> in the rest of the function.
>>>
>>> --
>>> Guillaume Quintard
>>>
>>> On Wed, Jul 25, 2018 at 9:49 AM, Prem Kumar <n.premkumar.me at gmail.com>
>>> wrote:
>>>
>>>> exp_expire(struct exp_priv *ep, double now)
>>>> {
>>>> ..
>>>>  if (oc->timer_when > now)
>>>>                 return (oc->timer_when);
>>>>
>>>>
>>>>
>>>>
>>>>   if (oc->exp_flags & OC_EF_POSTED) {
>>>>                 oc->exp_flags |= OC_EF_REMOVE;
>>>>                 oc = NULL;
>>>>         } else {
>>>>
>>>>
>>>> why do we need to set to oc to NULL after marking it as NULL. How does
>>>> the object will be removed from hash and free'd from respective storage
>>>> backend.
>>>>
>>>>
>>>> Thanks,
>>>> Prem
>>>>
>>>> _______________________________________________
>>>> varnish-misc mailing list
>>>> varnish-misc at varnish-cache.org
>>>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180726/4bf1226d/attachment-0001.html>

From FULLERD at parliament.uk  Thu Jul 26 15:05:22 2018
From: FULLERD at parliament.uk (FULLER, David)
Date: Thu, 26 Jul 2018 15:05:22 +0000
Subject: Memory utilisation gradually increasing
In-Reply-To: <CAJ6ZYQyRxCSUOJjLnKwu3+opEr1MkKfMcYh=pf_-_7HO+6=veg@mail.gmail.com>
References: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>
 <CAJ6ZYQxva00ptXmHDhB2+XVQddJOJE-hppJ-rn2KZ9Xxr7Thow@mail.gmail.com>
 <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk>
 <CAJ6ZYQyRxCSUOJjLnKwu3+opEr1MkKfMcYh=pf_-_7HO+6=veg@mail.gmail.com>
Message-ID: <F3CF0E15-55A8-41FD-81DC-8A670A028515@parliament.uk>

Thanks for your reply.

Am I correct in thinking that even though we?re not using Varnish for caching, objects are still stored using malloc?  We have malloc set at 100MB, with 1GB allocated to the Varnish container.  Based on the docs you?ve linked to should we set malloc at 750MB (75% of the container memory) and could this be the cause of the memory problem we?re seeing?

Regards,
David

From: Guillaume Quintard <guillaume at varnish-software.com>
Date: Wednesday, 25 July 2018 at 18:30
To: "FULLER, David" <FULLERD at parliament.uk>, varnish-misc <varnish-misc at varnish-cache.org>
Subject: Re: Memory utilisation gradually increasing

Let's keep the mailing list in CC :-)

http://varnish-cache.org/docs/trunk/users-guide/storage-backends.html#transient-storage<http://varnish-cache.org/docs/trunk/users-guide/storage-backends.html#transient-storage>

You also have Reza's post: https://info.varnish-software.com/blog/understanding-varnish-cache-memory-usage<https://info.varnish-software.com/blog/understanding-varnish-cache-memory-usage>

Finally, memory is will also be consumed by workspaces (one per thread).

--
Guillaume Quintard

On Wed, Jul 25, 2018 at 8:32 AM, FULLER, David <FULLERD at parliament.uk<mailto:FULLERD at parliament.uk>> wrote:
Hi Guillaume,

Thanks for the response, I?ve run the command you?ve suggested and get the following:

/ # varnishstat -1 | grep -e g_space -e g_bytes
SMA.s0.g_bytes                                0          .   Bytes outstanding
SMA.s0.g_space                        104857600          .   Bytes available
SMA.Transient.g_bytes                         0          .   Bytes outstanding
SMA.Transient.g_space                         0          .   Bytes available

The Varnish container was redeployed this afternoon and currently shows memory utilisation around 3% so probably not illustrating the problem very well right now.

Is there a way to limit the amount of transient storage and clear when hit without effecting performance?  Given that we aren?t caching are there any other settings we should look at to improve memory utilisation?

Kind regards,
David



From: Guillaume Quintard <guillaume at varnish-software.com<mailto:guillaume at varnish-software.com>>
Date: Wednesday, 25 July 2018 at 16:00
To: "FULLER, David" <FULLERD at parliament.uk<mailto:FULLERD at parliament.uk>>
Cc: "varnish-misc at varnish-cache.org<mailto:varnish-misc at varnish-cache.org>" <varnish-misc at varnish-cache.org<mailto:varnish-misc at varnish-cache.org>>
Subject: Re: Memory utilisation gradually increasing

Hello David,

Have a look at varnishstat ("varnishstat -1 | grep -e g_space -e g_bytes"). When you are passing, varnish is going to consume Transient storage.

--
Guillaume Quintard

On Wed, Jul 25, 2018 at 7:19 AM, FULLER, David <FULLERD at parliament.uk<mailto:FULLERD at parliament.uk>> wrote:
We currently have an issue with memory utilisation in Varnish 5.2.1, we are only using Reverse Proxy not the caching functionality.

We are running it in an AWS ECS Docker container, with 1GB of memory allocated.  Memory increases daily by around 8% until it tops out and site connectivity problems occur.  Redeploying the container resolves the problem and the cycle starts again.

When Varnish starts we have ?malloc? set at 100MB, from my understanding this setting is only relevant if caching is being used, which in our case it isn?t.

Has anyone seen a similar problem?

Thanks

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.

_______________________________________________
varnish-misc mailing list
varnish-misc at varnish-cache.org<mailto:varnish-misc at varnish-cache.org>
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc<https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc>

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.

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/20180726/43fc504c/attachment-0001.html>

From dridi at varni.sh  Thu Jul 26 15:25:45 2018
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Thu, 26 Jul 2018 17:25:45 +0200
Subject: Memory utilisation gradually increasing
In-Reply-To: <F3CF0E15-55A8-41FD-81DC-8A670A028515@parliament.uk>
References: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>
 <CAJ6ZYQxva00ptXmHDhB2+XVQddJOJE-hppJ-rn2KZ9Xxr7Thow@mail.gmail.com>
 <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk>
 <CAJ6ZYQyRxCSUOJjLnKwu3+opEr1MkKfMcYh=pf_-_7HO+6=veg@mail.gmail.com>
 <F3CF0E15-55A8-41FD-81DC-8A670A028515@parliament.uk>
Message-ID: <CABoVN9BLR-rhqzS=6S4xM4zQSrP9XTEf=raMKJUOTncjfY2nTA@mail.gmail.com>

On Thu, Jul 26, 2018 at 5:05 PM, FULLER, David <FULLERD at parliament.uk> wrote:
> Thanks for your reply.
>
> Am I correct in thinking that even though we?re not using Varnish for
> caching, objects are still stored using malloc?  We have malloc set at
> 100MB, with 1GB allocated to the Varnish container.  Based on the docs
> you?ve linked to should we set malloc at 750MB (75% of the container memory)
> and could this be the cause of the memory problem we?re seeing?

Are you reloading VCLs in your container? Loaded VCLs contribute to
the memory footprint but that's usually negligible. However we've seen
setups where cron jobs or similar means would schedule reloads on a
regular basis whether or not the VCL actually changed on disk, leading
to thousands of loaded VCL. And that could look like a leak with the
memory footprint gradually increasing.

Dridi

From FULLERD at parliament.uk  Fri Jul 27 13:04:47 2018
From: FULLERD at parliament.uk (FULLER, David)
Date: Fri, 27 Jul 2018 13:04:47 +0000
Subject: Memory utilisation gradually increasing
In-Reply-To: <CABoVN9BLR-rhqzS=6S4xM4zQSrP9XTEf=raMKJUOTncjfY2nTA@mail.gmail.com>
References: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>
 <CAJ6ZYQxva00ptXmHDhB2+XVQddJOJE-hppJ-rn2KZ9Xxr7Thow@mail.gmail.com>
 <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk>
 <CAJ6ZYQyRxCSUOJjLnKwu3+opEr1MkKfMcYh=pf_-_7HO+6=veg@mail.gmail.com>
 <F3CF0E15-55A8-41FD-81DC-8A670A028515@parliament.uk>
 <CABoVN9BLR-rhqzS=6S4xM4zQSrP9XTEf=raMKJUOTncjfY2nTA@mail.gmail.com>
Message-ID: <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk>

Hi Dridi,

Thank you for your response, we do not have any cron jobs or schedules set up.  Is there a way to check the number of VCLs currently loaded?

thanks

?On 26/07/2018, 16:26, "Dridi Boukelmoune" <dridi at varni.sh> wrote:

    On Thu, Jul 26, 2018 at 5:05 PM, FULLER, David <FULLERD at parliament.uk> wrote:
    > Thanks for your reply.
    >
    > Am I correct in thinking that even though we?re not using Varnish for
    > caching, objects are still stored using malloc?  We have malloc set at
    > 100MB, with 1GB allocated to the Varnish container.  Based on the docs
    > you?ve linked to should we set malloc at 750MB (75% of the container memory)
    > and could this be the cause of the memory problem we?re seeing?

    Are you reloading VCLs in your container? Loaded VCLs contribute to
    the memory footprint but that's usually negligible. However we've seen
    setups where cron jobs or similar means would schedule reloads on a
    regular basis whether or not the VCL actually changed on disk, leading
    to thousands of loaded VCL. And that could look like a leak with the
    memory footprint gradually increasing.

    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.

From dridi at varni.sh  Fri Jul 27 13:36:03 2018
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Fri, 27 Jul 2018 15:36:03 +0200
Subject: Memory utilisation gradually increasing
In-Reply-To: <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk>
References: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>
 <CAJ6ZYQxva00ptXmHDhB2+XVQddJOJE-hppJ-rn2KZ9Xxr7Thow@mail.gmail.com>
 <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk>
 <CAJ6ZYQyRxCSUOJjLnKwu3+opEr1MkKfMcYh=pf_-_7HO+6=veg@mail.gmail.com>
 <F3CF0E15-55A8-41FD-81DC-8A670A028515@parliament.uk>
 <CABoVN9BLR-rhqzS=6S4xM4zQSrP9XTEf=raMKJUOTncjfY2nTA@mail.gmail.com>
 <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk>
Message-ID: <CABoVN9C0OQepWmTZa6zuGxSdVmdCdCpyzg1+sCwxvuOn5M2d5Q@mail.gmail.com>

On Fri, Jul 27, 2018 at 3:04 PM, FULLER, David <FULLERD at parliament.uk> wrote:
> Hi Dridi,
>
> Thank you for your response, we do not have any cron jobs or schedules set up.  Is there a way to check the number of VCLs currently loaded?

Something like varnishadm vcl.list | wc -l

From FULLERD at parliament.uk  Fri Jul 27 14:41:12 2018
From: FULLERD at parliament.uk (FULLER, David)
Date: Fri, 27 Jul 2018 14:41:12 +0000
Subject: Memory utilisation gradually increasing
In-Reply-To: <CABoVN9C0OQepWmTZa6zuGxSdVmdCdCpyzg1+sCwxvuOn5M2d5Q@mail.gmail.com>
References: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>
 <CAJ6ZYQxva00ptXmHDhB2+XVQddJOJE-hppJ-rn2KZ9Xxr7Thow@mail.gmail.com>
 <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk>
 <CAJ6ZYQyRxCSUOJjLnKwu3+opEr1MkKfMcYh=pf_-_7HO+6=veg@mail.gmail.com>
 <F3CF0E15-55A8-41FD-81DC-8A670A028515@parliament.uk>
 <CABoVN9BLR-rhqzS=6S4xM4zQSrP9XTEf=raMKJUOTncjfY2nTA@mail.gmail.com>
 <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk>
 <CABoVN9C0OQepWmTZa6zuGxSdVmdCdCpyzg1+sCwxvuOn5M2d5Q@mail.gmail.com>
Message-ID: <83715EF0-9A49-4F3A-9632-DBC8F2511B90@parliament.uk>

Thanks, we have 1 active VCL and around 35 available (of these 3 are auto/warm and the remainder cold/cold).  The containers running Varnish had to be rebuilt a couple of hours ago, so I'll check varnishadm again on Monday to see whether the numbers have increased.  Are the cold/cold VCLs considered loaded in terms of memory usage?


?On 27/07/2018, 14:36, "Dridi Boukelmoune" <dridi at varni.sh> wrote:

    On Fri, Jul 27, 2018 at 3:04 PM, FULLER, David <FULLERD at parliament.uk> wrote:
    > Hi Dridi,
    >
    > Thank you for your response, we do not have any cron jobs or schedules set up.  Is there a way to check the number of VCLs currently loaded?

    Something like varnishadm vcl.list | wc -l



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.

From dridi at varni.sh  Sat Jul 28 17:56:07 2018
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Sat, 28 Jul 2018 19:56:07 +0200
Subject: Memory utilisation gradually increasing
In-Reply-To: <83715EF0-9A49-4F3A-9632-DBC8F2511B90@parliament.uk>
References: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>
 <CAJ6ZYQxva00ptXmHDhB2+XVQddJOJE-hppJ-rn2KZ9Xxr7Thow@mail.gmail.com>
 <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk>
 <CAJ6ZYQyRxCSUOJjLnKwu3+opEr1MkKfMcYh=pf_-_7HO+6=veg@mail.gmail.com>
 <F3CF0E15-55A8-41FD-81DC-8A670A028515@parliament.uk>
 <CABoVN9BLR-rhqzS=6S4xM4zQSrP9XTEf=raMKJUOTncjfY2nTA@mail.gmail.com>
 <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk>
 <CABoVN9C0OQepWmTZa6zuGxSdVmdCdCpyzg1+sCwxvuOn5M2d5Q@mail.gmail.com>
 <83715EF0-9A49-4F3A-9632-DBC8F2511B90@parliament.uk>
Message-ID: <CABoVN9DgZkC1-R=wv5wUK-gJMB9abPK_+o2RDnudUeqt-NLhTA@mail.gmail.com>

On Fri, Jul 27, 2018 at 4:41 PM, FULLER, David <FULLERD at parliament.uk> wrote:
> Thanks, we have 1 active VCL and around 35 available (of these 3 are auto/warm and the remainder cold/cold).  The containers running Varnish had to be rebuilt a couple of hours ago, so I'll check varnishadm again on Monday to see whether the numbers have increased.  Are the cold/cold VCLs considered loaded in terms of memory usage?

Yes, cold VCLs are considered loaded in terms of memory usage,
but in a cold state.

It means that they have a lower footprint, but an overhead still
exists. To lower the footprint, varnishd and (well-behaved) VMODs
release any resources that can be acquired again once the VCL is
warmed up prior its use. Just telling varnish to `vcl.use` a cold VCL
will automatically go through the warm up phase, and set the VCL as
active once it reaches the warm state.

Dridi

From dridi at varni.sh  Sat Jul 28 22:03:09 2018
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Sun, 29 Jul 2018 00:03:09 +0200
Subject: Escaping double quotes in probe request
In-Reply-To: <3fce8e49-7937-20fe-47bf-bee3410e0c15@gmail.com>
References: <3fce8e49-7937-20fe-47bf-bee3410e0c15@gmail.com>
Message-ID: <CABoVN9APiEDF70GaWiG1VvVs0vL0v8Szrh=Q00y2v-SH7wArkw@mail.gmail.com>

On Thu, Jul 19, 2018 at 10:32 AM, Igor Zivkovic <igzivkov at gmail.com> wrote:
> Hello,
>
> Is there a way to escape double quotes in probe requests? I need to send a
> JSON request and I've tried %22 but checking the packets with tcpdump it
> seems Varnish doesn't convert escapes back to double quotes. For example:
>
>   .probe = {
>     .request =
>       "POST /probe.php HTTP/1.1"
>       "Host: virtualhost.example.com"
>       "Content-Type: application/json"
>       "Connection: close"
>       ""
>       "{%22key%22:%22value%22}";
>   }

Hello Igor,

I wrote a test case showing how to do that:

    varnishtest "probe json body"

    barrier b1 cond 2

    server s1 {
        rxreq
        txresp
        expect req.method == POST
        expect req.url == "/probe.php"
        expect req.http.Host == virtualhost.example.com
        expect req.http.Content-Type == "application/json"
        expect req.http.Connection == close
        expect req.body ~ key
        expect req.body ~ value
        barrier b1 sync
    } -start

    varnish v1 -vcl+backend {
        probe default {
            .request =
                "POST /probe.php HTTP/1.1"
                "Host: virtualhost.example.com"
                "Content-Type: application/json"
                "Content-Length: 19"
                "Connection: close"
                ""
                {"{ "key": "value" }"};
        }
    } -start

    barrier b1 sync

There are a couple gotchas to be aware of, so I'll explain what I did here.

First, I'm not aware of escape sequences for double quotes in VCL but
we have "long" string (that may span multiple lines) that use
different delimiters {" and "} where a regular double quote " doesn't
have a special meaning.

But when it comes to JSON, you may easily conflict with the separators
if you want to keep your payload compact. That's because { opens an
object and is followed by a key between double quotes. So you need at
least one blank between any { followed by a " or " followed by a } in
your payload.

Finally, in order to have the test case pass, I had to put the content
length but I'm not sure whether this is needed or whether
varnishtest's mock server doesn't handle the case it should (or maybe
we have a command other than rxreq for the case where content length
is omitted). I'm really not motivated to investigate that last point
today.

Cheers

From FULLERD at parliament.uk  Mon Jul 30 12:50:40 2018
From: FULLERD at parliament.uk (FULLER, David)
Date: Mon, 30 Jul 2018 12:50:40 +0000
Subject: Memory utilisation gradually increasing
In-Reply-To: <CABoVN9DgZkC1-R=wv5wUK-gJMB9abPK_+o2RDnudUeqt-NLhTA@mail.gmail.com>
References: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>
 <CAJ6ZYQxva00ptXmHDhB2+XVQddJOJE-hppJ-rn2KZ9Xxr7Thow@mail.gmail.com>
 <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk>
 <CAJ6ZYQyRxCSUOJjLnKwu3+opEr1MkKfMcYh=pf_-_7HO+6=veg@mail.gmail.com>
 <F3CF0E15-55A8-41FD-81DC-8A670A028515@parliament.uk>
 <CABoVN9BLR-rhqzS=6S4xM4zQSrP9XTEf=raMKJUOTncjfY2nTA@mail.gmail.com>
 <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk>
 <CABoVN9C0OQepWmTZa6zuGxSdVmdCdCpyzg1+sCwxvuOn5M2d5Q@mail.gmail.com>
 <83715EF0-9A49-4F3A-9632-DBC8F2511B90@parliament.uk>
 <CABoVN9DgZkC1-R=wv5wUK-gJMB9abPK_+o2RDnudUeqt-NLhTA@mail.gmail.com>
Message-ID: <892D91DE-D9E0-4E3F-BE71-3A202D257368@parliament.uk>

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?



?On 28/07/2018, 18:57, "Dridi Boukelmoune" <dridi at varni.sh> wrote:

    On Fri, Jul 27, 2018 at 4:41 PM, FULLER, David <FULLERD at parliament.uk> wrote:
    > Thanks, we have 1 active VCL and around 35 available (of these 3 are auto/warm and the remainder cold/cold).  The containers running Varnish had to be rebuilt a couple of hours ago, so I'll check varnishadm again on Monday to see whether the numbers have increased.  Are the cold/cold VCLs considered loaded in terms of memory usage?

    Yes, cold VCLs are considered loaded in terms of memory usage,
    but in a cold state.

    It means that they have a lower footprint, but an overhead still
    exists. To lower the footprint, varnishd and (well-behaved) VMODs
    release any resources that can be acquired again once the VCL is
    warmed up prior its use. Just telling varnish to `vcl.use` a cold VCL
    will automatically go through the warm up phase, and set the VCL as
    active once it reaches the warm state.

    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.

From dridi at varni.sh  Tue Jul 31 09:03:01 2018
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Tue, 31 Jul 2018 11:03:01 +0200
Subject: Memory utilisation gradually increasing
In-Reply-To: <892D91DE-D9E0-4E3F-BE71-3A202D257368@parliament.uk>
References: <ADA3A1AF-5720-434B-BE68-14EDDBD11836@parliament.uk>
 <CAJ6ZYQxva00ptXmHDhB2+XVQddJOJE-hppJ-rn2KZ9Xxr7Thow@mail.gmail.com>
 <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk>
 <CAJ6ZYQyRxCSUOJjLnKwu3+opEr1MkKfMcYh=pf_-_7HO+6=veg@mail.gmail.com>
 <F3CF0E15-55A8-41FD-81DC-8A670A028515@parliament.uk>
 <CABoVN9BLR-rhqzS=6S4xM4zQSrP9XTEf=raMKJUOTncjfY2nTA@mail.gmail.com>
 <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk>
 <CABoVN9C0OQepWmTZa6zuGxSdVmdCdCpyzg1+sCwxvuOn5M2d5Q@mail.gmail.com>
 <83715EF0-9A49-4F3A-9632-DBC8F2511B90@parliament.uk>
 <CABoVN9DgZkC1-R=wv5wUK-gJMB9abPK_+o2RDnudUeqt-NLhTA@mail.gmail.com>
 <892D91DE-D9E0-4E3F-BE71-3A202D257368@parliament.uk>
Message-ID: <CABoVN9AfkNWus6arXGHsFNr_-Le9WMELX_uCFwz6eDe0qfrBDg@mail.gmail.com>

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

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

From guillaume at varnish-software.com  Tue Jul 31 15:13:00 2018
From: guillaume at varnish-software.com (Guillaume Quintard)
Date: Tue, 31 Jul 2018 08:13:00 -0700
Subject: Question about refreshing expired cache in background
In-Reply-To: <CAPqYDr9hb5qhZjT1O0vHpresPjs2hi6pWMRQrOQUN5jc4q+4CA@mail.gmail.com>
References: <CAPqYDr_5_7mw3ynd0PU4KURpTtbWq-jP76ciV0NrGF6tFmCCaQ@mail.gmail.com>
 <CAJ6ZYQwM8TnC3Z=Wb5wiMyg7L1eW37NBbhSNbJ4T5cc06hmjig@mail.gmail.com>
 <CAPqYDr9hb5qhZjT1O0vHpresPjs2hi6pWMRQrOQUN5jc4q+4CA@mail.gmail.com>
Message-ID: <CAJ6ZYQxsMNefdHZoDSHecSVT2J_sTpayREme9GBph64A11ffAA@mail.gmail.com>

> 2. that just hasn't been implemented yet, if I'm not mistaken (that would
be the softban feature)

-- 
Guillaume Quintard

On Tue, Jul 24, 2018 at 11:17 PM, Serhii Korobov <greyhomeua at gmail.com>
wrote:

> Hi
> I have question about "softban feature". I did not find information about
> that, except this message https://varnish-cache.org/
> lists/pipermail/varnish-dev/2014-May/007836.html
>
> I suppose this feature has not implemented yet. Am I right?
>
> Thanks!
>
> 2018-07-23 22:56 GMT+03:00 Guillaume Quintard <guillaume at varnish-software.
> com>:
>
>> Hi,
>>
>> 1. You already answer that one: you get a background fetch when obj.ttl
>> <= 0 but obj.ttl + obj.grace > 0.
>>
>> 2. that just hasn't been implemented yet, if I'm not mistaken (that would
>> be the softban feature)
>>
>> --
>> Guillaume Quintard
>>
>> On Mon, Jul 23, 2018 at 2:16 AM, Serhii Korobov <greyhomeua at gmail.com>
>> wrote:
>>
>>> Hi developers of Varnish
>>>
>>> I read information about Varnish 4 release (
>>> https://varnish-cache.org/lists/pipermail/varnish-announce
>>> /2014-April/000696.html ) and found there a new feature
>>> http://prntscr.com/k8dgfk . I need an information about refreshing
>>> expired cache in background.
>>>
>>> As I know from developer guide, fetching new object in background thread
>>> is available only in Grace Mode - http://book.varnish-software
>>> .com/4.0/chapters/Saving_a_Request.html#grace-mode when object's ttl
>>> has expired but grace period is not over yet.
>>>
>>> Here are my questions:
>>> 1. When and how can I use background cache refreshing?
>>> 2. Why Grace Mode and cache invalidation via "ban" command doesn't work
>>> together?
>>>
>>> Thanks
>>>
>>>
>>> _______________________________________________
>>> varnish-misc mailing list
>>> varnish-misc at varnish-cache.org
>>> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20180731/e26398c8/attachment-0001.html>