Varnish trunk rev 2780 refuses to start
Hi all. We have upgraded to the latest trunk version (2780), but Varnish refuses to start property, the syslog says: Jun 24 07:09:06 vvarnish varnishd[2280]: child (2281) Started Jun 24 07:09:06 vvarnish varnishd[2280]: Pushing vcls failed: CLI communication error Jun 24 07:09:06 vvarnish varnishd[2280]: Child (2281) said Closed fds: 3 4 5 6 10 11 13 14 Jun 24 07:09:06 vvarnish varnishd[2280]: Child (2281) said Child starts Jun 24 07:09:06 vvarnish varnishd[2280]: Child (2281) said managed to mmap 0 bytes of 734003200 Our configuration is: DAEMON_OPTS=-a :80 \ -T 127.0.0.1:6082 \ -f /etc/varnish/conf.vcl \ -u varnish -g varnish \ -s file,/var/lib/varnish/varnish_storage.bin,700MB \ -t 240 \ -p thread_pools=1 \ -p thread_pool_max=5000 CentOS 5.1, rpm built from trunk, revision 2780. Previously, we were using revision 2735, this works fine. Thanks. BR. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish trunk rev 2780 refuses to start
In message [EMAIL PROTECTED], anda n andan writes: Can you try #2786 pleae, I think I have fixed it now. Poul-Henning Hi all. We have upgraded to the latest trunk version (2780), but Varnish refuses to start property, the syslog says: Jun 24 07:09:06 vvarnish varnishd[2280]: child (2281) Started Jun 24 07:09:06 vvarnish varnishd[2280]: Pushing vcls failed: CLI communication error Jun 24 07:09:06 vvarnish varnishd[2280]: Child (2281) said Closed fds: 3 4 5 6 10 11 13 14 Jun 24 07:09:06 vvarnish varnishd[2280]: Child (2281) said Child starts Jun 24 07:09:06 vvarnish varnishd[2280]: Child (2281) said managed to mmap 0 bytes of 734003200 Our configuration is: DAEMON_OPTS=-a :80 \ -T 127.0.0.1:6082 \ -f /etc/varnish/conf.vcl \ -u varnish -g varnish \ -s file,/var/lib/varnish/varnish_storage.bin,700MB \ -t 240 \ -p thread_pools=1 \ -p thread_pool_max=5000 CentOS 5.1, rpm built from trunk, revision 2780. Previously, we were using revision 2735, this works fine. Thanks. BR. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish trunk rev 2780 refuses to start
2008/6/24 Poul-Henning Kamp [EMAIL PROTECTED]: In message [EMAIL PROTECTED], anda n andan writes: Can you try #2786 pleae, I think I have fixed it now. Working again ! Thank you very much. BR. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
varnish performance problem
Sorry if this is a duplicate post. I sent the following yesterday but
didn't see it appearing in the mailing list.
We are testing varnish as a potential replacement for our legacy squid
setup on a dual core 8GB RAM server. We've noticed that varnish
performance would suddenly deteriorate after running for a while. The
server load is at around 0.2 before all of a sudden it climbs to over
20 and keeps rising. Top shows varnish is using more than 90% of
memory when this happens.
We know that there's much large varnish instances running out there,
so it must be something with our setup. Does anyone know where we
should be looking at? I've attached the command we use to run varnish
and the vcl file below. I can provide more information if that helps.
varnishd -a localhost:80 -T localhost:6082 -f default.vcl -u varnish
-g varnish -s file,/mnt/varnish/varnish_storage.bin,20G
backend default {
set backend.host = x.x.x.x;
set backend.port = 80;
}
sub vcl_recv {
if (req.request != GET req.request != HEAD) {
pipe;
}
if (req.http.Expect) {
pipe;
}
if (req.http.Authenticate) {
pass;
}
lookup;
}
sub vcl_pipe {
pipe;
}
sub vcl_pass {
pass;
}
sub vcl_hash {
set req.hash += req.url;
set req.hash += req.http.host;
hash;
}
sub vcl_hit {
if (!obj.cacheable) {
pass;
}
deliver;
}
sub vcl_miss {
fetch;
}
sub vcl_fetch {
if (!obj.valid) {
error;
}
if (!obj.cacheable) {
pass;
}
if (obj.http.Set-Cookie) {
pass;
}
insert;
}
sub vcl_deliver {
deliver;
}
sub vcl_timeout {
discard;
}
sub vcl_discard {
discard;
}
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: varnish performance problem
In message [EMAIL PROTECTED], Jian ing Hu writes: Sorry if this is a duplicate post. I sent the following yesterday but didn't see it appearing in the mailing list. We are testing varnish as a potential replacement for our legacy squid setup on a dual core 8GB RAM server. We've noticed that varnish performance would suddenly deteriorate after running for a while. The server load is at around 0.2 before all of a sudden it climbs to over 20 and keeps rising. Top shows varnish is using more than 90% of memory when this happens. Are you running on a 32bit or 64 bit machine ? What does varnishstat say about how much you have loaded in the cache when performance deteriorates ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
Im running 32bit. But I think that I have succeded creating more then 238 threads before on another system with the same setup. Anyway, 64bit might be the thing to have... If I want to have Debian, is it AMD64 version that I should go for? (OT) / E Poul-Henning Kamp skrev: In message [EMAIL PROTECTED], Erik Torlen writes: I still have the same problem :( The threads are created up to 238 where they are stopped, even if I set threads_max = 1000 and threads_pools = 2 (or 3). I also tested the tips and decreased the stack sixe to 512 and increased overflow_max to 1% . Any idea what could be wrong? Are you running on a 32bit or 64bit system ? On a 32bit system you may simply be running out of address-space... ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
In message [EMAIL PROTECTED], Erik Torlen writes: Im running 32bit. But I think that I have succeded creating more then 238 threads before on another system with the same setup. Anyway, 64bit might be the thing to have... If I want to have Debian, is it AMD64 version that I should go for? (OT) Yes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
Erik Torlen skrev: Im running 32bit. But I think that I have succeded creating more then 238 threads before on another system with the same setup. Anyway, 64bit might be the thing to have... Maybe the init script should issue a warning that a 32bit arch is only usable as a test enviroment. Per. signature.asc Description: OpenPGP digital signature ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Question about threads
In message [EMAIL PROTECTED], Per Buer writes: Maybe the init script should issue a warning that a 32bit arch is only usable as a test enviroment. Well, Varnish is generally usable in 32bit, provided you have very small content, so I'm hessitant to rule it entirely out, but yes, we clearly need to push the 64bit angle. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: honoring browser reload request
is the
following VCL the correct solution to support browser shift-reloads to
get fresh content and actually update the cache?
sub vcl_hit {
if (req.http.Cache-Control ~ no-cache) {
set obj.ttl = 0s;
pass;
}
}
Only kind-of; IE and Mozilla send different things with a SHIFT (or CTRL)
+ Reload, we do virtually what you have outlined above, but with a slight
addition:
in vcl_recv, we shortcut and send such requests straight to lookup:
/* Honour Cache-Control: and Pragma: ... */
if (req.http.Pragma ~ .*no-cache.* || req.http.Cache-Control ~
.*no-cache.*) {
lookup;
}
...and then in vcl_recv we do similar to you:
/* Honour Cache-Control: and Pragma: ... */
if (req.http.Pragma ~ .*no-cache.* || req.http.Cache-Control ~
.*no-cache.*) {
set obj.ttl = 0s;
pass;
}
As far as I understood vcl(7), this means:
1. fetch the object from cache (implicit in the fact that we're inside
vcl_hit)
2. set ttl to 0s, expiring it (so next requests will fetch new content)
3. pass to backend (so *this* request see new content)
Does this do what I expect it to do?
Yes, this configuration does indeed do what you expect (purge the item, go
get a fresh one from the backend)
Is there a way to avoid hitting the backend twice?
You're only hitting the backend once if you're running the code from vcl_hit
Is there a way to do that in vcl_recv?
Not really, but see our shortcut above
(I guess not, since there's no obj object available yet, there)
I guess I could use purge_url(...), except I have virtual hosts and it
wants a regexp and req.url could contain some special char (could it?).
We tried with purge_url but it was just too hard and didn't want to do
what we expected. We've had good results with our configuration above.
Hope this helps,
regards,
Darryl Dixon
Winterhouse Consulting Ltd
http://www.winterhouseconsulting.com
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: honoring browser reload request
in vcl_recv, we shortcut and send such requests straight to lookup:
/* Honour Cache-Control: and Pragma: ... */
if (req.http.Pragma ~ .*no-cache.* || req.http.Cache-Control ~
.*no-cache.*) {
lookup;
}
...and then in vcl_recv we do similar to you:
Bother, of course I meant: ..and then in *vcl_hit* we do similar to you... :)
/* Honour Cache-Control: and Pragma: ... */
if (req.http.Pragma ~ .*no-cache.* || req.http.Cache-Control ~
.*no-cache.*) {
set obj.ttl = 0s;
pass;
}
regards,
Darryl Dixon
Winterhouse Consulting Ltd
http://www.winterhouseconsulting.com
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Varnish Questions
Hello list,
I was about to setup another squid install for a drupal site that is going
to be getting some high traffic and I found varnish. I think that product
is really great but I am having some issues.
First hardware.
I have varnish and the web server running on the same quad core dual xeon
box 8gb of ram on debian. I have used the debian package to install varnish
and it installed version1.0.2-2
There is a database for the site running on another box.
Here are my 2 questions, I hope someone out there can point me in the right
direction.
1. connection reset issues
I ran
siege -c 250 -r 1000 -i -d 1 http://myip
This is a sample of the output I get
HTTP/1.1 200 0.41 secs:5548 bytes == /
HTTP/1.1 200 0.41 secs:5548 bytes == /
HTTP/1.1 200 0.42 secs:5548 bytes == /
HTTP/1.1 200 0.41 secs:5548 bytes == /
Error: socket: read error Connection reset by peer sock.c:455: Connection
reset by peer
Error: socket: read error Connection reset by peer sock.c:455: Connection
reset by peer
Error: socket: read error Connection reset by peer sock.c:455: Connection
reset by peer
Error: socket: read error Connection reset by peer sock.c:455: Connection
reset by peer
Error: socket: read error Connection reset by peer sock.c:455: Connection
reset by peer
HTTP/1.1 200 1.17 secs:5548 bytes == /
HTTP/1.1 200 1.94 secs:5548 bytes == /
HTTP/1.1 200 0.63 secs:5548 bytes == /
HTTP/1.1 200 0.63 secs:5548 bytes == /
HTTP/1.1 200 0.62 secs:5548 bytes == /
At the end of the run I get Availability of around 45% If I run siege
directly to the webserver, I get an Availability of 98%. (it also takes
longer)
2. caching pages
I have updated content on my main site, and would like to clear the varnish
cache, I telnet into the management interface and run purge * (I also tried
purge *. , purge .* , purge *.*) I then clear my browser cache, and refresh
the page, I get the old page. If I visit the server directly, I get the new
page?
Below is my vcl.conf file I have comment out the cookie part because I would
like it to pass those requests to the webserver. (I guess it could cache
the front page)
backend default {
set backend.host = 10.10.0.10;
set backend.port = 81;
}
sub vcl_recv {
if (req.request == POST) {
pipe;
}
# force lookup even when cookies are present
#if (req.request == GET req.http.cookie) {
#lookup;
#}
if (req.request == GET req.url ~ \.(gif|jpg|swf|css|js)$) {
lookup;
}
}
sub vcl_fetch {
# force minimum ttl of 180 seconds
if (obj.ttl 180s) {
set obj.ttl = 180s;
}
}
Thanks for any help someone can give.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Varnish Questions
Hello list, Hi Jack, 1. connection reset issues Can't comment specifically on these, but your varnish version is very old. 1.1.2 is good and stable for us, and -trunk is apparently pretty stable, too... 2. caching pages I have updated content on my main site, and would like to clear the varnish cache, I telnet into the management interface and run purge * (I also tried purge *. , purge .* , purge *.*) I then clear my browser cache, and refresh the page, I get the old page. If I visit the server directly, I get the new page? it's 'url.purge' in 1.1.2, not sure about your version. Below is my vcl.conf file I have comment out the cookie part because I [...snip...] It's important to know/remember that the vcl you write does not *replace* the default vcl, it just runs first, unless you specifically return a different action (eg, lookup, pass, etc). The cookie stuff you hashed out will still run in the default vcl afterward with your current setup. See: http://varnish.projects.linpro.no/wiki/VCLExampleDefault ...for more information on this (be aware the default presented there is probably not correct for your current version). Thanks for any help someone can give. You're welcome ;) regards, Darryl Dixon Winterhouse Consulting Ltd http://www.winterhouseconsulting.com ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
