Resolving Out of Memory Errors During Shopware 6 Indexing

The Problem: PHP Fatal Memory Exhaustion

When running heavy Shopware 6 operations—specifically bin/console dal:refresh:index or large plugin installations—you may encounter a PHP Fatal Error: Allowed memory size of X bytes exhausted. This occurs because the Data Abstraction Layer (DAL) loads large sets of entities into memory during indexing. If the volume of products or categories exceeds the allocated PHP memory limit, the process crashes, leaving your storefront indexes incomplete or your plugin installation in a partial state.

Diagnostic Matrix

Symptom	Likely Cause	Primary Log Location
Command terminates abruptly with "Allowed memory size exhausted"	CLI PHP memory limit is too low for the entity count	Terminal output or var/log/prod.log
Web-based plugin update hangs or returns 500 error	PHP-FPM memory limit reached during post-install hooks	PHP-FPM error log / Nginx error log
Slow memory creep during indexing until crash	Large batch sizes causing memory accumulation in the DAL	System monitor (htop/top)

Step-by-Step Memory Audit

1. Verify CLI Memory Allocation: Shopware often runs via the command line, which uses a different php.ini than the web server. Run the following command as the web user (e.g., www-data) to see the active limit:

   php -r "echo ini_get('memory_limit');"

2. Assess Entity Volume: Determine if your data volume justifies a memory increase. Check the row counts of your largest tables:

   # Run via MySQL client
   SELECT COUNT(*) FROM product;
   SELECT COUNT(*) FROM category;

3. Monitor Real-time Consumption: Open a second terminal and run htop or top. Start the indexing process and watch the RES (Resident) memory column for the PHP process to see if it hits the limit rapidly or climbs steadily.

Resolution Strategies

Option A: Increasing the Memory Limit

If your server has sufficient physical RAM, increasing the PHP limit is the fastest fix. For CLI operations, it is recommended to set this to 512M or 1G.

Implementation: Edit your php.ini for the CLI version of PHP or pass the limit directly to the command:

# Run with a temporary memory override
php -d memory_limit=1G bin/console dal:refresh:index

Risk: Setting this too high on a server with limited RAM can trigger the Linux OOM Killer, which may shut down critical services like MySQL to save the OS.

Option B: Reducing Indexer Batch Size

If you cannot increase physical RAM, you must reduce the number of entities Shopware processes in a single iteration. This reduces the memory footprint per batch but increases the total execution time.

Implementation: Define the SWSHOPWARE.INDEXER.BATCH_SIZE environment variable in your .env file or system environment:

# Example .env entry
SWSHOPWARE.INDEXER.BATCH_SIZE=50

Lowering this value (e.g., from the default to 50 or 100) forces the DAL to clear memory more frequently.

Verification and Rollback

To verify the fix, execute the indexer again and monitor the process. The command is successful if it reaches 100% completion without a Fatal Error. You can confirm the memory limit is active by re-running the ini_get command mentioned in the audit section.

Rollback: If you modified the php.ini file, revert the memory_limit value to its previous state and restart the PHP-FPM service if applicable. If you added an environment variable, remove the line from .env and clear the cache using bin/console cache:clear.

When to Escalate

If memory exhaustion persists despite a 2G limit and a small batch size, investigate the following:

• Custom Plugins: A third-party plugin may have a memory leak in a ProductIndexer subscriber. Disable non-core plugins to isolate the cause.
• Database Deadlocks: Check for locked tables that may be causing PHP processes to hang and accumulate memory while waiting for a response.