Moodle cron memory growth: is scheduled‑task cleanup leaking?

Short answer

The most likely cause is not a leak in task cleanup and not the retry/backoff logic — it is the lifetime of the single PHP process that runs admin/cli/cron.php. Moodle executes all due scheduled tasks and then drains the adhoc queue inside one process. PHP's Zend allocator frees memory for reuse inside the process but rarely returns it to the OS, so RSS climbs monotonically even when every task cleans up correctly. Globals like $DB, $CFG, and the MUC caches also accumulate a retained baseline as more code and definitions load.

Does retry/backoff retain task objects?

No. Failed adhoc tasks are written back to the mdl_task_adhoc table with an incremented faildelay (exponential backoff) and re-read from the database on the next run. Retry state lives in the database, not in process memory, so a growing backlog adds DB rows and work per run — which can indirectly raise memory by making each run longer — but it does not pin PHP objects across invocations. You can confirm this directly:

SELECT classname, COUNT(*) AS n, MAX(faildelay) AS max_delay
FROM mdl_task_adhoc GROUP BY classname ORDER BY n DESC;

Separating allocator noise from a real leak

RSS alone cannot distinguish the two. Instrument a run by logging memory_get_usage(true) (real emalloc allocation) before and after each task, alongside RSS from getrusage() or /proc/self/status:

• If memory_get_usage(true) returns to baseline after each task while RSS keeps climbing, you are seeing allocator retention — expected, and not a bug in your tasks.
• If real usage climbs monotonically, one task is genuinely leaking — typically a plugin registering static references, an unbounded in-memory cache, or circular references the cycle collector only reclaims periodically. Re-run cron with only that task enabled to isolate it.

Also compare with Opcache disabled for CLI (php -n admin/cli/cron.php or opcache.enable_cli=0) to rule out shared-segment artifacts inflating RSS readings.

Would per-task process recycling help?

Restarting PHP per task would reset RSS, but it fights Moodle's design: each spawn re-pays bootstrap, config load, and cache warmup, so throughput drops noticeably on sites with many small tasks. Cheaper mitigations, in order of preference:

1. Cap work per run using Moodle's task processing limits so a single process handles a bounded number of adhoc tasks, and run cron more often with shorter runs.
2. Wrap cron in a supervisor that bounds lifetime — e.g. a systemd service with MemoryMax= or a wrapper that exits after N minutes — so the OS recycles the process between runs rather than mid-task.
3. If instrumentation proves a real leak, fix the offending plugin; no process-management strategy outruns a monotonic leak indefinitely.

Avoid hard-killing cron mid-task: it can leave stale cron locks and requeue adhoc tasks. Verify exact runner behavior (lock handling, faildelay backoff) against your installed release's lib/classes/task, since internals vary between Moodle versions.