Runtimes Intermediate

Fixing Composer ‘Memory Limit Exhausted’ Errors on CentOS Stream / Rocky Linux

Resolve Composer 'memory limit exhausted' errors on CentOS Stream and Rocky Linux by adjusting PHP CLI and FPM memory limits effectively.

👨‍💻
Senior Systems Architect • Verified in Staging Labs

Resolve Composer 'memory limit exhausted' errors on CentOS Stream and Rocky Linux by adjusting PHP CLI and FPM memory limits effectively.

When working with PHP applications, especially those managing numerous dependencies like modern Symfony, Laravel, or Magento projects, Composer is an indispensable tool. However, it can be resource-intensive. A common hurdle faced by developers and system administrators on CentOS Stream or Rocky Linux is Composer crashing with a "memory limit exhausted" error, preventing successful dependency installation or updates. This guide will walk you through diagnosing and resolving this issue.

Symptom & Error Signature

You'll typically encounter this error when running composer install, composer update, or similar Composer commands directly from your terminal. The output will look similar to this:

Loading composer repositories with package information
Installing dependencies from lock file (including require-dev)
Verifying lock file contents with composer.json.
Package operations: 215 installs, 0 updates, 0 removals
  - Installing symfony/polyfill-mbstring (v1.27.0): Extracting archive
Fatal error: Allowed memory size of 209715200 bytes exhausted (tried to allocate 81920 bytes) in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/Solver.php on line 223

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-exhausted for more info on the "memory limit exhausted" error.

The specific Allowed memory size (e.g., 209715200 bytes which is 200MB) and the file/line number might vary, but the core message Allowed memory size of X bytes exhausted remains constant.

Root Cause Analysis

The "Allowed memory size of X bytes exhausted" error indicates that the PHP process running Composer has attempted to allocate more memory than its configured memory_limit allows. Several factors contribute to this on CentOS Stream / Rocky Linux environments:

  1. Default PHP CLI memory_limit: On many systems, the default php.ini configuration for the PHP CLI (Command Line Interface) is often set to 128M, 256M, or even 512M. While sufficient for simple scripts, complex Composer operations, especially on large projects with deep dependency trees, can easily exceed this.
  2. Composer's Resource Usage: Composer's dependency solver can be memory-intensive. It needs to load metadata for all required packages and their dependencies, build a dependency graph, and find a compatible set of versions. This process consumes significant RAM.
  3. Multiple PHP Installations: CentOS Stream and Rocky Linux often use dnf modules for PHP (e.g., php:8.1). You might have different php.ini files for the PHP CLI and PHP-FPM, or even multiple versions of PHP installed, each with its own configuration. Composer usually runs using the default PHP CLI version in your PATH.
  4. PHP-FPM memory_limit vs. CLI memory_limit: It's crucial to understand that the memory_limit for the PHP CLI (used by Composer) is distinct from the memory_limit for PHP-FPM (used by your web server like Apache HTTPD or Nginx). Increasing one does not affect the other automatically, though they might share a base php.ini.

Step-by-Step Resolution

Follow these steps to effectively increase the PHP memory limit for Composer on your CentOS Stream or Rocky Linux server.

1. Identify Current PHP CLI memory_limit

First, determine the current memory limit set for your PHP CLI and identify which php.ini file is being used.

php -i | grep -E "Loaded Configuration File|memory_limit"

Example Output:

Loaded Configuration File => /etc/php.ini
memory_limit => 256M => 256M

This output tells us the php.ini file being used by the CLI is /etc/php.ini and the current memory_limit is 256M. Note that on systems with PHP module streams (e.g., php:8.1), the Loaded Configuration File might point to a version-specific path like /etc/opt/remi/php81/php.ini or /etc/php-cli.d/00-cli.ini.

2. Temporarily Increase Memory Limit for a Single Composer Run

For a quick fix or a one-off operation, you can increase the memory limit directly when executing Composer. This is highly recommended for initial attempts as it doesn't require modifying configuration files.

php -d memory_limit=-1 /usr/local/bin/composer install --no-dev --optimize-autoloader

Replace /usr/local/bin/composer with the actual path to your Composer executable if it's different (e.g., ~/bin/composer or just composer if it's in your PATH).

The -d memory_limit=-1 flag tells PHP to disable the memory limit (-1 means unlimited). This should be used cautiously and ideally only for CLI tools like Composer.

Adding --no-dev and --optimize-autoloader can also help reduce memory usage and speed up the installation process, especially in production environments.

If this command succeeds, it confirms that the memory limit was indeed the issue. You can then proceed to a more permanent solution.

3. Permanently Adjust PHP CLI memory_limit

To avoid constantly using the -d flag, you should modify the php.ini file used by the PHP CLI.

  1. Locate the Correct php.ini: From step 1, you identified the Loaded Configuration File. It's commonly /etc/php.ini or a version-specific path.

    • If your system uses a modular PHP setup (e.g., Remi repo), you might have separate php.ini files for CLI and FPM, or configuration snippets. Check the output of php --ini to confirm all loaded files. Often, /etc/php-cli.d/ contains CLI-specific overrides. If you have a file like /etc/php-cli.d/composer.ini (or similar), it's best to create or modify that. Otherwise, modify the main php.ini.
  2. Edit the php.ini file: Use sudo with your preferred text editor (e.g., vi or nano).

    sudo vi /etc/php.ini
    

    (Replace /etc/php.ini with your actual CLI php.ini path)

  3. Find and Modify memory_limit: Search for the line containing memory_limit.

    ; Maximum amount of memory a script may consume (128MB)
    ; http://php.net/memory-limit
    memory_limit = 256M
    

    Change the value to 1G (1 Gigabyte) or 2G (2 Gigabytes) for complex projects. A value of 512M is often a good starting point. For Composer specifically, 1G or 2G is usually safe as it only affects CLI scripts.

    memory_limit = 1G
    

    While setting memory_limit = -1 (unlimited) works, it's generally not recommended for server-side php.ini configurations. An runaway script could consume all system memory, leading to crashes. For CLI tools like Composer run manually, it's less risky but still best to set a high, but finite, limit.

  4. Save the file and exit the editor.

  5. Verify the Change: Run php -i | grep memory_limit again to ensure your change has taken effect for the CLI.

    php -i | grep memory_limit
    

    You should now see memory_limit => 1G => 1G.

4. Permanently Adjust PHP-FPM memory_limit (Optional, but Good Practice)

While the Composer error primarily relates to the PHP CLI, it's good practice to ensure your PHP-FPM processes (which serve your web application) also have adequate memory, especially if Composer is part of an automated deployment that might invoke web-based Composer commands.

  1. Locate the PHP-FPM php.ini: PHP-FPM typically uses a different php.ini or loads configuration from specific directories.

    php-fpm -i | grep -E "Loaded Configuration File|memory_limit"
    

    Note: If php-fpm is not in your PATH, you might need to specify the full path, e.g., /usr/sbin/php-fpm -i or /opt/remi/php81/root/usr/sbin/php-fpm -i.

    This will show the main php.ini used by PHP-FPM. You might also find memory limits set in FPM pool configuration files, typically located under /etc/php-fpm.d/. For example, www.conf:

    sudo vi /etc/php-fpm.d/www.conf
    

    Look for php_admin_value[memory_limit] directives. If present, these will override the main php.ini setting for that specific FPM pool.

  2. Edit the php.ini or FPM pool configuration: Similar to step 3, find memory_limit and increase it. For web applications, a value between 256M and 512M is common, but complex applications may need 1G.

    ; In /etc/php.ini or specific FPM config
    memory_limit = 512M
    

    Or in an FPM pool config file like www.conf:

    php_admin_value[memory_limit] = 512M
    
  3. Restart PHP-FPM Service: For changes to PHP-FPM configuration to take effect, you must restart the service.

    sudo systemctl restart php-fpm
    

    (If you are using a versioned PHP-FPM service, like php81-php-fpm, adjust the command accordingly: sudo systemctl restart php81-php-fpm)

    Forgetting to restart the PHP-FPM service is a common mistake. Your changes will not apply until the service is reloaded or restarted.

5. Consider Increasing System Swap Space (Advanced)

If you've increased PHP's memory_limit significantly and are still encountering memory issues, or if your server frequently runs out of physical RAM, it might indicate a broader system resource constraint. Increasing swap space can provide a temporary buffer, though it's much slower than RAM.

This is a more advanced topic and should be considered only after exhausting PHP-level adjustments and verifying your server's total RAM capacity is genuinely insufficient.

# Check current swap space
swapon --show

# Example to create a 4GB swap file (adjust count for desired size)
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Make swap permanent across reboots
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Verify new swap
swapon --show

Relying heavily on swap space can degrade performance significantly. The best solution for consistent memory exhaustion is to add more physical RAM to your server or optimize the application and its dependencies to use less memory.

After applying the relevant memory limit adjustments, re-run your Composer command. The "memory limit exhausted" error should now be resolved, allowing Composer to complete its operations successfully.

👨‍💻

Johnathon Wheeler

Senior Systems Architect & DevOps Engineer • Austin, TX

Connect on LinkedIn →

Johnathon has over 16 years of hands-on experience designing, debugging, and scaling Linux web hosting stacks, container clusters, and high-availability database architectures. Every guide on ButItWorkedLocal is independently tested against Debian 12, Ubuntu 24.04/22.04 LTS, Rocky Linux, and Docker environments to guarantee reproducibility in production.

🛡️

Our Production Verification Guarantee

Encountering a bug not covered here or running a non-standard kernel configuration? Our solutions are continually refined against real production incidents. Submit an environment trace for our editorial team to replicate.