A white screen with a fatal error about “allowed memory size exhausted” sends most site owners straight to raising a number in wp-config.php. Sometimes that fixes it. Often it just delays the same crash until the next heavy plugin update or bulk import. Understanding what memory_limit actually controls, and what it does not, will save you from guessing.
PHP Memory Limit vs Server RAM
These are not the same thing, and mixing them up leads to bad decisions. Server RAM is the total physical memory available on the machine, shared across the web server, the database, any caching layer, and every other process running on that box. PHP’s memory_limit is a per-process ceiling: the maximum amount of memory a single PHP script is allowed to use before PHP kills it.
A server with a modest amount of RAM can comfortably run PHP processes with a memory_limit of 256M each, because in normal operation almost no request actually uses anywhere near that ceiling. The limit is a safety valve, not a reservation. Setting memory_limit to 512M does not mean WordPress grabs 512M of RAM on every page load. It means a runaway script is allowed to climb that high before PHP stops it.
What Actually Consumes PHP Memory
Every plugin and theme loads code into memory on each request. A site running a dozen active plugins pulls in more classes and functions than a lean install, but most everyday page loads still stay well under a typical limit. The spikes come from specific operations:
- Image processing, especially resizing or manipulating large uploaded images
- Import and export tools handling large CSV or XML files
- Page builders assembling complex layouts server-side
- PDF or document generation
- Bulk operations run through wp-cli, like large search-and-replace jobs or migrations
- Plugin or core updates that load multiple subsystems at once
Object caching through Redis or Memcached actually reduces PHP memory pressure for typical requests, because expensive database queries get served from cache instead of recomputed. But that caching layer runs as its own service with its own memory allocation, entirely separate from PHP’s memory_limit. A generous PHP ceiling and a starved Redis instance are two unrelated problems that happen to share a server.
Reading the White Screen: Memory Exhaustion Errors
The classic error looks something like: “Allowed memory size of X bytes exhausted (tried to allocate Y bytes).” You’ll find it in your PHP error log, or in wp-content/debug.log if WP_DEBUG_LOG is enabled. The X value tells you the ceiling that was hit. The Y value tells you how much the script tried to grab when it failed.
There are actually two limits at play, and it’s easy to conflate them. WP_MEMORY_LIMIT is a constant WordPress itself enforces internally, with a modest default. WP_MAX_MEMORY_LIMIT raises that ceiling for admin-side and background tasks. But neither of these can exceed the real PHP-level memory_limit set by the server environment. Raising WP_MEMORY_LIMIT to 512M does nothing if the underlying PHP configuration caps requests at 128M. The PHP-level setting always wins.
How to Check and Change Your Memory Limit
The fastest way to see your actual PHP memory_limit is with wp-cli:
wp eval 'echo ini_get("memory_limit");'wp cli info will also show you the PHP version and configuration in use, which matters since PHP 8.1 through 8.3 are the current mainstream, and PHP 8.3 with OPcache enabled is a solid default for most WordPress sites today.
To raise WordPress’s own internal ceiling, add this to wp-config.php above the line that says “That’s all, stop editing”:
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');Remember these only raise what WordPress allows itself. If your host’s actual PHP memory_limit is lower, you’ll need to change it at the server level, through a control panel PHP settings screen, a php.ini or .user.ini override where your host permits it, or by asking your hosting provider directly. On a managed LiteSpeed environment this is usually a simple dashboard setting rather than something you edit by hand.
128M, 256M, or More: A Practical Guide
128M is the low end today. It can work for a lean brochure site running a handful of well-behaved plugins, but it leaves no headroom for image-heavy uploads, imports, or a page builder rendering a complex layout.
256M is a sensible modern default for most business sites and moderate WooCommerce stores. It gives enough headroom for typical plugin stacks and occasional bulk operations without inviting runaway scripts to consume unbounded resources.
512M and above makes sense for larger WooCommerce catalogs, sites doing heavy data imports or exports, or setups running several resource-hungry plugins simultaneously. Beyond that, you’re usually looking at a specific workload, not a general-purpose site.
Here’s the part that trips people up: more memory is not automatically faster. memory_limit is a safety ceiling, not a performance lever. A site that feels slow rarely needs a higher memory_limit; it needs faster storage, a proper object cache, or fewer redundant queries. PHP 8.3 with OPcache reduces the overhead of compiling PHP scripts on every request, which does far more for real-world speed than raising a memory ceiling ever will. Treat a memory exhaustion error as a diagnostic signal first: find out which plugin or operation triggered it, and only raise the limit once you understand why it happened. Otherwise you’re just postponing the same crash at a higher threshold.
Object Caching and Memory: A Separate Pool
It’s worth repeating because it’s a common point of confusion: Redis and Memcached, used for persistent object caching via a drop-in, manage their own memory pool on the server, configured independently of PHP’s memory_limit. A site can have a generous PHP memory ceiling and still suffer from a Redis instance that’s too small for its cached dataset, or vice versa. If you’re troubleshooting performance rather than a white screen, check both settings separately rather than assuming one covers the other.
The Takeaway
PHP memory_limit is a per-process ceiling, not a slice of server RAM, and raising it blindly treats a symptom rather than a cause. Use wp-cli to check your actual limit, read exhaustion errors for the plugin or operation that triggered them, and size your ceiling to your real workload: 128M for lean sites, 256M as a solid modern baseline, 512M or more for heavy imports and large stores. Pair a sane memory limit with PHP 8.3 and OPcache, and a properly sized object cache, and you’ll spend a lot less time staring at white screens.