[wp-trac] [WordPress Trac] #57625: WP_Query cache memory leak

[WordPress Trac]

#57625: WP_Query cache memory leak
--------------------------+------------------------------
 Reporter:  owi           |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Cache API     |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  performance
--------------------------+------------------------------

Comment (by owi):

 @spacedmonkey it seems that could be a good separation (maybe?) but that
 circles back to my original question

 > That was my thinking - is there a possibility that query caches belong
 to its own cache group and we flush it on certain events? Or even better
 by setting an event in cron as it might be tricky/countrproductive doing
 that during regular operation? Is moving keys between cache groups
 backwards compatible in the WordPress context?

 Is moving keys to its own cache group backwards compatible? Can we do it
 at all considering how WordPress dev tries to not break backwards
 compatibility?

 Regarding your last question:
 >  There are other query caches that been in core for years, so is this
 such a problem now?
 My perspective may be anegdotic but I am managing quite high traffic WP
 installations since years (hundreds thousands daily), all built on
 composer, redis with CI/CD etc. and all previous query caches were
 behaving quite well and if there was a mem leak then it was usually a
 developers fault (mostly due to going around WP built-in functions).

 Since 6.0 with the terms and 6.1 with the posts query the redis can fill
 up within day or two... And for example generate 1.2m keys out of which
 1.1m is wp_query out of which 95-99%+ are already invalid ;) And once
 editor just opens up gutenberg screen then `last_changed` is bumped up and
 the story starts again :)

 The best example of how this story is problematic is trying to reproduce
 the steps from my original posts. Fresh WP, fresh DB, opening new posts
 screen depending on conditions spawns few wp_query keys and only last ones
 are valid. Refresh it few times and you have 20 invalid keys. Multiply it
 by 10k or 100k+ posts and 20+ users and its a recipe for a disaster.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57625#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform