We already keep most of this data in memory and flush it only periodically, so we don't enforce the strictest durability standards on in-game changes (i.e. What we really need is to move all potentially-disk-blocked write activity like map, modstore, player, and auth saving into a background thread. I've also heard that it could be related to postgresql being the back-end for the dedicated server (which I do, event though the public shapshot downloads are converted to sqlite) so while I didn't think that could be the cause, it might be useful for reproducing the problem.
#Minetest videos how to#
forum post at bottom of OP) indicates that this is not a game-specific problem, and if somebody else who runs a server and has observed this could provide instructions on how to configure to repro it that would be much appreciated. The fact that people are reporting this elsewhere (N.B. I apparently need to make this change for my game anyway, to cut down on unnecessary mesh rebuilding. I'm going to implement the meta privatization so we can eliminate that as a factor and get a more clear picture of what's going on here, but I'll be very surprised if it's a "fix". The original problem was on a dedicated server, where client mesh generation should be a non-issue, so the only way that should be the cause would be if the sending of block update packets to the clients is the cause of much lag the lag spikes also happen about once a second, where I'm sure that the update packets are not all batched that way. Preliminary results from that effort show an improvement in performance, but still not enough to make a notable difference in the overall performance.Ĭompletely disabling all ABMs drops the server lag down significantly, but it's still nowhere near as low as it should be. Right now there are 82, but I think I may be able to reduce them by as much as half by multiplexing. I've also gotten some advice from rubenwardy to try to reduce the number of ABMs registered with MT. I also have a few players who are very sensitive to network traffic and will report traffic problems if they arise, and I've spent some time at least managing the game's responsibility for generating network traffic, so that seems to suggest that's not the issue. If it is network, then it must be the processing overhead from them, not the traffic itself, because I'm measuring based on globalstep dtime, not based on time to respond to a client action.
#Minetest videos mod#
I can't tell whether it's networking or not, but I've been fine-tuning the lua code for this mod well into diminishing returns. Note that the lag is higher now in some cases apparently triple.
#Minetest videos install#
Rechecked on my server (NodeCore Community World) and the lag was about 0.54 on 5.3, and 0.18 on 5.2. Operating system: Linux 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 () x86_64 GNU/Linux (Debian 10)ĬPU: Intel(R) Xeon(R) CPU E5-2630 v4 2.20GHz (VPS from Contabo,, no add-ons) SummaryĪverage server lag is about triple what it was under 5.2.0 using the same mod code.
0 kommentar(er)
