Let’s be honest: I only use Java for Minecraft. So I only debugged with it. But all version, server or client, all launchers. All of them use double (or more) RAM. In the game the correctly allocated amount is used, but on my system double or more is allocated. Thus my other apps don’t get enough memory, causing crashes, while the game is suffering as well.

I’m not wise enough to know what logs or versions or whatever I should post here as a cry for help, but I’ll update this with anything that’ll help, just tell me. I have no idea how to approach the problem. One idea I have is to run a non-Minecraft java application, but who has( or knows about) one of those?

@[email protected]’s request:

launch arguments [-Xms512m, -Xmx1096m, -Duser.language=en] (it’s this little, so that the difference shows clearly. I have a modpack that I give 8gb to and uses way more as well. iirc around 12)

game version 1.18.2

total system memory 32gb

memory used by the game I’m using KDE’s default system monitor, but here’s Btop as well:

this test was on max render distance, with 1gb of ram, it crashed ofc, but it crashed at almost 4gbs, what the hell! That’s 4 times as much

I’m on arch (btw) (sry)

    • taaz@biglemmowski.winEnglish
      4·
      3 months ago

      You could also (hard) limit the total (virtual) memory process will use (but the system will hard kill it if tries to get more) with this:
      systemd-run --user --scope -p MemoryMax=8G -p MemorySwapMax=0 prismlauncher

      You would have to experiment with how much Gs you want to specify as max so that it does not get outright killed. If you remove MemorySwapMax the system will not kill the process but will start aggressively swapping the processes’ memory, so if you do have a swap it will work (an depending on how slow the disk of the swap is, start lagging).

      In my case I have a small swap partition on an m2 disk (which might not be recommended?) so I didn’t notice any lagging or stutters once it overflow the max memory.
      So in theory, if you are memory starved and have swap on a fast disk, you could instead use MemoryHigh flag to create a limit from where systemd will start the swapping without any of the OOM killing (or use both, Max has to be higher then High obv).