How many cores used by 1.10.x and/or the Debian/NodeJS MineOS package?

Hardware
1

Hey all,

Just checking out whether or not the information I’ve found so far about CPU core utilization is still accurate; that servers still only use a single core to run servers?

Is that still true? If it is true, do other server jars (spigot, whatever else) utilize more CPU cores than just one?

Is there a way, if this is true, to utilize more cores?

If this is wrong, and current MineOS / Minecraft jars do utilize more cores, is there a limit? (e.g. quad core, hexacore, etc?)

Thanks in advance for taking the time to respond!

Cheers.

2

A topic much like this question is being discussed here: One online player lockes out server CPU for one core (forge)

As far as I can tell there are rumours that some java tweaks, using the correct java version, that will work on some servers to force them multicore.

Core usage is more of an java thing than a server thing, since it is the java engine that enables multicore if suported. I guess you’d have to program the server jars in a way that utilizes multiple cores to be able to make use of more than one core effectively.

3

Here’s my take:

No. Minecraft already uses multiple threads when available. Vanilla minecraft, mind you. However, using multiple threads is misleading because it is definitely not the scale-able performance you’d expect when somebody says a game is programmed multi-threaded.

From a technical perspective, Minecraft (vanilla) runs these in separate threads:

  1. normal game loop (does all the logic of all the entities/players)
  2. chat
  3. chunk loading

Now, #1 and #3 are pretty important things to have split up, and this improved performance quite a bit–but this has been around for a long time now, so it’s nothing new or anything to get excited about.

What we really do care about, which we will likely not get for some time to come, is having the #1 normal game loop multi-threaded. Most of what uses up CPU and is the bottleneck is how all the monsters, plants, animals, water, and sun get calculated to behave. If the game loop was multi-threaded, it would require unbelievably drastic changes to the codebase, something which probably isn’t too appealing for Mojang/MS to invest into.

Minecraft will automatically start leveraging the threads and cores it has available. Just as with other games you play, you typically do not have to go into settings or configuration to say “use my 8 cores”–it just knows to.

It’s no different for Minecraft. If you have one core, and Minecraft makes three threads, then your one core will service all three threads. If you have multiple cores and Minecraft makes three threads, then maybe numerous cores will service the three threads. One way or another, the performance gain we want isn’t really in the use of multiple threads or cores, but the appropriate splitting of work from the game loop…which isn’t here yet.

Java tweaks have been a contentious issue for years now, and many people claim that a lot of difference can be made from tweaking java variables here and there. Half a decade ago I put in my two cents on the bukkit forum–there’s multiple replies there by me, “Will D” #1 #2 #3.

I really recommend it…but I am a bit biased being the author. That said, the information I wrote there still holds up today and will help give some perspective to what Java tweaks can and cannot do for improving performance.

TLDR; all the Java tweaks in the world can, at best, help prevent some degree of sluggishness from a server that is resource-limited. all the Java tweaks in the world cannot improve Minecraft performance close to what a multi-threaded rewrite could do for Java.

From the Bukkit original staff:

All of these threads detailing how to optimise the JVM are misleading and inaccurate. Generally, the JVM is pretty good at optimising itself based on the environment the JVM is running in (with a few obvious exceptions). Any other optimisations require a lot of time and trial and error to figure out what configuration is right for your server. Every java application is different, and on top of this, every server environment is different too.

2 Likes
5

I’d say don’t even bother.

Irqbalance identifies the highest volume interrupt sources, and isolates them to a single unique cpu, so that load is spread as much as possible over an entire processor set, while minimizing cache miss rates for irq handlers.

The highest interrupt source here will be java. It won’t be granular like “a single minecraft game thread”. Thus, irqbalance will isolate a particular Java process (one per server, if you run multiple). All the multiple threads the jar will run will be in that one CPU process anyway and Java will know to have garbage collection run on separate cores.

In short, where we want irqbalance to help…it can’t because it sees Java as the process to manage, not “chat thread” and “game loop thread”, etc.

Also don’t bother.

Preload is an ‘Adaptive Read-ahead Damon’, which is the equivalent to Windows Vista’s Superfetch. Effectively what it does is speeds up application load time by monitoring the software that is loaded and used day to day, the software used most often, and cache them in memory. If you have a lot of memory, you will notice things will improve.

You shouldn’t have a lot of memory. Your Java heap should be using up available memory. Memory dedicated to the heap/Minecraft is the single most significant way to improve your game’s performance (provided that you’re not so short on memory that other system services fail).

Memory used for preload is not even remotely as valuable as memory that Java can use to hold jar-related assets.

I’d say you can safely ignore both of these utilities.