Flush Magento Cache roughly means: remove the cache entries Magento knows belong to Magento.

bin/magento cache:clean

bzw.

bin/magento c:c

Magento clears its own entries but leaves the underlying cache storage intact.

Flush Cache Storage instead means: Clear the entire cache storage currently used by Magento.

bin/magento cache:flush

bzw.

bin/magento c:f

Think of it as a drawer: cache:clean removes only Magento’s items from the drawer. cache:flush empties the entire drawer.

This matters with Redis, for example. If another application uses the same Redis storage, Flush Cache Storage may remove that application’s cache data too.

For normal cache maintenance, Flush Magento Cache. Flush Cache Storage is generally sufficient. The other option is more drastic and should be used only when the entire cache storage really needs to be emptied.

For temporary analysis, you can create a plugin for TypeList::cleanType() and Cache Manager::flush() . Register it in etc/di.xml:

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">

    <type name="Magento\Framework\App\Cache\TypeList">
        <plugin name="cache_trace_type_list"
                type="Vendor\Module\Plugin\CacheTrace"/>
    </type>

    <type name="Magento\Framework\App\Cache\Manager">
        <plugin name="cache_trace_manager"
                type="Vendor\Module\Plugin\CacheTrace"/>
    </type>

</config>

The plugin logs the affected cache type and call stack:

<?php

declare(strict_types=1);

namespace Vendor\Module\Plugin;

use Magento\Framework\App\Cache\Manager;
use Magento\Framework\App\Cache\TypeList;
use Magento\Framework\Filesystem\DirectoryList;

class CacheTrace
{
    public function __construct(
        private readonly DirectoryList $directoryList
    ) {
    }

    public function beforeCleanType(
        TypeList $subject,
        string $typeCode
    ): array {
        $this->writeTrace('CLEAN', [$typeCode]);

        return [$typeCode];
    }

    public function beforeFlush(
        Manager $subject,
        array $types
    ): array {
        $this->writeTrace('FLUSH', $types);

        return [$types];
    }

    private function writeTrace(string $action, array $types): void
    {
        $trace = debug_backtrace(
            DEBUG_BACKTRACE_IGNORE_ARGS,
            25
        );

        $lines = [];

        foreach ($trace as $entry) {
            $call = ($entry['class'] ?? '')
                . ($entry['type'] ?? '')
                . ($entry['function'] ?? '');

            $location = isset($entry['file'])
                ? $entry['file'] . ':' . ($entry['line'] ?? '')
                : '';

            $lines[] = $call . ' ' . $location;
        }

        $message = sprintf(
            "[%s] %s: %s\n%s\n\n",
            date('Y-m-d H:i:s'),
            $action,
            implode(', ', $types),
            implode("\n", $lines)
        );

        file_put_contents(
            $this->directoryList->getPath(DirectoryList::LOG)
                . '/cache-trace.log',
            $message,
            FILE_APPEND | LOCK_EX
        );
    }
}

If, for example, the full_page or layout cache gets cleared, the corresponding call stack is written to var/log/cache-trace.log. You can often identify whether the call originated in Magento core, a cron job or a specific extension.

It is also important to distinguish CLEAN from FLUSH. Clean removes specific Magento cache types, while flush clears the underlying cache storage.

Use this kind of tracing only while debugging and remove it afterwards. When a store keeps losing its full page cache for no apparent reason, it can quickly reveal which code is clearing the cache..

Magento may create a separate Layout Cache Eintrag for every product and store view. With 50,000 products and several store views, the number of cache entries can become very large.

The result is excessive memory usage in Redis or Valkey, even when catalog size and traffic do not seem to justify it.

Affected versions include Magento Open Source and Adobe Commerce ab Version 2.4.8 bis vor 2.4.10. Adobe provides the Quality Patch ACP2E-4908 for the issue.

I can help install the patch in your Magento 2 store or investigate other potential causes.

A block with cacheable=”false” can make the whole page non-cacheable. With Private Content, the page itself remains cacheable, while only certain user-specific sections are loaded separately and rendered dynamically.

Typical examples include the shopping cart, customer name and wishlist.

The principle is simple: Cacheable content comes from the full page cache; personal content is loaded independently.

cacheable=”false” should not be used indiscriminately just because one area of the page is dynamic. Private Content provides a cleaner solution in many cases without sacrificing full page caching for the entire page.

A simple example is a custom customer section. The PHP class provides the personalized data:

namespace Vendor\Module\CustomerData;

use Magento\Customer\CustomerData\SectionSourceInterface;

class Example implements SectionSourceInterface
{
    public function getSectionData(): array
    {
        return [
            'message' => 'Dieser Inhalt ist individuell'
        ];
    }
}

The section is then declared in etc/frontend/di.xml registriert:

<type name="Magento\Customer\CustomerData\SectionPoolInterface">
    <arguments>
        <argument name="sectionSourceMap" xsi:type="array">
            <item name="example" xsi:type="string">Vendor\Module\CustomerData\Example</item>
        </argument>
    </arguments>
</type>

In Hyvä, customer sections are available through the event private-content-loaded :

<div
    x-data="{ message: '' }"
    @private-content-loaded.window="
        message = $event.detail.data.example?.message || ''
    "
>
    <span x-text="message"></span>
</div>

The page itself stays in the full page cache. Only the customer section data is supplied separately in the browser and can vary by visitor.

One common culprit is cacheable=”false”:

<block class="Vendor\Module\Block\Example"
       name="example"
       template="Vendor_Module::example.phtml"
       cacheable="false"/>

. If such a block appears on the page, Magento treats the entire page as non-cacheable. Even an otherwise normal category or product page may then be rendered again on every request.

Especially with third-party extensions or older customizations, search for cacheable=”false”when full page caching seems ineffective. This attribute is sometimes used to render dynamic content even though other Magento mechanisms, such as Private Content , are more appropriate.

Typical cache tags look like this:

cat_p_123
cat_c_42
cms_p_5

The structure is simple: the first part identifies the entity type, while the following number is usually the entity’s Entity ID. cat_p_123 stands for product ID 123, cat_c_42 for category ID 42 and cms_p_5 for CMS page ID 5.

Magento defines these prefixes on the relevant entities, for example in product code using cat_p. The entity ID is appended to produce a unique cache tag.

If product 123 changes, Magento can invalidate cache entries carrying the tag cat_p_123 instead of clearing the entire full page cache. Varnish uses this information with the cached objects to invalidate specific content.

The tags are generated in part by Magento’s IdentityInterface and its method getIdentities(). Custom blocks and modules can also declare which data their cached output depends on.

Cacheable GraphQL requests use these tags too, allowing product, category and CMS data to be invalidated selectively.

Missing or incorrect dependencies in custom code can lead to a particularly awkward problem: The cache works, but continues to serve stale content after the underlying data changes.

For templates, Magento Template Hints can help you identify which .phtml template and block are actually used. Run the following command from the CLI and reload the storefront.

bin/magento dev:template-hints:enable

For PHP classes, dev:di:info is useful because it identifies the active preference and plugins for a given class.

bin/magento dev:di:info 'Magento\Catalog\Block\Product\View'

When changing PHP classes, preferences or plugins, you may also need to compile again, especially in Production Mode.

bin/magento setup:di:compile

Magento regenerates proxies, factories and interceptors. Old generated code can therefore prevent changes from appearing even after clearing the cache.

Custom modules can also involve preferences and plugins that replace or intercept the class you expected to execute. Template overrides and Magento’s fallback mechanism add another layer, so a simple bin/magento cache:flush cannot fix every such issue.

If your changes still do not appear, first determine which code is actually running and which module or theme provides it..

Valkey is Redis compatible. Before upgrading Magento, check how cache and sessions are configured and whether your server is prepared for 2.4.9.

I can examine your Magento installation, explain whether you need Valkey changes and perform the necessary adjustments. get in touch and I will review your store and server.

1. Switch to developer mode:

php bin/magento deploy:mode:set developer

Keep in mind that the store may be briefly unavailable while Magento regenerates code. The better wayto enable or disable Magento 2 cache types is option 2:

2. Caches direkt per CLI aktivieren / deaktivieren

php bin/magento cache:status           # Show all cache types and their status, e.g. "graphql_query_resolver_result"
php bin/magento cache:enable <type>     # Enable one or more cache types
php bin/magento cache:disable <type>    # Disable one or more cache types
php bin/magento cache:clean            # Clear the Magento cache
php bin/magento cache:flush            # Flush other caches, such as Redis or filesystem caches

Either of these two approaches lets you control the Magento 2 cache status.

php -r 'require "app/Mage.php"; Mage::app()->getCacheInstance()->flush();'