Re: "ExpBan: nnn was banned"

2009-07-06 Thread Martin Goldman
Yes - Eventually I kind of figured out/assumed that's what was going on.
Initially I couldn't figure out what "banned" meant.

Thanks,
Martin

On Tue, Jun 30, 2009 at 8:14 PM, Tollef Fog Heen
wrote:

> ]] Martin Goldman
>
> | I got a complaint from a user that some percentage of his page views seem
> | too slow to be coming from the cache. I brought up our home page and
> started
> | refreshing it over and over. Sure enough, while most of the page views
> are
> | in fact getting  cached, once every 5 or 6 times, I get a cache miss.
> When
> | this happens, varnishlog shows something like this:
> |
> |32 VCL_call c recv lookup
> |32 VCL_call c hash hash
> | *   32 ExpBan   c 1607291667 was banned
> | *   32 VCL_call c miss fetch
>
> Do you add purges every now and then?  This looks like the result of a
> purge forcing an object to be removed, which then gives you a cache
> miss.
>
> --
> Tollef Fog Heen
> Redpill Linpro -- Changing the game!
> t: +47 21 54 41 73
> ___
> varnish-misc mailing list
> varnish-misc@projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: Thread memory allocation question

2009-07-06 Thread Ken Brownfield
Overcommit defaults off; sane use cases for overcommit are few and far  
between, IMHO.  With overcommit on, the performance implications might  
be more of a wash... but then you have two problems.

Even though the stack remains mostly unused, it would still have to be  
swapped out under memory pressure, and thread creation and reclamation  
would cause more swap thrash.  Used or not, the performance pain is  
the same.

Plus I'd rather not allocate/waste 8GB of RAM for 1,000 varnish  
threads at idle, which represents two orders of magnitude more than it  
needs.

A 1MB limit holds up fine for me, though 256KB or even 128KB should be  
fine as well, since Varnish tends to sit at around 86KB under Linux/ 
x86_64.  Maybe Varnish could have its own stacksize parameter, rather  
than using the ulimit value?  Out-of-box scalability would be much  
better, and this is how MySQL handles it, FWIW.
-- 
Ken.

On Jun 30, 2009, at 5:11 PM, Tollef Fog Heen wrote:

