[ Solved ] 1.13-pre1 locked to single-thread under MineOS?


#1

Hi all,

Having tried to run a 1.13-pre1 server on MineOS the other day, and getting horrible performance, I decided to do a little investigating.

I’m running MineOS in a Docker container within unRAID. Created a server, logged in, and saw CPU usage on one thread jump to 100% - As expected when first loading a world. This stabilised after a few minutes, a couple of others joined, and we went about our business. After a few minutes though - when people started exploring and generating new chunks, the lag made the game unplayable, followed by a server crash.

Investigated more, and yes, this happens whenever new chunks are generated. a CPU thread gets pegged at 100%, the server can’t keep up and closes itself for being too far behind.

Tried making a server on my local machine, and it runs great. Also, all 8 threads are used.
Made a server on a Windows VM on the same unRAID box as before, and this also runs great, using all 6 threads.

TL;DR:
Seems Minecraft has multithreaded chunk generation now.
Server on MineOS Docker in unRAID is locked to a single thread, causing the server to lag generating chunks, and crashing it.
Same server on Win10 VM runs perfectly fine, using several threads.
All default settings, as far as I’m aware.

Is there something in MineOS that was hard-coded a while ago for single-thread that can be changed, or is there something else causing this that I’m missing?


#2

Just an observation about Pre1.13, I was unplayable on single player for me until I allocated 4GB ram and I am on a newer PC with an 8th gen i7, this will be unplayable for a lot of older pcs imo


#3

Nothing in MineOS is thread-aware; the webui itself is a single-thread that simply launches instances of a) the webui and b) Java. Java instances started through MineOS (for the servers themselves) therefore have unfettered access to all available cores.

This right here is adding two variables I don’t work with very often. Docker, however, does have an option for cpu affinities and pinning, though nothing in the Docker build file (or the docker image from hub.docker.com) have the ability/capacity to limit to a single thread, which leads me to believe that … is it possible unraid itself is responsible for this.

According to this page about UnRAID: https://lime-technology.com/forums/topic/47833-vm-priority-and-docker-cpu-selection/?tab=comments#comment-471906

As far as I know, docker cpu pinning is set during container creation and changes to it require a container reinstall.

This suggests to me that unraid is the limiting factor, inadvertently limiting it on a recognized Linux docker (but not limiting it on the HVM that is required for a windows vm).


#4

Thanks for the reply, Will.

**Edit: I figured it out. **
There’s a parameter you can set on boot: isolcpus. This isolates CPUs from unRAID itself, but they can still be assigned to VMs and Docker containers.

For some reason, when using these isolated threads, even though 4 were set, only 1 was used. Setting 4 threads in use by unRAID as well resolves the issue. I’ll raise this with LimeTech and see if they can investigate.

CPU pinning is exposed in the unRAID UI, and I’ve pinned MineOS to 4 threads. I’ve seen usage spread across threads normally.

I just tried restricting a Plex container in the same manner, and the load on that was spread across all cores as expected.

With MineOS, there are 6 servers set to start on boot, yet only 1 thread says pegged while the other don’t show a flicker of activity. If each MC server is its own java process, surely there’d be some movement there?

I tried pinning to different cores and that had no affect.

Is there anything I can capture to maybe shed some light on what’s going on here? I could of course reinstall the container, but it tends to have issues picking up existing servers/archives/snapshots, in my experience.