Skip to content

feat(php): advise on PHP-FPM, OPcache and memory_limit bottlenecks - #1234

Open
karlitschek wants to merge 4 commits into
masterfrom
feat/php-advisor
Open

karlitschek wants to merge 4 commits into
masterfrom
feat/php-advisor

Conversation

@karlitschek

Copy link
Copy Markdown
Member

Based on feat/os-status-collector (#1214).

AI disclosure: this change was written with Claude Code (claude-opus-5-5) and is to be reviewed by the author before it leaves draft; every commit carries an Assisted-by trailer.

🤖 Generated with Claude Code

@karlitschek
karlitschek force-pushed the feat/os-status-collector branch from 6d327c2 to 34014ec Compare October 25, 2026 19:19
Base automatically changed from feat/os-status-collector to master October 25, 2026 19:24
@nextcloud-command nextcloud-command added the AI assisted This PR contains AI-assisted commits label Oct 25, 2026
karlitschek and others added 4 commits October 25, 2026 20:45
The PHP-FPM and OPcache checks are to run on the database advisor's
engine (Rule, RuleSet, Advisor, ExpressionEvaluator) rather than on a
second one. The engine is generic already: Snapshot is a map of
numbers with a flavour label, and nothing outside DatabaseController
picks a rule set by flavour. Three things were tied to databases, and
each now has an optional extension that leaves the database checks
exactly as they were:

- A rule skipped for a missing value always said "not present in this
  database's reports". A snapshot can now name the reason per key
  (Snapshot::$unavailable), e.g. "PHP-FPM does not run this page"; the
  database probe passes none, so its wording stays.
- An ApplyDescriptor had to recommend a value. Its closure may now
  return null, and the failing rule then comes without an apply, for
  when the snapshot gives nothing sound to recommend.
- The apply note was a fixed string. It may now be a closure over the
  snapshot, to say what a recommendation was computed from.

FLAVOUR_PHP names the new snapshot kind. The classes stay in the
Database namespace: moving them would touch every database file for
no change in behaviour.

Assisted-by: ClaudeCode:claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Signed-off-by: Frank Karlitschek <[email protected]>
The Status page prints the raw PHP-FPM counters (max children reached,
listen queue) and OPcache usage, but says nothing about what they mean
or what to change. GET /php/check runs nine rules on the advisor
engine the Database tab uses and returns them in the same shape:

- pm.max_children was reached: suggests a value from the memory
  available now (80 % of it) and the average private memory (RssAnon
  from /proc/<pid>/status) of the pool's workers that fpm_get_status()
  lists. Where no worker can be read (restricted mode, not Linux,
  open_basedir) memory_limit stands in as an upper bound, and the note
  says so. A second rule flags when there is no memory for more
  workers, instead of suggesting a value that would make it swap.
- requests waiting in the listen queue now, or at any time since
  PHP-FPM started
- OPcache memory nearly full or out-of-memory restarts, the interned
  strings buffer nearly full, and the script slots nearly used up.
  max_accelerated_files is compared through the prime OPcache rounds
  it up to, and the suggestion is one of those primes.
- revalidate_freq below 2 with validate_timestamps on, as a hint only
- memory_limit below Nextcloud's 512 MB, and, as a hint, the busiest
  number of workers times memory_limit exceeding RAM

Rules whose data is missing are skipped with the reason: no PHP-FPM
(mod_php, CLI), OPcache off or restricted, server memory unknown.

PHP-FPM and OPcache state belongs to the SAPI, so the endpoint reads
it live in the web request and never from a background job. It costs
two status calls and at most 64 short /proc reads, closes the session
first like the database check, and is admin-only by default.

Assisted-by: ClaudeCode:claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Signed-off-by: Frank Karlitschek <[email protected]>
The card sits below the PHP and OPcache sections and asks /php/check
when the page opens, so the PHP-FPM and OPcache numbers are those of
the web server's PHP. Failing checks come first, alerts before
warnings before hints, as the Database tab's rule cards. When nothing
fails it says so, and the passing and skipped checks with their
reasons stay folded away below.

The snippet dialog learned two more files: php.ini takes bare
directives with a ";" comment, and a PHP-FPM directive comes under the
header of the pool that served the request. PHP-FPM reopens a pool
section that appears twice, so the block may be appended to the
pool's file as it is. Its instruction names the file and that PHP-FPM
or the web server has to be reloaded rather than the database. The
database snippets are unchanged.

Assisted-by: ClaudeCode:claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Signed-off-by: Frank Karlitschek <[email protected]>
Assisted-by: ClaudeCode:claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Signed-off-by: Frank Karlitschek <[email protected]>
@karlitschek
karlitschek marked this pull request as ready for review October 25, 2026 20:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI assisted This PR contains AI-assisted commits

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants