PrestaShop Memory Limit Exceeded: Causes and Fixes

Understanding PHP memory_limit

The memory_limit directive in PHP controls how much RAM a single PHP process can consume before the engine terminates it with a fatal error. When you see the message "Allowed memory size of X bytes exhausted" in PrestaShop, it means a specific PHP request tried to use more memory than the configured limit allows.

Every page load in PrestaShop runs PHP code that loads the framework, connects to the database, processes data, renders templates, and sends HTML to the browser. Each of these steps consumes memory. The memory_limit acts as a safety net: it prevents a single runaway process from consuming all available server RAM, which would crash other processes and potentially bring down the entire server.

The default memory_limit in PHP is typically 128M (128 megabytes). PrestaShop officially recommends at least 256M, and many stores require 512M or more depending on catalog size, installed modules, and traffic. Understanding what drives memory consumption helps you determine the right value for your store rather than blindly increasing the limit.

How to Check Your Current Memory Limit

There are several ways to verify what memory limit your PrestaShop installation is currently using.

From the PrestaShop Back Office

Navigate to Advanced Parameters > Information. This page displays your server's PHP configuration, including the current memory_limit value. PrestaShop will also show warnings if the value is below its recommended minimum.

Using phpinfo()

Create a temporary file called info.php in your PrestaShop root directory with this content:

<?php phpinfo(); ?>

Access it via your browser at yourdomain.com/info.php. Search the page for "memory_limit" to see both the Local Value (what is actually active) and the Master Value (what is set in php.ini). The local value may differ from the master value if an .htaccess, .user.ini, or the application itself overrides it.

Important: Delete this file immediately after checking. A phpinfo() page exposes detailed server configuration that attackers can exploit.

Via Command Line

If you have SSH access, run:

php -i | grep memory_limit

Note that the CLI PHP configuration may differ from the web server configuration. To check the web-facing value, use the phpinfo() method or the PrestaShop back office.

Common Causes of Memory Limit Errors

Large Product Imports

Importing products via CSV is one of the most memory-intensive operations in PrestaShop. Each row in the import file is loaded into memory, processed, validated, and inserted into the database. A CSV file with 10,000 products, each with multiple combinations, images, and descriptions, can easily require 512MB or more of memory.

PrestaShop's import tool processes products in batches, but the batch size and the amount of data per product determine the total memory footprint. Large text fields (descriptions with HTML), many columns, and UTF-8 encoded files with special characters all increase memory usage per row.

To reduce memory consumption during imports:

• Split large CSV files into smaller chunks (1,000-2,000 rows each)
• Import products without images first, then import images separately
• Disable non-essential modules during import (statistics, search indexing)
• Use the command-line import if available, which avoids web server timeout limits

Products with Many Combinations

Products with many attributes (size, color, material) generate combinations exponentially. A product with 5 sizes, 10 colors, and 3 materials creates 150 combinations. Each combination is a separate database record with its own price, reference, stock, and image associations. When PrestaShop loads a product page for editing in the back office, it loads all combinations into memory at once.

Products with 500+ combinations are a known pain point. At 1,000+ combinations, you will almost certainly hit memory limits with the default configuration. Solutions include:

• Increasing memory_limit to 512M or 1G for the back office
• Restructuring products to reduce combination count (separate products instead of mega-combinations)
• Using modules that handle combinations more efficiently through pagination

Bloated or Poorly Coded Modules

Third-party modules are a frequent source of memory problems. Common issues include:

• Loading entire database tables into PHP arrays: A module that runs SELECT * FROM ps_orders without a LIMIT clause loads every order ever placed into memory. For a store with 100,000 orders, this can consume hundreds of megabytes.
• Memory leaks in loops: Modules that process items in a loop but accumulate objects without freeing them. PHP's garbage collector handles simple cases, but circular references and stored references can prevent cleanup.
• Excessive logging: Debug logging that writes large arrays or objects to log files, using var_export() or print_r() on complex PrestaShop objects, can consume enormous amounts of memory.
• Unoptimized image processing: Modules that resize or watermark images using GD or ImageMagick load the entire uncompressed image into memory. A 5000x5000 pixel image at 24-bit color depth requires approximately 75MB of RAM just for the pixel data.

To identify which module is causing memory issues, check the error message carefully. It usually includes a file path that points to the responsible module. You can also enable PrestaShop's debug mode to get more detailed stack traces.

Large Catalogs and Complex Queries

Stores with tens of thousands of products, many categories, and complex attribute structures put more pressure on memory during normal operation. Category pages with layered navigation (faceted search) are particularly demanding because the filter engine must calculate available attribute values across thousands of products.

The back office product listing, order listing, and customer listing pages all load data into memory for display. With very large datasets, even the basic list view can hit memory limits, especially when modules add extra columns or calculations to these lists.

Smarty Template Compilation

