PHP Error: Allowed Memory Size of X Bytes Exhausted

A PHP script stops dead and the page goes blank or shows a fatal error like this:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/example/public_html/wp-content/plugins/example/import.php on line 512

This is PHP's memory_limit doing exactly what it was configured to do. The script asked for more memory than it is permitted to use, so PHP halted it rather than letting it consume the server. This guide explains what the numbers in that message mean, how to raise the limit correctly on Noiz hosting, and how to tell whether raising it is the right fix at all.

It also corrects a piece of advice that circulates widely and does not work. If you have been told to put RLimitMem max in your .htaccess file, see the section below on why that directive has nothing to do with this error.

Last reviewed: 27 July 2026, against PHP 8 (every currently supported branch behaves identically for this setting). This guide is written for Noiz hosting and is kept current against PHP. It complements, and does not replace, the official PHP documentation linked below.

Official Documentation Reference

• PHP Manual: the memory_limit directive
• PHP Manual: per-directory .user.ini files
• PHP Manual: where and how configuration settings can be changed
• PHP Manual: setting a value at runtime with ini_set()
• Apache Manual: the RLimitMem directive (for comparison)

Prerequisites

• Access to your hosting control panel, or to your site files through File Manager or SFTP.
• The full error message, including the file path and line number it names. That path tells you which application is at fault and where a per-directory fix belongs.
• A backup copy of any configuration file you are about to edit, particularly .htaccess, since a single bad line there takes the whole site offline until it is corrected.

What the error is actually telling you

Every part of the message is useful, so read it before changing anything:

• Allowed memory size of 134217728 bytes is your current limit expressed in bytes. Divide by 1048576 to get megabytes, so 134217728 is 128M, 268435456 is 256M, and 536870912 is 512M. This number is the value you are about to change.
• Tried to allocate 20480 bytes is the request that pushed the script over the edge. It is rarely the culprit. In this example the script needed a further 20 KB and could not get it, which means the previous 128 MB had already been consumed by something else.
• In /path/to/file.php on line 512 is simply where the ceiling was hit, not necessarily where the memory was wasted. Treat it as a strong hint about which plugin, theme, or component to investigate, rather than as a confirmed diagnosis.

One further point that saves a lot of confusion: memory_limit applies to a single PHP request, not to your account as a whole. Setting it to 512M does not reserve half a gigabyte permanently. It means any one script is allowed to grow to that size before PHP stops it.

Why "RLimitMem max" does not fix this

Older articles, including an earlier version of this one, recommended adding RLimitMem max to .htaccess. Do not use it for this problem.

RLimitMem is an Apache directive. It sets the operating-system memory limit for processes that Apache itself launches as child helpers, historically CGI scripts. It never touches PHP's own memory_limit value, so the number in your error message will not budge. Where the server accepts the directive in .htaccess at all, it does nothing on a site running PHP-FPM or FastCGI, because those PHP processes are not started by Apache. Where the server does not accept it, the line returns a 500 Internal Server Error and leaves the situation looking worse than it was.

PHP's memory ceiling is a PHP setting and has to be changed in a place PHP reads. That means your control panel, a .user.ini file, a php_value line where PHP runs as an Apache module, or the script itself. Those four methods are covered below.

Decide whether to raise the limit at all

The PHP default is 128M, which is comfortable for the great majority of sites. A memory error is often a symptom rather than the illness, so it is worth thirty seconds of thought before reaching for a bigger number:

• Did it start suddenly? If the site was fine yesterday and the only change was a plugin update or a new extension, suspect that change first. A runaway loop or a query that loads an entire database table into an array will exhaust any limit you set.
• Is the failed allocation tiny? A script that dies while asking for a few kilobytes has already burned through everything it was given. Raising the limit may buy a few seconds and then fail again slightly later.
• Is the task genuinely heavy? Resizing large images, importing or exporting sizeable datasets, generating PDFs, running Composer, or operating a busy WordPress site with a page builder are all legitimate reasons to need more than 128M. Here, raising the limit is the correct answer.

Where raising it is justified, 256M is the usual first step and 512M is a reasonable ceiling for a shared site. Avoid -1, which means unlimited: on shared hosting a single faulty script would then be free to consume everything available. If 512M is still not enough, that is evidence of a code fault, not of a limit set too low.

How to raise the limit

The right method depends on how PHP runs on your account. The methods below are ordered from most reliable to most situational. If you are unsure which applies, start with the control panel, which works in every case.

Method 1: Your hosting control panel (recommended)

Setting the value in the panel applies it at account or subscription level, so it takes effect regardless of whether PHP runs as FPM, FastCGI, or a module, and it survives changes to your site files.

• Plesk: open Websites & Domains, select the domain, click PHP Settings, set memory_limit to your chosen value, and click Apply or OK.
• DirectAdmin: open the PHP configuration for the domain and edit memory_limit for the PHP version the site is actually using. If more than one version is installed, changing the wrong one is the most common reason nothing happens.
• cPanel: open MultiPHP INI Editor, select the domain, and set memory_limit there.
• ISPConfig: open the website under Sites, go to the Options tab, and add the value to the custom PHP settings field for the site.

Where an account uses the CloudLinux PHP Selector, that is the correct place to make the change instead. Step-by-step instructions are in How to Increase or Decrease PHP Memory Limit via CloudLinux Selector in cPanel and the DirectAdmin equivalent.

Method 2: A .user.ini file (PHP-FPM and FastCGI)

Most current hosting runs PHP as FPM or FastCGI rather than as an Apache module. On those setups the correct file-based approach is a .user.ini file, and .htaccess will not work at all.

1. Using File Manager or SFTP, open the folder your site runs from, normally the document root such as httpdocs, public_html, or web.
2. Create a plain-text file named exactly .user.ini, noting the leading dot. Enable Show hidden files in your File Manager if you cannot see it afterwards.
3. Add this single line and save:

   memory_limit = 256M

Allow a few minutes. PHP caches .user.ini files, by default for 300 seconds, so a change can take up to five minutes to appear. Reloading the page repeatedly in the first minute and concluding that the file does not work is the classic mistake here.

Note the syntax difference between the two file types. A .user.ini file uses ini syntax with an equals sign, while .htaccess uses Apache syntax with a space. Mixing them up produces a file that is silently ignored, or a 500 error, depending on which way round you get it wrong.

Method 3: .htaccess (only where PHP runs as an Apache module)

The classic .htaccess method works only when PHP is loaded as an Apache module, commonly called mod_php. On that kind of setup, add this line to the .htaccess file in your document root:

php_value memory_limit 256M

If the error persists on one particular area of the site, add the same line to an .htaccess file inside the folder named in the error message, for example yourdomain.com/wp-admin/.htaccess. Settings in a subfolder override the parent for requests served from that folder.

If the site returns a 500 error the moment you save, your server is not running mod_php. Remove the line immediately and the site will recover, then use Method 1 or Method 2 instead. This is the expected outcome on most modern hosting and is not a sign that anything is broken. If you need a walkthrough of editing the file itself, see How to Edit the .htaccess File in the cPanel File Manager.

Method 4: Inside the script (targeted and temporary)

If only one script needs the extra headroom and you are able to edit it, raise the limit at the top of the file, before any heavy work begins:

<?php
ini_set('memory_limit', '256M');

This suits a one-off import, a migration script, or a scheduled maintenance job, and it keeps the higher limit away from every other request on the site. It will not help if memory is exhausted before execution reaches that line, and it has no effect where the host has locked the setting.

WordPress: the wp-config.php constants

WordPress applies its own limit on top of the PHP one, which is why a site can still report memory errors after the server value has been raised. Add these lines to wp-config.php, above the line that reads /* That's all, stop editing! */:

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

WP_MEMORY_LIMIT governs the public side of the site and WP_MAX_MEMORY_LIMIT governs the admin area and cron tasks, which is why an import can fail in the dashboard while the front end behaves perfectly. Neither constant can exceed the limit PHP itself allows, so raise the PHP value first and these second.

Confirm the new limit is live

Do not assume the change took. Create a file named something unguessable such as meminfo-check.php in your document root, containing:

<?php
echo 'memory_limit = ' . ini_get('memory_limit');

Load it in your browser and read the value. Delete the file as soon as you have the answer so it is not left publicly reachable. If the figure still shows the old value, the change was made somewhere PHP is not reading, and the troubleshooting notes below cover the usual reasons.

Command-line scripts follow a different setting

PHP on the command line, including WP-CLI, Composer, cron jobs that call the PHP binary directly, and Drush, reads its own configuration and ignores both .user.ini and any web server setting. Command-line PHP is frequently configured with no limit at all, which is why an import that fails in the browser often succeeds when run over SSH. If a command-line task does hit the limit, raise it just for that run:

php -d memory_limit=512M yourscript.php

Running a heavy import or migration this way is usually a better answer than permanently raising the limit for every visitor request on the site.

Troubleshooting

The site returned a 500 Internal Server Error after editing .htaccess: PHP is not running as an Apache module on your account, so php_value is not a recognised directive. Remove the line, confirm the site loads again, and use the control panel or a .user.ini file instead.

The value refuses to change: check for something overriding it. A control panel setting generally beats a file-based one, a .user.ini in a subfolder beats one in the document root, and an ini_set() call inside the application beats them all. Confirm too that you edited the settings for the PHP version the site actually runs, since accounts with several versions installed make this easy to get wrong.

The change appeared to do nothing, then worked later: that is the .user.ini cache, which holds values for five minutes by default. Nothing is wrong.

It still runs out of memory at 512M: this is a code fault rather than a configuration problem in almost every case. Disable recently added or updated plugins and extensions one at a time until the error stops, and look closely at anything that loads a whole database table, a whole directory listing, or a whole file into memory in one go. Raising the number again simply moves the failure point.

Raising the limit helps briefly, then the error returns: a hosting account can also have a ceiling on the total physical memory all its processes may use at once, which is separate from PHP's per-script memory_limit. If PHP reports the higher figure but scripts are still being cut off, the account may be reaching that ceiling and the workload has probably outgrown its current plan.

The error only appears on one page or one action: note the file path in the message and treat it as the starting point. A single plugin, a single oversized image, or a single report that queries everything at once is a far more likely explanation than a limit that is broadly too low.

Need a hand?

If the error will not clear, Noiz support can check exactly how PHP is configured on your account, apply the correct value in the right place, and read the server error log to identify which component is consuming the memory. Customers on a Noiz managed plan can simply open a support ticket and Noiz will take care of it. Include the full error message, the affected URL, and which of the methods above you have already tried, so the team can get to the cause quickly.