Memory limit raised but site still slow: PHP-FPM, queries and plugins to check

Raising memory_limit in php.ini or in the .user.ini file makes the "Allowed memory size exhausted" message disappear. It doesn't make slowness disappear if the cause wasn't actually memory but a bottleneck upstream. Before touching that value again, it's worth checking three things: PHP-FPM processes, database queries, and plugins.

PHP-FPM: processes are the limit, not memory

Each PHP-FPM process consumes RAM for the entire duration of the request. If the maximum number of processes (pm.max_children) is too low relative to traffic, excess requests wait in a queue instead of being served: the site seems slow even if the CPU is not saturated.

To see this, enable the FPM status page by setting pm.status_path in the pool configuration. The status file provides information about the configuration and contents of the FPM status page. The fields to watch are: "listen queue" (requests waiting for a free process), "max children reached" (whether the maximum ceiling has ever been reached) and "memory peak" (the peak memory used by the pool). If "listen queue" is not zero or "max children reached" is 1, the number of processes is the real bottleneck, not the memory_limit value.

To calculate how many processes the machine can handle, the basic formula is:

pm.max_children = RAM available for PHP / average RAM per process

The average RAM per process is measured with ps -ylC php-fpm --sort:rss by looking at the RSS column. On a server with 4 GB of RAM and an average process of 70 MB, the calculation gives approximately 57, to be rounded to a conservative value of 55–60. The number should be written in /etc/php/[version]/fpm/pool.d/www.conf and requires a restart of PHP-FPM to take effect.

Slow queries: the database you don't see

A site can remain slow even with free PHP-FPM processes if each request waits on the database. The tool to discover this is the MySQL/MariaDB slow query log, which is turned off by default. It can be enabled at runtime with:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';

The default threshold value only logs queries above 10 seconds, which is too permissive for a website: lower it to 1 second or even 0.5 seconds to catch queries that slow down the page without ever reaching a visible timeout. To make it permanent after a database restart, the same directives should be written in the configuration file, typically /etc/mysql/my.cnf or /etc/mysql/mysql.conf.d/mysqld.cnf. The generated file can be read with mysqldumpslow or, on installations with Percona Toolkit, with pt-query-digest.

The plugin that generates no errors but consumes memory

The last suspect is a plugin that stays below the memory_limit threshold but uses almost all of it, slowing down every request without ever triggering the fatal error. To identify it on WordPress, the reference tool is Query Monitor, which adds a panel in the admin toolbar and allows you to determine which plugins generate duplicate or slow queries and how much PHP and memory each page component consumes.

A warning from the plugin's own official page: on pages with hundreds of queries, Query Monitor currently uses more memory than I would like it to, because of the stack trace recorded for each query. On sites already at the memory limit, it's best to use it for targeted diagnosis and disable it immediately after, rather than leaving it active in production.

In summary

If the site is still slow after raising memory_limit, the useful order of checks is: first the PHP-FPM queue (pm.status_path), then the database slow query log, and finally Query Monitor to isolate the responsible plugin. The memory_limit value alone tells you nothing about response time: it only tells you whether a request has reached or not exhausted the allocated memory.