Render cache memory usage grows continuously during sustained page rendering

Short answer

Yes — enable automatic garbage collection of orphaned cache tags on sites using the database cache backend, but understand that it will not fix your PHP memory exhaustion. These are two separate problems: the memory growth is a process-level leak (addressed by the render cache fix you mentioned), while cache_tags GC is a storage-hygiene measure that keeps the table bounded. Apply the leak fix first, verify memory is stable, then turn on tag cleanup via cron.

Separating the two problems

Continuously growing PHP memory during sustained rendering almost always comes from accumulating render array metadata, static caches, or repeated entity loads inside a long-running process (drush, queue workers, test runners). The cache_tags table lives in the database — it consumes disk, not PHP memory. A bloated cache_tags table can slow tag invalidation lookups, but it cannot exhaust the PHP memory limit by itself.

Confirmed behavior: the database cache backend records tag invalidations in cache_tags, and rows belonging to deleted cache items are not removed automatically by default, so the table grows unboundedly on write-heavy sites. Drupal core provides an opt-in tag garbage collection mechanism that purges orphaned/invalidated tag records during cron rather than on every request.

Should GC be on by default?

For your site: yes, enable it. The cost is a periodic DELETE against cache_tags during cron, which is far cheaper than the alternative — an ever-growing table that degrades invalidation performance and complicates backups. Running cleanup on every request would add DELETE queries under load; keep it on cron only.

Frequency

• High-churn sites (frequent content edits, cache clears, commerce): run it with each cron run.
• Low-traffic sites: daily is sufficient; the risk of running it too rarely is just a larger table, not data loss.

Verification steps

1. Confirm the memory leak is closed: profile memory_get_usage() (or a profiler) across a sustained render loop before and after applying the render cache fix. Memory should plateau, not climb linearly.
2. Check cache_tags row counts before and after a cron run with GC enabled:

drush sqlq "SELECT COUNT(*) FROM cache_tags;"
drush cron
drush sqlq "SELECT COUNT(*) FROM cache_tags;"

The count should drop after cron if orphaned rows existed.

1. Review cron logs to confirm the cleanup task runs, and measure its duration once against a production-sized cache_tags table so you know the worst-case cron cost.

Caveats

Exact GC configuration names and availability vary by Drupal core minor version — confirm against your installed version's documentation before relying on a specific setting key. If memory still grows after the fix, the remaining suspect is custom code holding references in a long-running process, not the cache backend.