Advanced MT Server performance settings: Hardware

[Festus1965]

Hardware

* main maybe is CPU, not much cores/threads but fast (frq)

when the CPU is not doing anything, but still one gamer lag, then go next step,
as there may by a bottleneck get data to cpu from HDD, or as too less RAM ...

* RAM, motherboard build in RAM
** more is better, 8 min I think, 16 good, 32 have advantage (see then OS System cache)
AND
** using all slots on motherboard, as 1 slot 100% RAM speed, but 4 slots near 200% then !!!

OR/AND
* fast HDD access
** normal HDD has about 200 read/write / s -
** SSD can have up to near 500 read / write
** M.2 SSD onboard or via adapter get up to 2.200 read/write at me - even can 3600 / s
* or use RAID that spread access over 2 or more HDD, mean 2 with 200 get near 400 read/write i think, 4 in a raid for speed can reach 800 then (here you are better than normal SSD)
--- Important what raid is used ---

BUT
if have a lot of RAM can be used as cache, RAM is better/faster --> OS Settings

[Festus1965]

OS System

Linux


Ubuntu (what I use and found some, less but helpful)
* /etc/sysctl.conf

Code: Select all

vm.swappiness = 1
vm.dirty_ratio = 95

* using swap at last option, keep on fast memory (instead on very slow HDD swap)
* use up to 95% of ram to cache (and this keep map in cache + fast available) example at me dump is 16.6 GB, and up to 12 GB RAM are used as cache after 2 days




further I use:
* sudo htop
as can set Priority (F7=-1 F8=+1),
and here 2 main mtserver get (-2)18, all other mts (-1)19, and htop (+1)21 -- try to ensure after os mts is first to do !


even I use GUI Ubuntu (with own GPU card), the empty run is near 0% - and with mtserver just near 5% - so that isnt that big deal.

[Festus1965]

do not forget to check this: Server performance settings

MT Server

minetest.conf

# for [Mod] free_lj_mem 1.5
timeloop = 1800
maxluamem = 350000
# keep lua mem low (avoid OOM)

# Maximum number of players connected simultaneously
max_users = 32
# keep maybe just 10% higher than max you know server can handle
# (do not forget lost points if higher than 32)

# allow profiler for some time, use with /profiler save and see cpu using mods
profiler.load = true


# *** FOLLOWING I explain later ***
# but this are most my settings
# check my server lag, before listen to complain posts I have proofed it


# how many blocks are flying in the wire simultaneously per client
#max_simultaneous_block_sends_per_client = 40
max_simultaneous_block_sends_per_client = 400

# how many blocks are flying in the wire simultaneously per server
#max_simultaneous_block_sends_server_total = 200
max_simultaneous_block_sends_server_total = 12000

# Number of extra blocks that can be loaded by /clearobjects at once
# This is a trade-off between sqlite transaction overhead and
# memory consumption (4096=100MB, as a rule of thumb)
#max_clearobjects_extra_loaded_blocks = 4096
max_clearobjects_extra_loaded_blocks = 512000
# when you have a lot of RAM, use it !

# From how far clients know about objects, stated in mapblocks (16 nodes).
# type: int
# active_object_send_range_blocks = 3
active_object_send_range_blocks = 3

# How large area of blocks are subject to the active block stuff, stated in mapblocks (16 nodes).
# In active blocks objects are loaded and ABMs run.
# type: int
# active_block_range = 3
active_block_range = 2
# this one mostly is resulting in lag !!!

# From how far blocks are sent to clients, stated in mapblocks (16 nodes).
# type: int
# max_block_send_distance = 10
max_block_send_distance = 10

# Maximum number of forceloaded blocks
#max_forceloaded_blocks = 16
max_forceloaded_blocks = 5120

#server_unload_unused_data_timeout = 600 # 86400 24 h, 1 Tag
server_unload_unused_data_timeout = 86400
# when you have a lot of RAM and set cache, then USE it !

# Maximum number of statically stored objects in a block.
# type: int
# max_objects_per_block = 64
max_objects_per_block = 1024
# this maybe an issues when using pipeworks, works like this

# See http://www.sqlite.org/pragma.html#pragma_synchronous
# type: enum values: 0, 1, 2
# sqlite_synchronous = 2
sqlite_synchronous = 1

# Level of logging to be written to debug.txt.
# 0 = none, 1 = errors and debug, 2 = action, 3 = info, 4 = verbose
#debug_log_level = error,debug,warning
debug_log_level = warning

