Memory and execution time errors in PrestaShop: memory_limit and friends

You launch a product import and halfway through it stops with a blank screen. A scheduled task that syncs stock has not finished for weeks. The order export works for one month but not for a year. Messages such as Allowed memory size of ... bytes exhausted or Maximum execution time of ... seconds exceeded appear in the error log.

These are PHP's two most common limits, and there are more than you might think. Let us look at what they are, where they are configured and when it makes sense to raise them.

The limits involved

memory_limit

The maximum memory a PHP process can use. If the request exceeds it, PHP stops it with a fatal error: Allowed memory size exhausted. In the store it shows up as a blank screen or a 500 error.

max_execution_time

The maximum time, in seconds, a script can run. When it is exceeded, PHP stops it: Maximum execution time exceeded. Note: on Linux this counter does not include the time the script spends waiting for the database or an external API, only its own execution time.

Those outside PHP

Even if PHP has not stopped it, the request may die earlier for another reason:

• The PHP process manager (PHP-FPM) has its own maximum time per request.
• The web server or the proxy (Apache, Nginx, a load balancer or a CDN) closes the connection if it receives no response within a certain time. The customer sees a 502 or 504 error, while the script may still be running behind it.
• The database may cut off idle connections or queries that run too long.
• max_input_vars, which is not about memory or time but produces similar symptoms: it limits how many fields a form accepts. A product page with many combinations or a translations screen may save only part of the data without any visible error.

Where they are configured

It depends on the hosting:

• In the hosting panel, in the PHP configuration section; this is the most common.
• In a php.ini or .user.ini file in the website root, if the hosting allows it.
• In the server configuration, if you have a VPS or a dedicated server.

To find out which values the store really has, do not trust what the panel says: check them in the back office server information (Advanced Parameters → Information) or with a temporary page that shows the PHP configuration, and delete it afterwards.

Where they appear in PrestaShop

• Large CSV imports, especially with images downloaded from a URL during the import.
• Thumbnail regeneration in catalogues with many photos or very large photos.
• Scheduled tasks of modules that sync with an ERP, a supplier or a marketplace.
• Exports of orders, customers or products covering long periods.
• PDF generation with many invoices at once.
• Clearing the cache or recompiling the Symfony container in PrestaShop 8 and 9, which needs a fair amount of memory in one go.
• Specific pages: a category with thousands of products and no pagination, a product with hundreds of combinations, an order page with many lines.

When to raise the limit and when not to

Raising memory_limit or max_execution_time is reasonable when the process is legitimately large and one-off: an initial import, a migration, a full regeneration. PrestaShop itself requires a generous minimum amount of memory, and many hosting plans come with values below what the store needs.

But if you need more each time, the problem lies elsewhere:

• A process that loads everything into memory (all products, all orders) instead of working in batches. With today's catalogue it fits; with next year's, it will not.
• A loop that never ends or that processes the same thing over and over, because of a module bug.
• Queries without an index on tables that have grown, which take longer and longer.
• Slow external API calls within the same process, one per product.

If a huge limit "fixes" a normal store page, such as a category or a product page, it is not fixed: that page consumes resources it should not, and under traffic it will bring the server down.

How to diagnose it

1. Read the full message in the PHP error log: it gives the file and line where memory or time ran out. Sometimes it is a line in a specific module; other times, a core function called from a module.
2. Tell web and terminal apart: does the failure happen when requesting a URL or when running a script from the console? Each has its own limits.
3. Look at the response code: a 500 is usually PHP; a 502 or 504, the web server or proxy tired of waiting.
4. Reproduce it on a copy, enabling PrestaShop's debug mode, which shows the error on screen instead of a blank page.
5. Check whether it grows with the data: if it fails with a year and not with a month, the process does not work in batches.

Good practice for long processes

• Run heavy tasks from the terminal, not by requesting a URL, whenever the module allows it.
• Split large imports into smaller files.
• Schedule heavy tasks outside traffic hours and avoid two running at the same time.
• Use modules that work in batches and resume where they left off if interrupted.
• Keep PrestaShop, PHP and modules up to date: modern PHP versions use less memory and are faster with the same code.

How to solve it in PrestaShop

RKR Sentinel alerts you via Telegram when the store hits exhausted memory, timeouts, fatal errors or 500 responses, with the message, file and line, a code excerpt, the stack trace, the URL and the versions, without having to enable debug mode in production. Each error is grouped by its fingerprint so that repeats do not flood your chat. If the problem lies in a process that needs rewriting to work in batches, or in server limits you do not know where to configure, with a Rekire support hours package we diagnose it on a copy and fix it.