Problem/Motivation
Drupal\Core\Cache\MemoryBackend::garbageCollection is a no-op.
When testing a long-running drush process that creates 100s of thousands entities we stumbled upon a memory issue. RAM consumption was growing with every iteration. This was not unusual. It's a single process and all the created entities were landing in the entity cache. Easy-peasy, let's just clear the entity cache for the unwanted entity types with $storage->resetCache(), right?
Not really. :) This had no effect on the memory consumption. MemoryBackend::resetCache only updates the expires property and removal should be done in ::garbageCollection, which looks like this:
public function garbageCollection() {
}
Steps to reproduce
- Load an entity
- Call
$storage->resetCache() - Run
\Drupal::service('entity.memory_cache')->garbageCollection(); - Get the cache item with
$allow_invalidset to TRUE
Proposed resolution
Remove invalid cache items when ->garbageCollection() is invoked.
Remaining tasks
None.
User interface changes
None.
Introduced terminology
None.
API changes
None.
Data model changes
None.
Release notes snippet
Drupal\Core\Cache\MemoryBackend::garbageCollection() removes invalid cache items from memory.
Issue fork drupal-3480025
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3480025-memory-cache-allow-gc
changes, plain diff MR !9816
- 3480025-there-is-no
changes, plain diff MR !9815
Comments
Comment #2
blazey commentedComment #3
blazey commentedComment #5
blazey commentedComment #8
blazey commentedAdded the method body.
Comment #9
smustgrave commentedThanks for reporting!
Will most likely need a test case showing this bug
Nice issue summary!
Comment #10
tstoecklerThanks for this, this is very helpful!
I have run into this issue lots of times and have come into the habit of copy-pasting the following stanza to various services in various projects for exactly this purpose:
I never figured out how to properly solve this issue, though, great work on that! Not sure how to write a test for this, as the concrete memory usage at any given point is always a bit unpredictable, but maybe someone will have an idea. Definitely bookmarking this and will give this a spin when I get a chance.
Comment #12
dcam commentedI added a test.
Comment #13
dcam commentedComment #14
smustgrave commentedTest coverage appears to be there https://git.drupalcode.org/issue/drupal-3480025/-/jobs/7435887
Since we are touching memory can we add a simple CR? May be overkill but think it would be nice.
Comment #15
dcam commentedI created the change record at https://www.drupal.org/node/3559908. In this case, there isn't anything that implementing code needs to change, so I didn't include before and after examples.
Comment #16
smustgrave commentedThanks for taking care of that!
Comment #17
catchThe problem in the issue summary should already be fixed by #3498154: Use LRU Cache for static entity cache in the sense that there's a cap on the number of items in the entity memory cache now, so manual memory management shouldn't be necessary.
However implementing this method seems fine, didn't review the MR yet.
Comment #20
catchCommitted/pushed to 11.x and cherry-picked to 11.3.x, thanks!