>
> ]] "Poul-Henning Kamp"
>
> | In message <5c056ae2-7207-42f8-9e4b-0f541dc4b...@slide.com>, Ken  
> Brownfield wri
> | tes:
> |
> | >Would a stack overflow take out the whole child, or just that  
> thread?
> |
> | The kernel would try to extend the stack and provided you are not on
> | a 32 bit system, it shouldn't ever have a problem with that.
>
> On the other hand, the gain from decreasing the stack size would  
> just be
> a bit less book-keeping for the kernel, unless you have overcommit
> turned off (which I don't think anybody actually uses), right?
>
> -- 
> Tollef Fog Heen
> Redpill Linpro -- Changing the game!
> t: +47 21 54 41 73
> ___
> varnish-misc mailing list
> varnish-misc@projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc

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


Re: Inline C and memory allocation

2009-07-06 Thread Ken Brownfield
Isn't VRT_SetHdr() what you're looking for?  Mind its semantics, though.
-- 
Ken.

On Jul 6, 2009, at 7:26 AM, Laurence Rowe wrote:

> Hi,
>
> Thought my C is rather rusty by now, I'd like to make the mod_auth_tkt
> [1] signed cookie authentication / authorisation system work with
> Varnish. The idea would be to encode the acceptable authorisation
> tokens for a page into it's response header then check the tokens in
> the user's auth_tkt cookie against the tokens in the cached header
> during vcl_deliver.
>
> I can find examples online that read data from headers using
> VRT_GetHdr, but in order to implement/port mod_auth_tkt I will need to
> decode the data in the cookie and write the decoded contents to new
> headers. With apache, I would use apr_psprintf or similar to allocate
> memory from the pool. What would be the equivalent in Varnish?
>
> Laurence
>
> [1] http://www.openfusion.com.au/labs/mod_auth_tkt/
> ___
> varnish-misc mailing list
> varnish-misc@projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc

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


Segfault in libvarnishcompat.so.1.0.0, after upgrading to build 4131

2009-07-06 Thread Ross Brown
After upgrading to trunk (build 4131) last week, we are seeing an issue when 
the object cache (using malloc) becomes full. We are running a server with 16GB 
of RAM with the following startup options:

-s malloc,12G 
-a 0.0.0.0:80 
-T 0.0.0.0:8021 
-f /usr/local/etc/current.vcl 
-t 86400 
-h classic,42013 
-P /var/run/varnish.pid 
-p obj_workspace=4096 
-p sess_workspace=262144 
-p lru_interval=60 
-p sess_timeout=10 
-p shm_workspace=32768 
-p ping_interval=1 
-p thread_pools=4 
-p thread_pool_min=50 
-p thread_pool_max=4000 
-p cli_timeout=20

VCL is pretty basic, we normalise and only accept GET and HEAD requests. 

Plotting usage using Cacti, we see varnishd crash and restart when the object 
cache is full.

Example of an error occurring :
Jul  3 11:04:50 tmcache2 kernel: [68325.150385] varnishd[15155]: segfault at ff 
ip 7f1df03a4d06 sp 7f1dd44b6120 error 4 in 
libvarnishcompat.so.1.0.0[7f1df039e000+e000]
Jul  3 11:04:52 tmcache2 varnishd[2594]: Child (15130) not responding to ping, 
killing it.
Jul  3 11:04:52 tmcache2 varnishd[2594]: Child (15130) not responding to ping, 
killing it.
Jul  3 11:04:52 tmcache2 varnishd[2594]: Child (15130) died signal=11
Jul  3 11:04:52 tmcache2 varnishd[2594]: Child cleanup complete
Jul  3 11:04:52 tmcache2 varnishd[2594]: child (5066) Started
Jul  3 11:04:52 tmcache2 varnishd[2594]: Child (5066) said Closed fds: 3 4 5 8 
9 11 12
Jul  3 11:04:52 tmcache2 varnishd[2594]: Child (5066) said Child starts
Jul  3 11:04:52 tmcache2 varnishd[2594]: Child (5066) said Ready

This bug only occurs in build 4131, prior to this we were using build 4019 and 
didn't have this issue. 

Ross Brown
Trade Me Limited

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


Re: tcp reset problem with varnish 2.0.4 o n Solaris 10 (SPARC)

2009-07-06 Thread Alex Hooper
Rob S uttered:
> Alex Hooper wrote:
> 
>> 5 VCL_call c recv
>> 5 VCL_return   c pass
>> 5 VCL_call c pass
>> 5 VCL_return   c pass
>> 5 VCL_call c error
>> 5 VCL_return   c deliver
> 
> 
> It looks like you're using "pass", rather than "fetch", which probably
> isn't desirable when you're just doing a simple GET request.  I'd expect
> to see something like:
> 
>7 VCL_call c recv
>7 VCL_return   c lookup
>7 VCL_call c hash
>7 VCL_return   c hash
>7 VCL_call c miss
>7 VCL_return   c fetch
> 
> Can you send your VCL file, so that I can take a look at the logic?
> 

Hi,

Having not got past the testing stage, my VCL file comprises only the
lines I origianlly posted, the rest is all default. Here it is again for
convenience:

  backend test01 {
.host = "83.231.175.37";
.port = "80";
.connect_timeout = 10s;
.first_byte_timeout = 15s;
.between_bytes_timeout = 2s;

  }

  sub vcl_recv {
set req.backend = test01;

  }

Cheers,

Alex.
-- 
Alex Hooper   |   www.bmjpg.com
Systems and Database Administration   |   ahoo...@bmjgroup.com
BMJ Technology, BMJ Publishing Group  |   +44 20 7383 6049
BMA House, LONDON, WC1H 9JR   |


___
The BMJ Group is one of the world's most trusted providers of medical 
information for doctors, researchers, health care workers and patients 
www.bmjgroup.bmj.com.  This email and any attachments are confidential.  If you 
have received this email in error, please delete it and kindly notify us.  If 
the email contains personal views then the BMJ Group accepts no responsibility 
for these statements.  The recipient should check this email and attachments 
for viruses because the BMJ Group accepts no liability for any damage caused by 
viruses.  Emails sent or received by the BMJ Group may be monitored for size, 
traffic, distribution and content.  BMJ Publishing Group Limited trading as BMJ 
Group.  A private limited company, registered in England and Wales under 
registration number 03102371.  Registered office: BMA House, Tavistock Square, 
London WC1H 9JR, UK.
___
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: tcp reset problem with varnish 2.0.4 o n Solaris 10 (SPARC)

2009-07-06 Thread Alex Hooper
Rob S uttered:
> Alex Hooper wrote:
>> I wonder does anyone have an idea of what might be happening?
>>   
> Alex,
> 
> I've not seen this before, but I've found that 'varnishlog' typically
> provides very helpful information.  Can you post a log of the request?


Hi Rob,

Log follows.

# /local/bin/varnishlog
0 CLI  - Rd ping
0 CLI  - Wr 0 200 PONG 1246893786 1.0
0 CLI  - Rd ping
0 CLI  - Wr 0 200 PONG 1246893789 1.0
0 CLI  - Rd ping
0 CLI  - Wr 0 200 PONG 1246893792 1.0
5 SessionOpen  c 193.22.89.2 32966 :80
5 ReqStart c 193.22.89.2 32966 1075615183
5 RxRequestc GET
5 RxURLc /
5 RxProtocol   c HTTP/1.1
5 RxHeader c Host: group.bmj.com
5 RxHeader c User-Agent: Mozilla/5.0 (Windows; U; Windows NT
5.1; en-GB; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR
3.5.30729)
5 RxHeader c Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
5 RxHeader c Accept-Language: en,en-us;q=0.7,fr;q=0.3
5 RxHeader c Accept-Encoding: gzip,deflate
5 RxHeader c Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
5 RxHeader c Keep-Alive: 300
5 RxHeader c Connection: keep-alive
5 RxHeader c Cookie: OAX=wRZZAknt5E8AB5OI;
RMAM=01cen16_1230.4aM4O9VW|cen7_1230.4a4Oc3E0|;
__utma=1.790239517130949200.1240951802.1241617626.1241622593.3;
__utmz=1.1240951802.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none);
anonId=0bbac82d-19f2-4efe-904b-6d2ca5cbbb4
5 RxHeader c Cache-Control: max-age=0
5 VCL_call c recv
5 VCL_return   c pass
5 VCL_call c pass
5 VCL_return   c pass
5 VCL_call c error
5 VCL_return   c deliver
5 Length   c 466
5 VCL_call c deliver
5 VCL_return   c deliver
5 TxProtocol   c HTTP/1.1
5 TxStatus c 503
5 TxResponse   c Service Unavailable
5 TxHeader c Server: Varnish
5 TxHeader c Retry-After: 0
5 TxHeader c Content-Type: text/html; charset=utf-8
5 TxHeader c Content-Length: 466
5 TxHeader c Date: Mon, 06 Jul 2009 15:23:14 GMT
5 TxHeader c X-Varnish: 1075615183
5 TxHeader c Age: 0
5 TxHeader c Via: 1.1 varnish
5 TxHeader c Connection: close
5 ReqEnd   c 1075615183 1246893794.202419758
1246893794.217293501 0.001565456 0.014699459 0.000174284
5 SessionClose c error
5 StatSess c 193.22.89.2 32966 0 1 1 0 1 0 235 466
0 StatAddr - 193.22.89.2 0 10951 27 27 0 27 0 6345 12582
0 CLI  - Rd ping
0 CLI  - Wr 0 200 PONG 1246893795 1.0

Cheers,

Alex.
-- 
Alex Hooper   |   www.bmjpg.com
Systems and Database Administration   |   ahoo...@bmjgroup.com
BMJ Technology, BMJ Publishing Group  |   +44 20 7383 6049
BMA House, LONDON, WC1H 9JR   |


___
The BMJ Group is one of the world's most trusted providers of medical 
information for doctors, researchers, health care workers and patients 
www.bmjgroup.bmj.com.  This email and any attachments are confidential.  If you 
have received this email in error, please delete it and kindly notify us.  If 
the email contains personal views then the BMJ Group accepts no responsibility 
for these statements.  The recipient should check this email and attachments 
for viruses because the BMJ Group accepts no liability for any damage caused by 
viruses.  Emails sent or received by the BMJ Group may be monitored for size, 
traffic, distribution and content.  BMJ Publishing Group Limited trading as BMJ 
Group.  A private limited company, registered in England and Wales under 
registration number 03102371.  Registered office: BMA House, Tavistock Square, 
London WC1H 9JR, UK.
___
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: "ExpBan: nnn was banned"

2009-07-06 Thread Tollef Fog Heen
]] Martin Goldman 

| I got a complaint from a user that some percentage of his page views seem
| too slow to be coming from the cache. I brought up our home page and started
| refreshing it over and over. Sure enough, while most of the page views are
| in fact getting  cached, once every 5 or 6 times, I get a cache miss. When
| this happens, varnishlog shows something like this:
| 
|32 VCL_call c recv lookup
|32 VCL_call c hash hash
| *   32 ExpBan   c 1607291667 was banned
| *   32 VCL_call c miss fetch

