There is an action in my game that results in the deletion of MeshPart instances and some ValueBase objects. Naturally, one would seem to think that removing these objects would reduce the memory load on the game. But it is creating the opposite effect: as I delete the objects (using Destroy()) the memory goes up, permanently?
Obviously this is frightening to me, because if the memory is going up and never going back down, that’s going to crash servers eventually. Is UntrackedMemory something I should be worried about, or am I misunderstanding its meaning?
I am able to replicate this. And confirm the deletion of MeshPart instances does result in UntrackedMemory going up, and quite rapidly. If I’m being completely honest this is quite weird.
Also, no, setting the MeshPart’s Parent to nil doesn’t help. You’re also right about the memory never going back down.
Sounds like the inconsistency I keep finding every time I play, for instance, Phantom Forces. When I review the memory, it sometimes end up higher if the server is old and less if it was fresh.
Was the StreamingSounds memory spikes fixed or is it still there?
Same issue here, I only use :Destroy() but the older the server the higher it’s latency and ping, resulting in wait times becoming way longer than they should be.
I’m glad that I’m not the only one experiencing this problem, at least it means it’s not something that I’m doing. At the same time, hopefully someone addresses this issue quickly.
@BuildThomas since this doesn’t seem to be a scripting mistake on my part, should this thread be moved to bug reports?
Edit: unless it’s not a bug and we’re unclear as to what is going on here. An explanation from one of the engineers would probably be the most helpful.
local m = game.ServerStorage.MeshPart
while true do
for i = 1,100 do
m:Clone().Parent = workspace
end
wait(0.5)
for i,c in ipairs(workspace:GetChildren()) do
if c:IsA("MeshPart") then
c:Destroy()
end
end
wait(2)
end
If you could make another attempt to make a repro it will help us investigate the core issue.
I recently redid my method and it continues to persist. I have MeshParts in a Folder and I use a for loop to delete them all. This results in the UntrackedMemory going up.
The code I use to delete them is as follows.
Edit: Removing the wait() so there was no delay resulted in it going up instantly. But as said before, it never went down, actually it continued to go up, albeit slowly.
local Meshs = game:GetService("Workspace"):FindFirstChild("Meshs"):GetChildren()
for _, mesh in pairs (Meshs) do
mesh:Destroy()
wait()
end
Thanks for the followup. I tried creating a place with only the script you posted and it did not repro the issue for me, so I think some other script needs to work together with the script you posted in order to trigger the issue. Do you have any other scripts that interact with the Meshs folder or its children?
Can you try enabling the stats hud (View → “Stats” section on the far right, toggle “Stats”, it should show a bunch of numbers on the screen. On the top left it should say “----- World -----”, and right under that it will have an Instance count. Does this instance count continue to increase in cases where you see the memory leak?
There are no other scripts in the place. That script is the sole user-created script in the place file.
I opened up the stats hud as you requested, and when MeshParts were getting deleted by a good, the instance part went up by about 1-4 for every 50 or so meshes deleted, however this number was subtracted sometime later, and the UntrackedMemory went down 0.5 when it happened. However having the script yield with a wait() causes UntrackedMemory to go up and down repeatedly.
Upon removing the wait() in the loop. All meshes deleted instantly, UntrackedMemory instantly rises by 5 and the number of instances remains the same for about 7 seconds before plummeting. However UntrackedMemory does not decrease with it, infact it goes up instantly by 2. After that is fluctuates but it makes net-gains and never decreases by a substantial amount.
Nothing else loads in the place. Its a blank Baseplate with an assortment of Meshes. The only things in the Workspace are the Meshes and the baseplate. The only other thing in the place is the Script that deletes the meshes.
In the end I’m beginning to assume this could be an issue with the Client, or the Computer’s memory. Recently I ran into a problem where the website and games never completely loaded. This issue turned out to be a problem with the firewall blocking the Roblox Ports. However this didn’t fix the problem.
Also for short clarification, this wasn’t tested in Studio. I published it to a place then played it from there. As for the instances, about 7/10 the instances will go down when the meshes are deleted. However UnTrackedMemory goes up anyway.
I think I have a repro where I can consistently cause the UntrackedMemory to increase while the script is running (though once I stop the script the memory recovers a bit until I enable the script again). There also seems to be some categories in core memory which are getting high and not dropping even when nothing is happening in the game.
Hi, I believe that this issue is occuring in my game as well. I have a system in which users create a lot of models which have meshparts in them, and the only time I can reliably make the UntrackedMemory go up is when those models are deleted. Currently within my codebase I have no childRemoved signals/tagRemoved signals that would be storing anything in memory when something is destroyed.
I couldn’t really pin down the issue to occur with the same intensity that memory leaks when I delete things in my game, but this issue also occurs when there are no scripts running in my game, upon deleting large quantities of models, untracked memory goes up and never gets quite back down.
Any updates on this? This sounds like it could be the cause for a lot of my server-memory issues. Because I have 100 player servers, theres a lot of Character mesh parts that are created/destroyed, and overtime my server-memory goes over ~3.6GB and crashes after 12-24 hours.
Stats.InstanceCount continues to go up and up overtime, never going down.
@alexnewtron The repro I have does not result in a growing Instance count, only growth in non-tracked memory, the issue affecting your game is different from what I have in my repro place.
Seems very close to what is happening in our game. We have a fair few mesh parts, and that combined with our region system (creates and destroys regions based on players location), causes a leak in our process memory. Although the untracked memory does not go up.
For the 349 release going out next week I was able to track down a few places where we were allocating memory without tracking which may help with the originally reported issue, but will likely not help with the issue that alexnewtron and DoubleJump_Jake are indicated (leak of tracked memory).
@DoubleJump_Jake if you encounter a server with large memory usage, could you open the dev console and grab a screenshot of the memory breakdown?
Our leak is on the client. We are destroying and generating parts locally.
So I can get a screenshot of the client memory going up? It is rather gradual, but if a player was on for an hour or so they would definitely see a performance hit.
I would suggest making a repro file of this and sending it to @LordRugdumph along with the screenshots from the developer console they asked for. There’s usually not too much that can be done without these, since if they had a reproduction of it already they probably wouldn’t ask for one.
