To reduce memory usage you can do the following things.

Set these settings in the config:

GridUnload = 1
GridCleanUpDelay = 30000
Terrain.Preload.Continents = 0
Terrain.Preload.Instances  = 0
mmap.enabled = 0
Collision.Models.Unload = 1
Instance.UnloadDelay = 30000
Visibility.ForceActiveObjects = 0

In the database:

UPDATE `creature` SET `spawn_flags`=0 WHERE `spawn_flags`=1;
UPDATE `gameobject` SET `spawn_flags`=0 WHERE `spawn_flags`=1;
TRUNCATE TABLE `transports`;

With no players in the game, memory usage will remain constant and cpu usage should be at 0%.

To reduce memory usage you can do the following things.

Set these settings in the config:

GridUnload = 1
GridCleanUpDelay = 30000
Terrain.Preload.Continents = 0
Terrain.Preload.Instances  = 0
mmap.enabled = 0
Collision.Models.Unload = 1
Instance.UnloadDelay = 30000
Visibility.ForceActiveObjects = 0

In the database:

UPDATE `creature` SET `spawn_flags`=0 WHERE `spawn_flags`=1;
UPDATE `gameobject` SET `spawn_flags`=0 WHERE `spawn_flags`=1;
TRUNCATE TABLE `transports`;

With no players in the game, memory usage will remain constant and cpu usage should be at 0%.

I would like to ask how much GB of memory the server needs to support the Mangosd service if the above configuration is not modified

To fully load the open world takes 4.5 GB. But with more players it will continue to increase, because memory needs to be allocated for their session, for the player object, for their items, etc. And if they enter instances or battlegrounds, memory usage will grow further as it needs to load those maps.

If you want to reduce memory usage beyond the settings I gave you, you can compile the core as 32 bit, as this will halve the size of all pointers, thus reducing requirements a bit more.

You could also empty all the tables containing localization texts.

Hello, using the solution you provided, the memory of the Mangos service remains stable during front-end operation and will not continue to increase. Switching to running with a daemon will still increase memory infinitely.

[121646.776776] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=realmd.service,mems_allowed=0,global_oom,task_memcg=/system.slice/mangosd.service,task=mangosd,pid=447908,uid=0
[121646.776929] Out of memory: Killed process 447908 (mangosd) total-vm:46159724kB, anon-rss:3546964kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:87072kB oom_score_adj:0

I might have the same or a similar problem. I run a current build, default config of https://github.com/mserajnik/vmangos-deploy. Once I get to

World initialized.
SERVER STARTUP TIME: 0 minutes 3 seconds

>> Only expired mails (need to be return or delete) or DB table `mail` is empty.
vmangos>

The memory usage of the process is at about 3.5GB. Then it increases by about 7GB per half second or second and gets killed once it fills my 32GB.

Starting realmd uses 24GB of memory and then stops using more (but runs from then on). That sounds an awful lot for that process as well.

