This error means a single PHP request used more memory than the memory_limit setting allows, so PHP killed it mid-execution. The number in the message is the limit in bytes (134217728 is 128 MB, a common default), and "tried to allocate" is just the last small allocation that tipped it over, not the cause of the problem.
You see it in the PHP error log, in the browser if display_errors is on, or as a blank page or HTTP 500 if it is off. It is especially common in WordPress, Magento, Drupal and Laravel, and in command line jobs such as Composer.
Causes, most likely first
- The limit is simply low for the workload. Image processing, large imports, page builders and big plugin stacks can legitimately need 256 MB or more.
- A plugin, theme or module loads far too much data. A query that returns 200,000 rows into an array, or a loop that builds a giant string, will exhaust any limit.
- A runaway or recursive loop. Memory grows until the limit is hit, no matter how high you set it.
- You changed the wrong setting. The limit actually in effect comes from a different file or layer than the one you edited, so nothing changes.
- CLI tools using the web limit or the reverse. Composer, WP-CLI or a cron script often runs with a different
php.inithan the website.
Step 1: find the limit that is really in effect
PHP reads settings from several places, and the web server and the command line usually use different files. Check both:
# CLI
php -i | grep -E "memory_limit|Loaded Configuration File"
# Which ini files PHP-FPM loads (version number will differ)
php-fpm8.2 -i | grep -E "memory_limit|Loaded Configuration"
ls /etc/php/8.2/fpm/conf.d/
To see the value the web server really uses, create a temporary file info.php containing <?php phpinfo(); in your web root, load it, find memory_limit, and then delete the file immediately. Never leave phpinfo() public.
Step 2: raise the limit in the right place
Pick the method that matches how PHP runs on your server.
php.ini (all setups). Edit the loaded file, for example /etc/php/8.2/fpm/php.ini:
memory_limit = 256M
Then reload the service: sudo systemctl reload php8.2-fpm (or restart Apache if you use mod_php).
PHP-FPM pool override. In /etc/php/8.2/fpm/pool.d/www.conf, a pool setting overrides php.ini and cannot be changed by scripts when set with php_admin_value:
php_admin_value[memory_limit] = 256M
.user.ini (shared hosting with FastCGI). Create .user.ini in the site root:
memory_limit = 256M
Changes can take a few minutes because PHP caches .user.ini (default user_ini.cache_ttl is 300 seconds).
.htaccess (Apache with mod_php only).
php_value memory_limit 256M
On FastCGI or PHP-FPM this line causes a 500 error, so use it only if you know PHP runs as an Apache module.
WordPress. WordPress has its own constants in wp-config.php, placed above the "That's all, stop editing" line:
define( 'WP_MEMORY_LIMIT', '256M' ); // front end
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // admin and heavy tasks
These only raise PHP's limit up to what the host permits. See WordPress memory limit exhausted fix for the WordPress-specific walkthrough.
Composer and CLI scripts.
COMPOSER_MEMORY_LIMIT=-1 composer install
php -d memory_limit=1G artisan queue:work
Step 3: fix what is using the memory
If the error returns after you double the limit, raising it is only hiding a bug. Find the offender:
- Read the stack trace in the log. With
error_logenabled, the file and line named after the message usually point to the plugin or function that was allocating. - Disable plugins one at a time on staging, or rename the plugin folder, and retest the failing URL.
- Look for unbounded queries. Use
LIMIT, pagination, cursors oryieldgenerators instead of loading everything withfetchAll(). - Process large imports in batches and call
unset()on big arrays when finished. - In Laravel, use
chunk()orlazy()instead ofget()on large tables.
For a quick peak-memory reading inside your own code, memory_get_peak_usage(true) logged at the end of a request shows how close you are to the limit.
How to verify the fix
Reload the page that failed and check the response with the HTTP Status Checker; a 500 turning into 200 confirms the request now completes. Confirm the new limit is active by checking phpinfo() again, and watch the error log (tail -f /var/log/php8.2-fpm.log or your site's error log) while exercising the slow action. The Website Health Check gives a broader pass over the site afterward. If the failure only happens on certain actions, such as a nightly import, put the URL under the Uptime Monitor so you learn about a recurrence quickly.
Next steps
- Check the page with the HTTP Status Checker to confirm it returns 200.
- Run the Website Health Check for a wider look at the site.
- Read Fix 500 Internal Server Error if the error shows as a generic 500.
- Review the related PHP parse error page when a fatal error is not memory related.
- Set up an Uptime Monitor with a keyword check for pages that fail intermittently.
FAQ
What is a safe memory_limit for PHP?
128 MB suits simple sites, and 256 MB is a common setting for WordPress with a page builder or WooCommerce. Go higher only for a measured reason, and remember the limit applies per request, so total RAM needed is roughly the limit times your concurrent PHP workers.
I raised memory_limit but nothing changed. Why?
You almost certainly edited a file that your PHP handler does not load, or a pool-level php_admin_value is overriding it. Run phpinfo() from the web, not php -i on the command line, and confirm the value and the loaded configuration file.
Can the host block me from raising it?
Yes. Shared hosts cap the value, and WP_MEMORY_LIMIT cannot exceed the cap. Ask your host to raise it, or move to a plan with more resources.
Why does the message say "tried to allocate 20480 bytes"?
That is only the final allocation that failed. The memory was consumed earlier in the request, so look at the stack trace rather than at that number.
Get notified when this fix updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.