question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Severe memory issue and crash with ViaVersion on Paper 1.14

See original GitHub issue

Describe the bug Big memory issue (crash and can’t connect) when connecting from Geyser (Builds 162, 161, 160) to a Java 1.14.4 Paper based server (latest build of 1.14.4 paper) that is using ViaVersion 2.2.3, and is under a BungeeCord proxy hosted on the same machine.

When i connect (using Geyser online mode) to the server, the proxy sees my account trying to connect, it succesfully autenticates with Mojang credentials and then it idles for a while. Meanwhile the player start falling in the void, lagging. Then Geyser crashes.

I am hosting Geyser on a separated VPS by Hetzner, 2gb of ram. Startup flags are simply: java -Xmx1G -Xms2G -jar Geyser.jar

When connecting it reaches 2g of ram and Ubuntu kills the process instantly, since the vps has only 2gb of ram. If i allocate xmx1gb and xms1gb then it reaches 1gb and crashes, without being killed by ubuntu.

I also tried to host Geyser on my laptop allocating 5 gb of ram or more, freezes anyway and the server kicks me out for various reasons (Lost connection, timeout, …)

To Reproduce Make a similar setup to mine:

  • Geyser hosted on vps
  • Java hosted on dedicated ovh, on paper 1.14, under BungeeCord
  • Disable any eventual anti ddos service (i had TCP Shield completely disabled, connected via clear ip)
  • Disable every plugin made exception for ViaVersion
  • Connect with mcpe on android to geyser
  • Authenticate with mojang credentials
  • Wait for the crash

Expected behavior I tried to point my Geyser installation to a random 1.15 server, and it worked quite nice. You did an incredible job so far, only if it wasn’t that it isn’t working for my server!

Screenshots / Videos image

Server Version Paper version git-Paper-243 (MC: 1.14.4) (Implementing API version 1.14.4-R0.1-SNAPSHOT)

Geyser Version Standalone (Builds 162, 161, 160), floodgate was installed on the bungeecord but the auth on geyser was set to online anyway.

Minecraft: Bedrock Edition Version 1.14.60 android and ios (ipad)

Additional Context All plugins disabled made exception for ViaVersion. Bungeecord had floodgate enabled while testing but Geyser was set to online mode anyway. TCP Shield disabled and using clear ip.

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:23 (6 by maintainers)

github_iconTop GitHub Comments

2reactions
Camotoycommented, May 19, 2020

-Xmx1G -Xms2G don’t these flags mean that you have a maximum of 1GB and a minimum of 2GB? If you were able to get it working anyway that may not be the problem but try switching them around anyway.

1reaction
danielboos1commented, May 19, 2020

I recommend setting them both the same value. Here is why…

In a production environment, if you monitor the GC data, you will notice that is a relatively short period of time (usually less than an hour), the JVM will eventually increase the heap size to the -Xmx setting. Each time the JVM increases the heap size it must ask the OS for additional memory, which takes time (and thus adds to the response time of any requests that were is process when the GC hit). And usually the JVM will never let go of that memeory. Therefore, since the JVM will eventually grab the -Xmx memory, you might as well set it to that at the beginning.

Another point is that with a smaller heap size (starting with -Xms), GCs will happen more often. So by starting with a larger heap initially the GCs will happen not as often.

Finally, in a production environment, you usually run only one app server per OS (or per VM). So since the app server is not competing for memory with other apps you might as well give it the memory up front.

Note that the above is for production. It applies also to the syatem test environment since the system test environment should mimic production as close as possible.

For development, make -Xms and -Xmx different. Usually, you are not doing much work with the app server in development, so it will often stay with the -Xms heap setting. Also, since in development the app server will share the machine with lots of other apps (mail client, word processors, IDEs, databases, browsers, etc), setting the -Xms to a smaller size lets the app server play more nicely with the other software that is also competing for the same resources.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Universal - ViaVersion | Page 196 - High Performance Minecraft
I have a problem with the chest and fences. They would not connect, I tried install the lastest version and version 1.6.0 and...
Read more >
ViaVersion - Bountysource
Describe the bug, provide any errors 2/3 players out of the 75 of my server crash as soon as it arrives on the...
Read more >
[Java][1.17.1] Server crashing due to memory issues - Reddit
Hi there! Unfortunately, the error code 137 indicates that your server doesn't have enough RAM. Minecraft 1.17 has been known to require much ......
Read more >
Hello! What duplication glitches still exist on Minecraft servers ...
Keep in mind these worked but most of them were patched by paper/spigot. chunk ... the developer(s) or administrator(s) of that server use...
Read more >
#technically a re-upload but also additional caps | Explore Tumblr ...
With this changelog, we'd like to issue a special reminder that every “change” ... [12/25/19] Paper 1.14.4 b226 -> Paper 1.14.4 b237 ^...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found