Amazing find! Is this necessary to do with regular Welds (not WeldConstraints) as well?
2 Likes
Hi, it seems like this affects all instances that reference other instances, such as ObjectValues, Beams, Trails, Welds, Motor6Ds, etc.
4 Likes
Insane. Thank you so much for discovering and sharing this, youâre genuinely a life saver. My experience has a lot of welds frequently being added and destroyed, so this is a major impact on the server memory usage for me.
I suggest you make another bug report about this to try to get the attention of Roblox engineers.
1 Like
Has this been fixed internally? I personally tested this in studio but I havenât seen any immediate change even with the fix, but maybe it was because I was testing in studio and in-game.
Bump. Have been experiencing PhysicsPart being above 2.5g+ at certain times.
Game has lots of car spawning and deleting.
1 Like
Bump, againâŠ
I confirmed that it happens. I had to debug this particular issue for 10 hours, Iâm so mad I didnât see this bug report earlier. Lesson learned - use Google duhâŠ
The graph is making patterns as if it is screaming for help and trying to draw something, interestingâŠ
Depending on your case it can be completely linear or get wavy like that, sometimes even drawing whole smooth curves. I know this means absolutely nothing, but just a nice thing to admire if you are bored. Couldnât find any fixes. I disabled all physics simulation, all client effects, all networking, everything, literally just spawning NPCs and killing them right after. By now I am 100% positive I am clearing and destroying everything correctly. First I thought the memory leak was by a script until I finally after hours of scrolling pin-pointed it to PhysicsParts.
Funny enough it has been a bug for quite a long I guess. I found a messages on the Roblox OSS Discord server, but I donât think they are effective or can solve it. I donât believe this is due to strong references because it doesnât make sense. Not only do I :Destroy() all of the parts, but I also self.Model = nil completely manually and it still doesnât work. Any references to the already deleted class are also removed, but even if they exist itâs just nil isnât it? Not an expert, but for me logically this sounds correct. I also did ran a check to see if any death events donât work, everything gets cleared, nothing is left, both server and client.
2 Likes
Bumping again. This is STILL happening. Look at how unhappy my character is.
EDIT: Gonna give a bit more context as to what Iâve tried doing to fix this.
When I was looking into it a bit further, I found out that the usage of the Precise collision fidelity in my game might have been the culprit. So I changed every single union/meshpart in the game to Hull.
The memory usage for PhysicsParts had no noticeable change.
I then thought that it mightâve had something to do with the mobs in my game and their pathfinding or something, so I disabled mob spawning entirely to see if it would change anything.
Again, there was no noticeable change.
Then, MetatableIndex showed his findings with Weld properties not being cleared up properly. So I wrote a script to check when any Welds, Beams, Trails, etc. were removed using game.DescendantRemoving and cleared their Part0 and Part1 properties.
Again, NO NOTICEABLE CHANGE in the memory usage.
This also happens in instanced servers (like small rooms where you fight bosses) so it isnât related to the map.
This has to be an issue on Robloxâs end because Iâm all out of ideas.
1 Like
Hi all, I wanted to give a quick update on some internal investigations and to clarify some points:
- With respect to humanoid respawning, there was in fact a small networking memory leak that has been resolved. Thanks everyone for helping us identifying this issue! Caveat, however:
- Memory leak identification is not straightforward, and the small leak above may not actually have much of an impact on some of the cases here.
- I want to note that many of the increases and graphs here are simply indicating increased buffer memory: this is a common pattern within the engine to reduce slow de-allocation / re-allocation patterns by preserving already allocated space. As stated by khanovich, a lot of the apparent memory increases are simply indications of this buffer increase, which slowly level off over time.
Understandably, itâs very difficult to separate this buffer memory increase, as well as potential lua-related reference memory leaks, from actual potential internal leaks, and we donât have great tools for this, internally or with studio. I wasnât able to find any reliably physics-specific memory leak in any of the remaining attached place files. I may be wrong, though!
If any of you have a place file with minimal Lua, whose physics (or any) memory does not plateau eventually (in fact crashes!), thatâs the clearest indication that would really help us investigate any potential remaining tangible physics issues here. Again, that plateau may be quite high (>500 MB or so), so donât let the initial increase fool you â for better or worse, that is intended behavior.
7 Likes
I usually donât reply to helpful replies but this was the best thing Iâve learned this year. My 100 players servers had over 3gb+ of PhysicsParts memory after only an hour of being online which I assumed was from the cloning of bullet projectiles. I found that storing the parts in Workspace under the map and cloning/destroying from there doesnât leak PhysicsParts memory unlike ReplicatedStorage which does.
Also, sorry for the bump. Maybe this will get some new attention and testers to find a more permanent solution apart from this temporary one:
3 Likes