Best Practices - Suggestions Request

[Poul-Henning Kamp]

In message <4680C2E3.2010108 at iamcool.net>, Anup Shukla writes:

>I understand that running both services on the same server is probably a 
>bad idea, but due to time constraints i had no option but to go ahead 
>with the current setup.

It is not an obviously bad idea, and in many cases it is likely to
work quite well.

If it works for you, be happy about the saved hardware :-)

>The problem is, the varnish process dies every 7 - 10 days, and i have 
>to manually restart it.
>One solution would be to write a script which monitors varnishd and 
>starts it if not running.
>
>I, however, would like to understand "Why it dies"... I have been 
>monitoring the servers for long times at a stretch and it seems that a 
>flood of requests for big files (100+ MB) seems to get varnishd down. I 
>cannot be very sure about this though.

It's not much to go from, but here are some ideas:

1. Do you have enough storage space ?  By default Varnish takes a
fixed fraction of the free space in /tmp, that may not be enough.
Use the "-s" argument to specify a different directory and/or how
much space you want to use.

>Another thing is, is it possible to configure varnish such that it adds 
>a custom header to the response (for example, the ip of the server which 
>processed the request or any custom value). This would greatly assist in 
>knowing which server served the request.

I'm working on VCL support for such headermodification right now.

>Is it possible to make varnish refuse connections from the clients it it 
>detects that the backend has stopped responding and start servicing 
>again the moment it detects that the backend is up?

At some point we will be able to, but not right now.

>Sorry, if i have asked too many questions at one go.

You're welcome :-)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.