-Xmx=6G is FAR from being enough to run the mod default value should be around 10GB or 12GB

[lagraviereScience]

The default value, provided in the file user_jvm_args.txt available after executing ./startserver.sh contains the value 6G (as in 6GB) for the -Xmx java parameter.

However, I'm running the server for only a few people (4 simultaneous players tops), and the server keeps crashing when generating new chunks (players exploring a little).

According to my measurements it's because of the server "eats away" all the available RAM -> then reaches the maximum allowed and crashes.

Suggestion:
Increase the default value to at least 9, 10 or 12GB depending on how you want to be "safe".

In any case, 6GB is NOT a value that allows a stable behavior for ATM8.

[James103]

From my experience in 1.0.9, the client can run with 6 GB of RAM allocated, but from your post, it appears the server initially requires 6 GB of RAM allocated (to startup and run with up to 1 player connected), but every additional player adds 2-3 GB to the RAM requirement.

Furthermore, every time a player loads a chunk or goes through a portal to another dimension, the server (and player's client) permanently require more RAM to continue running.

[lagraviereScience]

@James103 Well, then, "there you go" -> with your explanation it makes even more sense that 6GB is not enough.

Like, if you play with two or three people (which is my use case): 6GB is not enough, Java tries its best to stay within the 6GB limit, but when players starts to wander around in different directions, explore more, generate more chunks -> the server just crashes out of memory

[James103]

The leak must be coming from one or more of the mods in the pack; can you please bisect the modlist (if possible) to find which mod(s) may be leaking memory on each chunk or world load?

[lagraviereScience]

Bisect the modlist?
You mean? Listing the mods running on the server?
Or more simply if you have a process or a link explaining I can look into it

For info:
I'm good with Linux and programming
I'm just not familiar with the whole "minecraft universe"

[James103]

This post should be what I mean by "bisect the modlist": https://www.reddit.com/r/feedthebeast/comments/evpy6r/tips_for_modpack_authors_how_to_find_misbehaving/

[lagraviereScience]

Thanks for the link, it presents two methods that are aiming at the same goal, sorting out which mod(s) are responsible for memory leak.

That's where my lack of knowledge in what I call the "minecraft universe" is gonna cause an issue, plus testability requires high load to make the server crash, i.e. to reproduce the bug/malfunction.

That means that I need to figure out amongst the tons of mods in ATM8 which are the ones that I can disable.
As far as I am concerned, having actually tried that: removing/disabling one mod almost surely makes the whole ATM8 unstable to the point that the server won't even start.

Second even if I manage to sort out mods and disable some of them, there's no proof that those are the ones causing the problem. Thus, meaning that the problematic mod(s) are part of the essential ones, without which, again, ATM8 server won't start anyway

And finally, for EACH case, i.e. for EACH subset of mods, I need to have players ready join, load and wait and do random shit until the server maybe crashes or not.

I think I'm not the person to do this.
My knowledge in the modding world of Minecraft is 0, same for Forge, etc. etc. etc.

[huntdogy]

Just wanted to say Rubidium seemed to be the issue (not entirely shocked there)
change log from version 0.6.2a
Fixed ArrayIndexOutOfBoundsException (thanks to FTB and Sodium teams)
More parities with Forge Rendering API (Multipart Models, lightning in BlockRenderer, fixed overlay sprites in FluidRenderer)
Added optimized cloud rendering
Backported Direction.getFacing optimization
Fixed glitch with textures placed at the atlas border (thanks for an idea to malte0811 and to IMS for finding bug out)
Fix checking if adjacent side is solid using wrong position (thanks to pupnewfster)
Fix item quad coloring (thanks to malte0811)
Use StampedLock instead of synchronized block in MixinMultipartBakedModel
after loading up my world (with rubidium update applied in a separate instance) memory is consistent and not constantly climbing. Further note do not give java large amounts of ram as it will eat it all and become lazy when clearing out parts not needed id recommend 8-8.5 gigs of ram for this pack

[Mitchell5200]

Just wanted to say Rubidium seemed to be the issue (not entirely shocked there) change log from version 0.6.2a Fixed ArrayIndexOutOfBoundsException (thanks to FTB and Sodium teams) More parities with Forge Rendering API (Multipart Models, lightning in BlockRenderer, fixed overlay sprites in FluidRenderer) Added optimized cloud rendering Backported Direction.getFacing optimization Fixed glitch with textures placed at the atlas border (thanks for an idea to malte0811 and to IMS for finding bug out) Fix checking if adjacent side is solid using wrong position (thanks to pupnewfster) Fix item quad coloring (thanks to malte0811) Use StampedLock instead of synchronized block in MixinMultipartBakedModel after loading up my world (with rubidium update applied in a separate instance) memory is consistent and not constantly climbing. Further note do not give java large amounts of ram as it will eat it all and become lazy when clearing out parts not needed id recommend 8-8.5 gigs of ram for this pack

Okay, that is unrelated to Server memory issues, as Rubidium is a client only mod and does not have any affect on servers