| My understanding of using 'pass' in vcl_hit is that it causes the
object
| to be marked as 'hit for pass' and therefore is uncacheable from that
| point onwards. In fact, pass'ing out of vcl_hit was what I used to do
a
| while ago, but it caused that exact behaviour (items would no longer
]] Darryl Dixon - Winterhouse Consulting
| My understanding of using 'pass' in vcl_hit is that it causes the object
| to be marked as 'hit for pass' and therefore is uncacheable from that
| point onwards. In fact, pass'ing out of vcl_hit was what I used to do a
| while ago, but it caused that
| My understanding of using 'pass' in vcl_hit is that it causes the object
| to be marked as 'hit for pass' and therefore is uncacheable from that
| point onwards. In fact, pass'ing out of vcl_hit was what I used to do a
| while ago, but it caused that exact behaviour (items would no longer be
Hi DES,
Darryl Dixon - Winterhouse Consulting
darryl.di...@winterhouseconsulting.com writes:
+if (req.http.Pragma ~ .*no-cache.* || req.http.Cache-Control ~
.*no-cache.*) {
+purge_url(regsub(req.url, [?].*$, .*$));
+}
+
It would be interesting to see how often this
hi darryl
i had a simlar problem (varnish child process consuming lots of memory) a
week
ago (see the thread make varnish don't start a subprocess)
the solution for my problem seems to be to use a high-enough cache-size:
starting varnish with
-s file,/tmp/storage,300M
will make the
Hi All,
I have an odd problem that I have only noticed happening since moving from
1.1.2 to 2.0.3 - excessive memory consumption of the varnish child
process. For example, I have a varnish instance with a 256MB cache
allocated, that is currently consuming 4.9GB of resident memory (6.5GB
virtual).
Not that I have an answer, but I'd be curious to see the differences
in 'pmap -x pid' output for the different children.
--Michael
On Apr 7, 2009, at 6:27 PM, Darryl Dixon - Winterhouse Consulting wrote:
Hi All,
I have an odd problem that I have only noticed happening since
moving from
Further to this, I just ran the pmap on the runaway process again (roughly
15 minutes since last time), and the large ~2GB allocation has jumped by
about 60MB in that time, eg:
--
3940: /u01/app/varnish/sbin/varnishd -a
