-
Notifications
You must be signed in to change notification settings - Fork 41
Mitigating memory explosions from difficult negotiations #130
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can confirm that memory is being freed after negotiations 👍
Looks like this PR is more than just the trim call, so I don't feel qualified to approve it. I did have one really tiny suggested change though. |
Co-authored-by: Geoffrey Biggs <gbiggs@killbots.net>
Yeah, the trim is really just to make sure that the explosions are truly temporary and to not alarm anyone who looks at the memory usage of the fleet adapter. The other changes are what was really needed to keep the memory explosions from being unsustainably large, in particular these changes are making it so that difficult planning jobs are being discarded when they're no longer useful instead of being allowed to grow obscenely large and eventually die off with no benefit. |
This PR should help mitigate the fleet adapter memory explosions that were sometimes being caused by difficult negotiations.
This does not fix the underlying issue of the motion planner utilizing large amounts of memory, but it makes it so that planning work being done for negotiations are managed more carefully, and as a result we should see a much lower ceiling for high the memory explosions can get.
A later PR will address the core issue of the motion planner's memory usage. For now this should PR should be sufficient to prevent fleet adapters from using up so much memory that they risk crashing.