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: 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: Hello Thomas, On Wed, Jul 4, 2018 at 10:43 AM, Winkelmann, Thomas (RADIO TELE FFH - Online) wrote: > Hello everbody, > > finally we got Varnish 6.0 + Vmods + Hitch TLS running on Ubuntu. So far > everything works fine, also HTTP/2 Support. > > > 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? > > > 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: References: <8A76B2DB46634944BEEBB218DAE22BC2654F79598F@exchange-srv2.office.radioteleffh.de> 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) wrote: > Hello everbody, > > finally we got Varnish 6.0 + Vmods + Hitch TLS running on Ubuntu. So > far everything works fine, also HTTP/2 Support. > > > 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? > > > 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> <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) wrote: > Hello everbody, > > finally we got Varnish 6.0 + Vmods + Hitch TLS running on Ubuntu. So > far everything works fine, also HTTP/2 Support. > > > 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? > > > 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> <8A76B2DB46634944BEEBB218DAE22BC2654F794473@exchange-srv2.office.radioteleffh.de> <8A76B2DB46634944BEEBB218DAE22BC2654F7959E6@exchange-srv2.office.radioteleffh.de> Message-ID: 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) 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) wrote: > > Hello everbody, > > > > finally we got Varnish 6.0 + Vmods + Hitch TLS running on Ubuntu. So > > far everything works fine, also HTTP/2 Support. > > > > > > > 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? > > > > > > > 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: 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: 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: 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\", \"x-portal: www.berlin.de\", \"X-Forwarded-Host: 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 berlin.de | 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: 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: 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: 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: References: Message-ID: 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 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: 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: 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 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\ ", > \"x-portal: www.berlin.de\ ", > \"X-Forwarded-Host: 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 > berlin.de | 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: 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: References: Message-ID: 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 > 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: 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: References: Message-ID: 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 > 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: 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: References: Message-ID: 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 > 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: 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: 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: 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: References: Message-ID: 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 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: 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: 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: 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: <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk> Message-ID: 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 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 > *Date: *Wednesday, 25 July 2018 at 16:00 > *To: *"FULLER, David" > *Cc: *"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 > 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: 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: References: Message-ID: 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 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: 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: References: Message-ID: 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 > 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: 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: References: Message-ID: 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 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 >> 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: 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: References: Message-ID: 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 > 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 >>> 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: 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: References: <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk> Message-ID: 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 Date: Wednesday, 25 July 2018 at 18:30 To: "FULLER, David" , varnish-misc 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 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 > 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 > Date: Wednesday, 25 July 2018 at 16:00 To: "FULLER, David" > Cc: "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 > 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. 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: 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: References: <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk> Message-ID: On Thu, Jul 26, 2018 at 5:05 PM, FULLER, David 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: References: <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk> 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" wrote: On Thu, Jul 26, 2018 at 5:05 PM, FULLER, David 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: <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk> <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk> Message-ID: On Fri, Jul 27, 2018 at 3:04 PM, FULLER, David 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: References: <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk> <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk> 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" wrote: On Fri, Jul 27, 2018 at 3:04 PM, FULLER, David 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: <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk> <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk> <83715EF0-9A49-4F3A-9632-DBC8F2511B90@parliament.uk> Message-ID: On Fri, Jul 27, 2018 at 4:41 PM, FULLER, David 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: On Thu, Jul 19, 2018 at 10:32 AM, Igor Zivkovic 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: References: <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk> <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk> <83715EF0-9A49-4F3A-9632-DBC8F2511B90@parliament.uk> 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" wrote: On Fri, Jul 27, 2018 at 4:41 PM, FULLER, David 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: <92AD7F3D-D5F9-435B-9712-48F8C735642A@parliament.uk> <99B4A9D4-5D48-46BC-9900-E38122BC36A0@parliament.uk> <83715EF0-9A49-4F3A-9632-DBC8F2511B90@parliament.uk> <892D91DE-D9E0-4E3F-BE71-3A202D257368@parliament.uk> Message-ID: On Mon, Jul 30, 2018 at 2:50 PM, FULLER, David 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: References: Message-ID: > 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 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 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 >> 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: