Re: Still running out of workspaces ? (sess_workspace=551077)

2010-03-04 Thread Per Buer
On Thu, Mar 4, 2010 at 3:57 AM, Simon Males  wrote:

> I don't really know how to interpret this, but I see references to
> "esi" and "session". ESI is used heavily and sess_workspace is 551077.
>

I know of people running with a session workspace of ~5M. And yes, this
really needs to be an autotuning setting.



> Below I have the Varnish startup parameters. Should I just continue to
> increase the sess_workspace until it stops happening?


Yes.

-- 
Per Andreas Buer,  CEO, Varnish Software AS
Phone: +47 21 54 41 21 / Mobile: +47 958 39 117 / skype: per.buer
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Restart needed after new backend declared?

2010-03-04 Thread Simon Kammerer
Hi list,

I declared a new backend and added a simple rule in vcl_recv like

if(req.http.host ~ "xx.yyy.com"){
 set req.backend = newbackend;
}

and then used Kristians script to reload VCL:

-
#!/bin/bash
# Reload a varnish config
# Author: Kristian Lyngstol

FILE="/etc/varnish/default.vcl"

# Hostname and management port
# (defined in /etc/default/varnish or on startup)
HOSTPORT="localhost:6082"
NOW=`date +%s`

error()
{
  echo 1>&2 "Failed to reload $FILE."
  exit 1
}

varnishadm -T $HOSTPORT vcl.load reload$NOW $FILE || error varnishadm -T 
$HOSTPORT vcl.use reload$NOW || error echo Current configs:
varnishadm -T $HOSTPORT vcl.list
-


But the new backend is not used, I had to restart varnish to use the new 
configuration.

Am I missing something?





Mit freundlichem Gruß
Simon Kammerer

-- 
Web 3.0 AG
Moskau 314B
CH-8262 Ramsen
Tel: +41 (0) 52 533 4725
Fax: +41 (0) 52 533 4625
simon.kamme...@web30.ch
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: Child panics on OpenSolaris

2010-03-04 Thread Paul Wright
On 22 February 2010 18:02, Paul Wright  wrote:
...
> For anyone else following along I've now had varnish running for over
> 5 hours without issue, here are the things I found out:
>
> * add the Range unsetting code to ensure that such requests don't make
> it through to the back end
> * remove the TCP_Assert() that wraps the setsockopt() call on line 184
> of bin/varnishd/cache_acceptor.c
> * compile with gcc, not Sun Studio (there's still some sort of
> funniness with TCP_(non)blocking() )
>
> CC=/usr/bin/gcc CFLAGS="-O3 -L/lib/amd64 -pthreads -m64
> -fomit-frame-pointer" LDFLAGS="-lumem -pthreads" ./configure
> --prefix=/opt
>
> * pass the right flags through to gcc when launching vanishd
>
> newtask -p highfile /opt/sbin/varnishd -f /opt/etc/varnish/firebox.vcl -F \
> -p 'cc_command=/usr/bin/gcc -fpic -shared -m64 -o %o %s' \
> -T 127.0.0.1:9001 \
> -s malloc,2G \
> -p sess_timeout=5s \
> -p max_restarts=12 \
> -p waiter=poll \
> -p connect_timeout=0s \
> -p sess_workspace=65536
>
> * keep checking http://letsgetdugg.com/2009/12/04/varnish-on-solaris/
> for hints and suggestions

Latest update, we're seeing "Connection refused" panics like the following:

Child (1955) died signal=6
Child (1955) Panic message: Assert error in TCP_blocking(), tcp.c line 164:
  Condition(TCP_Check(j)) not true.
errno = 146 (Connection refused)
thread = (cache-worker)
ident = -smalloc,-hcritbit,poll
Backtrace:
  42fb51: /opt/sbin/varnishd'pan_ic+0xb1 [0x42fb51]
  2f: [0x2f]
sp = 13570018 {
  fd = 47, id = 47, xid = 0,
  client = ?.?.?.?:?,
  step = STP_FIRST,
  handling = deliver,
  restarts = 0, esis = 0
  ws = 13570088 {
id = "sess",
{s,f,r,e} = {13570d90,13570d90,0,+65536},
  },
  http[req] = {
ws = 13570088[sess]
  "",
  "/i/nl/all/0.gif",
  "HTTP/1.1",
  "Host: media.firebox.com",
  "User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2;
en-us) AppleWebKit/531.21.8 (KHTML, like Gecko)",
  "Accept: */*",
  "Accept-Language: en-us",
  "If-Modified-Since: Tue, 22 Sep 2009 15:34:33 GMT",
  "If-None-Match: "16a8070-2b-4742c55c1f440"",
  "Connection: keep-alive",
  "X-Forwarded-For: 85.189.102.193",
  },
  worker = fd7ff7bf1d80 {
ws = fd7ff7bf1ec8 {
  id = "wrk",
  {s,f,r,e} = {fd7ff7bdfcb0,fd7ff7bdfcb0,0,+65536},
},
},
},

Interesting things to note, we're confident that this request is a
cache hit which rules out the backend (handling = deliver).  Also the
client address appears to have been mangled:

  client = ?.?.?.?:?,

Would this cause varnish to attempt opening a connection which is then refused?

As a workaround would it be advisable to add a clause to TCP_Check (in
include/libvarnish.h) to skip over errno 146 (Connection refused)
along with the existing ECONNRESET and ENOTCONN clauses?

Cheers,

Paul.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc