How to Fix the WordPress Memory Limit Error

The WordPress memory limit error is fixed by finding which layer is enforcing the limit, not by blindly adding RAM. Check the web request's PHP value, compare it with wp-config.php and PHP-FPM, then isolate the plugin, theme, or operation consuming the memory. Raise the limit gradually only after confirming the VPS can support it.

What does the WordPress memory limit error mean?

I usually meet this error while someone is trying to upload a large image, run an import, or open an administration screen with too many plugins loaded. The message means one PHP request reached its configured memory_limit. It does not automatically mean the VPS has run out of RAM.

The error often contains Allowed memory size of ... bytes exhausted. A low PHP limit, a heavy plugin, theme code, a large import, or too many PHP-FPM workers can all be involved. The useful question is not simply “how do I add more memory?” It is “which layer is refusing the allocation, and why?”

Reading the two values in the error

A typical PHP error looks like this:

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 40960 bytes)

268435456 bytes equals 256 MiB. PHP reached its 256 MiB limit and stopped while trying to allocate another 40 KiB. The tried to allocate value is not the total memory already in use; it is the final allocation that failed.

The WordPress constants WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT cannot create a limit above what PHP permits. If PHP’s memory_limit is lower, WordPress may not be able to use the value it requests.

Read the error first. Convert the exhausted byte value to MiB, then verify PHP’s actual memory_limit separately. That distinction prevents a surprising number of unnecessary VPS upgrades.

Find the current PHP memory limit before changing anything

In the WordPress dashboard, open Tools > Site Health > Info > Server to see the PHP version and memory limit. That value belongs to the PHP SAPI serving the web request. It may not match the output of php -i over SSH.

For an initial command-line check, run:

php -r 'echo "memory_limit=" . ini_get("memory_limit") . PHP_EOL;'

This reports the CLI configuration. A site using PHP-FPM may load a different php.ini from the one used by CLI PHP. Small detail, large consequences.

On Debian and Ubuntu systems, these commands show the installed PHP version, configuration paths, and FPM services:

php -v
php --ini
systemctl list-units --type=service 'php*-fpm.service'

php --ini shows the main configuration file for CLI PHP, which is why it is not enough by itself. The FPM service may be named php8.2-fpm or php8.3-fpm. Check the systemctl output instead of guessing the service name.

To inspect the value used by the web request, you can temporarily create a PHP file containing ini_get('memory_limit'). Delete it immediately after testing. A public phpinfo() page can expose more version, path, and environment information than you intended.

If WP-CLI is installed, inspect the WordPress constants with:

wp eval 'echo WP_MEMORY_LIMIT . PHP_EOL . WP_MAX_MEMORY_LIMIT . PHP_EOL;'

This prints the values WordPress defines. Do not treat it as proof of PHP’s effective limit until you have checked the PHP SAPI serving the site.

Compare the layers. Record the memory values from CLI PHP, PHP-FPM, and WordPress separately. I once changed the WordPress value first and then wondered why nothing changed; CLI PHP was reporting a different configuration from the web request.

Can wp-config.php increase the WordPress memory limit?

Two constants are commonly set in wp-config.php:

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

WP_MEMORY_LIMIT is the target for normal site requests, while WP_MAX_MEMORY_LIMIT is used for administration and some background operations. Add the lines before the That's all, stop editing! comment. If a constant already exists, edit that definition rather than adding a second one.

These settings do not manufacture RAM. If PHP has a memory_limit of 128M, asking WordPress for 512M will usually have no effect. The hosting environment may also restrict ini_set and related changes.

Back up the file and check its syntax before editing it. On a system with WP-CLI installed, from the WordPress directory:

cp wp-config.php wp-config.php.bak
php -l wp-config.php

php -l checks PHP syntax only; it does not prove that WordPress is loading this particular file. I check the site root and file ownership first, because editing a staging copy by mistake is an unnecessarily quiet way to waste an hour.

WordPress’s developer documentation does not prescribe one universal value for these constants. The right setting depends on the site, its plugins, and the available server capacity. A content site may work comfortably at 256M, while image processing or a large import may need more temporary memory.

Change one thing. Take a backup, change one value, and repeat the failing dashboard operation before making another adjustment.

Raise PHP’s memory_limit at the correct layer

When the WordPress constants do not help, inspect PHP itself. The method depends on whether PHP runs as an Apache module, PHP-FPM, or through a hosting control panel. Do not copy a setting from a different server and assume the handler is the same.

Using php.ini

Use php --ini to find a PHP configuration path, but remember that it may show the CLI file. Confirm the FPM configuration path through the service configuration and your distribution’s documentation. The setting looks like this:

memory_limit = 256M

After changing it, reload or restart the matching FPM service:

sudo systemctl reload php8.2-fpm

Use restart instead if a reload is not supported or if the service documentation calls for it. Replace the PHP version with the one installed on your server. I have seen a runbook say php8.2-fpm when the machine actually had 8.3 installed. Verify first.

.user.ini and control panels

Shared hosting and restricted VPS environments may support a .user.ini file:

memory_limit = 256M

PHP-FPM may not read a changed .user.ini immediately. The delay depends on user_ini.cache_ttl, so wait a few minutes before deciding that the setting failed. With cPanel, Plesk, or a similar panel, changing the PHP option in the panel is usually safer.

In some Apache setups, this may work in .htaccess:

php_value memory_limit 256M

On PHP-FPM or CGI installations, the same line can produce a 500 error. Do not add it until you know how the web server runs PHP. A configuration experiment that takes the whole site down is not a useful experiment.

Identify the SAPI first. Change the setting at that layer, then confirm the value through an actual web request.

Which plugin or theme is consuming the memory?

Raising the limit may reduce the symptom without removing the cause. Backup tools, image resizing, XML or CSV imports, page builders, and ecommerce plugins can all process large data sets.

Start by enabling the WordPress log carefully:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Errors are commonly written to wp-content/debug.log. On a production site, setting WP_DEBUG_DISPLAY to true can show implementation details to visitors. Turn debugging off after the test, or handle the log according to your existing logging policy.

Search the log for plugin and theme paths:

grep -nEi 'Allowed memory size|memory exhausted|wp-content/plugins|wp-content/themes' wp-content/debug.log | tail -n 50

If /wp-content/plugins/example-plugin/ appears repeatedly, that plugin is a strong candidate, not automatic proof. The same code may be called by a cron task, REST request, or administration screen.

For isolation, deactivate plugins one at a time in staging. With WP-CLI:

wp plugin list --status=active
wp plugin deactivate plugin-directory

Disabling every plugin on production at once can break payments, caching, or security controls. Take a snapshot or verified backup first, then use a short maintenance window if the test must happen on the live site.

When reviewing How to Install WordPress on a VPS: Step-by-Step Guide, keep the PHP version, FPM service, and file ownership in the same troubleshooting record. Changing only the application layer leaves half the picture missing.

Test one variable at a time. Disable plugins and the theme one at a time in staging, and repeat the same failing request after every change.

Check PHP-FPM workers and total VPS memory

PHP’s per-request limit and the VPS’s total RAM are different constraints. In PHP-FPM, pm.max_children limits the number of PHP processes that can run at once. Setting it high without measuring each worker’s real RSS can cause swap usage and 502 responses.

free -h
ps -eo pid,ppid,rss,cmd --sort=-rss | head -n 15
systemctl status php8.2-fpm --no-pager

The rss value is in KiB. If the ten busiest PHP processes each use roughly 180 MiB, pm.max_children = 20 could theoretically require about 3.6 GiB. That calculation still leaves nothing for the operating system, database, or web server.

A rough starting calculation for an FPM pool is:

safe max_children ≈ RAM available for PHP / average RSS of one PHP process

This is only an estimate. Validate it with ps, FPM status metrics, and monitoring data during busy periods. If available memory is falling, swap is continuously growing, or the kernel logs contain OOM messages, increasing memory_limit is not the right first response.

For the process-level commands, see Linux Process Management: Using ps, top, and kill. During memory pressure, do not reach for kill -9 at random; first identify which service is creating the processes.

Measure before tuning. Check worker RSS, database usage, swap, and available RAM before changing pm.max_children.

Choosing between 256M and 512M

There is no single memory value that fits every WordPress installation. Separate ordinary page requests from heavy administrative work when choosing a starting point.

These ranges are starting points for diagnosis, not mandatory requirements. There is no general rule saying that WordPress, PHP, or a plugin always needs 512M.

If the error appears only during media uploads, inspect image dimensions and whether GD or ImageMagick is doing the processing, along with PHP execution time. If the dashboard works but the frontend fails, the theme template, query volume, or cache layer may be a better lead.

Increase gradually. Review RSS, swap, and error logs instead of jumping straight to 1G.

When the WordPress memory error continues

If the error remains after increasing a value, check these layers in order:

• Wrong PHP SAPI: CLI may show 512M while PHP-FPM still runs at 128M.
• Wrong file: Multiple WordPress installations or staging directories may exist.
• Configuration restriction: The hosting account may prevent changes to the directive.
• PHP version: A plugin or extension may not support the installed version.
• Real RAM pressure: FPM, MariaDB, and the web server may be consuming memory together.
• Broken code: An infinite loop or an unbounded array can fill the limit quickly.

Compare Nginx, PHP-FPM, and WordPress logs over the same time window. If the client sees HTTP 502, do not focus only on WordPress; an FPM process may have been killed or may have timed out. The layer-by-layer approach in How to Fix a 502 Bad Gateway Error is useful here.

Check disk space as well. A system that cannot write logs, create temporary files, or allocate new inodes can produce confusing symptoms:

df -h
df -i
journalctl -u php8.2-fpm --since "1 hour ago" --no-pager

A full disk is not itself a memory error, but it can remove the evidence you need and make PHP processes behave unexpectedly.

Keep the time window consistent. Compare WordPress, PHP-FPM, the web server, the operating system, and disk status for the same incident.

Reduce memory use instead of only raising the limit

The lasting fix is often to make the expensive operation smaller, not to write a larger number into a configuration file. Remove unused plugins; deactivating them leaves their files and update burden on the system. Keep active plugins updated, but test updates in staging first.

Resize images before uploading them. Split a large CSV import into smaller batches instead of one enormous PHP request. If WP-Cron runs heavily, consider scheduling it through system cron and preventing the same job from running in parallel.

Page caching, PHP OPcache, and database query analysis matter too. Arguing about TTFB to the millisecond before installing a cache is looking in the wrong place. Caching does not always fix a memory error, but it can reduce repeated PHP requests and lower pressure on the workers.

If the VPS is undersized, monitor CPU, RAM, disk I/O, and swap together. Adding RAM will not fix a plugin that grows its memory on every request. I keep Prometheus and Grafana on my homelab for this reason; a single uptime check cannot show what the PHP workers were doing between two successful requests.

After a memory change, keep monitoring data covering at least the busy period. Uptime Kuma shows availability, while PHP-FPM process counts, RAM, and swap require metrics such as those collected by Prometheus.

The next time you see this error, resist the urge to edit three configuration files at once. Check the web request, make one controlled change, and leave yourself enough evidence to know what actually fixed it.

Check These Before Raising the Limit

• Read the complete PHP error and convert the exhausted byte value to MiB.
• Verify memory_limit through the PHP SAPI serving the website.
• Compare CLI PHP, PHP-FPM, and WordPress memory values.
• Back up wp-config.php before editing its constants.
• Enable logging without displaying errors to visitors.
• Test plugins, themes, and heavy operations one at a time in staging.
• Measure FPM RSS, swap, disk space, and available VPS memory.

Frequently Asked Questions

Sources

• WordPress Developer Resources – wp-config.php — developer.wordpress.org
• PHP Manual – Core php.ini Directives — php.net
• PHP Manual – PHP-FPM Configuration — php.net
• WordPress Developer Resources – Debugging WordPress — developer.wordpress.org