Do you add purges every now and then?  This looks like the result of a
purge forcing an object to be removed, which then gives you a cache
miss.

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: Thread memory allocation question

2009-07-06 Thread Tollef Fog Heen

]] "Poul-Henning Kamp" 

| In message <5c056ae2-7207-42f8-9e4b-0f541dc4b...@slide.com>, Ken Brownfield 
wri
| tes:
| 
| >Would a stack overflow take out the whole child, or just that thread?
| 
| The kernel would try to extend the stack and provided you are not on
| a 32 bit system, it shouldn't ever have a problem with that.

On the other hand, the gain from decreasing the stack size would just be
a bit less book-keeping for the kernel, unless you have overcommit
turned off (which I don't think anybody actually uses), right?

-- 
Tollef Fog Heen 
Redpill Linpro -- Changing the game!
t: +47 21 54 41 73
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


Re: tcp reset problem with varnish 2.0.4 o n Solaris 10 (SPARC)

2009-07-06 Thread Rob S
Alex Hooper wrote:
> I wonder does anyone have an idea of what might be happening?
>   
Alex,

I've not seen this before, but I've found that 'varnishlog' typically 
provides very helpful information.  Can you post a log of the request?

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


Re: tcp reset problem with varnish 2.0.4 o n Solaris 10 (SPARC)

2009-07-06 Thread Rob S
Alex Hooper wrote:

 > 5 VCL_call c recv
 > 5 VCL_return   c pass
 > 5 VCL_call c pass
 > 5 VCL_return   c pass
 > 5 VCL_call c error
 > 5 VCL_return   c deliver


It looks like you're using "pass", rather than "fetch", which probably 
isn't desirable when you're just doing a simple GET request.  I'd expect 
to see something like:

7 VCL_call c recv
7 VCL_return   c lookup
7 VCL_call c hash
7 VCL_return   c hash
7 VCL_call c miss
7 VCL_return   c fetch

Can you send your VCL file, so that I can take a look at the logic?


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


bereq.connect_timeout sub second value

2009-07-06 Thread Václav Bílek
helo


is it posible to set subsecond valu in bereq.connect_timeout

example:
set bereq.connect_timeout = 0.3

and how to find out that the timeout was exceded?

... the idea is that varnish is in ffront of LVS cluster and vhen one
LVS backend is too slow i want to restart te reques on another LVS
backend ( for varnish it means only restart of the request).


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


Inline C and memory allocation

2009-07-06 Thread Laurence Rowe
Hi,

Thought my C is rather rusty by now, I'd like to make the mod_auth_tkt
[1] signed cookie authentication / authorisation system work with
Varnish. The idea would be to encode the acceptable authorisation
tokens for a page into it's response header then check the tokens in
the user's auth_tkt cookie against the tokens in the cached header
during vcl_deliver.

I can find examples online that read data from headers using
VRT_GetHdr, but in order to implement/port mod_auth_tkt I will need to
decode the data in the cookie and write the decoded contents to new
headers. With apache, I would use apr_psprintf or similar to allocate
memory from the pool. What would be the equivalent in Varnish?

Laurence

[1] http://www.openfusion.com.au/labs/mod_auth_tkt/
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc


tcp reset problem with varnish 2.0.4 o n Solaris 10 (SPARC)

2009-07-06 Thread Alex Hooper
Hi,

Having a requirement to ease the load on a high-traffic site of ours, I
was recently diverted from reaching for Squid by a colleague who
recommended Varnish.

I grabbed the source for 2.0.4 (having looked for a package but not
found one, despite a suggestion that it was available as part of Sun's
Webstack) and compiled it using the compiler bundled with Sun Studio 12
update 1 (having initially tried using gcc and hitting a problem with
isfinite()).

All compiled fine so I created a simple test config:

  backend test01 {
.host = "83.231.175.37";
.port = "80";
.connect_timeout = 10s;
.first_byte_timeout = 15s;
.between_bytes_timeout = 2s;

  }

  sub vcl_recv {
set req.backend = test01;

  }

and started up with

  varnishd -a :80 -T localhost:6082 -p sess_timeout=60 -f
/local/etc/varnish/bmjgroup.vcl


That looked OK, but requests to varnish all gave 503s. Watching the
logs, I could see that flow was passing from 'pass' to 'error', but was
given no more clue. It wasn't until I watched the packets on the wire
that I saw that Varnish was sending resets before even completing a
handshake:

  varnish -> web:   SYN
  varnish -> web:   RST
  web -> varnish:   SYN ACK
  varnish -> web:   RST


Having searched the wiki, mailing lists and bug database for a
resolution to this, I found nothing except for issue #522 (Odd TCP reset
problems with trunk 4080) which seems not to be related.

I compiled, and am running varnish on, Solaris 10 5/08 (SPARC).

I wonder does anyone have an idea of what might be happening?

Cheers,

Alex.
-- 
Alex Hooper   |   www.bmjpg.com
Systems and Database Administration   |   ahoo...@bmjgroup.com
BMJ Technology, BMJ Publishing Group  |   +44 20 7383 6049
BMA House, LONDON, WC1H 9JR   |


___
The BMJ Group is one of the world's most trusted providers of medical 
information for doctors, researchers, health care workers and patients 
www.bmjgroup.bmj.com.  This email and any attachments are confidential.  If you 
have received this email in error, please delete it and kindly notify us.  If 
the email contains personal views then the BMJ Group accepts no responsibility 
for these statements.  The recipient should check this email and attachments 
for viruses because the BMJ Group accepts no liability for any damage caused by 
viruses.  Emails sent or received by the BMJ Group may be monitored for size, 
traffic, distribution and content.  BMJ Publishing Group Limited trading as BMJ 
Group.  A private limited company, registered in England and Wales under 
registration number 03102371.  Registered office: BMA House, Tavistock Square, 
London WC1H 9JR, UK.
___
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc