Two of the runtime's lookaside tables grow with how much has happened rather
than with how much is in use, and nothing takes an entry out again:
discord_members - one JSON member object per (guild, user) ever seen in a
member window. Scrolling a large guild's member list puts thousands in, and
they stay for the life of the process.
matrix_reaction_targets and matrix_own_reactions - one entry per
reaction event seen. take_matrix_reaction_target removes an entry when a
redaction resolves against it, which is the minority of reactions; its doc
comment claims this keeps the map from growing unboundedly, and it does not.
Small in absolute terms next to the arena finding above - a few megabytes -
so this is hygiene rather than the cure. Filed because it is exactly the shape
of thing that becomes the cure on a machine left running for a week.
The solution
A ceiling of 5,000 entries on each, applied on insert by a shared cap_cache
helper: past it, three quarters of the table is kept and the rest goes.
Which entries go is not chosen. A HashMap has no order to call oldest, and
keeping one would cost a second structure on every insert to save a lookup
that already knows how to fail - so the trade is deliberate and written down:
this may drop something in use, and what happens then is one more request.
Both tables are caches with a miss path.
Fixed in nobilis dbbc483 "Hold less of what a long day leaves behind", with a
test.
## The problem
Two of the runtime's lookaside tables grow with how much has happened rather
than with how much is in use, and nothing takes an entry out again:
- `discord_members` - one JSON member object per (guild, user) ever seen in a
member window. Scrolling a large guild's member list puts thousands in, and
they stay for the life of the process.
- `matrix_reaction_targets` and `matrix_own_reactions` - one entry per
reaction event seen. `take_matrix_reaction_target` removes an entry when a
redaction resolves against it, which is the minority of reactions; its doc
comment claims this keeps the map from growing unboundedly, and it does not.
Small in absolute terms next to the arena finding above - a few megabytes -
so this is hygiene rather than the cure. Filed because it is exactly the shape
of thing that becomes the cure on a machine left running for a week.
## The solution
A ceiling of 5,000 entries on each, applied on insert by a shared `cap_cache`
helper: past it, three quarters of the table is kept and the rest goes.
Which entries go is not chosen. A `HashMap` has no order to call oldest, and
keeping one would cost a second structure on every insert to save a lookup
that already knows how to fail - so the trade is deliberate and written down:
this may drop something in use, and what happens then is one more request.
Both tables are caches with a miss path.
Fixed in nobilis dbbc483 "Hold less of what a long day leaves behind", with a
test.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The problem
Two of the runtime's lookaside tables grow with how much has happened rather
than with how much is in use, and nothing takes an entry out again:
discord_members- one JSON member object per (guild, user) ever seen in amember window. Scrolling a large guild's member list puts thousands in, and
they stay for the life of the process.
matrix_reaction_targetsandmatrix_own_reactions- one entry perreaction event seen.
take_matrix_reaction_targetremoves an entry when aredaction resolves against it, which is the minority of reactions; its doc
comment claims this keeps the map from growing unboundedly, and it does not.
Small in absolute terms next to the arena finding above - a few megabytes -
so this is hygiene rather than the cure. Filed because it is exactly the shape
of thing that becomes the cure on a machine left running for a week.
The solution
A ceiling of 5,000 entries on each, applied on insert by a shared
cap_cachehelper: past it, three quarters of the table is kept and the rest goes.
Which entries go is not chosen. A
HashMaphas no order to call oldest, andkeeping one would cost a second structure on every insert to save a lookup
that already knows how to fail - so the trade is deliberate and written down:
this may drop something in use, and what happens then is one more request.
Both tables are caches with a miss path.
Fixed in nobilis dbbc483 "Hold less of what a long day leaves behind", with a
test.
Finished -
dbbc483a32