The fatal message states the configured memory ceiling and the allocation PHP attempted when it ran out. The named file is not always the original consumer; it may simply request the next few bytes after another component filled memory.
Raising the limit can restore a legitimate workload, but it can also let a loop consume the whole server. Measure first.
Capture the complete fatal
Match the request timestamp with the PHP log and record allowed bytes, attempted allocation, file, line and call stack.
Also record:
web or CLI request
URL/action
PHP version and handler
cart/import/media size where relevant
recent code/config changeRedact filesystem account names, query values and customer data.
Check the effective limits
WordPress can define WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT, while PHP and hosting enforce their own ceilings. Inspect the value in the failing web/CLI context.
error_log( 'Memory limit: ' . ini_get( 'memory_limit' ) );
error_log( 'Peak bytes: ' . memory_get_peak_usage( true ) );Use temporary protected logging and remove it. Do not print configuration to public pages.
Reproduce with measured inputs
Use staging with the same PHP, plugins and a sanitised dataset. Compare a small and failing import, image, page or administrator action.
If peak memory grows roughly with item count, batching may solve it. If it grows on every repeated callback, inspect accumulation or recursion.
Profilers can add overhead; use them in staging unless the production investigation is explicitly controlled.
Establish a normal baseline
Measure the same request with the smallest valid input, then with representative production data. Record peak memory before and after the component’s main callback.
The absolute number matters less than the growth curve. A fixed overhead may be acceptable, while several extra megabytes for every post will fail at scale. Repeat the request to detect caches or static variables that grow across a long-lived PHP worker.
Find unbounded data loads
Search the call path for WP_Query, get_posts(), raw database fetches and APIs that retrieve all records. Request IDs or required fields instead of complete objects.
$ids = get_posts( array(
'post_type' => 'post',
'posts_per_page' => 100,
'fields' => 'ids',
) );Paginate further for large sites. A limit of 100 is illustrative, not a universal batch size.
Inspect media and file processing
Large source images decompress to much more memory than their file size. PDF generation, archive extraction and image regeneration can exceed otherwise reasonable limits.
Check pixel dimensions, colour depth and enabled image sizes. Optimise sources and process media in bounded CLI/background batches.
Do not disable security validation on uploaded files just to reduce processing.
Isolate the responsible component
Use the call stack and controlled comparison to disable one plugin, theme function or custom snippet in staging. Check must-use plugins and drop-ins separately.
A generic memory fatal after an update may reflect a changed hook sequence or duplicate registration. Compare versions and changelogs.
Do not edit WordPress core or deactivate unrelated production components randomly.
Set capacity responsibly
When normal measured peak is legitimate and the current limit too low, raise it through cPanel, Plesk or supported PHP configuration.
Multiply per-worker memory by possible concurrent PHP workers and leave RAM for MySQL, web server and operating system. A high per-request ceiling can cause system OOM kills under traffic.
Use CLI with its own planned limits for exceptional maintenance tasks.
Verify peak and recurrence
Repeat the original action and a larger boundary case while logging peak memory. Confirm public pages and concurrent administrator requests remain healthy.
Recurring care should trend memory fatals and peak use after releases. The durable repair identifies the workload, bounds it and sets a limit supported by real server capacity.