WordPress PHP Settings: memory_limit, Upload Limits, OPcache, PHP-FPM

This article is a localized edition of the Japanese original. Read the Japanese original

Many WordPress problems, such as out-of-memory errors, large images that won't upload, or admin saves that time out, come down to PHP settings. This article covers the PHP settings you most often need to review for WordPress: how to check them, where to change them, and reasonable values.

As of October 2026, the official WordPress site recommends PHP 8.3 or later. The examples in this article also assume PHP 8.3 (the standard package on Ubuntu 24.04).

Check your current settings

Check in Site Health (recommended)

In the admin, go to "Tools" → "Site Health" and open the "Info" tab.

• The "Server" section: PHP version, PHP SAPI (how PHP runs), PHP memory limit, PHP time limit, upload max filesize, PHP post max size, PHP max input variables, opcode cache, and more
• The "WordPress Constants" section: the values of WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT

These are the values of the PHP that actually runs WordPress. Use this screen to confirm your changes, too.

A caveat when checking from the command line

If you log in to the server and run php -i or php --ini, you see the settings of the command-line (CLI) PHP. It often reads different files from the PHP-FPM that the web server uses, so it isn't a reliable way to check the values WordPress sees.

On Ubuntu, the configuration files are split like this:

To see which files PHP-FPM reads, run:

php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"

You can also put a PHP file that calls phpinfo() in the public folder, but that exposes detailed server information to anyone. If you use it, delete the file right after checking.

Settings worth reviewing and suggested values

• If post_max_size is smaller than upload_max_filesize, the effective limit is post_max_size. Raise both together when you raise the upload limit
• The PHP manual says memory_limit should be larger than post_max_size
• The suggested values are typical for an ordinary WordPress site. Decide them together with the server's memory and the number of PHP-FPM workers (covered below)

Where to change the settings

Where you can change them depends on how PHP runs (the "PHP SAPI" in Site Health) and on the type of server.

On a VPS (PHP-FPM)

Instead of editing php.ini itself, add a separate settings file. It is less likely to be overwritten by package updates, and your changes are easy to see.

; /etc/php/8.3/fpm/conf.d/99-wordpress.ini
memory_limit = 256M
max_execution_time = 120
max_input_time = 120
max_input_vars = 3000
upload_max_filesize = 64M
post_max_size = 64M

; In production, log errors instead of showing them on screen
display_errors = Off
log_errors = On

After saving, check the syntax and then reload:

sudo php-fpm8.3 -t
sudo systemctl reload php8.3-fpm

If you use Nginx, a higher upload limit can also run into Nginx's client_max_body_size (default 1MB). If you see 413 Request Entity Too Large, review the Nginx configuration as well.

As an Apache module (mod_php)

You can put the settings in the .htaccess file in the WordPress folder.

php_value memory_limit 256M
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 120
php_value max_input_vars 3000

php_value only works when PHP runs as an Apache module. On a server that runs PHP-FPM or CGI, it can cause a 500 error. For shared hosting, see also How to change PHP settings with .htaccess.

On shared hosting (FPM/CGI)

If your host's control panel has a PHP settings screen, use it. If not, place a .user.ini file in the WordPress folder (the same place as wp-config.php). It uses the same syntax as php.ini.

; .user.ini
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120
max_input_vars = 3000

By default, .user.ini is re-read every five minutes (user_ini.cache_ttl = 300), so changes can take a few minutes to apply. Settings that can only be changed in php.ini (including most OPcache settings) can't be changed in .user.ini. If your host enforces a cap, you can't go above it.

How WP_MEMORY_LIMIT in wp-config.php actually works

WordPress can raise memory_limit by itself based on constants in wp-config.php.

<?php
// Add above the "That's all, stop editing!" line in wp-config.php
define( 'WP_MEMORY_LIMIT', '256M' );     // Limit for the front end and general use
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Limit for the admin and image processing

WordPress core (wp-includes/default-constants.php) handles them as follows:

