Switching from Docker to non-Docker Breaks Java

Technical Support
1

OS Name/Version: Ubuntu 20.04

Product Name/Version: 2.3.2.10

Problem Description:

I have a PaperMC instance up and running in Docker. I initially selected the Docker option. But now when I attempt to switch away from Docker, I cannot start the server. Error message reports “Java 8 not installed.”

When I go to the configuration panel, there are no Java versions shows available in the drop-down.

Then when attempting to go back to Docker, I still cannot start the server. I ended up having to rollback to a snapshot to recover. I did this twice, and was able to reproduce the issue both times.

Questions:

  1. Should I be able to disable the Docker option and expect that AMP will download any Java dependencies automatically?
  2. If no, should I install Java myself in the host?
  3. If yes, do I only need the Java version required for the specific server (i.e., Java 17 in this case)?
  4. I assume using Oracle Java will be most performant and receive security updates first? (I notice OpenJDK is referenced in the configuration when using Docker…)

The documentation mentions there is a small performance penalty to using Docker… my kids were complaining that there was sometimes a little lag when only 4-6 of them were playing. I have Ubuntu running in a VM hosted on a 16c/32t Xeon server, and have given the VM 6 cores and 6 GB of RAM. I have not set any core limit in AMP, and set the Java limit to 4 GB. The guest OS load is < 1.0. I assume this is lag caused by PaperMC and/or GeyerMC+Floodgate, and not by the VM itself. Agree?

I’m available to screen share with Google Meet if you would like to see the problem live, in case that helps diagnose.

Thanks!

2
  1. No. AMP doesn’t install dependencies except during installation. So normally when you tell it to use Docker it doesn’t bother to install Java on the host because it wouldn’t be needed.
  2. Yes - using bash <(wget -qO- getamp.sh) installJava to install the versions AMP is expecting.
  3. AMP uses Adoptium JDK and fetches multiple versions to cover different types of Minecraft server. Generally you want to use JDK17 for recent MC versions.
  4. See 3.

Performance wise you’d struggle to measure the performance difference of Docker in most cases, let alone notice it. It’s somewhat academic in that regard.

Minecraft is extremely reliant on single threaded performance, and does not make any real use of multiple threads/cores - so it’s all about clock speed. Sometimes disabling Hyperthreading can get a small performance boost on Xeon chips.

Second to that are IO concerns, Minecraft is very sensitive to IO performance so make sure the server is on a fast solid-state drive.

You can get a bit more information on what’s going on by turning on AMPs extended metrics. This will let you see if the server is starting to use swap space which will cause hitching.

3

Thank you for the detailed reply! I think for now I will just leave the instances running in docker since it should have minimal impact.

The Ubuntu VM is backed by a ZFS ZVOL which is backed by 2xRAID-Z1 VDEVs comprising 10x 7200-RPM hard drives. I doubt I/O is really causing an issue here, but I will watch the guest iowait in top during some games. I did turn off the sync I/O option in the AMP config since the backing storage is very reliable and on UPS.

So far I have just been noticing that the guest load average is generally <= 1, but if you say the MC server software is generally single-threaded, that makes sense. But it’s also a little worrying when the JVM approaches 100% since there’s nothing I can do to speed it up with the server itself except buying faster (clockspeed) CPUs, which frankly is very annoying since I have 16 cores, most of which are idle. :slight_smile:

The ony other thing I could do is run AMP in Docker on the host so there is not even a VM emulation layer. But I’m using all virtio devices, so the VM overhead should be minimal. And CubeCoders doesn’t supply an official Docker image for this use case. (I see some third-party Docker images available, but I would much rather use one directly from the developer… any future plans there?)

If they continue having lag problems I will experiment with more JVM options as well as increased RAM allocation, but it doesn’t sound like those are likely to help much, if it all, at this point.

Thanks again!