a couple of questions about -spersistent

Ken Brownfield kb+varnish at slide.com
Thu Jun 17 22:17:19 CEST 2010


We use five 300GB SSD volumes:

	-h classic,524287
	-p between_bytes_timeout 15s
	-p cache_vbe_conns on
	-p cli_buffer 32768
	-p default_grace 0s
	-p default_ttl 0s
	-p err_ttl 0s
	-p first_byte_timeout 15s
	-p listen_depth 8192
	-p lru_interval 3600
	-p max_restarts 2
	-p pipe_timeout 15s
	-p purge_dups on
	-p rush_exponent 32
	-p sess_timeout 15s
	-p thread_pools 8
	-p thread_pool_min 32
	-p thread_pool_max 8192
	-p thread_pool_stack 262144
	-s persistent,/cache/sdb/varnish,240G
	-s persistent,/cache/sdc/varnish,240G
	-s persistent,/cache/sdd/varnish,240G
	-s persistent,/cache/sde/varnish,240G
	-s persistent,/cache/sdf/varnish,240G

I'm /pretty/ sure I also tested with a single -s option, but I (embarrassingly) may not have.

Yeah, those tests look solid.  I'll run the tests when I'm back at my build machine.

Thanks,
-- 
Ken

On Jun 17, 2010, at 12:55 PM, Poul-Henning Kamp wrote:

> In message <1CA68FE7-95D5-4AE2-A66E-C107D7233B34 at slide.com>, Ken Brownfield wri
> tes:
> 
>> CHK(0x7f520fa2b080 SILO 0x7f51cf3e0000 SILO) = 3
> 
> What does your -spersistent option look like ?
> 
>> Is it possible to create a unit test for this, where the child is shut 
>> down in a way that properly flushes non-full segments?  I'd be willing 
>> to write one as a starting point.
> 
> We have that, check the varnishtest/tests/p*.vtc files.
> 
> -- 
> 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.





More information about the varnish-misc mailing list