PrestaShop uses the Smarty template engine, which compiles templates into PHP files for faster rendering. The compilation process itself consumes memory, and complex templates with many includes, loops, and conditional blocks require more memory to compile. After the first compilation, cached versions are used, so this is primarily an issue when the cache is cleared or during development.

How to Increase the Memory Limit

Method 1: php.ini

The most reliable method is editing the PHP configuration file directly. The location depends on your setup:

• Debian/Ubuntu: /etc/php/8.x/fpm/php.ini (PHP-FPM) or /etc/php/8.x/apache2/php.ini (mod_php)
• CentOS/RHEL: /etc/php.ini or /etc/php.d/
• cPanel: MultiPHP INI Editor in WHM or cPanel

Find the memory_limit line and change it:

memory_limit = 512M

After saving, restart PHP-FPM or Apache:

# PHP-FPM
sudo systemctl restart php8.2-fpm

# Apache with mod_php
sudo systemctl restart apache2

Method 2: .htaccess (Apache with mod_php only)

Add this line to the .htaccess file in your PrestaShop root directory:

php_value memory_limit 512M

This method only works with Apache running mod_php. If you use PHP-FPM (which is more common on modern setups), this directive is silently ignored or may cause a 500 error. To check which PHP handler you are using, look at the Server API line in your phpinfo() output.

Method 3: .user.ini (PHP-FPM)

Create or edit a file called .user.ini in your PrestaShop root directory:

memory_limit = 512M

PHP-FPM reads .user.ini files from the document root. Note that changes take effect after the user_ini.cache_ttl period (default 300 seconds / 5 minutes), so you may need to wait or restart PHP-FPM for the change to take effect immediately.

Method 4: Within PrestaShop's Code

PrestaShop sets its own memory limit in the file config/defines.inc.php. Look for a line like:

@ini_set('memory_limit', '256M');

You can increase this value directly in the code. However, this approach has a limitation: the ini_set() function can only increase the memory limit up to the value set in php.ini. If php.ini sets memory_limit = 128M and your code tries to set it to 512M, the actual limit will remain 128M (unless the master value allows overrides, which depends on the PHP_INI_ALL vs PHP_INI_SYSTEM classification).

Method 5: Per-Pool Configuration (PHP-FPM)

If you manage your own server, you can set memory limits per PHP-FPM pool. Edit the pool configuration file (e.g., /etc/php/8.2/fpm/pool.d/www.conf) and add:

php_admin_value[memory_limit] = 512M

Using php_admin_value makes this setting immutable — it cannot be overridden by .user.ini or ini_set(). This is useful for enforcing limits in multi-tenant environments.

Per-Process vs Shared Memory

It is important to understand that memory_limit applies to each individual PHP process, not to PHP as a whole. If you set memory_limit = 512M and your server runs 20 concurrent PHP processes, the theoretical maximum memory consumption by PHP is 10GB (20 x 512MB).

This is why blindly increasing the memory limit can cause problems. On a server with 4GB of RAM, setting memory_limit = 1G with 10 PHP-FPM workers means PHP alone could try to use 10GB, causing the system to swap heavily or trigger the Linux OOM killer, which forcefully terminates processes to free memory.

The correct approach is to balance the memory limit with the number of PHP workers:

• Available RAM for PHP = Total RAM - OS overhead - MySQL memory - web server memory - other services
• Max PHP workers = Available RAM for PHP / memory_limit

For example, on a 4GB VPS: 4GB total - 0.5GB OS - 1GB MySQL - 0.25GB Nginx = 2.25GB for PHP. With memory_limit = 256M, you can safely run 8-9 PHP-FPM workers. With memory_limit = 512M, you can only run 4 workers, meaning fewer concurrent requests can be served.

Configure the PHP-FPM pool to match:

pm = dynamic
pm.max_children = 8
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5

Diagnosing Memory Leaks and Excessive Usage

If increasing the memory limit only delays the error rather than fixing it, you likely have a memory leak or an inefficient process. Here is how to diagnose the root cause.

Enable PrestaShop Debug Mode

Edit config/defines.inc.php and set:

define('_PS_MODE_DEV_', true);

This enables detailed error reporting, including the exact file and line number where the memory limit was exceeded. The stack trace shows the chain of function calls that led to the error, helping you identify the responsible module or core function.

Monitor Memory Usage in Code

You can add memory monitoring to specific code sections to pinpoint where memory spikes occur:

