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 <[email protected]>, 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
> [email protected] | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-misc mailing list
[email protected]
http://lists.varnish-cache.org/mailman/listinfo/varnish-misc
