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