/amazon-elasticache

Slot Memory Imbalance Detection

When to use: Uneven memory across cluster nodes (one node near DatabaseMemoryUsagePercentage ceiling while siblings are well below), suspected hash-tag bundling, or planning resharding and want to identify which slots carry the most memory. Valkey 8.0+ cluster mode enabled only. When not needed: Cluster-wide uniform memory pressure (troubleshooting.md Memory Pressure). Per-node CPU imbalance without memory skew (hot-key-detection.md). Serverless (abstracts slot topology).

Preconditions

Engine version gate

CLUSTER SLOT-STATS with MEMORY-BYTES requires Valkey 8.0+ (this is a Valkey-only feature and is not available on any Redis OSS engine version). Verify:

valkey-cli -h <endpoint> -p 6379 --tls INFO server | grep -E 'redis_version|valkey_version'

Pre-Valkey 8.0 degraded workflow: 1) Per-shard CloudWatch triage (Tier A). 2) valkey-cli --bigkeys against the hot shard's primary. 3) CLUSTER KEYSLOT <key> per big-key candidate to find the heavy slot. 4) MEMORY USAGE <key> on top candidates for byte confirmation. Takes 15-30 minutes on a 10M-key shard vs. subsecond with SLOT-STATS.

Feature flag

cluster-slot-stats-enabled must be yes in the parameter group. This is a Valkey 8.0+ parameter; verify it is available in your cache parameter group before relying on it. Note: This parameter may not appear in ElastiCache parameter groups documentation. It may be enabled by default or not exposed as a configurable parameter. CONFIG GET is restricted on all ElastiCache caches; check via the AWS API:

aws elasticache describe-cache-parameters \
  --cache-parameter-group-name <parameter-group-name> \
  --query "Parameters[?ParameterName=='cluster-slot-stats-enabled'].ParameterValue" \
  --output text --region <region>

If missing or no, enable via parameter group modification (zero-downtime on most configs).

Command availability

Tier A: Triage with CloudWatch

Step 1: Per-node memory utilization

aws cloudwatch get-metric-statistics \
  --namespace AWS/ElastiCache \
  --metric-name DatabaseMemoryUsagePercentage \
  --dimensions Name=CacheClusterId,Value=<node-id> Name=CacheNodeId,Value=0001 \
  --start-time <24h-ago> --end-time <now> \
  --period 300 --statistics Maximum --region <region>

Run for each primary (discover with CLUSTER SHARDS).

Stop condition: If all primaries are within 10 percentage points, memory is distributed uniformly. No slot-imbalance problem. Route to troubleshooting.md Memory Pressure if overall memory is high.

Proceed if spread is >15 percentage points (e.g., one node at 85%, another at 45%).

Step 2: Confirm persistence

Query BytesUsedForCache per node over 24h (node-based, using CacheClusterId and CacheNodeId dimensions). For serverless, use BytesUsedForCache with the ServerlessCacheName dimension. A stable gap over hours is real. A 10-minute transient is not.

Tier B: Narrow with CLUSTER SLOT-STATS

Step 1: Identify memory-heavy slots

valkey-cli -h <endpoint> -p 6379 --tls \
  CLUSTER SLOT-STATS ORDERBY MEMORY-BYTES DESC LIMIT 20

A single dominant slot (order of magnitude above peers) is a memory hotspot.

Cost and impact

Subsecond, negligible impact. Reads stats Valkey already maintains. Safe at any time on production.

Step 2: Map hot slots to shards

Use CLUSTER SHARDS output to map each hot slot to its primary. Hot slot on the already-hot node confirms the story.

Step 3: Correlate with key count

valkey-cli -h <endpoint> -p 6379 --tls CLUSTER COUNTKEYSINSLOT <hot-slot>

Stop condition: If top 20 slots are within 2x of each other, no single hot slot. Consider rebalancing slot assignments rather than application-level remediation.

Tier C: Verify with key-level inspection

Step 1: Sample keys from the hot slot

valkey-cli -h <endpoint> -p 6379 --tls \
  CLUSTER GETKEYSINSLOT <hot-slot> 200

Step 2: Identify hash-tag pattern

Look for common {...} hash-tag prefix in returned keys. If most keys are {tenant_42}:session:*, {tenant_42}:cache:*, tenant 42 has concentrated its keys into a single slot.

Step 3: Measure top keys

valkey-cli -h <endpoint> -p 6379 --tls MEMORY USAGE <key>

If one key dominates bytes, this is a big-key problem (route to big-key-hunter.md). If memory is evenly distributed, hash-tag concentration is the cause.

Remediation

Pick based on Tier C classification:

Cross-links

• Hot slot also has high CPU: hot-key-detection.md Tier B (same SLOT-STATS, ORDERBY CPU-USEC axis)
• Specific key in slot is oversized: big-key-hunter.md
• Concentration is prefix-based, not slot-based: key-space-distribution-by-prefix.md
• Alarm patterns for memory imbalance: alarm-packs.md