• If you don't define WP_MEMORY_LIMIT, the default is 40M (64M on Multisite)
• WordPress raises memory_limit to WP_MEMORY_LIMIT only when it is larger than PHP's memory_limit. If PHP's value is larger, it does nothing (it never lowers it)
• In the admin and during image processing, it raises the limit to WP_MAX_MEMORY_LIMIT (default 256M, or PHP's value if that is larger)
• If the server doesn't allow memory_limit to be changed, both constants stay at PHP's value

In other words, the wp-config.php constants don't override PHP's settings; they raise the limit, within what is allowed, when PHP's setting is lower. If errors continue, check PHP's own memory_limit first. Fixing out-of-memory errors is also covered in How to raise the memory limit in wp-config.php.

Check and tune OPcache

OPcache is a built-in PHP feature that keeps compiled PHP files in memory and reuses them on later requests. WordPress loads many PHP files on every page view, so having it enabled reduces the work per request.

The OPcache defaults in PHP 8.3 already work as-is for many sites.

If you have many plugins and the number of PHP files is close to the limit, count the files before raising it.

# Count the PHP files in WordPress
find /var/www/html -name "*.php" | wc -l

; Example additions to /etc/php/8.3/fpm/conf.d/99-wordpress.ini
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000

Keep these points in mind:

• Leave opcache.validate_timestamps at 1. WordPress rewrites files when you update plugins, themes or core from the admin. With 0, old code may keep running after an update
• Since WordPress 5.5, core clears the OPcache entry for each file it rewrites during an update (wp_opcache_invalidate()). Code that calls opcache_reset() yourself after every update is generally unnecessary
• Each PHP-FPM pool has its own OPcache. Running opcache_reset() from the command line, for example with wp eval, does not clear the web side's OPcache. To clear everything, reload PHP-FPM with sudo systemctl reload php8.3-fpm
• opcache.fast_shutdown, which appears in older articles, was removed in PHP 7.2. Setting it has no effect

How to check OPcache usage is explained in WordPress OPcache settings.

Decide the number of PHP-FPM workers

If your VPS uses PHP-FPM, the number of requests it can handle at once is set by the pool's worker count (pm.max_children). Ubuntu's default is pm.max_children = 5, which can be too low for a busy site.

Set pm.max_children by dividing the memory available to PHP by the memory per worker. First, measure how much memory the workers actually use (running this during busy hours gives a more realistic number).

# Show the number of php-fpm8.3 processes and their average memory (MB), including the master process
ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=$1; n++} END {printf "%d processes, avg %.0f MB\n", n, s/n/1024}'

For example, if a server has 4GB of memory, you leave 1.5GB for the database, the OS and so on, PHP can use 2.5GB, and each worker averages 60MB, then 2500 ÷ 60 ≈ 41, so set pm.max_children to about 40. A single worker can grow up to memory_limit, so leave some headroom.

; Change the matching lines in /etc/php/8.3/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 40
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12
; Recycle a worker after it handles this many requests (limits memory growth)
pm.max_requests = 500

sudo php-fpm8.3 -t
sudo systemctl reload php8.3-fpm

pm.start_servers must be at least pm.min_spare_servers and no more than pm.max_spare_servers. For detailed tuning with the status page and the slow request log, see How to optimize PHP-FPM on a VPS.

Confirm the changes took effect

1. Open "Tools" → "Site Health" → "Info" → "Server" again and check that the values changed
2. You can also check the upload limit in the "Maximum upload file size" note on the Media "Add New Media File" screen
3. If nothing changed, check that the file you edited is one PHP-FPM (or Apache) actually reads, that you reloaded it, and that you aren't hitting a cap set by your host

Summary

• Check settings in the "Info" tab of Site Health. php -i shows the command-line values, so be careful
• Where to change settings depends on how PHP runs: a file in conf.d for PHP-FPM, .htaccess for mod_php, and the control panel or .user.ini for FPM/CGI on shared hosting
• WP_MEMORY_LIMIT only raises PHP's memory_limit when it is lower; it never lowers it or goes past a limit the server forbids changing
• OPcache is enabled by default. Leave validate_timestamps at 1 and don't use opcache.fast_shutdown
• Set PHP-FPM's pm.max_children by dividing the available memory by the memory per worker

Related articles:

• How to raise the memory limit in wp-config.php
• How to change PHP settings with .htaccess
• WordPress OPcache settings
• How to optimize PHP-FPM on a VPS

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)