dashdanw

First of all I agree with you that the code could use some optimization. That being said I'm not sure how complex the server codebase is as it stands.] That's interesting that you didn't see any performance hits, did you notice anything else in particular? Hard limits, etc.? Just curious for myself. That still doesn't sound necessarily great to me. The fact that it's on a NAS means that it's susceptible to more efficiency problems, though I have to take your word on that you're pretty confident that's not causing any issues. Nice one, I've definitely seen harshly diminishing returns or even overloading happening with too many threads or unbalanced configs. I see the same thing, it's pretty frustrating not being able to parallelize it when it seems like such an easy candidate for any sort of sharding. Keep in mind that the extra workers because threaded will also end up hogging iowait time depending on the implementation, but I think you're definitely hitting the nail on the head with the fact that at the end of the day there seems to be maybe one or so threads per user. I wasn't sure how much you had looked into your proc and your running system. Those things can be far more complex than they let on to be *especially* if you're virtualizing which I'm assuming you're not. Also sorry about the link I didn't see it noticed, the messages were pretty dense and just looking at the numbers on your config I've seen similar issues with the same types of ratios that get exacerbated by fiddling with more settings.

In my experience the problem stems from a combination between the ratio between workerThreads and generatorThreads/scriptBackgroundThreads . They seem to recommend a 4:1 or 3:1 ratio and they don't seem to recommend anything above 3 or 4 generatorThreads even with a ton of cores.

Is that all you have of the logs? It seems like whatever happened it decided to exit higher up from where you started posting but I could be wrong.

In my experience ,12 is a bit overkill for aliveSectorsPerPlayer for most servers, you may want to cap closer to 8 or 10 as it seems to have an slowing effect on the worker threads the more you add both. You probably want to start by increasing the ratio between worker threads and generator/script threads as per the docs (https://avorion.gamepedia.com/Setting_up_a_server#Examples_for_different_machines:). It seems like every person I've talked to has has similar issues when they don't stick to the 4:1 - 3:1 ratio the developers suggest. Also verify that your processor supports hyperthreading if you're going to exceed the number of threads per core or you'll run into more issues. As a final note on the matter of ZFS, assuming you're using linux it's good to note that ZFS is not natively supported on linux, and has a rather unique read/write architecture. I'm not going to say that it's also compounding the issues but I will say that you may want to work with a more classic/predictable filesystem before you have these issues ironed out, or at the very least configure your ZFS cluster in an extremely vanilla manner. Just a thought! Also here's a little example of how I might configure your server (having used much weaker boxes). 16x Cores 24GB Memory saveInterval=600 sectorUpdateTimeLimit=300 emptySectorUpdateInterval=2 workerThreads=16 generatorThreads=4 scriptBackgroundThreads=3 aliveSectorsPerPlayer=8 weakUpdate=true profiling=true sendCrashReports=true hangDetection=true backups=true backupsPath= simulateHighLoadServer=false sendSectorDelay=2 placeInShipOnDeathDelay=7