The script outgrew PHP's memory_limit. Raise it for a real workload, but treat it as a leak symptom in long scripts or a plugin/WordPress bloat issue — not something to paper over forever.
memory_limit defaults to 128M; big CSV imports, bulk media processing, or large report generation legitimately need more. php -r 'echo ini_get("memory_limit");' shows the current value.
Queries returning unbounded rows into arrays, appending in a loop without unsetting, or a plugin bug. Raising the limit just delays the same crash — profile before you raise.
php -r 'echo ini_get("memory_limit");' ; php -i | grep -i memory_limit # web SAPI may differ from CLI
# php.ini: memory_limit = 512M ; or .htaccess: php_value memory_limit 512M ; or wp-config.php: define('WP_MEMORY_LIMIT', '512M');
php -d memory_limit=1G import.php
# log memory_get_usage() at loop iterations; check queries fetching entire tables; wp-cli --skip plugins to isolate a plugin
WP_MEMORY_LIMIT only affects WordPress; the real ceiling is PHP's memory_limit — set both consistently. Recurring exhaustion on normal traffic is a bug (often a plugin), and unlimited limits just move the crash to OOM at the server level.
512M-1G covers most real workloads. Beyond that, suspect a leak. The limit exists to protect the server from one bad script — removing it entirely is a self-inflicted DoS risk.
Memory consumption depends on the data flowing through — each run allocates differently before hitting the same ceiling. That randomness signature = leak/loop, not a static workload.
Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.
Browse the template store →One-time. Yours to modify. Instant download from the NinjaOps template store.