Redis maxmemory reached: eviction, leaks, and dangerous fixes

Redis maxmemory reached: eviction, leaks, and dangerous fixes is easier when you treat it as an evidence problem instead of a command-memory test. The goal is not to type the cleverest one-liner. The goal is to identify the failing layer, preserve a recovery path, and make the smallest change that proves or rejects a hypothesis.

Start with a precise question

The task is understanding Redis memory pressure. Write down what is known: the exact host, user-visible symptom, first observed time, and most recent change. “SSH is broken” is too broad. “TCP reaches port 22, but public-key authentication fails for deploy after yesterday's key rotation” is a tractable problem.

The first command set

Run the smallest read-only checks that expose state:

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

Do not paste the output into a random fix. Read each command as a question. Does the name resolve? Is the port listening? Which identity is selected? Which process owns the resource? What happened immediately before the error?

Interpret before changing

Know whether Redis is a cache or a durable queue before enabling eviction; the same policy can be safe for one and data loss for the other.

A useful investigation moves from outside to inside:

1. Confirm the symptom from the same path a user takes.
2. Check name resolution and network reachability.
3. Confirm the expected process is running and listening.
4. Read the narrowest relevant logs and timestamps.
5. Inspect dependencies such as disk, memory, certificates, and databases.
6. Form one explanation that accounts for all observations.
7. Make one reversible change and retest the original symptom.

Common mistakes

Restarting first. A restart can restore service, but it also destroys process state and turns a diagnosable failure into a story. Capture status, recent logs, resource use, and the current configuration first when time allows.

Changing several layers at once. Editing DNS, firewall rules, service config, and credentials in the same attempt makes success impossible to explain and failure harder to unwind.

Treating a warning as the root cause. Production logs are full of old warnings. Correlate by timestamp and request path; the loudest line is not automatically causal.

Skipping the rollback. Before a config edit, know the previous file, command, image, or package version and how to restore it from the current session.

Turn the fix into an operating check

After service is restored, write a small check that would have exposed the condition earlier: certificate days remaining, free disk and inodes, failed systemd units, connection-pool saturation, or a real application health request. Monitoring should observe the failure mode, not merely prove that a VM responds to ping.

Doing the same investigation with Tryssh

This workflow is what Tryssh is designed to accelerate. Ask the copilot the precise question, and it can run the read-only sequence over SSH, interpret the combined output, and propose the next step. The visible terminal remains a separate channel. If the repair changes state, Tryssh displays the exact command and waits for approval.

That division matters: diagnosis benefits from speed and breadth; production changes benefit from friction and review. Download Tryssh for macOS and use the first 200 agent turns on a real host—no card required.

Related operating guides

Keep the journalctl guide nearby for service evidence, and review the SSH hardening checklist before changing remote access. Together they cover the observability and recovery assumptions behind most server repairs.