Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extreme memory usage from using RP1KCT's 'start sim from <time>' feature #3089

Closed
al2me6 opened this issue Aug 11, 2021 · 2 comments
Closed
Assignees

Comments

@al2me6
Copy link
Collaborator

al2me6 commented Aug 11, 2021

Steps for reproduction:

  1. Create a new game with RP1 (doesn't matter if sandbox or career, just needs access to its KCT fork).
  2. Add a number of vessels (~20?). Could be asteroids.
  3. Build any vessel (probe core works).
  4. In the KCT window, click 'simulate', then fill in a large duration (at least 1 year, I had to use ~3 years for a save with only some asteroids) in the 'time from now' box.
  5. Click 'simulate'.

Observe that memory usage steadily increases once the Principia UI pops up on the loading screen. This continues until either the computation finishes (seen via CPU usage) or, if there are sufficient vessels and the duration is long enough, the computer crashes due to OOM. If the computation does finish, memory usage will slowly decrease (at about the same rate as it increased at) back to normal levels, at which point the scene loads.

Egg noted on Discord that this might be due to Principia not handling large single timesteps well.

The relevant code in KCT is https://github.com/KSP-RO/RP-0/blob/6ce79fe5ac84b9c655dcd9439aa3bba04968d0f0/Source/KerbalConstructionTime/KerbalConstructionTime.cs#L974.

Journal here, if that's useful: https://drive.google.com/file/d/11DBpYpjVfcmcA1HpiQDQ29G5H3xvnyA6/view?usp=sharing

@pleroy pleroy self-assigned this Aug 17, 2021
@pleroy
Copy link
Member

pleroy commented Aug 17, 2021

I have been able to reproduce the problem, thanks for the journal.

We have a bunch (~10) vessels doing PileUp::DeformAndAdvanceTime(a_long_time) (I saw 566 days). We generate trajectories for all these pile-ups, with about 5 million points, each point using 128 bytes. That's about 6 GiB (at the time when I interrupted the replay, I'm sure it would have happily grown more).

We have threads doing WaitForVesselToCatchUp, of course, and they will ultimately get the pile-up trajectories and downsample them, but they are stuck until all the pile-up integrations are done.

This never happens in the real game, because we call DeformAndAdvanceTime on short times and then we transfer the trajectories to the vessels, where they get downsampled.

A proper fix would require major restructuring of the way that vessels and pile-ups interact. I don't see this happening any time soon.

@pleroy
Copy link
Member

pleroy commented Sep 29, 2021

I am going to close this issue because I believe that it was fixed by the above KSP-RO pull request.

@pleroy pleroy closed this as completed Sep 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants