To properly evaluate your 512MB cache configuration, you'll need to monitor key metrics through Varnish's built-in tools:

varnishstat -f MAIN.n_lru_nuked
varnishstat -f MAIN.s0.c_bytes
varnishstat -f MAIN.s0.g_bytes

Cache Evictions (n_lru_nuked): This counter shows how many objects were removed from cache due to space constraints. A high value indicates your cache might be undersized.

# Sample output:
MAIN.n_lru_nuked        12345         0.30 LRU nuked objects

Current Cache Usage (c_bytes): Shows actual memory used by cached objects.

Total Cache Space (g_bytes): Displays your configured cache size (512MB in your case).

Create a monitoring script that periodically checks these values:

#!/bin/bash
CACHE_USAGE=$(varnishstat -1 -f MAIN.s0.c_bytes | awk '{print $2}')
CACHE_SIZE=$(varnishstat -1 -f MAIN.s0.g_bytes | awk '{print $2}')
EVICTIONS=$(varnishstat -1 -f MAIN.n_lru_nuked | awk '{print $2}')

USAGE_PERCENT=$((100*$CACHE_USAGE/$CACHE_SIZE))

echo "Cache usage: ${USAGE_PERCENT}%"
echo "Evictions: $EVICTIONS"

Consider these thresholds:

• Consistent cache usage >90% with frequent evictions → Increase cache size
• Usage consistently <50% → You may reduce cache size
• Eviction rate spikes during traffic peaks → Consider temporary size increase

For graphical monitoring, install VAC:

# Ubuntu/Debian
sudo apt-get install varnish-agent
sudo service varnish-agent start

Access the web interface at http://your-server:6085

Add logging to your VCL to track cache misses:

sub vcl_miss {
    std.log("Cache miss for: " + req.url);
}

For a data-driven approach to sizing:

1. Monitor for 1-2 weeks to capture traffic patterns
2. Calculate average object size using varnishhist
3. Adjust cache size based on working set analysis

varnishhist -b | awk '{print $1}' | sort -n | uniq -c

---

To properly evaluate your 512MB cache configuration, these are the critical metrics to monitor:

varnishstat -1 -f MAIN.n_lru_nuked -f MAIN.n_lru_moved -f SMA.s0.c_bytes

Key parameters explanation:

• SMA.s0.c_bytes: Current bytes allocated in storage
• MAIN.n_lru_nuked: Objects forcibly evicted due to space constraints
• MAIN.n_lru_moved: Objects moved within LRU list (healthy cache activity)

Here's what the numbers tell you:

Scenario	Healthy Signs	Problem Indicators
Cache Size Adequacy	SMA.s0.c_bytes stable at ~80-90% of capacity	Consistently hitting 100% capacity
Eviction Rate	MAIN.n_lru_nuked near zero	High MAIN.n_lru_nuked with low traffic changes

For regular monitoring, use this bash script:

#!/bin/bash
CACHE_SIZE=512
WARNING_THRESHOLD=90 # Percentage

output=$(varnishstat -1 -f MAIN.n_lru_nuked -f SMA.s0.c_bytes)
bytes_used=$(echo "$output" | awk '/SMA.s0.c_bytes/ {print $2}')
nuked=$(echo "$output" | awk '/MAIN.n_lru_nuked/ {print $2}')

percent_used=$((bytes_used * 100 / (CACHE_SIZE * 1024 * 1024)))
echo "Cache usage: $percent_used% (${bytes_used} bytes)"
echo "Objects evicted: $nuked"

if [ $percent_used -gt $WARNING_THRESHOLD ]; then
  echo "WARNING: Cache usage exceeds $WARNING_THRESHOLD% threshold"
fi

For deeper insight, examine the Varnish Shared Log:

varnishlog -g request -q "VCL_Log:CacheFull" -i BereqURL

This shows which URLs are being evicted due to cache constraints. Combine with -b for backend requests or -c for client requests.

For production environments, consider implementing dynamic sizing:

varnishadm param.set workspace_client 128k
varnishadm param.set workspace_backend 128k
varnishadm param.set lru_interval 10

These parameters help optimize memory usage within your fixed 512MB allocation.

Create a Grafana dashboard with these key queries:

# Cache Utilization
deriv(varnish_main_SMA_s0_g_bytes{instance="$instance"}[1m])

# Eviction Rate
irate(varnish_main_MAIN_n_lru_nuked{instance="$instance"}[5m])

# Hit Ratio
sum(irate(varnish_main_MAIN_cache_hit{instance="$instance"}[5m])) / 
(sum(irate(varnish_main_MAIN_cache_hit{instance="$instance"}[5m])) + 
 sum(irate(varnish_main_MAIN_cache_miss{instance="$instance"}[5m])))