Here are some notes I did for troubleshooting. I think the performance issue comes down to how BDS implemented threading on linux.
I made some progress getting the most out of it, and still need to do some profiling to see if there's much to do...but at a quick glance, it seems that the threading implementation works poorly under linux, and it works best with a max of 2 threads.
I've found that performance for entities (minecarts, mobs, etc) degrades significantly when max_threads is set >2 (regardless of the underlying host). It seems that this degradation minimally affects players and world loading – for example, when degraded, a player can run smoothly, along a rail track, but stick down a mine cart, and ride, and movement can be about 1 square per second, and mobs/fired arrows/etc also move at about 1 square per second.
My test environment: a freshly installed ubuntu 20.04 on a dell r410, 2x xeon x5650 processors (6 cores/12 threads each), 24gb ram, disks are 2x mirrored 15k rpm 143gb sas disks. The only thing running is a single copy of bedrock_server. I've tested with incremental changes to max-threads, tick-distance, view-distance, server-authoritative-movement. I have one user logged in an existing world, at the world spawn, with a fairly large number of entities within the tick distance. I have another user logged in, riding a mine cart in the nether. All tests are done on in previously loaded chunks, on a freshly started server instance within 30 seconds of instance start up. (I have separately tested to see if letting the server run for 10 minutes to load prior to testing would affect things, but with no noticeable difference).
Either user can be logged in and operate just fine. However, with both users logged in, if the max_threads is set anywhere over 2, (ex: 3, 4, 8, 24, 0(unlimited)), the nether rail cart comes to a crawl, and mob movement is visibly stuttery. With max_threads set to 1 or 2, The mob movement (chickens, spiders, etc) is smooth, and the nether rail mine cart has minimal stuttering.
view_distance does not seem to have a noticeable performance effect below about 48, however at higher values, max_threads needs to be increased, or elytra flight can outfly block loading. With max_threads=0(unlimited) and view_distance=96, elytra flight is possible without overflying loaded blocks. However, any mobs encountered move at a glacially slow pace. tick_distance does seem to have an effect, but I haven't teased that out yet – I suspect that larger number of mobs ticking exercises the thread limitations.
With max_threads set to anything other than 1 or 2, and server-authoritative-movement=client-auth, an interesting thing happens – when the server is somewhat loaded (for example, in an area with extensive redstone contraptions), any time a player descends (down scaffolding, stairs, ladder, etc) the player will take fall damage as if they had fallen the distance descended. If a player descends 64 blocks of scaffolding, they will take damage as if they fell 64 blocks in free-fall. But with the same settings, and server-auth, player movement is still smooth, and no fall damage occurs with descent.
A few other interesting things I've seen: When running in strace -f -c, with max_threads=0, a 2m2s run has this output from strace (truncated for just top 6 calls): {{% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ----------------}} {{ 75.34 295.929352 1699 174123 60918 futex 13.61 53.461597 15420 3467 recvfrom}} {{ 3.83 15.026166 221 67866 read 3.50 13.743365 1330 10326 1 clock_nanosleep}} {{ 3.15 12.361606 13 888758 clock_gettime 0.30 1.174830 9 129890 gettimeofday}} {{}} {{}}And same world, same logins, etc, though run happened to be about 1m25s: {{% time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ----------------}} {{ 55.44 28.957834 889 32565 12730 futex 26.86 14.028774 5182 2707 recvfrom}} {{ 7.75 4.045752 143 28272 read 6.96 3.637554 536 6778 clock_nanosleep}} {{ 1.62 0.843697 3 212790 clock_gettime 0.72 0.374866 5 69017 gettimeofday}} {{}} {{}}Noting that the max_threads=0 version spent almost 5 minutes of cpu time (in 2 mins of real time) making futex calls, while the max_threads=2 run used considerably less cpu time than real time. The max_threads=0 version made considerably more futex calls, and spent considerably more time per call.
brian c
Here are some notes I did for troubleshooting. I think the performance issue comes down to how BDS implemented threading on linux.
I made some progress getting the most out of it, and still need to do some profiling to see if there's much to do...but at a quick glance, it seems that the threading implementation works poorly under linux, and it works best with a max of 2 threads.
I've found that performance for entities (minecarts, mobs, etc) degrades significantly when
max_threadsis set >2 (regardless of the underlying host). It seems that this degradation minimally affects players and world loading – for example, when degraded, a player can run smoothly, along a rail track, but stick down a mine cart, and ride, and movement can be about 1 square per second, and mobs/fired arrows/etc also move at about 1 square per second.My test environment: a freshly installed ubuntu 20.04 on a dell r410, 2x xeon x5650 processors (6 cores/12 threads each), 24gb ram, disks are 2x mirrored 15k rpm 143gb sas disks. The only thing running is a single copy of
bedrock_server. I've tested with incremental changes tomax-threads,tick-distance,view-distance,server-authoritative-movement. I have one user logged in an existing world, at the world spawn, with a fairly large number of entities within the tick distance. I have another user logged in, riding a mine cart in the nether. All tests are done on in previously loaded chunks, on a freshly started server instance within 30 seconds of instance start up. (I have separately tested to see if letting the server run for 10 minutes to load prior to testing would affect things, but with no noticeable difference).Either user can be logged in and operate just fine. However, with both users logged in, if the
max_threadsis set anywhere over2, (ex:3,4,8,24,0(unlimited)), the nether rail cart comes to a crawl, and mob movement is visibly stuttery. Withmax_threadsset to1or2, The mob movement (chickens, spiders, etc) is smooth, and the nether rail mine cart has minimal stuttering.view_distancedoes not seem to have a noticeable performance effect below about48, however at higher values,max_threadsneeds to be increased, or elytra flight can outfly block loading. Withmax_threads=0(unlimited) andview_distance=96, elytra flight is possible without overflying loaded blocks. However, any mobs encountered move at a glacially slow pace.tick_distancedoes seem to have an effect, but I haven't teased that out yet – I suspect that larger number of mobs ticking exercises the thread limitations.With
max_threadsset to anything other than1or2, andserver-authoritative-movement=client-auth, an interesting thing happens – when the server is somewhat loaded (for example, in an area with extensive redstone contraptions), any time a player descends (down scaffolding, stairs, ladder, etc) the player will take fall damage as if they had fallen the distance descended. If a player descends 64 blocks of scaffolding, they will take damage as if they fell 64 blocks in free-fall. But with the same settings, andserver-auth, player movement is still smooth, and no fall damage occurs with descent.A few other interesting things I've seen: When running in
strace -f -c, withmax_threads=0, a 2m2s run has this output from strace (truncated for just top 6 calls):{{% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------}}
{{ 75.34 295.929352 1699 174123 60918 futex
13.61 53.461597 15420 3467 recvfrom}}
{{ 3.83 15.026166 221 67866 read
3.50 13.743365 1330 10326 1 clock_nanosleep}}
{{ 3.15 12.361606 13 888758 clock_gettime
0.30 1.174830 9 129890 gettimeofday}}
{{}}
{{}}And same world, same logins, etc, though run happened to be about 1m25s:
{{% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------}}
{{ 55.44 28.957834 889 32565 12730 futex
26.86 14.028774 5182 2707 recvfrom}}
{{ 7.75 4.045752 143 28272 read
6.96 3.637554 536 6778 clock_nanosleep}}
{{ 1.62 0.843697 3 212790 clock_gettime
0.72 0.374866 5 69017 gettimeofday}}
{{}}
{{}}Noting that the
max_threads=0version spent almost 5 minutes of cpu time (in 2 mins of real time) makingfutexcalls, while themax_threads=2run used considerably less cpu time than real time. Themax_threads=0version made considerably more futex calls, and spent considerably more time per call.