From hernan at cmsmedios.com Mon Sep 1 00:02:54 2014 From: hernan at cmsmedios.com (=?UTF-8?Q?Hern=C3=A1n_Marsili?=) Date: Sun, 31 Aug 2014 21:02:54 -0300 Subject: problem with statistics varnishstat Message-ID: Hi, I have a web site in which every url with _req on it, it should be PASS and not cached on Varnish. We are using PASS on the VCL to not cache this, but it trashed the hit ratio statistics. How can we make varnish to not count this on the average hit ratio? the use of PIPE has been suggested. Thank you! Saludos, Hern?n. [image: logo tfs] http://www.cms-medios.com | http://blog.tfsla.com | facebook.com/cmsmedioscel +54 [911] 4945 2272 | skype hmarsili | Linkedin ar.linkedin.com/in/hmarsiliSuscribite a nuestras novedades por e-mail o RSS feed o Twitter @tfsla >> Argentina +54 11 4711-8999 | USA +1 305 722-5130 | M?xico +52 55 5350-1090 | Espa?a +34 93 179-0330 | El Salvador +503 21 13-9730 | Venezuela +58 212 335-1180 | Colombia +57 1 508-7840 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hernan at cmsmedios.com Wed Sep 3 01:25:23 2014 From: hernan at cmsmedios.com (=?UTF-8?Q?Hern=C3=A1n_Marsili?=) Date: Tue, 2 Sep 2014 22:25:23 -0300 Subject: X-Forwarded-For where? Message-ID: Hi,I need to obtain the real ip the the client, not the ip of the CDN service. I found example with this on the vcl_recv. Others with similar code o the vcl_miss and similar code on vcl_deliver.r remove req.http.X-Forwarded-For; set req.http.X-Forwarded-For = req.http.rlnclientipaddr; I try them all, all of them work. But, which is the most efficient way? :) Saludos, Hern?n. -------------- next part -------------- An HTML attachment was scrubbed... URL: From YARIV-H at yit.co.il Wed Sep 3 05:50:30 2014 From: YARIV-H at yit.co.il (=?utf-8?B?15nXqNeZ15Eg15TXqNeQ15w=?=) Date: Wed, 3 Sep 2014 05:50:30 +0000 Subject: X-Forwarded-For where? In-Reply-To: References: Message-ID: <1DC6764DE551494993B3C6C09A6045F3015FA518@mailbox10.yedioth.co.il> Hi , X-Forwarded-For will contain all ip addresses used to access your server from the outside (client > proxy > cdn > varnish > your web server) The address varnish is seeing as source ip is the cdn server ip . Most cdn networks have a special header custom for them that shoes the client ?s real ip , you should use that header. [yariv_sig_outlook] From: varnish-misc-bounces+yariv-h=yit.co.il at varnish-cache.org [mailto:varnish-misc-bounces+yariv-h=yit.co.il at varnish-cache.org] On Behalf Of Hern?n Marsili Sent: Wednesday, September 03, 2014 4:25 AM To: varnish-misc Subject: X-Forwarded-For where? Hi,I need to obtain the real ip the the client, not the ip of the CDN service. I found example with this on the vcl_recv. Others with similar code o the vcl_miss and similar code on vcl_deliver.r remove req.http.X-Forwarded-For; set req.http.X-Forwarded-For = req.http.rlnclientipaddr; I try them all, all of them work. But, which is the most efficient way? :) Saludos, Hern?n. [Banner] Powered by U?BTech XTRABANNER -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 10506 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Banner1-d236.jpg Type: image/jpeg Size: 50706 bytes Desc: Banner1-d236.jpg URL: From ksorensen at nordija.com Wed Sep 3 10:53:08 2014 From: ksorensen at nordija.com (Kristian =?ISO-8859-1?Q?Gr=F8nfeldt_S=F8rensen?=) Date: Wed, 03 Sep 2014 12:53:08 +0200 Subject: Varnishstat problems with 3.0.5 in Debian Squeeze Message-ID: <1409741588.24910.1.camel@nordija.com> Hi, I've upgraded one of our Debian Squeeze Varnish servers from 3.0.2 to 3.0.5 today, and seem to have run in to the same problem as described here: https://www.varnish-cache.org/forum/topic/1317 . It looks to me like varnishd and varnishstat does not agree on the format of the VSL, or at least which counters to find where. I have a strong suspicion that what varnishstat reports as "backend_busy" is actually "client_conn" and "backend_reuse" is actually "client_req" and "backend_toolate" is actually "cache_hit", since those numbers matches pretty what I would expect for those variables. If this is not the case backend_toolate is worryingly high after the upgrade. I've tried stopping all varnish-related processes, removing _.vsl from /var/lib/varnish// and starting processes again in the hope that it was only some incompatibility between in the VSL-file between 3.0.2 and that the upgrade did not take care of that correctly, but that doesn't make any difference. I also noticed that I had to specify -S /etc/varnish/secret and -T localhost:6082 as command line arguments to varnishadm, so it does not seem to read it correctly from the VSL as it did on 3.0.2. I have another server with identical config where varnishstats works fine, but that one is running Debian Wheezy and Varnish on that server was installed as 3.0.5 rather than being upgraded from 3.0.2. Could it be something with the Squeeze packages, or something releated to the upgrade procedure on Debian? Just as in the forum post obove, my varnishd seems to be working correctly - I just can't get any usable counters from it via varnishstat. Since nobody posted a solution on the forum I decided to try my luck on varnish-misc in the hope that someone here will be able to help me solving the problem. BR Kristian S?rensen From james at ifixit.com Wed Sep 3 19:26:00 2014 From: james at ifixit.com (James Pearson) Date: Wed, 03 Sep 2014 12:26:00 -0700 Subject: X-Forwarded-For where? In-Reply-To: References: Message-ID: <1409772002-sup-5197@geror.local> Excerpts from Hern?n Marsili's message of 2014-09-02 18:25:23 -0700: > Hi,I need to obtain the real ip the the client, not the ip of the CDN > service. > > I found example with this on the vcl_recv. Others with similar code o the > vcl_miss and similar code on vcl_deliver.r > > remove req.http.X-Forwarded-For; > set req.http.X-Forwarded-For = req.http.rlnclientipaddr; > > I try them all, all of them work. But, which is the most efficient way? :) vcl_recv, vcl_miss, and vcl_deliver are called in different circumstances, so you want the one that is correct, not the most efficient. You probably shouldn't munge X-Forwarded-For like that, as you're discarding useful information. If the rlnclientipaddr header contains what you want, then why don't you just access that directly in your application? Here's what we are using, called from vcl_recv: sub parse_x_forwarded_for { set req.http.ClientIp = client.ip; # When coming from the ssl terminator, set ClientIp to something useful. if (client.ip == "127.0.0.1") { # Parse out the actual client IP from X-Forwarded-For. It's useful to have # this information without doing string-matching each time. if (req.http.X-Forwarded-For ~ ",") { set req.http.ClientIp = regsub(req.http.X-Forwarded-For, "^.*?([^,\s]+)$", "\1"); } else if (req.http.X-Forwarded-For) { set req.http.ClientIp = req.http.X-Forwarded-For; } # Set X-Forwarded-For cause that's what a proxy is supposed to do. if (req.restarts == 0) { if (req.http.X-Forwarded-For) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For + ", " + client.ip; } else { set req.http.X-Forwarded-For = client.ip; } } } } We were using vmod_ipcast to actually set client.ip (so we could use it with ACLs), but ran into a problem ( https://github.com/lkarsten/libvmod-ipcast/issues/4 ) and haven't had a chance yet to test the fix. HTH. - P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From james at ifixit.com Wed Sep 3 20:22:18 2014 From: james at ifixit.com (James Pearson) Date: Wed, 03 Sep 2014 13:22:18 -0700 Subject: Varnishstat problems with 3.0.5 in Debian Squeeze In-Reply-To: <1409741588.24910.1.camel@nordija.com> References: <1409741588.24910.1.camel@nordija.com> Message-ID: <1409775503-sup-3124@geror.local> Excerpts from Kristian Gr?nfeldt S?rensen's message of 2014-09-03 03:53:08 -0700: > I've upgraded one of our Debian Squeeze Varnish servers from 3.0.2 to 3.0.5 > today, and seem to have run in to the same problem as described here: > https://www.varnish-cache.org/forum/topic/1317 . > > Could it be something with the Squeeze packages, or something releated to the > upgrade procedure on Debian? We have several CentOS 5 servers running Varnish 3.0.5 on which varnishstat works as expected. It would be good to get more data, but it does not seem unlikely it's a distro-related thing, given all the problem reports are from Debian-family installs. That being said, we also don't do in-place upgrades, but bring up new VMs afresh. - P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From john at surfeasy.com Thu Sep 4 01:37:38 2014 From: john at surfeasy.com (John Mah) Date: Wed, 03 Sep 2014 21:37:38 -0400 Subject: Varnishstat problems with 3.0.5 in Debian Squeeze In-Reply-To: <1409741588.24910.1.camel@nordija.com> References: <1409741588.24910.1.camel@nordija.com> Message-ID: <5407C262.8060907@surfeasy.com> On 2014-09-03, 6:53 AM, Kristian Gr?nfeldt S?rensen wrote: > I've upgraded one of our Debian Squeeze Varnish servers from 3.0.2 to > 3.0.5 today, and seem to have run in to the same problem as described > here: https://www.varnish-cache.org/forum/topic/1317 . > > It looks to me like varnishd and varnishstat does not agree on the > format of the VSL, or at least which counters to find where. Kristian: I have run into this issue in the past and if I remember correctly you may have to just pull in proper 'libvarnishapi1' package from the official varnish repo. cheers, - John Mah From ksorensen at nordija.com Thu Sep 4 05:20:13 2014 From: ksorensen at nordija.com (Kristian =?ISO-8859-1?Q?Gr=F8nfeldt_S=F8rensen?=) Date: Thu, 04 Sep 2014 07:20:13 +0200 Subject: Varnishstat problems with 3.0.5 in Debian Squeeze In-Reply-To: <5407C262.8060907@surfeasy.com> References: <1409741588.24910.1.camel@nordija.com> <5407C262.8060907@surfeasy.com> Message-ID: <1409808013.19369.1.camel@nordija.com> On Wed, 2014-09-03 at 21:37 -0400, John Mah wrote: > On 2014-09-03, 6:53 AM, Kristian Gr?nfeldt S?rensen wrote: > > I've upgraded one of our Debian Squeeze Varnish servers from 3.0.2 to > > 3.0.5 today, and seem to have run in to the same problem as described > > here: https://www.varnish-cache.org/forum/topic/1317 . > > > > It looks to me like varnishd and varnishstat does not agree on the > > format of the VSL, or at least which counters to find where. > > Kristian: > > I have run into this issue in the past and if I remember correctly you > may have to just pull in proper 'libvarnishapi1' package from the > official varnish repo. Thanks a lot. That was the indeed case. I still had libvarnishapi1 3.0.2 installed. apt-get install libvarnishapi1 fixed the issue. I actually suspected something like that, so I ran "apt-get upgrade" as part of the upgrade yesterday (after only doing an "apt-get install varnish"), but apparently something prevented libvarnishapi1 from being upgraded that way. No extra packages pulled in by running apt-get install libvarnishapi1" this morning though, so I'm not sure why it wasn't upgraded as part of the "apt-get upgrade". Wouldn't this indicate a bug in the Debian packaging ? Shouldn't the varnish 3.0.5 package depend on the libvarnishapi package in version 3.0.5, to prevent stuff like this from happening? BR Kristian > cheers, > - John Mah > > > _______________________________________________ > varnish-misc mailing list > varnish-misc at varnish-cache.org > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From gabster at lelutin.ca Thu Sep 4 07:12:32 2014 From: gabster at lelutin.ca (Gabriel Filion) Date: Thu, 04 Sep 2014 03:12:32 -0400 Subject: Varnishstat problems with 3.0.5 in Debian Squeeze In-Reply-To: <1409808013.19369.1.camel@nordija.com> References: <1409741588.24910.1.camel@nordija.com> <5407C262.8060907@surfeasy.com> <1409808013.19369.1.camel@nordija.com> Message-ID: <540810E0.9000003@lelutin.ca> On 04/09/14 01:20 AM, Kristian Gr?nfeldt S?rensen wrote: > Wouldn't this indicate a bug in the Debian packaging ? Shouldn't the > varnish 3.0.5 package depend on the libvarnishapi package in version > 3.0.5, to prevent stuff like this from happening? there's already a dependency from the varnish package to libvarnishapi1: dep: libvarnishapi1 (>= 3.0.0) shared libraries for Varnish (c.f. https://packages.debian.org/squeeze-backports/varnish ) but that's why it didn't upgrade automatically when you bumped version to squeeze-backports: then it means the dependency is not high enough, it should be >= 3.0.5 you should report a bug on the debian package to describe your issue and the fix you've used, and suggest to update the dependency on the package. -- Gabriel Filion -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From jdh132 at psu.edu Thu Sep 4 14:03:29 2014 From: jdh132 at psu.edu (Jason Heffner) Date: Thu, 4 Sep 2014 10:03:29 -0400 Subject: varnishlog -m -w In-Reply-To: <53FF5629.50907@uplex.de> References: <1304E667-5031-4ADB-A18D-942E9FEF25F5@psu.edu> <53FF5629.50907@uplex.de> Message-ID: > > On Aug 28, 2014, at 12:17 PM, Geoff Simmons wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 08/28/2014 05:42 PM, Jason Heffner wrote: >> We are running Varnish 3.0.5-1 from the el6 repo. When trying to >> use varnishlog with the -w option we are noticing that it ignores >> the -m option. >> >> For instance >> >> varnishlog -a -w /var/log/varnish/varnish.log -m TxStatus:503 > > In my experience, -m in Varnish 3 does not filter at all unless you also > provide -b or -c for backend or client transactions, respectively. > It's unrelated to -w. > > Since you're evidently looking for client transactions including > responses with status 503, try this: > > $ varnishlog -c -a -w /var/log/varnish/varnish.log -m TxStatus:503 > > (BTW, this has all been greatly improved in Varnish 4.) > > > HTH, > Geoff > - -- Sorry, I had missed your response last week. I tried varnishlog -c -a -w /var/log/varnish/varnish.log -m TxStatus:503 and that still will log all entries to varnish.log. I actually want to do a more complicated match on several errors and this was what I used to recreate the problem to rule out that pattern match. I do want to move to Varnish 4 at some point but still working on re-creating all the rules. From ksorensen at nordija.com Thu Sep 4 16:58:21 2014 From: ksorensen at nordija.com (Kristian =?ISO-8859-1?Q?Gr=F8nfeldt_S=F8rensen?=) Date: Thu, 04 Sep 2014 18:58:21 +0200 Subject: Varnishstat problems with 3.0.5 in Debian Squeeze In-Reply-To: <540810E0.9000003@lelutin.ca> References: <1409741588.24910.1.camel@nordija.com> <5407C262.8060907@surfeasy.com> <1409808013.19369.1.camel@nordija.com> <540810E0.9000003@lelutin.ca> Message-ID: <1409849901.19369.11.camel@nordija.com> On Thu, 2014-09-04 at 03:12 -0400, Gabriel Filion wrote: > On 04/09/14 01:20 AM, Kristian Gr?nfeldt S?rensen wrote: > > Wouldn't this indicate a bug in the Debian packaging ? Shouldn't the > > varnish 3.0.5 package depend on the libvarnishapi package in version > > 3.0.5, to prevent stuff like this from happening? > > there's already a dependency from the varnish package to libvarnishapi1: > > dep: libvarnishapi1 (>= 3.0.0) > shared libraries for Varnish > > (c.f. https://packages.debian.org/squeeze-backports/varnish ) > > > but that's why it didn't upgrade automatically when you bumped version > to squeeze-backports: then it means the dependency is not high enough, > it should be >= 3.0.5 Sorry if I was unclear. The "Debian packaging" I was referring to above is not the packaging done by Debian in squeeze-backports, since I'm using the packages from repo.varnish-cache.org, but rather the packaging process that produces Debian packages for repo.varnish-cache.org. > you should report a bug on the debian package to describe your issue and > the fix you've used, and suggest to update the dependency on the package. > I was actually trying to find out if this is considered a bug in varnish-cache.org context, and if it makes sense to file a Varnish trac ticket for this. BR Kristian From ojoa at vwd.com Fri Sep 5 09:52:18 2014 From: ojoa at vwd.com (Oliver Joa) Date: Fri, 05 Sep 2014 11:52:18 +0200 Subject: varnish dies Message-ID: <540987D2.6070206@vwd.com> Hi, I want to rollout varnish-4.0.1 but it dies on some Requests, does anyone have a idea why or how to find out the problem? It is a ESI-Include. I can not reproduce bei myself. Here is the error: @40000000540985ae330e26fc Child (6453) died signal=6 @40000000540985ae3352cd34 Child (6453) Panic message: @40000000540985ae3352d11c Assert error in WS_Release(), cache/cache_ws.c line 225: @40000000540985ae3352d11c Condition(bytes <= ws->e - ws->f) not true. @40000000540985ae3352d11c thread = (cache-worker) @40000000540985ae3352d504 ident = Linux,3.2.0-4-amd64,x86_64,-smalloc,-smalloc,-hcritbit,epoll @40000000540985ae3352d504 Backtrace: @40000000540985ae3352d504 0x433fe5: pan_ic+0xc5 @40000000540985ae3352d8ec 0x44b573: WS_Release+0xb3 @40000000540985ae3352d8ec 0x442e28: VRT_IP_string+0x68 @40000000540985ae3353176c 0x7fc0899f128e: ./vcl.XjUmWR1J.so(VGC_function_vcl_deliver+0xae) [0x7fc0899f128e] @40000000540985ae33531b54 0x440817: vcl_call_method+0x187 @40000000540985ae33531b54 0x441728: VCL_deliver_method+0x48 @40000000540985ae33531f3c 0x437e2e: cnt_deliver+0x1ce @40000000540985ae33531f3c 0x438531: CNT_Request+0x111 @40000000540985ae33531f3c 0x41a510: ESI_Deliver+0x7d0 @40000000540985ae33531f3c 0x43b2a8: V1D_Deliver+0x368 @40000000540985ae33533a94 req = 0x7fc07ec9a020 { @40000000540985ae33533a94 sp = 0x7fc07d41a720, vxid = 1073872911, step = R_STP_DELIVER, @40000000540985ae33533a94 req_body = R_BODY_NONE, @40000000540985ae33533e7c err_code = 404, err_reason = (null), @40000000540985ae33533e7c restarts = 0, esi_level = 1 @40000000540985ae33533e7c sp = 0x7fc07d41a720 { @40000000540985ae33534264 fd = 13, vxid = 65537, @40000000540985ae33534264 client = 87.143.149.127 29833, @40000000540985ae33534264 step = S_STP_WORKING, @40000000540985ae3353946c }, @40000000540985ae3353946c worker = 0x7fc084142c50 { @40000000540985ae33539854 ws = 0x7fc084142e68 { @40000000540985ae33539854 id = "wrk", @40000000540985ae33539854 {s,f,r,e} = {0x7fc084142450,0x7fc084142450,(nil),+2048}, @40000000540985ae3353bf64 }, @40000000540985ae3353c34c VCL::method = DELIVER, @40000000540985ae3353c34c VCL::return = abandon, @40000000540985ae3353c34c }, @40000000540985ae3353c34c ws = 0x7fc07ec9a1b8 { @40000000540985ae3353c734 id = "req", @40000000540985ae3353c734 {s,f,r,e} = {0x7fc07ec9c010,+56,(nil),+57360}, @40000000540985ae3353c734 }, @40000000540985ae3353c734 http[req] = { @40000000540985ae3353cb1c ws = 0x7fc07ec451b8[req] @40000000540985ae3353d6d4 "GET", @40000000540985ae3353d6d4 "/esi/rahmen.htn?sektion=einzelwertnaviTable&e4=uebersicht&e5=&i=159096", @40000000540985ae3353dabc "HTTP/1.1", @40000000540985ae3353dabc "Accept: text/html, application/xhtml+xml, */*", @40000000540985ae3353dea4 "Referer: http://www.finanztreff.de/news/eon-darauf-muessen-wir-nun-achten/9996145", @40000000540985ae3353dea4 "Accept-Language: de-DE", @40000000540985ae3353dea4 "User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko", @40000000540985ae3353ea5c "UA-CPU: AMD64", @40000000540985ae3353ea5c "DNT: 1", @40000000540985ae3353ee44 "Connection: Keep-Alive", @40000000540985ae3353ee44 "Host: www.finanztreff.de", @40000000540985ae3353ee44 "X-USF-clientip: 87.143.149.127", @40000000540985ae3353f22c "X-Forwarded-For: 87.143.149.127, 87.143.149.127", @40000000540985ae3353f22c }, @40000000540985ae3353f22c http[resp] = { @40000000540985ae3353f9fc ws = 0x7fc07ec9a1b8[req] @40000000540985ae3353fde4 "HTTP/1.1", @40000000540985ae3353fde4 "404", @40000000540985ae3353fde4 "Not Found", @40000000540985ae3353fde4 "Date: Fri, 05 Sep 2014 09:42:59 GMT", @40000000540985ae335401cc "Server: Apache", @40000000540985ae335401cc "Cache-Control: max-age=1", @40000000540985ae335401cc "X-Powered-By: USF-10/80/027/2", @40000000540985ae3354116c "X-USF-ESI-Include: 1", @40000000540985ae33541554 "X-USF-Error: ESI", @40000000540985ae33541554 "Last-Modified: Fri, 05 Sep 2014 09:42:59 GMT", @40000000540985ae33541554 "Expires: Fri, 05 Sep 2014 09:43:00 GMT", @40000000540985ae3354193c "Vary: Accept-Encoding,X-USF-Cookie", @40000000540985ae3354193c "Content-Type: text/plain; charset=UTF-8", @40000000540985ae3354193c "X-Varnish: 131087", @40000000540985ae335424f4 "Age: 0", @40000000540985ae335424f4 "Via: 1.1 varnish-v4", @40000000540985ae335428dc "X-USF-Cache: MISS", @40000000540985ae335428dc }, @40000000540985ae335428dc vcl = { @40000000540985ae335428dc srcname = { @40000000540985ae335428dc "input", @40000000540985ae33542cc4 "Builtin", @40000000540985ae33542cc4 "/usr/local/opt/varnish/etc/cookie.inc", @40000000540985ae33542cc4 "/usr/local/opt/varnish/etc/pool-push-a.inc", @40000000540985ae3354387c "/usr/local/opt/varnish/etc/push.inc", @40000000540985ae3354387c }, @40000000540985ae3354387c }, @40000000540985ae33543c64 obj (REQ) = 0x7fc0894ac800 { @40000000540985ae33543c64 vxid = 2147614736, @40000000540985ae33543c64 http[obj] = { @40000000540985ae33543c64 ws = 0x7fc08109a268[] @40000000540985ae3354404c "HTTP/1.1", @40000000540985ae3354404c "404", @40000000540985ae3354404c "Not Found", @40000000540985ae3354481c "Date: Fri, 05 Sep 2014 09:42:59 GMT", @40000000540985ae33544c04 "Server: Apache", @40000000540985ae33544c04 "Cache-Control: max-age=1", @40000000540985ae33544c04 "X-Powered-By: USF-10/80/027/2", @40000000540985ae33544fec "X-USF-ESI-Include: 1", @40000000540985ae33544fec "X-USF-Error: ESI", @40000000540985ae33544fec "Last-Modified: Fri, 05 Sep 2014 09:42:59 GMT", @40000000540985ae335453d4 "Expires: Fri, 05 Sep 2014 09:43:00 GMT", @40000000540985ae33548e6c "Vary: Accept-Encoding,X-USF-Cookie", @40000000540985ae33548e6c "Content-Type: text/plain; charset=UTF-8", @40000000540985ae33549254 }, @40000000540985ae33549254 len = 632, @40000000540985ae33549254 store = { @40000000540985ae33549254 632 { @40000000540985ae3354963c 46 65 68 6c 65 72 28 45 53 49 29 3a 20 4c 65 69 |Fehler(ESI): Lei| @40000000540985ae3354963c 64 65 72 20 69 73 74 20 65 69 6e 20 50 72 6f 62 |der ist ein Prob| @40000000540985ae3354a1f4 6c 65 6d 20 61 75 66 67 65 74 72 65 74 65 6e 2e |lem aufgetreten.| @40000000540985ae3354a1f4 0a 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d |.---------------| @40000000540985ae3354a5dc [568 more] @40000000540985ae3354a5dc }, @40000000540985ae3354a5dc }, @40000000540985ae3354a9c4 }, @40000000540985ae3354a9c4 }, Thanks a lot. Regards Oliver Joa ********************************************************************* Der Inhalt dieser E-Mail ist ausschlie?lich f?r den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Ver?ffentlichung, Vervielf?ltigung oder Weitergabe des Inhalts dieser E-Mail unzul?ssig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen. The content of this e-mail is meant exclusively for the person to whom it is addressed. If you are not the person to whom this e-mail is addressed or his/her representative, please be informed that any form of knowledge, publication, duplication or distribution of the content of this e-mail is inadmissible. In such cases we kindly ask you to contact the sender of this e-mail. _ ********************************************************************* From gs2656 at columbia.edu Fri Sep 5 16:12:54 2014 From: gs2656 at columbia.edu (Geoffrey Schwartz) Date: Fri, 5 Sep 2014 12:12:54 -0400 Subject: ACLs to match Headers Message-ID: Hello, Is it possible to use an ACL and match it against, say, the X-Forwarded-For header? We're using Varnish (v3.0.5) in a load-balanced environment and it would be nice to not have to write up a regular expression for each IP address/range we need to match against. -- Geoffrey Schwartz Columbia University - CUIT Ext. 19835 -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at ifixit.com Fri Sep 5 17:37:18 2014 From: james at ifixit.com (James Pearson) Date: Fri, 05 Sep 2014 10:37:18 -0700 Subject: ACLs to match Headers In-Reply-To: References: Message-ID: <1409938600-sup-767@geror.local> Excerpts from Geoffrey Schwartz's message of 2014-09-05 09:12:54 -0700: > Is it possible to use an ACL and match it against, say, the X-Forwarded-For > header? We're using Varnish (v3.0.5) in a load-balanced environment and it > would be nice to not have to write up a regular expression for each IP > address/range we need to match against. You can convert the string into an IP type: https://github.com/lkarsten/libvmod-ipcast - P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From t.honacker at googlemail.com Tue Sep 9 10:33:55 2014 From: t.honacker at googlemail.com (Tobias Honacker) Date: Tue, 9 Sep 2014 12:33:55 +0200 Subject: Varnish Puppet Module Message-ID: Hi guys, is there any official Puppet Module out there for using Varnish 3 (Varnish 4 support not a must-have)? We are using Puppet 3 with Hiera. If not has anyone some favourite Puppet Modules? Thanks and best regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.langhorn at digital.cabinet-office.gov.uk Tue Sep 9 10:44:23 2014 From: andrew.langhorn at digital.cabinet-office.gov.uk (Andrew Langhorn) Date: Tue, 9 Sep 2014 11:44:23 +0100 Subject: Varnish Puppet Module In-Reply-To: References: Message-ID: By official, I?m assuming you mean one released by puppetlabs. For that, there?s not. But, there are modules on the Forge and GitHub that claim to support Varnish 3 - specifically maxchk/varnish, which you can use the `version` param (defaults to present), to specify v3. Might even support v4. On 9 September 2014 at 11:37:22, Tobias Honacker (t.honacker at googlemail.com) wrote: Hi guys, is there any official Puppet Module out there for using Varnish 3 (Varnish 4 support not a must-have)? We are using Puppet 3 with Hiera. If not has anyone some?favourite Puppet Modules? Thanks and best regards, Tobias _______________________________________________ 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 m.ramanna at ymail.com Wed Sep 10 00:39:24 2014 From: m.ramanna at ymail.com (Madhusudan Ramanna) Date: Tue, 9 Sep 2014 17:39:24 -0700 Subject: varnish health checks Message-ID: <1410309564.30060.YahooMailNeo@web121705.mail.ne1.yahoo.com> Hello, Is it possible to respond to a health check request (say, "/status") based on the number of objects already in memory ? If some varnish servers are not able to reach backend servers then those servers must shutdown if there are other varnish servers that can reach reach backend servers. But, if all backend servers are down, it is better for all varnish servers to serve stale content via grace mode. Is there a way to implement this ? thanks, Madhu -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.ramanna at ymail.com Wed Sep 10 04:25:58 2014 From: m.ramanna at ymail.com (Madhusudan Ramanna) Date: Tue, 9 Sep 2014 21:25:58 -0700 Subject: vcl_synth Message-ID: <1410323158.75589.YahooMailNeo@web121705.mail.ne1.yahoo.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.ramanna at ymail.com Wed Sep 10 04:36:59 2014 From: m.ramanna at ymail.com (Madhusudan Ramanna) Date: Tue, 9 Sep 2014 21:36:59 -0700 Subject: vcl_synth Message-ID: <1410323819.5332.YahooMailNeo@web121703.mail.ne1.yahoo.com> Hello, We're using 3.0.5 in production and currently testing 4.0.1. We have some urls for which we always construct synthetic responses. (/ping response pong) In 4.x vcl, I'm matching against the req url and returning synth with appropriate error code. >>>>>>>>>>>>>>> sub vcl_recv { if (req.url ~ "^/ping") { return (synth(1002, "OK")); } sub vcl_synth { if (resp.status == 1002) { set resp.status = 200; set resp.http.Content-Type = "text/plain; charset=utf-8"; synthetic("pong"); return (deliver); } } <<<<<<<<<<<<<<<<< However, when the backend is down, varnish does not return the synthetic response < HTTP/1.1 503 OK < Date: Wed, 10 Sep 2014 04:31:40 GMT < Server: Varnish < X-Varnish: 35 < Content-Length: 0 < Connection: keep-alive Here is the varnishlog - ReqHeader Host: localhost:6081 - ReqHeader Accept: */* - ReqHeader X-Forwarded-For: 127.0.0.1 - VCL_call RECV - Debug "VCL_error(1002, OK)" - VCL_return synth - VCL_call HASH - VCL_return lookup - Timestamp Process: 1410309978.983313 0.000075 0.000075 - RespHeader Date: Wed, 10 Sep 2014 00:46:18 GMT - RespHeader Server: Varnish - RespHeader X-Varnish: 32797 - RespProtocol HTTP/1.1 - RespStatus 503 - RespReason Service Unavailable - RespReason OK - VCL_call SYNTH - VCL_return deliver - RespHeader Content-Length: 0 Not sure why the thread would call HASH. I would expect varnish to deliver the response after the vcl_synth call ? Is this the expected behavior ? How can I fix this to return synthetic response without regard for the health of the backend appreciate your response ! thank you, Madhu ps: Also looking forward to 4.x version of Varnish book -------------- next part -------------- An HTML attachment was scrubbed... URL: From hernan at cmsmedios.com Tue Sep 16 14:56:12 2014 From: hernan at cmsmedios.com (=?UTF-8?Q?Hern=C3=A1n_Marsili?=) Date: Tue, 16 Sep 2014 11:56:12 -0300 Subject: problem with / url Message-ID: Hi, We have a site and we are getting a lot of request to the backend, in particular to / document listed on varnish top. 3.45 TxURL / When we go to the firebug and see the header, the /index.html and and the www.domain.com/ are both cached for 2 minutes with the same directive. The index.html is not remotely on the top urls. Nonetheless / is the top 1 / top 2 request to the backend. Have anyone seen this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From omegabk at gmail.com Wed Sep 17 06:33:19 2014 From: omegabk at gmail.com (omega bavedila katumua) Date: Wed, 17 Sep 2014 08:33:19 +0200 Subject: problem with / url In-Reply-To: References: Message-ID: <75FBBBE0-9D54-4F9A-9F4B-4EC355816C44@gmail.com> Hello, a complete output request from varnishlog may help to diagnose. Best Omega BK On 16 Sep 2014, at 16:56, Hern?n Marsili wrote: > Hi, > > > We have a site and we are getting a lot of request to the backend, in particular to / document listed on varnish top. > > 3.45 TxURL / > > When we go to the firebug and see the header, the /index.html and and the www.domain.com/ are both cached for 2 minutes with the same directive. The index.html is not remotely on the top urls. Nonetheless / is the top 1 / top 2 request to the backend. > > Have anyone seen this? > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From adam.schumacher at flightaware.com Wed Sep 17 17:58:14 2014 From: adam.schumacher at flightaware.com (Adam Schumacher) Date: Wed, 17 Sep 2014 17:58:14 +0000 Subject: Question about varnish memory usage Message-ID: We are running varnish varnish-3.0.5 revision 1a89b1f on freebsd (9.2-RELEASE-p10 and are seeing memory usage that does not seem to match with what it should be using based on our configurations. We have two servers with 32G of physical memory and 32G of swap. The varnishd process grows by about 1M a second until all the physical and virtual memory is filled, and then predictably, causes the box to crash. We only have 6G of malloc allocated (and confirmed with SMA.s0.g_bytes 6441093251), and n_object 981470 We have only noticed this problem since upgrading to 3.0.5 from an earlier 3.0.x version. I would prefer to not post our vcl publicly, but if someone thinks it will really help diagnose/troubleshoot, we can work something out. Varnishd is configured as follows in rc.conf: varnishd_storage="malloc,6G" varnishd_opts="-p send_timeout=200 -p sess_timeout=4 -p thread_pool_max=4000 -p thread_pool_add_delay=3 -p thread_pools=24 -p thread_pool_min=33 -p listen_depth=4096 -p thread_pool_add_delay=2 -p ping_interval=2 -h classic,250007 -p connect_timeout=2 -p cli_timeout=15 -p sess_workspace=262144" varnishd_flags="-P /var/run/varnishd.pid -a ${varnishd_listen} -f ${varnishd_config} -T ${varnishd_telnet} -s ${varnishd_storage} -u ${varnishd_user} -g ${varnishd_group} ${varnishd_opts}" ????? varnishstat -1: client_conn 104085169 104.67 Client connections accepted client_drop 0 0.00 Connection dropped, no sess/wrk client_req 171676104 172.65 Client requests received cache_hit 80479348 80.94 Cache hits cache_hitpass 7477423 7.52 Cache hits for pass cache_miss 72505475 72.92 Cache misses backend_conn 35664133 35.87 Backend conn. success backend_unhealthy 0 0.00 Backend conn. not attempted backend_busy 126139 0.13 Backend conn. too many backend_fail 0 0.00 Backend conn. failures backend_reuse 89690334 90.20 Backend conn. reuses backend_toolate 5596689 5.63 Backend conn. was closed backend_recycle 95286945 95.83 Backend conn. recycles backend_retry 9761 0.01 Backend conn. retry fetch_head 543 0.00 Fetch head fetch_length 43471073 43.72 Fetch with Length fetch_chunked 81315787 81.78 Fetch chunked fetch_eof 0 0.00 Fetch EOF fetch_bad 0 0.00 Fetch had bad headers fetch_close 482419 0.49 Fetch wanted close fetch_oldhttp 0 0.00 Fetch pre HTTP/1.1 closed fetch_zero 0 0.00 Fetch zero len fetch_failed 42364 0.04 Fetch failed fetch_1xx 0 0.00 Fetch no body (1xx) fetch_204 0 0.00 Fetch no body (204) fetch_304 61616 0.06 Fetch no body (304) n_sess_mem 1150 . N struct sess_mem n_sess 579 . N struct sess n_object 981470 . N struct object n_vampireobject 0 . N unresurrected objects n_objectcore 981914 . N struct objectcore n_objecthead 977110 . N struct objecthead n_waitinglist 622 . N struct waitinglist n_vbc 54 . N struct vbc n_wrk 792 . N worker threads n_wrk_create 792 0.00 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_lqueue 0 0.00 work request queue length n_wrk_queued 0 0.00 N queued work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 7 . N backends n_expired 45564349 . N expired objects n_lru_nuked 25923760 . N LRU nuked objects n_lru_moved 47547027 . N LRU moved objects losthdr 6 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 121715557 122.41 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 104086012 104.68 Total Sessions s_req 171676104 172.65 Total Requests s_pipe 0 0.00 Total pipe s_pass 52856380 53.16 Total pass s_fetch 125289270 126.00 Total fetch s_hdrbytes 64377166856 64741.92 Total header bytes s_bodybytes 1267141154173 1274320.68 Total body bytes sess_closed 10229836 10.29 Session Closed sess_pipeline 8090 0.01 Session Pipeline sess_readahead 3355 0.00 Session Read Ahead sess_linger 163142524 164.07 Session Linger sess_herd 170209860 171.17 Session herd shm_records 15318912048 15405.71 SHM records shm_writes 948277110 953.65 SHM writes shm_flushes 4301 0.00 SHM flushes due to overflow shm_cont 288266 0.29 SHM MTX contention shm_cycles 6539 0.01 SHM cycles through buffer sms_nreq 378913 0.38 SMS allocator requests sms_nobj 0 . SMS outstanding allocations sms_nbytes 0 . SMS outstanding bytes sms_balloc 1053544168 . SMS bytes allocated sms_bfree 1053544168 . SMS bytes freed backend_req 125332229 126.04 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded n_ban 1 . N total active bans n_ban_gone 1 . N total gone bans n_ban_add 1 0.00 N new bans added n_ban_retire 0 0.00 N old bans deleted n_ban_obj_test 0 0.00 N objects tested n_ban_re_test 0 0.00 N regexps tested against n_ban_dups 0 0.00 N duplicate bans removed hcb_nolock 0 0.00 HCB Lookups without lock hcb_lock 0 0.00 HCB Lookups with lock hcb_insert 0 0.00 HCB Inserts esi_errors 0 0.00 ESI parse errors (unlock) esi_warnings 0 0.00 ESI parse warnings (unlock) accept_fail 485 0.00 Accept failures client_drop_late 0 0.00 Connection dropped late uptime 994366 1.00 Client uptime dir_dns_lookups 0 0.00 DNS director lookups dir_dns_failed 0 0.00 DNS director failed lookups dir_dns_hit 0 0.00 DNS director cached lookups hit dir_dns_cache_full 0 0.00 DNS director full dnscache vmods 0 . Loaded VMODs n_gzip 84532076 85.01 Gzip operations n_gunzip 89997945 90.51 Gunzip operations sess_pipe_overflow 0 . Dropped sessions due to session pipe overflow LCK.sms.creat 1 0.00 Created locks LCK.sms.destroy 0 0.00 Destroyed locks LCK.sms.locks 1136739 1.14 Lock Operations LCK.sms.colls 0 0.00 Collisions LCK.smp.creat 0 0.00 Created locks LCK.smp.destroy 0 0.00 Destroyed locks LCK.smp.locks 0 0.00 Lock Operations LCK.smp.colls 0 0.00 Collisions LCK.sma.creat 2 0.00 Created locks LCK.sma.destroy 0 0.00 Destroyed locks LCK.sma.locks 692749199 696.67 Lock Operations LCK.sma.colls 0 0.00 Collisions LCK.smf.creat 0 0.00 Created locks LCK.smf.destroy 0 0.00 Destroyed locks LCK.smf.locks 0 0.00 Lock Operations LCK.smf.colls 0 0.00 Collisions LCK.hsl.creat 0 0.00 Created locks LCK.hsl.destroy 0 0.00 Destroyed locks LCK.hsl.locks 0 0.00 Lock Operations LCK.hsl.colls 0 0.00 Collisions LCK.hcb.creat 0 0.00 Created locks LCK.hcb.destroy 0 0.00 Destroyed locks LCK.hcb.locks 0 0.00 Lock Operations LCK.hcb.colls 0 0.00 Collisions LCK.hcl.creat 250007 0.25 Created locks LCK.hcl.destroy 0 0.00 Destroyed locks LCK.hcl.locks 319941259 321.75 Lock Operations LCK.hcl.colls 0 0.00 Collisions LCK.vcl.creat 1 0.00 Created locks LCK.vcl.destroy 0 0.00 Destroyed locks LCK.vcl.locks 1296332 1.30 Lock Operations LCK.vcl.colls 0 0.00 Collisions LCK.stat.creat 1 0.00 Created locks LCK.stat.destroy 0 0.00 Destroyed locks LCK.stat.locks 104086613 104.68 Lock Operations LCK.stat.colls 0 0.00 Collisions LCK.sessmem.creat 1 0.00 Created locks LCK.sessmem.destroy 0 0.00 Destroyed locks LCK.sessmem.locks 104233722 104.82 Lock Operations LCK.sessmem.colls 0 0.00 Collisions LCK.wstat.creat 1 0.00 Created locks LCK.wstat.destroy 0 0.00 Destroyed locks LCK.wstat.locks 3357946 3.38 Lock Operations LCK.wstat.colls 0 0.00 Collisions LCK.herder.creat 1 0.00 Created locks LCK.herder.destroy 0 0.00 Destroyed locks LCK.herder.locks 1 0.00 Lock Operations LCK.herder.colls 0 0.00 Collisions LCK.wq.creat 24 0.00 Created locks LCK.wq.destroy 0 0.00 Destroyed locks LCK.wq.locks 385937676 388.12 Lock Operations LCK.wq.colls 0 0.00 Collisions LCK.objhdr.creat 62749986 63.11 Created locks LCK.objhdr.destroy 61773004 62.12 Destroyed locks LCK.objhdr.locks 538087282 541.14 Lock Operations LCK.objhdr.colls 0 0.00 Collisions LCK.exp.creat 1 0.00 Created locks LCK.exp.destroy 0 0.00 Destroyed locks LCK.exp.locks 144950215 145.77 Lock Operations LCK.exp.colls 0 0.00 Collisions LCK.lru.creat 2 0.00 Created locks LCK.lru.destroy 0 0.00 Destroyed locks LCK.lru.locks 98393326 98.95 Lock Operations LCK.lru.colls 0 0.00 Collisions LCK.cli.creat 1 0.00 Created locks LCK.cli.destroy 0 0.00 Destroyed locks LCK.cli.locks 497050 0.50 Lock Operations LCK.cli.colls 0 0.00 Collisions LCK.ban.creat 1 0.00 Created locks LCK.ban.destroy 0 0.00 Destroyed locks LCK.ban.locks 145003057 145.82 Lock Operations LCK.ban.colls 0 0.00 Collisions LCK.vbp.creat 1 0.00 Created locks LCK.vbp.destroy 0 0.00 Destroyed locks LCK.vbp.locks 755162 0.76 Lock Operations LCK.vbp.colls 0 0.00 Collisions LCK.vbe.creat 1 0.00 Created locks LCK.vbe.destroy 0 0.00 Destroyed locks LCK.vbe.locks 71328212 71.73 Lock Operations LCK.vbe.colls 0 0.00 Collisions LCK.backend.creat 7 0.00 Created locks LCK.backend.destroy 0 0.00 Destroyed locks LCK.backend.locks 297688383 299.38 Lock Operations LCK.backend.colls 0 0.00 Collisions SMA.s0.c_req 191831833 192.92 Allocator requests SMA.s0.c_fail 25986715 26.13 Allocator failures SMA.s0.c_bytes 8510391233102 8558610.44 Bytes allocated SMA.s0.c_freed 8503950139851 8552132.86 Bytes freed SMA.s0.g_alloc 2003100 . Allocations outstanding SMA.s0.g_bytes 6441093251 . Bytes outstanding SMA.s0.g_space 1357693 . Bytes available SMA.Transient.c_req 111573947 112.21 Allocator requests SMA.Transient.c_fail 0 0.00 Allocator failures SMA.Transient.c_bytes 6898618916654 6937705.95 Bytes allocated SMA.Transient.c_freed 6898613391266 6937700.40 Bytes freed SMA.Transient.g_alloc 5373 . Allocations outstanding SMA.Transient.g_bytes 5525388 . Bytes outstanding SMA.Transient.g_space 0 . Bytes available VBE.backend1(,,80).vcls 1 . VCL references VBE.backend1(,,80).happy18446744073709551615 . Happy health probes VBE.backend2(,,80).vcls 1 . VCL references VBE.backend2(,,80).happy18446744073709551615 . Happy health probes VBE.backend3(,,80).vcls 1 . VCL references VBE.backend3(,,80).happy18446744073709551615 . Happy health probes VBE.backend4(,,80).vcls 1 . VCL references VBE.backend4(,,80).happy18446744073709551615 . Happy health probes VBE.backend5(,,80).vcls 1 . VCL references VBE.backend6(,,80).happy 0 . Happy health probes VBE.prod(,,80).vcls 1 . VCL references VBE.prod(,,80).happy 0 . Happy health probes VBE.backend7(,,80).vcls 1 . VCL references VBE.backend7(,,80).happy 0 . Happy health probes { Adam Schumacher IT Operations and Security Engineer Flightaware } -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5831 bytes Desc: not available URL: From perbu at varnish-software.com Thu Sep 18 06:40:44 2014 From: perbu at varnish-software.com (Per Buer) Date: Thu, 18 Sep 2014 08:40:44 +0200 Subject: Question about varnish memory usage In-Reply-To: References: Message-ID: Hi Adam. On Wed, Sep 17, 2014 at 7:58 PM, Adam Schumacher < adam.schumacher at flightaware.com> wrote: > The varnishd process > grows by about 1M a second until all the physical and virtual memory is > filled, and then predictably, causes the box to crash. We only have 6G of > malloc allocated (and confirmed with SMA.s0.g_bytes 6441093251), and > n_object 981470 > It seems you are using Transient storage. Transient is usually uncapped. You can cap Transient but you should probably figure out why Varnish is using Transient storage. Usually it will allocate Transient if 1) The objects TTL < 10s 2) Failed to allocate storage As a hotfix I would cap Transient at, say, 2G. "varnishd -s Transient=malloc,2G". You can probably up your main storage quite a bit with this in place. -- *Per Buer* CTO | Varnish Software AS Cell: +47 95839117 We Make Websites Fly! www.varnish-software.com [image: Register now] -------------- next part -------------- An HTML attachment was scrubbed... URL: From dridi.boukelmoune at zenika.com Thu Sep 18 14:50:56 2014 From: dridi.boukelmoune at zenika.com (Dridi Boukelmoune) Date: Thu, 18 Sep 2014 16:50:56 +0200 Subject: Question about varnish memory usage In-Reply-To: References: Message-ID: On Wed, Sep 17, 2014 at 7:58 PM, Adam Schumacher wrote: snip > > Varnishd is configured as follows in rc.conf: > > varnishd_storage="malloc,6G" > varnishd_opts="-p send_timeout=200 -p sess_timeout=4 -p > thread_pool_max=4000 -p thread_pool_add_delay=3 -p thread_pools=24 -p > thread_pool_min=33 -p listen_depth=4096 -p thread_pool_add_delay=2 -p > ping_interval=2 -h classic,250007 -p connect_timeout=2 -p cli_timeout=15 > -p sess_workspace=262144" > > varnishd_flags="-P /var/run/varnishd.pid -a ${varnishd_listen} -f > ${varnishd_config} -T ${varnishd_telnet} -s ${varnishd_storage} -u > ${varnishd_user} -g ${varnishd_group} ${varnishd_opts}" Hi Adam, thread_pool_max=4000 thread_pools=24 sess_workspace=262144 IIRC it means up to 4000x24x262144 bytes of RAM (about 24Go) *only* for worker workspaces. Probably not what you want. thread_pool_add_delay=3 thread_pool_add_delay=2 It looks like your tuning needs some love. Cheers, Dridi From adam.schumacher at flightaware.com Thu Sep 18 15:49:21 2014 From: adam.schumacher at flightaware.com (Adam Schumacher) Date: Thu, 18 Sep 2014 15:49:21 +0000 Subject: Question about varnish memory usage In-Reply-To: References: Message-ID: > > > >thread_pool_max=4000 >thread_pools=24 >sess_workspace=262144 > >IIRC it means up to 4000x24x262144 bytes of RAM (about 24Go) *only* >for worker workspaces. > >Probably not what you want. Yeah, I had noticed that too. It is something I need to work on to figure out what the optimal setting is. However, the server is only using 792 worker threads which works out to < 200m for worker workspaces. n_wrk 792 . N worker threads One thing I am confused about is that in the man page, thread_pool_stack default value is -1. I assume that means use the max defined by the OS? In FreeBSD, I think the default thread stack size is 64K, so that *shouldn?t* be a problem here, right? > >thread_pool_add_delay=3 >thread_pool_add_delay=2 Thanks for catching that, I?ll correct it. ::Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5831 bytes Desc: not available URL: From adam.schumacher at flightaware.com Thu Sep 18 15:54:27 2014 From: adam.schumacher at flightaware.com (Adam Schumacher) Date: Thu, 18 Sep 2014 15:54:27 +0000 Subject: Question about varnish memory usage In-Reply-To: References: Message-ID: Per, Thanks for the reply >> >It seems you are using Transient storage. Transient is usually uncapped. You >> can cap Transient but you should probably figure out why Varnish is using >> Transient storage. Usually it will >allocate Transient if >> >1) The objects TTL < 10s >> >2) Failed to allocate storage >From varnishstat I see: SMA.Transient.g_bytes 5525388 . Bytes outstanding If that is the same Transient storage you are referring to, I don?t see how varnishd could be taking up as much VM as it is. Or am I missing something? >> >As a hotfix I would cap Transient at, say, 2G. "varnishd -s >> Transient=malloc,2G". You can probably up your main storage quite a bit with >> this in place. I?ll give it a shot and let you know. It usually takes a couple days before filling up all the physical memory. ::Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5831 bytes Desc: not available URL: From perbu at varnish-software.com Thu Sep 18 19:28:40 2014 From: perbu at varnish-software.com (Per Buer) Date: Thu, 18 Sep 2014 21:28:40 +0200 Subject: Question about varnish memory usage In-Reply-To: References: Message-ID: On Thu, Sep 18, 2014 at 5:54 PM, Adam Schumacher < adam.schumacher at flightaware.com> wrote: > Per, > > Thanks for the reply > > >It seems you are using Transient storage. Transient is usually uncapped. > You can cap Transient but you should probably figure out why Varnish is > using Transient storage. Usually it will >allocate Transient if > >1) The objects TTL < 10s > >2) Failed to allocate storage > > > From varnishstat I see: > > SMA.Transient.g_bytes 5525388 . Bytes outstanding > > If that is the same Transient storage you are referring to, I don?t see > how varnishd could be taking up as much VM as it is. Or am I missing > something? > No, you're not. I read your email too fast. Seems your transient usage is relatively decent and not in the gigabytes. Wrt, Dridis point about threads might also not be that relevant as only 700-800 threads are being created. Session workspace is virtual until allocated so I don't think that is where your memory is disappearing. 24 thread pools is a bit odd (you only need two) but don't know of any leaks it might trigger. I'd stay away from classic hashing as cribit is stable and you're the only one I know that uses it. When is the varnishstat taken? Right before running out of memory? That would probably be useful. > >As a hotfix I would cap Transient at, say, 2G. "varnishd -s > Transient=malloc,2G". You can probably up your main storage quite a bit > with this in place. > > > I?ll give it a shot and let you know. It usually takes a couple days > before filling up all the physical memory. > Well, I'm somewhat doubtful it it will actually work. -- *Per Buer* CTO | Varnish Software AS Cell: +47 95839117 We Make Websites Fly! www.varnish-software.com [image: Register now] -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.schumacher at flightaware.com Thu Sep 18 20:30:25 2014 From: adam.schumacher at flightaware.com (Adam Schumacher) Date: Thu, 18 Sep 2014 20:30:25 +0000 Subject: Question about varnish memory usage In-Reply-To: References: Message-ID: From: Per Buer > > > Wrt, Dridis point about threads might also not be that relevant as only > 700-800 threads are being created. Session workspace is virtual until > allocated so I don't think that is where your memory is disappearing. > > 24 thread pools is a bit odd (you only need two) but don't know of any leaks > it might trigger. > > I'd stay away from classic hashing as cribit is stable and you're the only one > I know that uses it. > > When is the varnishstat taken? Right before running out of memory? That would > probably be useful. There are 24 thread pools because there are 24 cores in the server and I?m sure someone read somewhere that a pool per was the way to go. Probably that was a long time ago in a galaxy far, far away?. What are the significant differences between classic and cribit hashing? The system is currently fully using available physical memory and has burned through about 15% of the swap space. The varnishstat was taken after the physical memory was exhausted and with just a few Gigs of swap in use. Here is a current snapshot from top and varnishstat ?1 if that helps. Mem: 24G Active, 2857M Inact, 3757M Wired, 433M Cache, 510M Free ARC: 1715M Total, 555M MFU, 274M MRU, 1042K Anon, 216M Header, 670M Other Swap: 32G Total, 5174M Used, 27G Free, 15% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 87309 www 803 20 0 49189M 23483M select 22 130.1H 5.27% varnishd client_conn 115492418 106.06 Client connections accepted client_drop 0 0.00 Connection dropped, no sess/wrk client_req 195339845 179.39 Client requests received cache_hit 94748999 87.01 Cache hits cache_hitpass 8249240 7.58 Cache hits for pass cache_miss 79893031 73.37 Cache misses backend_conn 39130304 35.93 Backend conn. success backend_unhealthy 0 0.00 Backend conn. not attempted backend_busy 132086 0.12 Backend conn. too many backend_fail 0 0.00 Backend conn. failures backend_reuse 98773816 90.71 Backend conn. reuses backend_toolate 6237866 5.73 Backend conn. was closed backend_recycle 105011602 96.44 Backend conn. recycles backend_retry 11220 0.01 Backend conn. retry fetch_head 577 0.00 Fetch head fetch_length 48290509 44.35 Fetch with Length fetch_chunked 89008238 81.74 Fetch chunked fetch_eof 0 0.00 Fetch EOF fetch_bad 0 0.00 Fetch had bad headers fetch_close 509908 0.47 Fetch wanted close fetch_oldhttp 0 0.00 Fetch pre HTTP/1.1 closed fetch_zero 0 0.00 Fetch zero len fetch_failed 45097 0.04 Fetch failed fetch_1xx 0 0.00 Fetch no body (1xx) fetch_204 0 0.00 Fetch no body (204) fetch_304 68372 0.06 Fetch no body (304) n_sess_mem 1150 . N struct sess_mem n_sess 722 . N struct sess n_object 942029 . N struct object n_vampireobject 0 . N unresurrected objects n_objectcore 942471 . N struct objectcore n_objecthead 936744 . N struct objecthead n_waitinglist 624 . N struct waitinglist n_vbc 117 . N struct vbc n_wrk 792 . N worker threads n_wrk_create 792 0.00 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_lqueue 0 0.00 work request queue length n_wrk_queued 0 0.00 N queued work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 7 . N backends n_expired 50061996 . N expired objects n_lru_nuked 28851249 . N LRU nuked objects n_lru_moved 56196515 . N LRU moved objects losthdr 7 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 139062543 127.71 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 115493404 106.06 Total Sessions s_req 195339845 179.39 Total Requests s_pipe 0 0.00 Total pipe s_pass 58017202 53.28 Total pass s_fetch 137832710 126.58 Total fetch s_hdrbytes 73466348331 67467.23 Total header bytes s_bodybytes 1475428907061 1354948.26 Total body bytes sess_closed 11135893 10.23 Session Closed sess_pipeline 8340 0.01 Session Pipeline sess_readahead 3402 0.00 Session Read Ahead sess_linger 186082340 170.89 Session Linger sess_herd 193483825 177.68 Session herd shm_records 17182889691 15779.77 SHM records shm_writes 1058678573 972.23 SHM writes shm_flushes 4719 0.00 SHM flushes due to overflow shm_cont 335494 0.31 SHM MTX contention shm_cycles 7346 0.01 SHM cycles through buffer sms_nreq 405919 0.37 SMS allocator requests sms_nobj 0 . SMS outstanding allocations sms_nbytes 0 . SMS outstanding bytes sms_balloc 1127850835 . SMS bytes allocated sms_bfree 1127850835 . SMS bytes freed backend_req 137878631 126.62 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded n_ban 1 . N total active bans n_ban_gone 1 . N total gone bans n_ban_add 1 0.00 N new bans added n_ban_retire 0 0.00 N old bans deleted n_ban_obj_test 0 0.00 N objects tested n_ban_re_test 0 0.00 N regexps tested against n_ban_dups 0 0.00 N duplicate bans removed hcb_nolock 0 0.00 HCB Lookups without lock hcb_lock 0 0.00 HCB Lookups with lock hcb_insert 0 0.00 HCB Inserts esi_errors 0 0.00 ESI parse errors (unlock) esi_warnings 0 0.00 ESI parse warnings (unlock) accept_fail 547 0.00 Accept failures client_drop_late 0 0.00 Connection dropped late uptime 1088919 1.00 Client uptime dir_dns_lookups 0 0.00 DNS director lookups dir_dns_failed 0 0.00 DNS director failed lookups dir_dns_hit 0 0.00 DNS director cached lookups hit dir_dns_cache_full 0 0.00 DNS director full dnscache vmods 0 . Loaded VMODs n_gzip 92821054 85.24 Gzip operations n_gunzip 98789399 90.72 Gunzip operations sess_pipe_overflow 0 . Dropped sessions due to session pipe overflow LCK.sms.creat 1 0.00 Created locks LCK.sms.destroy 0 0.00 Destroyed locks LCK.sms.locks 1217757 1.12 Lock Operations LCK.sms.colls 0 0.00 Collisions LCK.smp.creat 0 0.00 Created locks LCK.smp.destroy 0 0.00 Destroyed locks LCK.smp.locks 0 0.00 Lock Operations LCK.smp.colls 0 0.00 Collisions LCK.sma.creat 2 0.00 Created locks LCK.sma.destroy 0 0.00 Destroyed locks LCK.sma.locks 762080017 699.85 Lock Operations LCK.sma.colls 0 0.00 Collisions LCK.smf.creat 0 0.00 Created locks LCK.smf.destroy 0 0.00 Destroyed locks LCK.smf.locks 0 0.00 Lock Operations LCK.smf.colls 0 0.00 Collisions LCK.hsl.creat 0 0.00 Created locks LCK.hsl.destroy 0 0.00 Destroyed locks LCK.hsl.locks 0 0.00 Lock Operations LCK.hsl.colls 0 0.00 Collisions LCK.hcb.creat 0 0.00 Created locks LCK.hcb.destroy 0 0.00 Destroyed locks LCK.hcb.locks 0 0.00 Lock Operations LCK.hcb.colls 0 0.00 Collisions LCK.hcl.creat 250007 0.23 Created locks LCK.hcl.destroy 0 0.00 Destroyed locks LCK.hcl.locks 364838330 335.05 Lock Operations LCK.hcl.colls 0 0.00 Collisions LCK.vcl.creat 1 0.00 Created locks LCK.vcl.destroy 0 0.00 Destroyed locks LCK.vcl.locks 1404720 1.29 Lock Operations LCK.vcl.colls 0 0.00 Collisions LCK.stat.creat 1 0.00 Created locks LCK.stat.destroy 0 0.00 Destroyed locks LCK.stat.locks 115493914 106.06 Lock Operations LCK.stat.colls 0 0.00 Collisions LCK.sessmem.creat 1 0.00 Created locks LCK.sessmem.destroy 0 0.00 Destroyed locks LCK.sessmem.locks 115660082 106.22 Lock Operations LCK.sessmem.colls 0 0.00 Collisions LCK.wstat.creat 1 0.00 Created locks LCK.wstat.destroy 0 0.00 Destroyed locks LCK.wstat.locks 3815488 3.50 Lock Operations LCK.wstat.colls 0 0.00 Collisions LCK.herder.creat 1 0.00 Created locks LCK.herder.destroy 0 0.00 Destroyed locks LCK.herder.locks 1 0.00 Lock Operations LCK.herder.colls 0 0.00 Collisions LCK.wq.creat 24 0.00 Created locks LCK.wq.destroy 0 0.00 Destroyed locks LCK.wq.locks 436653782 401.00 Lock Operations LCK.wq.colls 0 0.00 Collisions LCK.objhdr.creat 69117038 63.47 Created locks LCK.objhdr.destroy 68180433 62.61 Destroyed locks LCK.objhdr.locks 605204037 555.78 Lock Operations LCK.objhdr.colls 0 0.00 Collisions LCK.exp.creat 1 0.00 Created locks LCK.exp.destroy 0 0.00 Destroyed locks LCK.exp.locks 159855422 146.80 Lock Operations LCK.exp.colls 0 0.00 Collisions LCK.lru.creat 2 0.00 Created locks LCK.lru.destroy 0 0.00 Destroyed locks LCK.lru.locks 108706511 99.83 Lock Operations LCK.lru.colls 0 0.00 Collisions LCK.cli.creat 1 0.00 Created locks LCK.cli.destroy 0 0.00 Destroyed locks LCK.cli.locks 544317 0.50 Lock Operations LCK.cli.colls 0 0.00 Collisions LCK.ban.creat 1 0.00 Created locks LCK.ban.destroy 0 0.00 Destroyed locks LCK.ban.locks 159911741 146.85 Lock Operations LCK.ban.colls 0 0.00 Collisions LCK.vbp.creat 1 0.00 Created locks LCK.vbp.destroy 0 0.00 Destroyed locks LCK.vbp.locks 826695 0.76 Lock Operations LCK.vbp.colls 0 0.00 Collisions LCK.vbe.creat 1 0.00 Created locks LCK.vbe.destroy 0 0.00 Destroyed locks LCK.vbe.locks 78260491 71.87 Lock Operations LCK.vbe.colls 0 0.00 Collisions LCK.backend.creat 7 0.00 Created locks LCK.backend.destroy 0 0.00 Destroyed locks LCK.backend.locks 327541647 300.80 Lock Operations LCK.backend.colls 0 0.00 Collisions SMA.s0.c_req 211189969 193.94 Allocator requests SMA.s0.c_fail 28921596 26.56 Allocator failures SMA.s0.c_bytes 9340561806222 8577829.76 Bytes allocated SMA.s0.c_freed 9334120384877 8571914.33 Bytes freed SMA.s0.g_alloc 1924886 . Allocations outstanding SMA.s0.g_bytes 6441310878 . Bytes outstanding SMA.s0.g_space 1140066 . Bytes available SMA.Transient.c_req 122683830 112.67 Allocator requests SMA.Transient.c_fail 0 0.00 Allocator failures SMA.Transient.c_bytes 7588011522470 6968389.31 Bytes allocated SMA.Transient.c_freed 7588004757463 6968383.10 Bytes freed SMA.Transient.g_alloc 6530 . Allocations outstanding SMA.Transient.g_bytes 6765007 . Bytes outstanding SMA.Transient.g_space 0 . Bytes available > >> >>>> >As a hotfix I would cap Transient at, say, 2G. "varnishd -s >>>> Transient=malloc,2G". You can probably up your main storage quite a bit >>>> with this in place. >> >> I?ll give it a shot and let you know. It usually takes a couple days before >> filling up all the physical memory. > > Well, I'm somewhat doubtful it it will actually work. > I guess it is a good thing I hadn?t actually made the change then. Since this is a production system, I was going to wait until our maintenance period tonight. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5831 bytes Desc: not available URL: From perbu at varnish-software.com Fri Sep 19 07:08:12 2014 From: perbu at varnish-software.com (Per Buer) Date: Fri, 19 Sep 2014 09:08:12 +0200 Subject: Question about varnish memory usage In-Reply-To: References: Message-ID: Hi On Thu, Sep 18, 2014 at 10:30 PM, Adam Schumacher < adam.schumacher at flightaware.com> wrote: > > There are 24 thread pools because there are 24 cores in the server and I?m > sure someone read somewhere that a pool per was the way to go. Probably > that was a long time ago in a galaxy far, far away?. > There was an assumption that the thread pools locking structures could stay local on each core and as such we did at some point recommend having one pool per core. However, we've been unable to see any performance increase in going past two pools. I think there might even be a small performance degradation with using many pools, but I'm not certain. Search the archive if you want to find out. Anyways, two pool is enough. > What are the significant differences between classic and cribit hashing? > During the 2.1 dev cycle critbit replaces the classic hash. Critbit is autoscaling and is more or less lockless so it became the default. Why we haven't retired the class hashing is a relevant question. We probably should. > > The system is currently fully using available physical memory and has > burned through about 15% of the swap space. The varnishstat was taken > after the physical memory was exhausted and with just a few Gigs of swap in > use. Here is a current snapshot from top and varnishstat ?1 if that helps. > > Could it be that your memory allocator is leaking memory? The varnishstat looks decent, there are no counters that are off the charts. Last time we saw behaviour like that was when we were seeing seeing leaks with malloc on Linux, before we switched to jemalloc. I think Varnish will try to link with jemalloc if it is available on your system. Is it? As you can see there are quite a few allocations happening and if that memory is not reclaimed and reused you'll be leaking quite a bit. -- *Per Buer* CTO | Varnish Software AS Cell: +47 95839117 We Make Websites Fly! www.varnish-software.com [image: Register now] -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.schumacher at flightaware.com Fri Sep 19 16:36:26 2014 From: adam.schumacher at flightaware.com (Adam Schumacher) Date: Fri, 19 Sep 2014 16:36:26 +0000 Subject: Question about varnish memory usage In-Reply-To: References: Message-ID: >> >> The system is currently fully using available physical memory and has burned >> through about 15% of the swap space. The varnishstat was taken after the >> physical memory was exhausted and with just a few Gigs of swap in use. Here >> is a current snapshot from top and varnishstat ?1 if that helps. > > Could it be that your memory allocator is leaking memory? The varnishstat > looks decent, there are no counters that are off the charts. Last time we saw > behaviour like that was when we were seeing seeing leaks with malloc on Linux, > before we switched to jemalloc. > > I think Varnish will try to link with jemalloc if it is available on your > system. Is it? As you can see there are quite a few allocations happening and > if that memory is not reclaimed and reused you'll be leaking quite a bit. > My understanding is that the base malloc in freebsd 9.2 is jemalloc ? the code was ported back into the base malloc.c. Between FreeBSD 9.2 and FreeBSD 10.0, they changed how it is done, and now is using the pure jemalloc.c code that should be the same as in Linux. https://svnweb.freebsd.org/base/release/9.2.0/lib/libc/stdlib/malloc.c?revis ion=255898&view=markup Vs https://svnweb.freebsd.org/base/release/10.0.0/contrib/jemalloc/src/jemalloc .c?revision=260789&view=markup That said, we have a freebsd 10 server running the same version of varnishd that has the same problem (the reason I had discounted freebsd as the culprit initially). This server?s hardware is much newer and as you can see has quite a bit more physical memory as well. It is running with a few more threads as you can see, because it has more cpu cores and was configured with more thread_pools. Otherwise, it is the same as our 9.2 boxes. >From our FreeBSD 10 box running varnish: CPU: 4.0% user, 0.0% nice, 0.7% system, 0.2% interrupt, 95.1% idle Mem: 4509M Active, 111G Inact, 6229M Wired, 73M Cache, 2757M Free ARC: 1911M Total, 464M MFU, 730M MRU, 400K Anon, 390M Header, 326M Other Swap: 32G Total, 8353M Used, 24G Free, 25% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1311 www 1291 20 0 354G 116G uwait 8 476.0H 21.19% varnishd $ uname -v > FreeBSD 10.0-RELEASE-p7 #0: Tue Jul 8 06:37:44 UTC 2014 root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC varnishstat ?1: client_conn 317914959 133.36 Client connections accepted client_drop 0 0.00 Connection dropped, no sess/wrk client_req 507413109 212.85 Client requests received cache_hit 236222630 99.09 Cache hits cache_hitpass 21505999 9.02 Cache hits for pass cache_miss 213793146 89.68 Cache misses backend_conn 111736980 46.87 Backend conn. success backend_unhealthy 0 0.00 Backend conn. not attempted backend_busy 8690564 3.65 Backend conn. too many backend_fail 516882 0.22 Backend conn. failures backend_reuse 265640872 111.43 Backend conn. reuses backend_toolate 14139104 5.93 Backend conn. was closed backend_recycle 279780619 117.36 Backend conn. recycles backend_retry 25784 0.01 Backend conn. retry fetch_head 1770 0.00 Fetch head fetch_length 121268619 50.87 Fetch with Length fetch_chunked 254268690 106.66 Fetch chunked fetch_eof 0 0.00 Fetch EOF fetch_bad 0 0.00 Fetch had bad headers fetch_close 1590881 0.67 Fetch wanted close fetch_oldhttp 0 0.00 Fetch pre HTTP/1.1 closed fetch_zero 0 0.00 Fetch zero len fetch_failed 167507 0.07 Fetch failed fetch_1xx 0 0.00 Fetch no body (1xx) fetch_204 0 0.00 Fetch no body (204) fetch_304 172230 0.07 Fetch no body (304) n_sess_mem 6946 . N struct sess_mem n_sess 593 . N struct sess n_object 992149 . N struct object n_vampireobject 0 . N unresurrected objects n_objectcore 993155 . N struct objectcore n_objecthead 988241 . N struct objecthead n_waitinglist 1273 . N struct waitinglist n_vbc 71 . N struct vbc n_wrk 1280 . N worker threads n_wrk_create 1595 0.00 N worker threads created n_wrk_failed 0 0.00 N worker threads not created n_wrk_max 0 0.00 N worker threads limited n_wrk_lqueue 0 0.00 work request queue length n_wrk_queued 4530 0.00 N queued work requests n_wrk_drop 0 0.00 N dropped work requests n_backend 7 . N backends n_expired 135419385 . N expired objects n_lru_nuked 76410300 . N LRU nuked objects n_lru_moved 128024378 . N LRU moved objects losthdr 28 0.00 HTTP header overflows n_objsendfile 0 0.00 Objects sent with sendfile n_objwrite 355076718 148.95 Objects sent with write n_objoverflow 0 0.00 Objects overflowing workspace s_sess 317934238 133.37 Total Sessions s_req 507413109 212.85 Total Requests s_pipe 0 0.00 Total pipe s_pass 165619470 69.47 Total pass s_fetch 377135515 158.20 Total fetch s_hdrbytes 189267454297 79393.14 Total header bytes s_bodybytes 3732756334613 1565801.44 Total body bytes sess_closed 35770111 15.00 Session Closed sess_pipeline 24574 0.01 Session Pipeline sess_readahead 7384 0.00 Session Read Ahead sess_linger 476097250 199.71 Session Linger sess_herd 494921706 207.61 Session herd shm_records 45611717569 19133.02 SHM records shm_writes 2842104094 1192.19 SHM writes shm_flushes 2794 0.00 SHM flushes due to overflow shm_cont 5861694 2.46 SHM MTX contention shm_cycles 19426 0.01 SHM cycles through buffer sms_nreq 2859746 1.20 SMS allocator requests sms_nobj 0 . SMS outstanding allocations sms_nbytes 0 . SMS outstanding bytes sms_balloc 8118447295 . SMS bytes allocated sms_bfree 8118447295 . SMS bytes freed backend_req 377315426 158.27 Backend requests made n_vcl 1 0.00 N vcl total n_vcl_avail 1 0.00 N vcl available n_vcl_discard 0 0.00 N vcl discarded n_ban 1 . N total active bans n_ban_gone 1 . N total gone bans n_ban_add 1 0.00 N new bans added n_ban_retire 0 0.00 N old bans deleted n_ban_obj_test 0 0.00 N objects tested n_ban_re_test 0 0.00 N regexps tested against n_ban_dups 0 0.00 N duplicate bans removed hcb_nolock 0 0.00 HCB Lookups without lock hcb_lock 0 0.00 HCB Lookups with lock hcb_insert 0 0.00 HCB Inserts esi_errors 0 0.00 ESI parse errors (unlock) esi_warnings 0 0.00 ESI parse warnings (unlock) accept_fail 459 0.00 Accept failures client_drop_late 0 0.00 Connection dropped late uptime 2383927 1.00 Client uptime dir_dns_lookups 0 0.00 DNS director lookups dir_dns_failed 0 0.00 DNS director failed lookups dir_dns_hit 0 0.00 DNS director cached lookups hit dir_dns_cache_full 0 0.00 DNS director full dnscache vmods 0 . Loaded VMODs n_gzip 257811067 108.15 Gzip operations n_gunzip 276663353 116.05 Gunzip operations sess_pipe_overflow 0 . Dropped sessions due to session pipe overflow LCK.sms.creat 1 0.00 Created locks LCK.sms.destroy 0 0.00 Destroyed locks LCK.sms.locks 8579238 3.60 Lock Operations LCK.sms.colls 0 0.00 Collisions LCK.smp.creat 0 0.00 Created locks LCK.smp.destroy 0 0.00 Destroyed locks LCK.smp.locks 0 0.00 Lock Operations LCK.smp.colls 0 0.00 Collisions LCK.sma.creat 2 0.00 Created locks LCK.sma.destroy 0 0.00 Destroyed locks LCK.sma.locks 2111376064 885.67 Lock Operations LCK.sma.colls 0 0.00 Collisions LCK.smf.creat 0 0.00 Created locks LCK.smf.destroy 0 0.00 Destroyed locks LCK.smf.locks 0 0.00 Lock Operations LCK.smf.colls 0 0.00 Collisions LCK.hsl.creat 0 0.00 Created locks LCK.hsl.destroy 0 0.00 Destroyed locks LCK.hsl.locks 0 0.00 Lock Operations LCK.hsl.colls 0 0.00 Collisions LCK.hcb.creat 0 0.00 Created locks LCK.hcb.destroy 0 0.00 Destroyed locks LCK.hcb.locks 0 0.00 Lock Operations LCK.hcb.colls 0 0.00 Collisions LCK.hcl.creat 250007 0.10 Created locks LCK.hcl.destroy 0 0.00 Destroyed locks LCK.hcl.locks 942040132 395.16 Lock Operations LCK.hcl.colls 0 0.00 Collisions LCK.vcl.creat 1 0.00 Created locks LCK.vcl.destroy 0 0.00 Destroyed locks LCK.vcl.locks 4406502 1.85 Lock Operations LCK.vcl.colls 0 0.00 Collisions LCK.stat.creat 1 0.00 Created locks LCK.stat.destroy 0 0.00 Destroyed locks LCK.stat.locks 317940634 133.37 Lock Operations LCK.stat.colls 0 0.00 Collisions LCK.sessmem.creat 1 0.00 Created locks LCK.sessmem.destroy 0 0.00 Destroyed locks LCK.sessmem.locks 318157037 133.46 Lock Operations LCK.sessmem.colls 0 0.00 Collisions LCK.wstat.creat 1 0.00 Created locks LCK.wstat.destroy 0 0.00 Destroyed locks LCK.wstat.locks 6160352 2.58 Lock Operations LCK.wstat.colls 0 0.00 Collisions LCK.herder.creat 1 0.00 Created locks LCK.herder.destroy 0 0.00 Destroyed locks LCK.herder.locks 1734 0.00 Lock Operations LCK.herder.colls 0 0.00 Collisions LCK.wq.creat 32 0.00 Created locks LCK.wq.destroy 0 0.00 Destroyed locks LCK.wq.locks 1140526679 478.42 Lock Operations LCK.wq.colls 0 0.00 Collisions LCK.objhdr.creat 183579053 77.01 Created locks LCK.objhdr.destroy 182591336 76.59 Destroyed locks LCK.objhdr.locks 1584172928 664.52 Lock Operations LCK.objhdr.colls 0 0.00 Collisions LCK.exp.creat 1 0.00 Created locks LCK.exp.destroy 0 0.00 Destroyed locks LCK.exp.locks 426984689 179.11 Lock Operations LCK.exp.colls 0 0.00 Collisions LCK.lru.creat 2 0.00 Created locks LCK.lru.destroy 0 0.00 Destroyed locks LCK.lru.locks 289232005 121.33 Lock Operations LCK.lru.colls 0 0.00 Collisions LCK.cli.creat 1 0.00 Created locks LCK.cli.destroy 0 0.00 Destroyed locks LCK.cli.locks 1180095 0.50 Lock Operations LCK.cli.colls 0 0.00 Collisions LCK.ban.creat 1 0.00 Created locks LCK.ban.destroy 0 0.00 Destroyed locks LCK.ban.locks 427224495 179.21 Lock Operations LCK.ban.colls 0 0.00 Collisions LCK.vbp.creat 1 0.00 Created locks LCK.vbp.destroy 0 0.00 Destroyed locks LCK.vbp.locks 1809670 0.76 Lock Operations LCK.vbp.colls 0 0.00 Collisions LCK.vbe.creat 1 0.00 Created locks LCK.vbe.destroy 0 0.00 Destroyed locks LCK.vbe.locks 224508313 94.18 Lock Operations LCK.vbe.colls 0 0.00 Collisions LCK.backend.creat 7 0.00 Created locks LCK.backend.destroy 0 0.00 Destroyed locks LCK.backend.locks 904980852 379.62 Lock Operations LCK.backend.colls 0 0.00 Collisions SMA.s0.c_req 578846458 242.81 Allocator requests SMA.s0.c_fail 76630001 32.14 Allocator failures SMA.s0.c_bytes 25682079523063 10773014.24 Bytes allocated SMA.s0.c_freed 25675638298667 10770312.30 Bytes freed SMA.s0.g_alloc 2023035 . Allocations outstanding SMA.s0.g_bytes 6441224396 . Bytes outstanding SMA.s0.g_space 1226548 . Bytes available SMA.Transient.c_req 343584190 144.13 Allocator requests SMA.Transient.c_fail 0 0.00 Allocator failures SMA.Transient.c_bytes 21240906064202 8910048.87 Bytes allocated SMA.Transient.c_freed 21240900389430 8910046.49 Bytes freed SMA.Transient.g_alloc 5520 . Allocations outstanding SMA.Transient.g_bytes 5674772 . Bytes outstanding SMA.Transient.g_space 0 . Bytes available -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5831 bytes Desc: not available URL: From al-varnishmisc at none.at Sun Sep 21 18:58:26 2014 From: al-varnishmisc at none.at (Aleksandar Lazic) Date: Sun, 21 Sep 2014 20:58:26 +0200 Subject: Question about designed solution with dynamic backend setup based on csv-file with backend Basic Authentication In-Reply-To: <20140218101006.GA1962@immer.varnish-software.com> References: <20140218101006.GA1962@immer.varnish-software.com> Message-ID: Hi. Am 18-02-2014 11:10, schrieb Lasse Karstensen: > On Thu, Feb 06, 2014 at 04:30:08PM +0100, Aleksandar Lazic wrote: [..] >> @2.) Write a script which create a $ID.vcl with the necessary >> "backend $ID { ...}" files. >> This script add also a 'sub vcl_recv {...}' per backend with >> header >> >> set req.http.Authorization = "BASIC [base64 encoded >> admin:adminpass]" > > If this is for the backend connection/requests, you need to set it on > bereq in > vcl_miss. Sorry but I think I still not have fully understand varnish. I need to change the request URL on the backend to another url and set the Authorization-Header. ####### backend id37 { .host = ""; .port = "9004"; .connect_timeout = 2s; } sub vcl_recv { ... if (req.url == "37") { set req.http.Authorization = "Basic Z2FzdDpnYXN0"; set req.http.url = ""; set req.backend_hint = id37; } ... } sub vcl_miss { if (req.url == "37") { set bereq.http.authorization = "Basic admin:adminpass"; set bereq.url = ""; # set req.backend_hint = id37; set bereq.backend = id37; } } ####### Message from VCC-compiler: 'bereq.http.authorization': cannot be set in method 'vcl_miss'. At: ('input' Line 41 Pos 9) set bereq.http.authorization = "Basic ..."; --------########################------------------------ Running VCC-compiler failed, exit 1 VCL compilation failed ################# on https://www.varnish-cache.org/docs/4.0/reference/vcl.html?highlight=include#bereq is described that the bereq.http.authorization is only writeable in vcl_pipe ################### bereq.http. Type: HEADER Readable from: vcl_pipe, backend Writable from: vcl_pipe, backend The corresponding HTTP header. ################### varnishd -V varnishd (varnish-4.0.1 revision 4354e5e) Copyright (c) 2006 Verdens Gang AS Copyright (c) 2006-2011 Varnish Software AS Thanks for any help. Aleks From oystein at gisnas.net Mon Sep 22 09:25:34 2014 From: oystein at gisnas.net (=?UTF-8?B?w5h5c3RlaW4gR2lzbsOlcw==?=) Date: Mon, 22 Sep 2014 11:25:34 +0200 Subject: Query by transaction ID Message-ID: Hi all, How can I query a specific VXID with varnishlog and friends (Varnish 4)? Typical use case is an error page showing the VXID and wanting to debug the relevant log afterwards. Did I miss the obvious? Cheers, ?ystein -------------- next part -------------- An HTML attachment was scrubbed... URL: From kervin at adevsoft.com Wed Sep 24 01:16:48 2014 From: kervin at adevsoft.com (Kervin L. Pierre) Date: Wed, 24 Sep 2014 01:16:48 +0000 Subject: Varnish 4 Taglist documented? Message-ID: <7cd60464fab845df84d589c3e9618ba6@BN1PR05MB360.namprd05.prod.outlook.com> Is there a taglist document somewhere? I just upgraded to Varnish 4 and it seems to have invalidated useful commands like... "varnishtop -b -i TxURL" 1. How can I accomplish this in Varnish 4 syntax? 2. Is there a master tag list somewhere? Even in the code if necessary? Best regards, Kervin From apj at mutt.dk Wed Sep 24 06:27:25 2014 From: apj at mutt.dk (Andreas Plesner Jacobsen) Date: Wed, 24 Sep 2014 08:27:25 +0200 Subject: Varnish 4 Taglist documented? In-Reply-To: <7cd60464fab845df84d589c3e9618ba6@BN1PR05MB360.namprd05.prod.outlook.com> References: <7cd60464fab845df84d589c3e9618ba6@BN1PR05MB360.namprd05.prod.outlook.com> Message-ID: <20140924062724.GX19870@nerd.dk> On Wed, Sep 24, 2014 at 01:16:48AM +0000, Kervin L. Pierre wrote: > > "varnishtop -b -i TxURL" > > 1. How can I accomplish this in Varnish 4 syntax? TxURL is named BereqURL in varnish 4 > 2. Is there a master tag list somewhere? Even in the code if necessary? man vsl -- Andreas From haazeloud at gmail.com Wed Sep 24 11:59:02 2014 From: haazeloud at gmail.com (David B.) Date: Wed, 24 Sep 2014 13:59:02 +0200 Subject: Varnish 3 : check url length in vcl In-Reply-To: References: Message-ID: <5422B206.8020305@gmail.com> Hi varnish users, Is there a simple way to check url length in a VCL ? Like described here : https://www.varnish-cache.org/trac/ticket/701#comment:1 Some code like : if (length(req.http) > 200) {...} Should be great, but this seems not to work. The best way could be to use inline C code with strlen ? Best Regards David. From kervin at adevsoft.com Wed Sep 24 20:50:50 2014 From: kervin at adevsoft.com (Kervin L. Pierre) Date: Wed, 24 Sep 2014 20:50:50 +0000 Subject: Varnish 4 Taglist documented? In-Reply-To: <20140924062724.GX19870@nerd.dk> References: <7cd60464fab845df84d589c3e9618ba6@BN1PR05MB360.namprd05.prod.outlook.com> <20140924062724.GX19870@nerd.dk> Message-ID: <77abfb9f3fa9414f9c16e8f9ce9950a0@BLUPR05MB354.namprd05.prod.outlook.com> Thanks a lot. Both works. Best regards, Kervin -----Original Message----- From: varnish-misc-bounces+kervin=adevsoft.com at varnish-cache.org [mailto:varnish-misc-bounces+kervin=adevsoft.com at varnish-cache.org] On Behalf Of Andreas Plesner Jacobsen Sent: Wednesday, September 24, 2014 2:27 AM To: varnish-misc at varnish-cache.org Subject: Re: Varnish 4 Taglist documented? On Wed, Sep 24, 2014 at 01:16:48AM +0000, Kervin L. Pierre wrote: > > "varnishtop -b -i TxURL" > > 1. How can I accomplish this in Varnish 4 syntax? TxURL is named BereqURL in varnish 4 > 2. Is there a master tag list somewhere? Even in the code if necessary? man vsl -- Andreas _______________________________________________ varnish-misc mailing list varnish-misc at varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc From m.ramanna at ymail.com Fri Sep 26 18:17:54 2014 From: m.ramanna at ymail.com (Madhusudan Ramanna) Date: Fri, 26 Sep 2014 11:17:54 -0700 Subject: vcl_synth In-Reply-To: <1410323819.5332.YahooMailNeo@web121703.mail.ne1.yahoo.com> References: <1410323819.5332.YahooMailNeo@web121703.mail.ne1.yahoo.com> Message-ID: <1411755474.48631.YahooMailNeo@web121701.mail.ne1.yahoo.com> To answer my own question, I got this to work by using valid http codes in synth() call. >>>>>>>>>> sub vcl_recv { if (req.url ~ "^/ping") { return (synth(200, "OK")); } } sub vcl_synth { if (resp.status == 200) { if (req.url ~ "^/ping") { synthetic("pong"); } set resp.http.Content-Type = "text/plain; charset=utf-8"; return (deliver); } } <<<<<<<<<<<< No more calls to backend and varnish returns the synthetic response right away. thanks, Madhu ps: please pardon typos in code if any On Tuesday, September 9, 2014 9:38 PM, Madhusudan Ramanna wrote: Hello, We're using 3.0.5 in production and currently testing 4.0.1. We have some urls for which we always construct synthetic responses. (/ping response pong) In 4.x vcl, I'm matching against the req url and returning synth with appropriate error code. >>>>>>>>>>>>>>> sub vcl_recv { if (req.url ~ "^/ping") { return (synth(1002, "OK")); } sub vcl_synth { if (resp.status == 1002) { set resp.status = 200; set resp.http.Content-Type = "text/plain; charset=utf-8"; synthetic("pong"); return (deliver); } } <<<<<<<<<<<<<<<<< However, when the backend is down, varnish does not return the synthetic response < HTTP/1.1 503 OK < Date: Wed, 10 Sep 2014 04:31:40 GMT < Server: Varnish < X-Varnish: 35 < Content-Length: 0 < Connection: keep-alive Here is the varnishlog - ReqHeader Host: localhost:6081 - ReqHeader Accept: */* - ReqHeader X-Forwarded-For: 127.0.0.1 - VCL_call RECV - Debug "VCL_error(1002, OK)" - VCL_return synth - VCL_call HASH - VCL_return lookup - Timestamp Process: 1410309978.983313 0.000075 0.000075 - RespHeader Date: Wed, 10 Sep 2014 00:46:18 GMT - RespHeader Server: Varnish - RespHeader X-Varnish: 32797 - RespProtocol HTTP/1.1 - RespStatus 503 - RespReason Service Unavailable - RespReason OK - VCL_call SYNTH - VCL_return deliver - RespHeader Content-Length: 0 Not sure why the thread would call HASH. I would expect varnish to deliver the response after the vcl_synth call ? Is this the expected behavior ? How can I fix this to return synthetic response without regard for the health of the backend appreciate your response ! thank you, Madhu ps: Also looking forward to 4.x version of Varnish book _______________________________________________ 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 nesta at iceburg.net Tue Sep 30 04:46:48 2014 From: nesta at iceburg.net (Brice Burgess) Date: Mon, 29 Sep 2014 23:46:48 -0500 Subject: lowercasing request - varnish 4 Message-ID: <542A35B8.1000905@iceburg.net> Hi, The varnish-4 Hashing documentation states; "It is worth pointing out that Varnish doesn't lowercase the hostname or the URL before hashing it so in theory having "Varnish.org/" and "varnish.org/" would result in different cache entries." I would like to lowercase both the host and url during my normalization routines in vcl_recv. Stackoverflow has an example using embedded C; === |C{ #include static void strtolower(const char *s) { register char *c; for (c=s; *c; c++) { if (isupper(*c)) { *c= tolower(*c); } } return; } }C sub vcl_recv{ C{ strtolower(VRT_r_req_url(sp)); }C } === Is this the recommended approach -- and will it work with the variable definition changes in varnish 4? (I'm worried||VRT_r_req_url|(sp) may break). Also -- what is the variable holding the Host string? Is VRT_r_req_host(sp) valid in varnish-4? Many thanks, ~ Brice -------------- next part -------------- An HTML attachment was scrubbed... URL: From apj at mutt.dk Tue Sep 30 06:40:45 2014 From: apj at mutt.dk (Andreas Plesner Jacobsen) Date: Tue, 30 Sep 2014 08:40:45 +0200 Subject: lowercasing request - varnish 4 In-Reply-To: <542A35B8.1000905@iceburg.net> References: <542A35B8.1000905@iceburg.net> Message-ID: <20140930064045.GB19870@nerd.dk> On Mon, Sep 29, 2014 at 11:46:48PM -0500, Brice Burgess wrote: > I would like to lowercase both the host and url during my > normalization routines in vcl_recv. Stackoverflow has an example > using embedded C; [...] > Is this the recommended approach No. Use the tolower method in the std vmod. man vmod_std -- Andreas From nesta at iceburg.net Tue Sep 30 08:42:50 2014 From: nesta at iceburg.net (Brice Burgess) Date: Tue, 30 Sep 2014 03:42:50 -0500 Subject: lowercasing request - varnish 4 In-Reply-To: <20140930064045.GB19870@nerd.dk> References: <542A35B8.1000905@iceburg.net> <20140930064045.GB19870@nerd.dk> Message-ID: <542A6D0A.3050709@iceburg.net> On 09/30/2014 01:40 AM, Andreas Plesner Jacobsen wrote: > On Mon, Sep 29, 2014 at 11:46:48PM -0500, Brice Burgess wrote: > >> I would like to lowercase both the host and url during my >> normalization routines in vcl_recv. Stackoverflow has an example >> using embedded C; > [...] > >> Is this the recommended approach > No. Use the tolower method in the std vmod. man vmod_std > Thanks Andreas. Much preferred! I'm now doing something like this; normalization.vcl ==== vcl 4.0; import std; sub vcl_recv { # normalize Host header set req.http.Host = std.tolower(regsub(req.http.Host, ":[0-9]+", "")); # URL MANIPULATIONS ################### # lowercase request URL set req.url = std.tolower(req.url); .... } Appears to be working well! ~ Brice From pprocacci at datapipe.com Tue Sep 30 18:18:58 2014 From: pprocacci at datapipe.com (Paul Procacci) Date: Tue, 30 Sep 2014 14:18:58 -0400 Subject: lowercasing request - varnish 4 In-Reply-To: <542A35B8.1000905@iceburg.net> References: <542A35B8.1000905@iceburg.net> Message-ID: <542AF412.1070102@datapipe.com> https://www.varnish-cache.org/docs/3.0/reference/vmod_std.html The std module provides a tolower function which is cleaner to use in my honest opinion. Either way would work fine though. There really isn't a wrong way to do it. ~Paul On 9/30/2014 12:46 AM, Brice Burgess wrote: > Hi, > > The varnish-4 Hashing documentation states; "It is worth pointing out > that Varnish doesn't lowercase the hostname or the URL before hashing > it so in theory having "Varnish.org/" and "varnish.org/" would result > in different cache entries." > > I would like to lowercase both the host and url during my > normalization routines in vcl_recv. Stackoverflow has an example using > embedded C; > > === > |C{ > #include > static void strtolower(const char *s) { > register char *c; > for (c=s; *c; c++) { > if (isupper(*c)) { > *c= tolower(*c); > } > } > return; > } > }C > > sub vcl_recv{ > C{ > strtolower(VRT_r_req_url(sp)); > }C > } > === > > Is this the recommended approach -- and will it work with the variable definition changes in varnish 4? (I'm worried||VRT_r_req_url|(sp) may break). > > Also -- what is the variable holding the Host string? Is VRT_r_req_host(sp) valid in varnish-4? > > Many thanks, > > ~ Brice > > > > > > _______________________________________________ > 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 pprocacci at datapipe.com Tue Sep 30 18:23:24 2014 From: pprocacci at datapipe.com (Paul Procacci) Date: Tue, 30 Sep 2014 14:23:24 -0400 Subject: lowercasing request - varnish 4 In-Reply-To: <542AF412.1070102@datapipe.com> References: <542A35B8.1000905@iceburg.net> <542AF412.1070102@datapipe.com> Message-ID: <542AF51C.6060802@datapipe.com> So sorry. Didn't notice there were already follow-ups to your question. My Mistake. ~Paul On 9/30/2014 2:18 PM, Paul Procacci wrote: > https://www.varnish-cache.org/docs/3.0/reference/vmod_std.html > > The std module provides a tolower function which is cleaner to use in > my honest opinion. > Either way would work fine though. There really isn't a wrong way to > do it. > > ~Paul > > On 9/30/2014 12:46 AM, Brice Burgess wrote: >> Hi, >> >> The varnish-4 Hashing documentation states; "It is worth pointing out >> that Varnish doesn't lowercase the hostname or the URL before hashing >> it so in theory having "Varnish.org/" and "varnish.org/" would result >> in different cache entries." >> >> I would like to lowercase both the host and url during my >> normalization routines in vcl_recv. Stackoverflow has an example >> using embedded C; >> >> === >> |C{ >> #include >> static void strtolower(const char *s) { >> register char *c; >> for (c=s; *c; c++) { >> if (isupper(*c)) { >> *c= tolower(*c); >> } >> } >> return; >> } >> }C >> >> sub vcl_recv{ >> C{ >> strtolower(VRT_r_req_url(sp)); >> }C >> } >> === >> >> Is this the recommended approach -- and will it work with the variable definition changes in varnish 4? (I'm worried||VRT_r_req_url|(sp) may break). >> >> Also -- what is the variable holding the Host string? Is VRT_r_req_host(sp) valid in varnish-4? >> >> Many thanks, >> >> ~ Brice >> >> >> >> >> >> _______________________________________________ >> 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: