A WordPress error that says “allowed memory size exhausted” is not fixed by blindly setting every PHP value to 9999M. The right WordPress PHP limits depend on what failed: memory exhaustion, a large media upload, a slow import, or PHP worker saturation during checkout. Raise the specific limit, verify that PHP is actually using it, then identify the plugin, query, or traffic pattern that created the pressure.
For most established WordPress sites, start with a 256M PHP memory limit, a 256M WordPress admin memory limit, a 64M upload limit, a 64M POST limit, and a 120-second execution time. WooCommerce stores, large builders, and import-heavy sites may need more. Those numbers are starting points, not a performance strategy.
What WordPress PHP limits control
PHP limits are guardrails imposed by the PHP runtime. WordPress runs inside PHP, so when a request reaches one of those guardrails, it fails, times out, or waits behind another request.
The limits most site owners encounter are memory, upload size, POST size, execution time, input variables, and PHP-FPM workers. They do not all live in the same place, and that is where generic advice goes wrong.
| Setting | What it controls | Practical starting value |
|---|---|---|
memory_limit | Memory available to one PHP process | 256M |
upload_max_filesize | Maximum size of one uploaded file | 64M |
post_max_size | Total size of a POST request | 64M or higher than upload limit |
max_execution_time | Maximum PHP execution time | 120 seconds |
max_input_vars | Fields PHP accepts in one request | 3000-5000 |
PHP-FPM pm.max_children | Concurrent PHP requests | Based on RAM and real worker usage |
A critical distinction: PHP memory is allocated per process, not per site. Setting `memory_limit = 512M` does not reserve 512 MB all the time. It permits each active PHP worker to reach that ceiling. On a server with 20 busy workers, an unnecessarily high limit can turn a plugin problem into RAM exhaustion and swapping.
Check the active limits before changing anything
The WordPress dashboard can show part of the picture. Go to Tools > Site Health > Info > Server and look for PHP memory limit, upload max filesize, PHP time limit, and max input variables. This is useful, but it does not reveal PHP-FPM worker capacity or whether a reverse proxy has its own upload restriction.
For command-line access, run:
wp eval 'echo "WP memory: " . WP_MEMORY_LIMIT . PHP_EOL; echo "PHP memory: " . ini_get("memory_limit") . PHP_EOL; echo "Upload: " . ini_get("upload_max_filesize") . PHP_EOL; echo "Post: " . ini_get("post_max_size") . PHP_EOL; echo "Time: " . ini_get("max_execution_time") . PHP_EOL;'Run the command from the WordPress document root and under the same user and PHP version serving the site. If your host uses different PHP handlers for CLI, web requests, cron, and staging, values can differ. That mismatch explains many cases where a change appears correct in SSH but the browser still reports the old limit.
Also inspect the actual failure. A memory error is usually logged as `Allowed memory size exhausted`. A timeout often appears as `Maximum execution time of 120 seconds exceeded`, a 504 gateway timeout, or an upstream timeout in the NGINX error log. Do not treat those as interchangeable.
Set WordPress PHP limits in the right layer
The server-level PHP configuration is the source of truth on managed hosting. Depending on the stack, that may be a PHP-FPM pool configuration, a PHP INI file, or a hosting control panel. Changes there apply predictably and survive WordPress updates.
A typical PHP INI configuration looks like this:
memory_limit = 256M upload_max_filesize = 64M post_max_size = 64M max_execution_time = 120 max_input_vars = 5000After changing PHP-FPM settings, reload or restart PHP-FPM. Editing a file without reloading the service leaves running workers on the old configuration.
You can also set WordPress memory constants in `wp-config.php`, above the line that says “That's all, stop editing!”:
define('WP_MEMORY_LIMIT', '256M'); define('WP_MAX_MEMORY_LIMIT', '256M');`WP_MEMORY_LIMIT` affects normal front-end requests. `WP_MAX_MEMORY_LIMIT` is intended for the WordPress administration area and memory-intensive tasks such as updates and image processing. Neither setting can override a lower PHP `memory_limit`. If PHP is capped at 128M, setting WordPress to 256M changes nothing.
Avoid putting PHP directives in random places because a blog post said it worked. `php_value` directives in `.htaccess` can trigger a 500 error when PHP runs through PHP-FPM. `ini_set()` works only for directives PHP allows at runtime, and many hosts disable it. A per-directory `.user.ini` file may work, but it can take several minutes to refresh and is often overridden by the host.
WordPress PHP limits for common failures
Memory exhaustion during updates, Elementor, or imports
Start at 256M. If a known, legitimate job still fails, raise it temporarily to 384M or 512M and observe the logs. A WooCommerce import with thousands of variable products can reasonably need additional memory. A normal page view that consumes 400M usually indicates inefficient plugin code, oversized autoloaded options, runaway object graphs, or a query returning far too much data.
Check the PHP error log after the increase. If the failure moves from memory exhaustion to slow execution, you have exposed the next bottleneck rather than fixed the underlying workload.
Media uploads that fail despite a higher upload limit
`upload_max_filesize` is only one gate. `post_max_size` must be equal to or larger than it, preferably with room for multipart form overhead. NGINX can also reject the request before PHP sees it through `client_max_body_size`.
For a 64 MB media upload, use at least:
upload_max_filesize = 64M post_max_size = 70MLarge video files are often a poor fit for the WordPress Media Library regardless of limits. They consume disk, backups, bandwidth, and PHP processing. Use an appropriate video delivery workflow instead of turning a content upload into a server capacity problem.
Checkout delays and 502 or 504 errors under traffic
Do not raise `max_execution_time` first. WooCommerce cart, checkout, account, and admin requests are commonly uncached. If all PHP workers are busy, the next shopper waits in the queue, then the web server may return a 502 or 504.
This is a PHP-FPM capacity issue, not a simple PHP time-limit issue. Measure average worker memory during representative traffic, reserve RAM for MySQL, Redis, the operating system, and cache, then size `pm.max_children` conservatively. More workers improve concurrency only while CPU and RAM have headroom. Beyond that point, they amplify database contention and make TTFB worse.
Fast CPU cores help with short WordPress requests, but hardware cannot rescue slow third-party API calls, uncached database queries, or a plugin doing expensive work on every checkout request. On high-frequency infrastructure such as WP Tango's AMD Ryzen 9950X platform, the remaining gains still come from controlling query cost, object caching, and worker contention.
Truncated menus, page builder forms, or bulk-edit screens
Raise `max_input_vars` when complex forms silently lose fields after saving. Large navigation menus, WooCommerce variations, and page builder settings can exceed the default 1000 variables. Set it to 3000 first, then 5000 if the form still requires it.
Do not set it to an extreme number without reason. Very large form submissions consume parsing time and expand the request attack surface. The right value is the smallest one that preserves the complete form.
Treat higher limits as a diagnostic tool, not a permanent patch
When a limit increase resolves an error, record the original value, the new value, the failing action, and the observed memory or execution time. Then test the workflow on staging after plugin updates. This is especially important for agencies managing multiple sites, where a single page builder update can alter request memory dramatically.
Keep PHP versions current, clear or restart opcode caches after deployments when appropriate, and monitor PHP-FPM queue length, worker utilization, slow logs, database load, and 95th-percentile TTFB. Those metrics tell you whether limits are protecting a healthy site or hiding a workload that is getting more expensive every week.
A well-sized limit should let legitimate work finish while making abnormal behavior visible. If increasing a value only makes the server fail later and louder, stop raising it and inspect the code path that is consuming the resource.
