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

Moodle cron memory growth

When running php admin/cli/cron.php on a site, the process RSS steadily rises, even though each scheduled task completes quickly. The feature under scrutiny is Moodle’s cron‑driven task processing, which handles both scheduled tasks (executed on a timetable) and adhoc tasks (queued for asynchronous work). The main uncertainty lies in whether the growth is caused by per‑task cleanup, the worker’s process lifetime, or the retry/backoff policy that keeps failed adhoc tasks in memory.

Because PHP’s memory_get_usage reports allocation and the OS RSS reflects allocator reuse, a single successful run cannot distinguish between a true leak and delayed garbage collection. The goal is to attribute the memory increase to a specific part of the task lifecycle and decide on a corrective strategy that preserves throughput while preventing runaway memory use.

Which component of the task processing chain is most likely responsible for the sustained RSS rise? Does the current retry/backoff implementation retain task objects across cron invocations? Would recycling the cron/worker process after each scheduled task mitigate the growth without sacrificing performance?