Reproduction Steps
To reproduce this memory leak, you should analyze the memory stats of the client or the server, depending on where the constraints are being created.
From what I have investigated, this memory leak occurs from constraints, such as WeldConstraints for example. Once the parts they are connected to are gone, the memory increases but never decreases.
I have made a repro place for this memory leak (uncopylocked).
1. Press the red button in the left 2. Take note of the “Memory” label (“Last” label serves as utility for this, by logging only the memory before the process begins) 3. Press the button again, to stop the part creation / destruction
Once these steps are done and/or repeated, you should notice the memory having increased from its original value every time the process is executed.
Expected Behavior
PhysicsPart is expected to decrease once created parts are destroyed. When there are no WeldConstraints involved, the memory decreases back to normal.
Actual Behavior
The PhysicsPart memory increases, but does not decrease once the parts are destroyed. This is very severe for large server games where many players are constantly joining, spawning in and using / creating constraint-heavy assets such as vehicles. In Glacier’s case for example, this results in server crashing.
Issue Area: Engine Issue Type: Performance Impact: Very High Frequency: Constantly
Edit: Thanks to @Camstcha’s insight, I’d like to note that there is in fact no memory leak. The apparent “memory leak” is just the garbage collector not having been activated. You can see this by creating a snapshot in LuaHeap; the memory will go back to normal.
Are you graphs from a repro in Studio or in a live game?
Context:
I just ran your test on an RCC + connected client and this “leak” stabilizes around 125 MB + I’m seeing 400MB of Untracked Memory on the RCC. After that point it stabilizes and never leaks above this.
In Studio, we have something called the “Change History Service”. Change History Service maintains a history of objects that used to exist in Roblox Studio so that you can undo. If you are testing memory leaks in Roblox Studio you will not get good results as Change History Service will extent the lifetime of objects in memory indefinitely in some cases until a critical memory point is triggered.
Hey, thanks for the reply,
I made sure the graphs and analysis obtained were done in-game as I am aware Studio is not reliable for tests like this, specially when memory is involved.
This is behavior we notice every time constraints are involved, including in the game we linked as an example Glacier. We have a system that allows us to spawn in vehicles, but also destroy them. Another for morphs, but also removing them. (and so forth)
Every time a vehicle is spawned in but removed right after, the memory increases but never goes down. Eventually, the server crashes given this has happened enough times.
I can’t really spot anything in the scripts that could result in them being the cause of the memory increase (and the dev console doesn’t indicate script memory to increase), but PhysicsPart does increase but never go down. Perhaps there’s something we’re doing wrong with how we spawn the vehicle in? What causes PhysicsPart to increase?
The UntrackedMemory being unusually high is also noticeable though, I’m not sure if it’s related as it seems to occur in empty baseplates as well.
I just went in-game in Glacier where the leak is specially noticeable (since it’s a big open world with vehicles and morphs constantly being created and destroyed), and this is what the memory in the server looks like:
I’m not sure how exactly this occurs… all I can really show is what I can analyse from this data.
Even if there ends up being no problem in the engine here we’re still at a loss, this issue has been affecting our game severely with constant server crashes every few hours after a build up of those values and from what we could gather it started happening seemingly randomly as well.
You for sure don’t have any object references being held by scripts on the server?
If you have a table that still holds a Part Reference (maybe for logs or something else), it will keep that part from being deleted.
I still haven’t fully identified what the Untracked Memory is. There are a few standard containers for objects in the engine that “expand” over use and stabilize at a max size once your heaviest load has been used with the process.
I’m asking someone to investigate what the untracked memory is in the mean time.
We are having identical serious memory leak issues over time which appear spread out over UntrackedMemory, PlaceMemory and CoreMemory at Pinewood Computer Core, a large game with vehicles, trains and parts that are damaged or explode, and regenerate throughout the facility.
This issue started happening around the same time as this thread and server memory could reach and exceed 5 GB after only 2 hours runtime! This is a new problem we’ve never had before which seems to have appeared without any game updates. I look forward to any updates on this thread as it seems to be our problem as well.
I can confirm this is still an issue as of today, with servers crashing after total server memory reaches a high enough threshold over time. The amount of memory stored seems to vary by server, there is a chance it may be correlated to what happens with physics objects in game being removed and respawned as well as having many constraints, such as the trains and vehicles.
Here’s how much memory a server from Pinewood Computer Core accumulates after a few hours, we can’t work out where its coming from.
Any word on this? I am experiencing the exact same scenario, constant physics parts climb in server memory with vehicles that contain constraints regenerating. Servers are unusable after persisting for 3+ hours.
This is one of the bugs in the engine that won’t allow us to go beyond what’s possible in ROBLOX due to the possible high memory usage even higher than games created in Unreal Engine; one solution that could potentially work is to make these part Instances to become a ModuleScript and loaded only when needed.
Why does storing parts in ReplicatedStorage increases PhysicsPart and not ServerStorage?
One thing I’ve noticed is when they’re unstored in ReplicatedStorage or workspace in the server is that it decreases PhysicsPart by almost zero.
When part instances is created purely by the client, then it’ll never increase PhysicsPart. But if we tried to clone a part instances in the client from ReplicatedStorage, then deletes it in the server - that part will still remain to have PhysicsPart memory. If only ReplicatedStorage does not increase PhysicsPart then this could solve a lot of problems.
Assets used here are called ‘Customization’ and ‘Muscles’ folder, they have CanCollide to false, Massless to false and I’ve taken measure for everything that could possibly affect PhysicsPart.
This video adds in both Customization folder and Muscles folder; which were assets requested from ServerStorage and was just re-parented to ReplicatedStorage. [SERVER]
This video uses a custom ‘ModuleScript’ to load it on client-only inside the ReplicatedStorage.
I cannot send the file in public but if any roblox staffs want to request it, please DM me.
Bump. PhysicsParts has been very high in my game, never dropping below 1,000 MB. We have a pretty large and detailed map, but we frequently use unions and meshes. Anchored parts are occasionally inserted into Workspace from the server for ability effects. All parts inserted from the server have CanCollide, CanQuery, and CanTouch all turned off (if that makes a difference at all) and are all cleared correctly.
Gonna bump this again. I’m not sure if it’s an issue on Roblox’s end or if I’m doing something wrong. Either way, I’d like some type of response because PhysicsParts is taking by far the most memory in my experience. Does anyone know how to reduce the memory cost?
Hey, I know it’s been two years, but I may have found the cause for the memory leak.
It seems that when destroying a Weld, Roblox does not actually remove its Part0 and Part1 references. This could potentially be the case for instances such as Beams and Trails, where attachments are referenced in Attachment0 and Attachment1.
I modified the demo to iterate through the object’s descendants, and remove any Part0 and Part1 reference and then disable the weld, and it seems like that fixes the memory leak.
Hopefully this is useful for patching it in-engine… would help out as I believe a lot of games are afflicted by this without knowing how to fix it!
for i, v in ipairs(Clone:GetDescendants()) do
if v:IsA("WeldConstraint") then
v.Part0 = nil
v.Part1 = nil
v.Enabled = false
end
end
