Running into a memory exhaustion error while working with Magento 2 is almost a rite of passage for developers. Whether you are installing a new module, upgrading the system, or simply refreshing the code generated folder, the setup:di:compile command is one of the most resource-intensive tasks in the Adobe Commerce ecosystem.

The error typically looks something like this:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 24 bytes) in /vendor/zendframework/zend-code/src/Scanner/FileScanner.php on line 36

This message indicates that PHP has hit its pre-configured memory ceiling. While 128MB or 256MB might be sufficient for standard web applications, Magento 2 requires significantly more overhead to scan thousands of classes, generate proxies, and build the Dependency Injection (DI) configuration. In this guide, we will explore several methods to resolve this issue, ranging from quick command-line overrides to permanent configuration changes.

Method 1: The Quick Command-Line Override

If you need to fix the error immediately without digging into configuration files, the fastest approach is to pass the memory_limit flag directly into the PHP command. This tells the PHP interpreter to ignore the default settings in your php.ini file for this specific execution.

To run the compilation with a 5GB limit, use the following command:

php -dmemory_limit=5G bin/magento setup:di:compile

If you are performing a full deployment, you should apply the same logic to the static content deployment command:

php -dmemory_limit=5G bin/magento setup:static-content:deploy

Note: If 5G still isn't enough for your specific environment, you can use -1 to allow PHP to consume as much memory as the system can provide, though this should be used with caution on shared servers.

php -dmemory_limit=-1 bin/magento setup:di:compile

Method 2: Finding and Updating the Correct php.ini

One of the most common mistakes developers make is updating the php.ini file used by the web server (like Apache or Nginx) while forgetting that the Command Line Interface (CLI) often uses a completely different configuration file.

To find out which configuration file your CLI is actually using, run:

php --ini

You will see output similar to this:

Configuration File (php.ini) Path: /etc/php/7.4/cli
Loaded Configuration File:         /etc/php/7.4/cli/php.ini
Scan for additional .ini files in: /etc/php/7.4/cli/conf.d

Navigate to the path listed under "Loaded Configuration File" and open it with your preferred editor (e.g., nano or vim). Search for the memory_limit parameter and increase it to at least 2G or 4G.

; Increase memory limit for Magento 2 CLI tasks
memory_limit = 2G

Method 3: Using .user.ini for Project-Level Settings

In Magento 2.1 and above, the system includes .user.ini files in the root directory. These files are designed to override global PHP settings on a per-project basis. This is particularly useful if you are on a managed hosting environment where you cannot modify the global php.ini file.

Locate the .user.ini file in your Magento root directory and update the following values:

; Set PHP memory limit to 768M or higher
memory_limit = 2G
max_execution_time = 18000

Keep in mind that .user.ini files are primarily respected by CGI/FastCGI setups. If your CLI is running as a standalone binary, this file might be ignored, and you should revert to Method 1 or 2.

Method 4: Modifying the bin/magento Entry Point

In extreme cases where environment variables are being stripped or ignored, you can force a memory limit increase by editing the bin/magento file itself. While modifying core files is generally discouraged, this script acts as the entry point for CLI commands and can be used to set runtime configurations.

Open bin/magento and add the following line immediately after the opening <?php tag:

ini_set('memory_limit', '2G');

This ensures that every time the bin/magento script is executed, it attempts to claim 2GB of RAM regardless of the system's global configuration.

Method 5: Handling Multiple PHP Versions

If you are using a control panel like Plesk, cPanel, or a local stack like XAMPP, your default php command might point to an older or different version of PHP than what Magento requires. This can cause unexpected memory issues because the wrong php.ini is being loaded.

Always try to use the full path to the specific PHP version intended for your Magento installation. For example, on a Plesk server, you might run:

/opt/plesk/php/7.4/bin/php -d memory_limit=3G bin/magento setup:di:compile

To verify which PHP binary is being used by the environment, you can create a temporary script:

  1. Create a file named check_env (no extension).
  2. Add the following content: ```php #!/usr/bin/env php