Varnish is restarting frequently

[Daniel Schledermann]

 On Wed, 9 May 2012 18:41:37 +0530, Sparsh Gupta wrote:

>> It would be more effective for you to use file-storage instead of
>> malloc + swap. It does not matter wether you are using SSD or normal
>> harddrives.
>
> By efficient do you also mean fast? Unfortunately the only thing I
> care is response times out of these boxes. I am happy to get more RAM
> if needed but got to have best possible performance/response times 
> out
> of them (both both Hits, misses and passed queries). Are you sure 
> file
> will be better than malloc + swap as far as speed / response times 
> are
> concerned

 Well.. there is a small performance gain by using malloc over file, 
 provided that your cache will fit in RAM. Malloc+swap is slower than 
 file. I'm quite sure of this. The precise effiency will vary from kernel 
 to kernel.



>>             -p thread_pools=32
>>             -p thread_pool_min=25
>>             -p thread_pool_max=4000
>>
>> This is waaaay to high. 2 or 4 threadpools is sufficient, and
>> threadpool_max is also very high. It makes for a total of 128000
>> total maximum threads, which I very much doubt that you need.
>
>  Thanks for the comments. I will try with lower values. What are the
> downsides of high values? My instances do around 4000req/second (max)
> and at times, a bunch of them reaches backend due to poor hit rate
> currently. I added extra threads to ensure they never choke the
> server, but if there is a downside, I will relook. Any way I can find
> out the best numbers for my instance (in my live environment, what
> should I look to find how to further tweak things)

 The old way of configuring threadpools was one per CPU-core. I believe 
 however that it has been proven not to matter. 2 or 4 thread pools will 
 be sufficient, regardless of the number of cores. Too many threads can 
 chew up some RAM if you are doing expensive operations such as ESI. You 
 can also have problems with exhausting your filedescriptors. Thats the 
 main downside AFAIK.