Reducing server memory from extremely high part counts

[spleenhook]

I am a developer at Skyblock (Islands 👩‍🌾 - Roblox). We have had a lot of issues with game servers crashing, especially with large “islands.” The way the game works, each user adds an unspecific but large (in the thousands) number of physics parts and other instances to the world. This is almost entirely “blocks”, a structure of BasePart wrapper (with no physical properties, intended for streaming), a child which is a model and a few meshes as children of the model (the mesh on the bottom level is the only physical and visual component).

I am unable to find any good sources explaining some of the server memory categories. The ones I am interested in an explanation on are:

1. “default” - by far the most memory is being used here, more than 50% of total tracked memory. It seems to grow with instance count, but not sure if it just a direct response to lots of instances or if it has some properties which can be minimized. Currently 1gb on the server I am on.

2. “network/raknet,” “network/replicator” and “network/streamingReplication” use about 200mb each on the same server. We do have streaming enabled with the default 1024 stud target radius (64 stud minimum radius).

3. “PhysicsParts” - do baseparts with no physical or visual properties (no collision, anchored, transparent) affect this number?

Thanks for any help.

[rbx_lua (Matthew)]

@spleenhook

with no physical properties, intended for streaming

Can you clarify what you mean by “no physical properties?” I am fairly certain that setting CanCollide to false does not prevent it from being physically simulated and subsequently using the server’s resources to support that operation. Consider that a part with CanCollide set to false can still detect collisions and fire events based on those collisions. Are you seeing high PhysicsParts usage that grows substantially with these large bases loading into the game?

@spleenhook

number of physics parts and other instances to the world

By “to the world” do you mean as a descendant of Workspace? If your clients are streaming the parts anyway, you might be better suited to remove the parts from Workspace entirely. If I were in your position, I would probably move them to a container such as ReplicatedStorage and have the clients locally pull them into their local Workspace as needed to stream the nearby parts. Given what you’ve said, I don’t really see any benefit to having the parts in Workspace.

@spleenhook

and a few meshes as children of the model (the mesh on the bottom level is the only physical and visual component).

You can even go further to make it more memory efficient on the server. Which instances are purely aesthetic? Could they be loaded in by the clients as they need them and not hosted on the server at all? For example, if you have a “grass” block, and a “grass” mesh to accompany it, does the server really need to see the entirely aesthetic mesh instance at all? Could the client recognize it as “grass” and, at the point of “streaming” the block in, apply the appropriate mesh on the spot?

Following that logic, you could go so far as to avoid hosting the instances on the server whatsoever. The server could store player base data using a more memory-efficient method (literally anything besides Instance objects) and clients could request map data information from the server, thereafter creating new instances and essentially generating them locally as needed.

@spleenhook

We have had a lot of issues with game servers crashing, especially with large “islands.”

Are these servers crashing as a direct response to people with large islands joining, or are they crashing over time either way, with larger islands serving to accelerate the issue? What does your memory usage look like over the life span of a server? Does it rise at a steady or alarming rate, rarely or never going down? It could be a memory leak caused by scripts, rather than an issue with a server not being able to handlle thousands of parts.

Unfortunately, I have never seen a game where “default” used so much memory, so I’m not sure what to tell you there. I do think it might help if you were to post the memory usage GUI that you’re seeing in one of these problem servers.

[Deadwoodx (uWood)]

Apologies for the bump, this post got fairly high in views and no solution marked, though been 3 years. If not solved already, I want to suggest a few things to assist in this issue.

When a lot of parts are there at a position in geometry, it is that the server calculates the events such as Touched and TouchEnded for every Part or every BasePart, inconsequential if it has a connected function managing those events or not. The 3D workspace and framework of Roblox still fire those events.

Ergo, it is suggested that the CanTouch is false to avoid triggering those events and disabling the
EnableFluidForces if the game does not rely intensively on 3D Physics of Terrain.

Additionally, a grouping of similar parts to a single part can be done to avoid high part counts and loading times taken on the client, increasing the client user experience.
Example:
More parts, ability to change properties of every part.

A lot of union operations are resource-intensive.

Since both the blocks are the same, it is better to use 1 part than 2 parts, it is well optimized and when there are a large amount of parts, this method will drastically improve the performance of the server and client.

Of course, you cannot apply individual properties to each block, but in most cases, there are common floor parts around and this will reduce the overall part count and increase performance.

And since the game you mentioned is a building genre game, it might be hard to make something like this (hovering to destroy a block)

It might be a problem, but in reality, it isn’t.
As you know, you would do this method on the same parts only, and it means their properties are nearly the same, like size and color. Whenever you perform this operation, you can set the individual part’s size in the attribute (x,y,z). Based on this, you can make a hover part from the size parameters, and you can make it bigger by 0.05 on all sides, so it will cover the part you focusing on, if scripted properly, trust me this would be better (in terms of performance and optimization and usage)

And setting a mesh CollisionFidelity to Hull or Box, if the Touched event is not required to be in-exact and you can find the difference here | Roblox Documentation for easier reference

Acknowledging the fact that it is a popular game, I hope these suggestions will help the game developer even more, I’m open to any correction in this post

Thank you,
Woodx