(I did not use a published docker image, as there was a problem with the client version in them, but built it myself via “docker build -t ghcr.io/mserajnik/vmangos-server:4544 -f docker/server/Dockerfile .")

I can't reproduce the problem, it must be linux specific. Realmd uses only 4 mb for me, less than the task manager.

Just a data point, I'm on linux. Just starting the services and no players ever logging in after 10 minutes I'm left with:

realmd uses 1.4MB with 1 realm
mangosd uses 1069.8MB

Have you tried compiling it with a different compiler (gcc / clang) and using a different version of linux?

When I closed the console (Console.Enable = 0) in the configuration file (mangosd.conf), the issue of infinitely increasing memory did not seem to recur

When I opened the console (Console. Enable=1), the memory began to increase infinitely again.

I have tried Ubuntu 20, Ubuntu 22, debian12, and GCC versions of gcc11 and gcc12, but they have not been resolved. However, this issue does not exist on Windows (regardless of whether the console is closed or not)!

Just a data point, I'm on linux. Just starting the services and no players ever logging in after 10 minutes I'm left with:

realmd uses 1.4MB with 1 realm mangosd uses 1069.8MB

I observe about the same running a Ubuntu 22.04 Docker container with version 5875 on a Linux host (using the same setup orygg already mentioned, it's made by me); I hadn't actively monitored memory usage before, but after running for around 30 minutes now I don't see any memory leaks here.

Just for reference, the binaries in the Docker images are built with GCC 11.4 and without debug symbols (-DDEBUG_SYMBOLS=0).

I find what Shirley-Jones writes interesting:

When I closed the console (Console.Enable = 0) in the configuration file (mangosd.conf), the issue of infinitely increasing memory did not seem to recur

Could this maybe be related in some way to e5ba29c then if it only affects Linux?

Try reverting the commit and see if it solves the issue.

@orygg

The memory usage of the process is at about 3.5GB. Then it increases by about 7GB per half second or second and gets killed once it fills my 32GB.

Starting realmd uses 24GB of memory and then stops using more (but runs from then on). That sounds an awful lot for that process as well.

I think you might be experiencing a different issue than what is described here, because those numbers you mention are extreme and much higher than what Shirley-Jones shows; realmd in particular should only use a few MB idling, obviously not 24 GB.

As stated above, I don't seem to have any memory leak issues using the prebuilt Docker images from the setup I provide; the issue with the wrong client versions you brought up should be resolved now (as you probably already saw), so maybe try using a prebuilt image and see if the memory usage is normal (or at least closer to what is described in this issue if there is a Linux-specific leak). If you still get that extreme usage and apparent leaking, feel free to open a separate issue about this in my repository and we can try to figure that out there, maybe what you observe is somehow Docker-specific (and as such, it would be outside of the scope of this project here).

Thanks for all the replys. I will look into it, once I have the time, starting with your builds @mserajnik .

@mserajnik if it's some combination of my chnages and docker then lets work togther to fix it.

@Shirley-Jones How are you using the server? Do you have some sort of script that sends commands to the CLI?

realmd using 24G makes me believe that what orygg is seeing is something else and perhaps speciifc to them as this is about mangosd leaking as I didn't touch realmd with my patch.

@imranh2

if it's some combination of my chnages and docker then lets work togther to fix it.

Like I wrote, I am personally not seeing any memory leaks in Docker, so I don't think it's a combination of those things; afaik, Shirley-Jones isn't using Docker either.

I believe that

• what Shirley-Jones describes is a Linux-specific memory leak, which might or might not be related to your changes (I only suspected that it might be because he wrote that disabling the console fixes it and iirc your commit was the last one that touched that area; but a memory leak could, of course, also have been there before)
• what orygg sees is probably unrelated to the issue here and rather maybe some Docker-specific problem, could also be dependent on the host he runs this on etc.

What is definitely interesting is that as opposed to Shirley-Jones both you and me are apparently not experiencing any memory leaks (if I understood your comment correctly?) despite us both also running on a Linux-based system (with different setups, you presumably directly on the host, me using a Docker container), so that's also something to figure out.

I am not exactly a C++ expert but I'm happy to help in any way I can.

@imranh2 I ran Mangosd directly on the Ubuntu 22 host as a daemon, without using the Docker container.
mangosd -c mangosd.conf -s run

When I closed the console (console. Enable=0), Mangosd had been running steadily for a day without crashing, and there was no infinite increase in memory.
I am not an expert in this area, but I am willing to do my best to provide assistance.

If it's convenient for you, you can leave an email and I can send you the server to take a look. Thank you.

Ok you run it as a daemon (-s run), I don't. I'll investigate this and see if I can get a leak.

I'm assuming @mserajnik also isn't running it in dameon mode too?

I'm assuming @mserajnik also isn't running it in dameon mode too?

No, I run both mangosd and realmd directly in the foreground as PID 1 in the Docker container (they run in separate containers).

Ok cool, this is a good lead to investigate.

Reducing the per process file descriptor limit solved my problem. Docker set it to a very high number per default.

Finding the solution took an unlikely path: tried to fire up valgrind in the container, got an error, The Internet told me that valgrind has a problem with high fd limits, turned it down, suddenly the runaway memory problem was gone.

After a brief look at the source and ACE’s sources, it looks like ACE reserves resources for every potential file descriptor in ACE_Dev_Poll_Reactor, which leads to the problem.

To elaborate. A comment on the constructor for the ACE_Dev_Poll_Reactor reads:

  /**
   * @note On Unix platforms, the @a size parameter should be as large
   *       as the maximum number of file descriptors allowed for a
   *       given process.  This is necessary since a file descriptor
   *       is used to directly index the array of event handlers
   *       maintained by the Reactor's handler repository.  Direct
   *       indexing is used for efficiency reasons.  If the size
   *       parameter is less than the process maximum, the process
   *       maximum will be decreased in order to prevent potential
   *       access violations.
   */

As the limit will be adjusted, if size is smaller than the limit, maybe instead of calling the constructor with no size argument in mangosd’s case, which is then internally set to ACE::max_handles(), or ACE::max_handles() in realmd’s case, passing a sufficiently high number (like min(ACE::max_handles, 1024)) would prevent others from having this problem in the future (whether in a container or any other Linux setting).

@orygg

Great find, even if not related to the problem described by Shirley-Jones here.

[...] passing a sufficiently high number (like min(ACE::max_handles, 1024)) would prevent others from having this problem in the future (whether in a container or any other Linux setting).

This sounds like a reasonable change to me; I would suggest, if you feel comfortable making a PR for it, do it. It will be easier for ratkosrb to review it that way I think and it also moves any potential further discussion into a separate thread (so we don't continue talking about two different issues here).

Ok the problem is with my readline changes. Readline doesn't like when we redirect stdin to /dev/null.

#2572 is what I really think we should do here to just not enable the CLI while in daemon mode, you don't have interactive daemons per se and the only way to do input into the process while in this state is hacky.

#2573 is a tested to fix this specific issue but not fully tested in all configurations.