+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Discussion (https://forum.cuberite.org/forum-5.html)
+--- Thread: How threaded it is? (/thread-481.html)
How threaded it is? - Taugeshtu - 06-12-2012
I'm thinking about hardware for my server... Should I go with single-CPU or two-CPU setup?
I mean, I'm aiming AMD Opteron 6200 series (which is nice IMO), and it has goddamn 12 cores. Each. And I can have two of them!
That could be really, REALLY big overkill, and I don't want that to happen
Now, question is: can MCS eat all 24 cores or not?
Is is even capable of running on multi-cpu setup?
RE: How threaded it is? - xoft - 06-12-2012
MCServer is about as threaded as it needs to be - it wouldn't make much sense to split into more threads than it's currently using. The number of threads actually used depends on the server settings and on the number of users that will be connecting to the server. For each world, several threads are created taking care of that world. Those are the most heavy-weight threads; the others are relatively idle.
Let me list the threads and their (subjectively estimated) workload, sorted from most utilized to least:
- Chunk generating. One thread per world.
- Chunk loading / saving. One thread per world.
- World ticking. Currently one thread per server, but expect this to get to one thread per world quite soon.
- Chunk lighting. One thread per world.
- Chunk sending. One thread per world.
- Player communication. One thread per 63 players (could be tweaked to more players per thread, if needed)
- Player authentication. One thread per server. Currently doesn't work, but expected to be fixed soon(ish).
- Housekeeping threads (webadmin, server listening socket, console input, socket notifier). One of each type per server. Almost no work done, ever.
So, generally, take the number of the worlds you want to be hosting, multiply by 5, add two or three and you get the ideal core number
Of course, the ideal might just be too much, so you can save on a few things. Chunk lighting and sending is about 5 times less work than the top three, so they can be shared in a single core. All the per-server and per-players threads can still squeeze onto that core, so you can get a simpler formula, 4 cores per world hosted. And with the server being quite performant as it is, I'd say even two worlds can share those 4 cores pretty safely. Three worlds if the third is a simple one, for example something like the End, or superflat - not much generating going on.
If you have two similar setups and are deciding between the two, take the one with better RAM-to-CPU throughput. Minecraft is about a loooooot of data being moved back and forth; I'd estimate that to be the actual bottleneck, rather than CPU itself. Of course, I have no experience with server-grade hardware, so my guess can be pretty useless here
As for your question: MCS could "eat" all 24 cores, if you host more worlds. With one world, it's a (very big) overkill.
I'm debugging on a single-world setup and I have 11 threads altogether..
RE: How threaded it is? - Taugeshtu - 06-12-2012
I'm planning like 5 worlds (Upper, Nether, Ender, Hell and Inanimate), probably one more...
Any chances we'll get threaded mods as well? (even settable would be great... Autosizing would be even better, like one thread per 63 mobs or so - I would like to fill my worlds with life
)And what about plugin threading? I've noticed "one thread per plugin" statement somewhere (probably in plugin<->plugin interaction discussion), is that true?
(If so, I guess I would benefit from splitting functions across many plugins)
So, in general, if I'm expecting HEAVY load on world modification (this could happen... You know, there is ever not enough TNT
), my bet is 4 cores per world + 2.And big cache. Bigger is better >:D
RE: How threaded it is? - xoft - 06-12-2012
Threaded mods? what do you mean?
Mobs are fixed, they need to be handled in the world's tick thread and there could be only one tick thread per world.
Current mobs are crappy, hopefully we'll get a new AI one day. But still, all in one thread. That's one of the reasons that the minecraft servers are so CPU-heavy.
It's not so much "one thread per plugin" as "no more than one thread executing one plugin's code". Plugins run in the thread in which their hook has happenned - OnTick is called in the context of the tick thread, OnChat is called in the player comm handling thread, etc. But there's a simple guarantee that no more than one thread is executing any single plugin's code (otherwise it would be a mess).
A while ago I was pondering about plugin-created threads - so that plugins can queue tasks for later execution etc. But it's quite difficult with the current Lua integration (i. e. I have no idea on how to do that
)
RE: How threaded it is? - FakeTruth - 06-12-2012
(06-12-2012, 05:10 AM)xoft Wrote: A while ago I was pondering about plugin-created threads - so that plugins can queue tasks for later execution etc. But it's quite difficult with the current Lua integration (i. e. I have no idea on how to do that
Two threads may not execute code of the same plugin at the same time, unless both threads have their own lua stack ( state ), which essentially makes it another plugin...