Confirm which cache service your Magento version actually uses
“Redis is full” is often used as shorthand for a cache-related incident, but the installed service and Magento version must be established first. Cache backends and supported configuration change over time. Some stores use Redis, some use Valkey, and others use different arrangements. Midoriweb checks the actual implementation before applying guidance written for another release.
Adobe’s cache configuration documentation records version-specific changes, including Valkey replacing Redis in CLI tooling from Commerce 2.4.9. That does not justify blindly converting an existing store during an incident. It means the diagnosis and any proposed configuration must match the installed software and supported deployment model.
This guide explains how to investigate memory pressure in a Redis-backed Magento environment. The operational method is also useful when discussing an equivalent cache service, but commands, compatibility and configuration must be verified for that service.
Identify what the affected instance stores
Before changing memory limits or eviction behaviour, establish the role of the instance. Is it used for cache data, sessions or several applications? Are different logical databases or prefixes involved? Which other processes share the host’s memory? These details determine the consequences of an apparently simple cache intervention.
Rebuildable cache data and customer session state are not interchangeable. A broad flush may remove information beyond the pages you intended to refresh. A logical database separation also does not automatically establish independent capacity or failure boundaries. Document the real service topology rather than relying on naming conventions.
Midoriweb would map Magento’s effective configuration to the running service, then identify the affected workload. Our full-page cache guide covers cache effectiveness; this article concentrates on memory pressure and its operational consequences.
Compare configured limits with actual memory behaviour
Collect memory usage, configured limits, eviction activity, errors and host-level pressure over the incident period. A single reading after a restart can miss the growth pattern that caused the failure. Compare normal traffic, catalogue updates and peak periods using the same measurement definitions.
Redis documents how key eviction behaves when a configured memory limit is reached. Different policies have different consequences. Do not select a policy solely because it removes an error message; establish what data can be discarded and how the application behaves when it is missing.
The cache dataset is not the only consumer of system memory. Service overhead and other processes need headroom. Raising a limit without considering the host can move the failure from the cache service to the operating system or another essential component.
Investigate growth, churn and unusual key patterns
Look for changes in data volume and turnover. A new cache-key dimension, large catalogue expansion or extension storing unusually large values can change memory demand. Frequent invalidation followed by rebuilding can also create heavy work even when the steady-state dataset appears reasonable.
Compare the timing with deployments, promotions, imports and traffic sources. If memory grows only during a particular workflow, inspect that workflow’s cache use before assuming the store simply needs a larger server. A configuration that creates many near-duplicate keys may require a design correction rather than permanent capacity growth.
Use diagnostic methods appropriate to a busy production service. Avoid expensive broad scans or commands without understanding their impact. A controlled sample and existing monitoring may provide enough evidence to identify a pattern without adding substantial load during the incident.
Relate cache pressure to Magento symptoms
Customers may experience slower pages, intermittent errors or session problems depending on what the service holds and how the application handles failures. Correlate the exact Magento error with service events. A slow storefront alone does not prove that cache memory is the cause.
When cache effectiveness falls, the application and database may perform more work. That can make PHP worker saturation or database latency appear at the same time. Our PHP-FPM capacity guide explains the worker layer, and the high TTFB guide provides a wider response-time framework.
Build a sequence: what changed first, which resource reached a constraint and which customer requests then deteriorated? This is more useful than treating every red monitoring chart as an independent fault requiring its own restart.
Choose recovery according to the data and cause
A recovery may involve reducing an abnormal workload, correcting cache behaviour, adjusting justified capacity or separating workloads. Each option needs an explanation of what it changes and how it can be reversed. The right immediate action may differ from the long-term improvement.
Do not use a broad flush as the default response to memory pressure. It can remove sessions or force a surge of cache rebuilding, depending on the architecture. If invalidation is necessary, establish the intended scope and the expected load during warm-up before executing it.
For capacity changes, consider the host and neighbouring services together. Confirm that the additional allocation exists and that the relevant limits will persist through service restarts and deployments. A temporary runtime adjustment that disappears later can create a recurring incident with misleadingly different symptoms.
Verify stability through normal and busy periods
After a correction, observe memory growth, evictions, errors and application response under representative traffic. A quiet ten-minute period is not enough to verify a problem that previously occurred during a nightly import or campaign peak. Revisit the specific workflow that triggered the incident.
Check customer journeys affected by the original failure, including account and checkout behaviour if sessions were involved. Confirm cache hit behaviour where relevant and ensure that prices, stock and personalised content remain correct. Performance improvement must not come from serving one customer’s private state to another.
Monitoring should have a useful warning threshold and a clear owner. Record the service role, normal range and escalation procedure so the next alert leads to diagnosis instead of an improvised flush. Include the expected behaviour during planned bulk operations.
How Midoriweb investigates cache infrastructure
Our performance and infrastructure services connect cache behaviour with Magento requests, PHP execution and database work. Internal service diagnosis requires an agreed access scope; it cannot be established from a public page-speed score alone. The Performance Investigation packages explain the distinction between external assessment and deeper investigation.
A useful brief includes the Magento version, cache service and role if known, observed error, timing and recent changes. The outcome should distinguish immediate recovery from capacity planning or code changes, with evidence for each recommendation. We do not prescribe a universal memory size because catalogue, traffic and application behaviour differ substantially between stores.
Cache memory questions
Does more memory always fix the problem?
No. It may provide necessary capacity, but abnormal key growth, poor cache behaviour or a competing host workload can require a different correction.
Is it safe to flush the cache service?
Only after identifying its data and scope. The same service may hold more than rebuildable page cache, and rebuilding can create additional application load.
Should every Magento store use the same Redis settings?
No. Verify the version, supported backend, workload and service role. Settings copied from another architecture can produce unsuitable behaviour even when they are syntactically valid.