error_log('Memory before operation: ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
// ... operation ...
error_log('Memory after operation: ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
error_log('Peak memory usage: ' . memory_get_peak_usage(true) / 1024 / 1024 . ' MB');

The memory_get_usage(true) function returns the actual amount of memory allocated by the OS to PHP, while memory_get_peak_usage(true) returns the maximum amount allocated at any point during the request.

Use Xdebug Profiling

Xdebug's profiler generates detailed reports of function calls, execution time, and memory consumption. Enable it temporarily in your PHP configuration:

xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug

Open the generated cachegrind files in a tool like KCacheGrind or Webgrind to visualize which functions consume the most memory. This is the most thorough diagnostic approach but should only be used on development servers due to the significant performance overhead.

Check Slow Queries and MySQL

Sometimes what appears to be a PHP memory issue is actually a MySQL problem. A slow query that returns millions of rows will cause PHP to allocate memory for the entire result set. Check MySQL's slow query log:

sudo tail -100 /var/log/mysql/slow-query.log

If you see queries with large result sets, add proper LIMIT clauses or implement pagination in the responsible module.

OPcache Memory

OPcache is a PHP extension that caches compiled PHP bytecode in shared memory, eliminating the need to parse and compile PHP files on every request. OPcache has its own memory allocation, separate from memory_limit.

The default OPcache memory (opcache.memory_consumption) is 128MB. PrestaShop with several modules installed can easily exceed this. When OPcache runs out of memory, it starts evicting cached entries and recompiling files on every request, causing significant performance degradation.

Check OPcache status from the command line:

php -r "print_r(opcache_get_status());"

Or look at the opcache section in your phpinfo() output. Key values to monitor:

• opcache.memory_consumption: Total memory allocated for OPcache (increase to 256M for PrestaShop)
• opcache.max_accelerated_files: Maximum number of files OPcache can cache (increase to 20000 for PrestaShop)
• Used memory vs Free memory: If free memory is near zero, increase memory_consumption
• Cache hit rate: Should be above 99%. Below 95% indicates memory pressure or frequent cache invalidation

Recommended OPcache configuration for PrestaShop:

opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 0
opcache.interned_strings_buffer = 16

Note that OPcache memory is shared across all PHP processes, unlike memory_limit which is per-process. Increasing OPcache memory does not multiply by the number of workers.

MySQL Memory Configuration

MySQL has its own memory configuration that indirectly affects PrestaShop performance and can contribute to overall server memory pressure. Key MySQL memory settings include:

• innodb_buffer_pool_size: The main memory buffer for InnoDB tables. Set to 50-70% of available RAM on a dedicated database server, or 25-50% on a shared server running both PHP and MySQL. This is the single most important MySQL performance setting.
• sort_buffer_size and join_buffer_size: Per-connection buffers for sorting and joining. Keep these at default values unless you have specific slow queries that benefit from larger buffers. Setting them too high wastes memory because they are allocated per connection.
• query_cache_size: Deprecated in MySQL 8.0 and removed entirely. If you are still on MySQL 5.7, a small query cache (64M) can help, but large query caches cause contention and reduce performance.

If MySQL consumes too much memory, it leaves less for PHP, potentially forcing you to reduce PHP-FPM workers or the memory limit. Use mysqladmin status or SHOW GLOBAL STATUS to monitor MySQL memory consumption.

When to Upgrade Your Hosting

Sometimes increasing the memory limit and optimizing your code is not enough. Here are signs that you need a more powerful server:

• You are constantly running at the maximum memory limit: If your processes regularly use 90%+ of the allocated memory, even after optimization, you need more RAM.
• The server swaps frequently: Check with free -h or vmstat 1. If swap usage is consistently high, you do not have enough physical RAM.
• Reducing PHP workers is hurting performance: If you had to reduce PHP-FPM workers to 3-4 to accommodate the memory limit, your site cannot handle concurrent visitors effectively.
• Your catalog keeps growing: A store that worked fine with 1,000 products may struggle with 10,000. Memory needs scale with catalog size, especially for search indexing, category listing, and back office operations.
• You need memory_limit above 1G: If a single PHP process needs more than 1GB of memory for normal operations (not imports), something is fundamentally wrong with either your code or your hosting capacity. Investigate the root cause before simply increasing the limit further.

When upgrading, prioritize more RAM over more CPU cores for PrestaShop. A server with 8GB RAM and 2 cores will serve PrestaShop better than one with 4GB RAM and 4 cores. Also consider separating MySQL onto its own server or using a managed database service, which frees up the application server's RAM entirely for PHP.

Quick Reference: Recommended Settings by Store Size

The following recommendations serve as starting points. Monitor your actual usage and adjust accordingly.

• Small store (under 1,000 products, few modules): memory_limit = 256M, 2GB RAM, 4-6 PHP workers
• Medium store (1,000-10,000 products, 20+ modules): memory_limit = 512M, 4GB RAM, 6-8 PHP workers
• Large store (10,000+ products, many combinations): memory_limit = 512M-1G, 8GB+ RAM, 8-16 PHP workers, separate database server
• During imports: Temporarily increase to 1G or 2G, then restore the normal value

Remember that the memory limit is a safety ceiling, not a target. A well-optimized PrestaShop store should rarely use more than 128-256MB per request for normal page loads. If normal operations consistently need 512MB or more, investigate and fix the underlying cause rather than continuing to increase the limit.

For more details, read our guides: What Actually Makes PrestaShop Slow: Database, Modules and Hosting and Choosing Hosting for PrestaShop: What Matters and What Is Marketing.