OOM command not allowed when used memory > 'maxmemory'

In an AI application, this can stop generation jobs, rate-limit updates, session writes, or agent checkpoints. Do not immediately choose a more aggressive eviction policy: deleting a cached response is different from deleting queue or workflow state.

First: identify what Redis is storing

Inventory key groups and owners:

• disposable model-response cache;
• sessions and authentication state;
• request, token, or cost counters;
• background job queues;
• agent checkpoints and locks;
• pub/sub or stream data.

If durable and disposable workloads share one instance, the safest fix may be separation rather than a global eviction change.

Inspect memory safely

Use read-only diagnostics appropriate to your managed service:

redis-cli INFO memory
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy
redis-cli MEMORY STATS

Avoid broad production key scans that block or transfer excessive data. Use cursor-based scanning, provider dashboards, sampling, and application key prefixes. Do not expose cached prompts or user data while debugging.

Understand the cause

Common causes include missing TTLs, unbounded conversation or tool payloads, queue backlog, retained stream entries, oversized values, a memory limit below the working set, or fragmentation. Check whether the increase is gradual, release-related, tenant-specific, or tied to a failed worker fleet.

Choose eviction by workload

An LRU/LFU policy can be suitable for a purely disposable cache. A no-eviction policy may be safer for queues and coordination because failure is visible rather than silently deleting state. The exact policy names and behavior depend on the Redis version and managed provider; verify current documentation.

Never rely on eviction to clean up job records that require explicit lifecycle handling.

Remediation sequence

1. Stop uncontrolled growth or pause the offending producer if safe.
2. Restore worker capacity when queue backlog caused the increase.
3. Add TTLs only to keys that are genuinely disposable.
4. Bound prompt, response, and agent-state payloads.
5. Trim streams and completed-job history through documented lifecycle rules.
6. Separate cache from queue/session workloads.
7. Increase capacity only after understanding growth.

Deleting all keys is not a production fix. It can log users out, reset quotas, lose jobs, and duplicate consequential agent actions.

Prevent recurrence

Monitor used memory, fragmentation, evictions, rejected writes, queue depth, largest key groups, and growth by tenant. Alert before the hard limit. Load-test rate limits and job spikes, not only steady cache traffic.

Queue handlers must be idempotent because recovery can redeliver work. The Redis vs Memcached guide explains why reliability requirements should determine instance boundaries.

Production rule

Use Redis as a bounded operational component, not an unowned dumping ground. Separate durable truth into the primary database, keep large files in object storage, and make cache, queue, and agent-state retention explicit. Connect the fix to AI Data Infrastructure and AI Operations.