Re: Create worker thread failed 12 Cannot allocate memory
[EMAIL PROTECTED] wrote: i686 GNU/Linuxi have also set the ulimit value as 50...and worker proces 2048 but still the same error ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc Correct me if Im wrong - but is it possible to address more than 4GB of RAM with a 32bit linux kernel ? ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: Best Practices - Suggestions Request
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.
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
My Varnish project
Hello, Thank you very much for an excellent product. I wish to use Varnish cache as a front end to my system, but I have some problems in using it, and the way forward probably involves hacking the code. I will run this past you all first to get your opinion. Background: Our site (http://www.adofms.com.au) is a traditional LAMP application, using PHP / Apache / MySQL. Users login to the application, and upon login, a session is created in the database, and a cookie is set for the user. The ADOFMS system contains a large number of Units - Fuel Card - Vehicles for the users to maintain. When a user logs in and gets a valid session, they can only see the vehicles and cards associated with their unit. So far so good. Problem that I have is that the session identification is done entirely by the cookie - I do not repeat the session ID in the URL. So for example - User number 1 visits : http://www.adofms.com.au/vehicles.php - and gets a list of vehicles that they own. User number 2 visits http://www.adofms.com.au/vehicles.php - and they get a different list of vehicles to what user 1 sees. So, of course, with Varnish, the vehicles.php output from user 1 is cached, and presented to user 2. This is very quick and efficient, but not what we want. I need things to be cached on a session by session basis. I believe I have 3 options here : 1) Re-write the whole PHP application to repeat the session ID as part of every URL in the system. That is do-able, but boring. 2) Cook up some VCL code to cache pages on a per-session basis, by appending the req.http.Cookie value to the URL before it is stored in the cache, and then doing the same thing when looking up the cache. VCL does not easily allow this to happen though Correct me if I am wrong. 3) Hack the source code of Varnish to use the session ID (from the cookie) to segregate cached results by session. I am going to have a go at method 3) anyway, but would like your opinion before starting out on this adventure :) I would think its not too hard, since I know exactly what I am trying to achieve, which is often half the battle when coding. I have some similar enhancements that would suit my application well. I will explain them here: Example for extra enchancement : I have a URL such as http://www.adofms.com.au/vehicles.php?op=viewid=12345 - Displays the full details of vehicle ID 12345, which can generate a lot of SQL calls to create. I would love to cache the results of this on a per user basis. If the user updates the vehicle - the naming conventions in this application guarantee that the backend receives a HTTP POST request with a URL of : http://www.adofms.com.au/vehicles.php?op=update .. followed by a call to redisplay the record, which in this case is http://www.adofms.com.au/vehicles.php?op=viewid=12345refresh=1 Now - If I am going to hack the Varnish code anyway, I can get around this by intercepting POST requests that have an op=update GET variable set, and an id=some value POST variable set .. and if so, remove the existing vehicles.php?op=viewid=some value entry from the cache. Again, running this idea past you for feedback. I understand that such a change would be very specific to our application and the way it works, but thats OK with me. Another alternative would be to make VCL a little more powerful - a couple of simple ways of changing the key value for the obj variable would go a long way I think .. and the ability to grab GET and POST variables would be very handy too. Would appreciate your thoughts on these issues. Thank you Steve OConnor ADOFMS Chief Developer ___ varnish-misc mailing list varnish-misc@projects.linpro.no http://projects.linpro.no/mailman/listinfo/varnish-misc
Re: My Varnish project
Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], admin writes:
Poul-Henning Kamp wrote:
The man pages for VCL do mention a vcl_hash interface, but it says it's
not implemented yet. Wasnt sure what it was, but I assume that is called
whenever the hash value for the key of the object is calculated ?
Yes.
Thanks
I have this now :
sub vcl_hash {
req.hash += req.http.cookie;
}
and get this when I run varnishd :
(/etc/varnish/adofms.vcl Line 22 Pos 14)
req.hash += req.http.cookie;
-
I think I need a more up to date source file ?
When I emerge varnish , it fetches and builds :
mirror://sourceforge/varnish/varnish-1.0.4.tar.gz
Is there a newer version in SVN or something ?
___
varnish-misc mailing list
varnish-misc@projects.linpro.no
http://projects.linpro.no/mailman/listinfo/varnish-misc
