Proper cache allocation (nuked objects but sm_bfree)

[Damon Snyder]

Hello,
I'm pretty sure we need to allocate a bigger cache for our varnish instance,
but I'm trying to understand what metrics we should be looking at to
determine how severely under allocated we are (and confirm that we need more
space). I don't want to just throw more memory at it without under standing
more about what is being allocated. I would also be interested to know if we
can't reclaim some object space to prevent nuking by doing some runtime
parameter tuning.

Here are some basic stats about the system: 4 core Centos box with kernel
2.6.18, 8GB of RAM, and a 64GB Intel X-25E SSD. And the varnishstat -1
output and startup options are here: http://pastebin.com/XmM0pMKv. We are
running varnishd (varnish-2.1.3 SVN 5049:5055).

According to the docs, the key statistic to look at is n_lru_nuked. This
value is constantly increasing. Every time you run 'varnishstat -1 -f
n_lru_nuked' the value changes. However, the value of sm_bfree seems to
always show some space available:

varnishstat -1 -f n_lru_nuked,sm_bfree,sm_balloc
n_lru_nuked         135193763          .   N LRU nuked objects
sm_balloc          5468946432          .   bytes allocated
sm_bfree           2047246336          .   bytes free

Does sm_bfree mean that we aren't filling the allocated cache? But if so,
why do we see the value of n_lru_nuked going up? The n_lru_nuked going up
also seems to be confirmed by the IO that we are seeing on the system. I
assume this is probably the OS shuffling objects to and from disk.

Any suggestions would be appreciated. Thanks,
Damon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20110907/7d054377/attachment-0003.html>