Best Practices - Suggestions Request

[ADOFMS Admin, SteveOC]

>> I am running version 1.0.4
>> Is that too old to use?
>> If so, i will update it immediately.
>>   
>>     
>
> Sorry for missing out on the release date. It is version 1.0.4 released 
> on May 20, 2007.
>
>   
hmm ...

I am running 1.0.4 as well, but I am building mine from the SVN
repository rather than from the 1.0.4 tarball that was available at the
time through the gentoo ebuilds.

I originally just did an emerge to get varnish running, but found some
issues with VCL, and it was suggested that I get the SVN release and try
some VCL extensions.

My SVN update was from the 29th May 2007, and there was sufficient
functionality difference between the SVN source compared to the
origiinal 1.0.4 release. Not a whole lot of code, but it added a few VCL
commands that got the job done for me, which were not working in the
original 20-May  1.0.4 release.

In my case, the following VCL code requires the SVN 1.0.4 release :

        sub vcl_hash {
             set req.hash += req.url;
             set req.hash += req.http.host;
             set req.hash += req.http.cookie;
             hash;
         }

Not suggesting that the SVN code would cure your crashes - but it
definitely gives you a better VCL environment than the stock release.

I havnt seen ANY stability or performance, or memory leak issues with
Varnish. My system gets hit hard enough, but in my case, varnish is only
serving smallish chunks, and has no constraints on disk space or RAM. My
main machine runs apache + php + mysql + varnish + a number of cronjobs
written in C, and even during very busy periods, it never goes to swap.
It has 'only' 4GB of physical RAM, and varnish is compiled in 64bit
mode. Not a problem on my setup, but every case is different.

When it comes to your situation with varnish dying - that really sounds
like a resource problem from the outside here. Hard to tell without
having your system right in front of me and watching what it is doing.
ie - I would be very keen to run one of your varnish instances under gdb
and try to simulate the point where it is dying, and see if you can find
a pattern there ??. Or at least run it from a console under gdb and let
it go for several days and hope that it crashes whilst in the debugger. 

Whilst commercial reality dictates that we need to find workarounds to
make things work from one day to the next (and that applies to
EVERYTHING) - Id encourage you to keep looking and find out exactly why
the process is stopping. Even if a new release of code fixes the
problem, its good for you to know why the old setup didnt work, and the
new one does. Keep looking :)

Sounds like Dag's latest code (which drops items from cache on a LRU
scheme as memory fills up)  is more likely to solve your problems longer
term. I assume that comes out first in SVN, so thats another good reason
to try the SVN release.