Memory Limits — WordPress and System

WordPress memory is controlled by multiple limits across WordPress, PHP, and the services around it (web server, OPcache, database, Redis). If one layer is lower than the others, requests can fail with "memory exhausted" errors even on servers with plenty of physical RAM.

Quick Summary

If PHP hits memory_limit, raising only WP_MEMORY_LIMIT in wp-config.php won't help. Set limits so each layer steps up cleanly and leaves enough headroom for the OS and background services.

The Operational Memory Hierarchy

When a dynamic PHP request runs, it passes through multiple boundaries.

memory-stack-hierarchy.txt

External Browser Request
  → WordPress Primary Execution (WP_MEMORY_LIMIT)
      → WordPress Admin Execution (WP_MAX_MEMORY_LIMIT)
          → Global PHP Engine Threshold (php.ini memory_limit)
              → Web Server Soft Limit (LSAPI memory limit)
                  → OPcache Reserve (compiled bytecode limits)
                      → Database Arrays (MariaDB buffer pool)
                          → Object Storage (Redis memory)
                              → Physical OS Limitations (SWAP Overflow)

System Execution Boundaries

Layer Boundary	Variable Declaration	Configuration Origin	Primary Function	Safe Baseline Parameter
1	WP_MEMORY_LIMIT	wp-config.php	Determines standard frontend rendering requirements.	128M – 256M
2	WP_MAX_MEMORY_LIMIT	wp-config.php	Allocates processing power for heavy /wp-admin/ arrays.	256M – 512M
3	PHP memory_limit	php.ini	Global cap on the exact size a single PHP process handles.	512M – 1024M
4	LSAPI Soft Limit	OLS WebAdmin Panel	Threshold protecting the server from rogue localized workers.	512M – 1G
5	Compiled Cache	OPcache Directives	Dictates the ceiling for pre-computed bytecode arrays.	256M – 512M

Rule of thumb: keep total allocations under ~80% of physical RAM so the OS has headroom for caches, buffers, and background processes.

Catastrophic Misconfiguration Vectors

The WordPress vs. PHP Collision

The most prevalent engineering failure occurs when WordPress assumes memory availability that PHP physically forbids.

wp-config.php (Incorrect Implementation)

define('WP_MEMORY_LIMIT', '512M'); // Demands half a Gigabyte

php.ini (Corresponding Restriction)

memory_limit = 128M ; Lower than the WordPress config above

Consequence: Elementor operations or WooCommerce flows can fail. WordPress may request more memory, but PHP will terminate the process when it exceeds memory_limit.

The Runaway Worker Equation

Over-allocating PHP workers can starve the OS and other services.

www.conf (Aggressive Allocation)

pm.max_children = 50
php_admin_value[memory_limit] = 512M

Consequence: 50 workers x 512M is a theoretical 25GB peak. On an 8GB VPS this can trigger swapping or the OOM killer terminating critical processes.

Resolution Engine: Enforce strict mathematical limitations. Available PHP execution RAM / Avg Worker Footprint = max_children.

Rapid Diagnostics Procedures

Interrogate the physical node instantly to witness real-time memory allocations.

diagnose-live-memory.sh

# Evaluate RAM (watch the 'available' column)
free -m

# Show the top 15 memory-consuming processes
ps aux --sort=-%mem | head -15

# Check OPcache memory usage (if OPcache status is available)
php -r "print_r(opcache_get_status()['memory_usage']);"

# Read the InnoDB buffer pool size
sudo mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Common Mistakes & Troubleshooting

Engineering Failure	Analytical Symptom	Remediation Execution
Inverted Directives	Backups and massive imports crash immediately at 3% completion.	Verify WP_MAX_MEMORY_LIMIT explicitly eclipses WP_MEMORY_LIMIT. Default WordPress logic forces Admin boundaries downward if misconfigured safely.
Redis saturation	Redis grows until it competes with the OS and other services.	Configure maxmemory and an eviction policy (example: allkeys-lru) appropriate for your workload.
Swap thrashing	The server becomes extremely slow and iowait rises.	Reduce memory allocations (buffer pools/workers) or increase physical RAM.

Target Quick Reference

Memory Hierarchy Verification

Execute this verification sequence after applying changes:

1. Confirm memory_limit cleanly exceeds WP_MAX_MEMORY_LIMIT.
2. Confirm WP_MAX_MEMORY_LIMIT cleanly exceeds WP_MEMORY_LIMIT.
3. Force Redis caps.
4. Bound MariaDB precisely under 50% physical limits.

What's Next

• File Descriptor Limits (ulimit -n)
• TCP Tweaks
• HugePages
• Memory Architecture