# Maximum number of blocks that can be queued for loading.
#emergequeue_limit_total = 256
emergequeue_limit_total = 5120
# never proofed, but works also

# Maximum number of blocks to be queued that are to be loaded from file.
# Set to blank for an appropriate amount to be chosen automatically.
#emergequeue_limit_diskonly = 32
emergequeue_limit_diskonly = 4096
# never proofed, but works also

# Maximum number of blocks to be queued that are to be generated.
# Set to blank for an appropriate amount to be chosen automatically.
#emergequeue_limit_generate = 32
emergequeue_limit_generate = 2048
# never proofed, but works also

# Number of emerge threads to use. Make this field blank, or increase this number, to use multiple threads.
# On multiprocessor systems, this will improve mapgen speed greatly, at the cost of slightly buggy caves.
#num_emerge_threads = 1
num_emerge_threads = 5
# I have 8 threads on 4 cores, so as 2 main mts are allways at me, and keep one for system i set (8 - 2 - 1 =) 5

# maximum number of packets sent per send step, if you have a slow connection
# try reducing it, but don't reduce it to a number below double of targeted
# client number
#max_packets_per_iteration = 1024
max_packets_per_iteration = 8192
# the higher the more (fast) date your clients get update - but if low INTERNET, mhhh

# Length of a server tick and the interval at which objects are generally updated over network.
# type: float
# dedicated_server_step = 0.09
dedicated_server_step = 0.033
server_step = 0.05
# whatever coders complain about this - I get my advantage with this !

# Time in between active block management cycles
# type: float
# active_block_mgmt_interval = 2.0
active_block_mgmt_interval = 1.5

# Length of time between ABM execution cycles
# type: float
# abm_interval = 1.0
abm_interval = 1.0

# Length of time between NodeTimer execution cycles
# type: float
# nodetimer_interval = 0.2
nodetimer_interval = 0.2

# At this distance the server will aggressively optimize which blocks are sent to clients.
# Small values potentially improve performance a lot, at the expense of visible rendering glitches.
# (some blocks will not be rendered under water and in caves, as well as sometimes on land)
# Setting this to a value greater than max_block_send_distance disables this optimization.
# Stated in mapblocks (16 nodes)
# type: int min: 2
# block_send_optimize_distance = 4
block_send_optimize_distance = 2

# type: bool
# server_side_occlusion_culling = true
server_side_occlusion_culling = true


world.mt
use faster database backend
* worldmap
* player
* ...


But maybe all optimizations are nothing worth when high ping / rtt gamer join in
I remember, when I got into ctf they all realized higher lag, even not know I was the reason with 250 ping.

[Festus1965]

you need to use "/profiler save" some time and check the summary of mod cpu time (given at last row in % of 100% counted)

[Mod]s

* moretrees
cut down near all more-trees around spawn - where this mod will be activated all time
# it works, I proofed it - before most cpu time, now near nothing

* technic
false the radiation check and hit, saving near 30% of cpu time
config.lug

Code: Select all

   enable_radiation_protection = "true",
   enable_entity_radiation_damage = "false",
   enable_longterm_radiation_damage = "false",


* pipeworks
luaentity.lua - sdomewhere line 365 (here my version) - but cut down 50% of cpu using

Code: Select all

local handle_active_blocks_timer = 0.01

minetest.register_globalstep(function(dtime)
   handle_active_blocks_timer = handle_active_blocks_timer + dtime
   if dtime < 0.03 or handle_active_blocks_timer >= (dtime * 9) then
      handle_active_blocks_timer = 0.01
      move_entities_globalstep_part1(dtime)
      move_entities_globalstep_part2(dtime)
   end
end)

[Festus1965]

connect via cable (10 MB is still MUCH enough !) - before use WiFi (most have sure 100 MB)

MT Client
(never forget, picture is calculated by CPU and shown by GPU - so your hardware limits it also)

* settings
off: if you feel to less fps, or you don't need (to see) this
* Smooth Lighting
* Particles
* 3D Cloud
...
* Shaders
use
* Simple Leaves

* client_mapblock_limit: I set high, I have RAM (4096)
keep in own memory, not need to ask for new so often, reduce a bit transfer - but advantage when revisit last area, is still there

* viewrange: the lower the better fps, as GPU has less work - for what long view when in house, mining

* enable mash-cache, I use 200 size

* client_unload_unused_data_timeout (in sec) I use most up to +4 to 12 hours 7200 or more, but
change here to bigger as testing, more mean go back last area may still be there, not loading all again,
too much I found fps slow down fast, if visit to much areas = better restart client


special for mobile gamer using WiFi !
just your internal home network will most be faster than what the provider can deliver you !
# setting a lower rate wifi setting, get more stable and at the end more transfer !
let me guess you have 1 MB, 2 MB 4 MB up to 10 MB INTERNET connection ?

but WiFi offers (read here Wiki) so
802.11b - can deliver - 1, 2, 5.5, 11 Mbit/s
802.11a (j, p y) - can deliver - 6, 9, 12, 18, 24, 36, 48, 54 Mbit/s
802.11n - can deliver - 20 = Up to 288.8 / 40 up to 600 Mbit/s
802.11ac - can deliver, depend on bandwith 346.8 to 3466.8 Mbit/s
what is that fast transfer rate helping you inside the house if it is never delivered from outside ???

yes, if you have an internal media-server, may check the rate used to look a movie, and adjust for this also

the disadvantage is, the higher the possible transfer-rate, the lower the quality or stability of connection
mean, using lower rate, connection will not fail so often when you just torn around in your bed with your phone/tab in the hand... hehe

: so if your "delivered" transfer rate from provider (check with download tests)
: is lower then the protocol WiFi using (802.11...),
==> maybe lower the internal WiFi internet (normally called intranet !) protocol and get even more stable connection in house between router and device !!!
AND also check a bit for optimal position of router (wall reduce signal), and antennas straight UP ! - they are round sender/receiver ! if taken for one floor living area


practical example at my home:
* true fiber deliver me 50 MB/s
* so 802.11a with 54 MB/s WIFI is just perfect,
but
* I use cable as possible
* I use mesh, mean 5 WIFI router around the house, as of restaurant, spread usage also, and everywhere full signal strenght

example from last stay hotel 6 day
I forced my WIFI to connect only 11 MB, as before so often timed out as normal 54 BM. With 11 worked fine and steady.


But maybe all optimizations are nothing worth when you join far away server with high ping / rtt
I remember, when I got into ctf they all realized higher lag, even not know I was the reason with 250 ping.

[Festus1965]

about reduced cpu time usage:

lagcheck: 05.03.2019 before all the optimizations:
Modname | Average | Min | Max
technic (7) | 643 | 0 | 587903
moretrees (15) | 577 | 0 | 182051
technic (1) | 313 | 0 | 66937
technic (6) | 136 | 0 | 1611
moretrees (3) | 133 | 0 | 4057
bushes_classic (1) | 43 | 0 | 406
moretrees (22) | 42 | 0 | 123291
3d_armor_stand (1) | 41 | 0 | 224
pipeworks (2) | 40 | 0 | 232
technic (15) | 35 | 0 | 53
moretrees (14) | 34 | 0 | 186

07.03.2019 - cut off trees (jungle tree of more-trees !) around spawn
* pipeworks: 41% (main globalstep[1])
* technic 18% (main from Switching Station 75%, globalstep[2] 15%)
* mesecon: 8% (main globalstep[1])
* mobs_animal: 6.8% (half of this by on_step[23])
* default: 6.3%
* mobs_monster: 5.6%
* areas: 4.2%
* player_api 2.5%
* time: 2%
...
* moretrees: 0.0 % ???


last profiler after 6 days server run 17.04.2019:
* 19.7 % - mobs_monster
* 16.2 % - mesecons
* 15.2 % - technic
* 12.8 % - pipeworks
* 7.8 % - mobs_animal ...

? So some off you may ask why
* mobs_monster from 5.6 to 16.2 %, and
* mesecons from 8 to 16% raised up.
Clear, when you are able to cut out 50% of former cpu usage, all other users have then double of used time, as there share of the now less using time sum "grows". So that's an reverse proof of saving cpu time also.

[twoelk]

the lag around spawn by moretrees might be due to the amount of leaves regardless of tree type. I would guess a bunch of jungletrees around spawn would produce similar lag.
Might be worth investigating.
Moretrees is too beautifull to be so bad for a server
yay - save the trees!

[Festus1965]

a bunch of jungletrees around spawn would produce similar lag.
Might be worth investigating. ...

this is what I have proofed ! just took down all more-trees (in my case, yes ! the 98% jungle trees - needed about 4 days with saw) around areas where most gamer are and might activate it. So a lot of work, but sure worth !