Rozdíly
Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.
|
dev:mohlo_by_se_hodit [31.01.2014 10:52] ritchie max_lag |
dev:mohlo_by_se_hodit [19.01.2015 20:23] (aktuální) ritchie zalohovani db bez restartu mt serveru |
||
|---|---|---|---|
| Řádek 63: | Řádek 63: | ||
| m_env->reportMaxLagEstimate(max_lag); | m_env->reportMaxLagEstimate(max_lag); | ||
| </code> | </code> | ||
| + | |||
| + | Další pěkné vysvětlení max_lag, by Zeno: https://forum.minetest.net/viewtopic.php?t=10884&p=167238#p167292 | ||
| + | |||
| + | >max_lag is kind of diffucult to explain. If you're interested in your **own** lag, RTT is the value you want to be looking at (not max_lag). | ||
| + | > | ||
| + | >What max_lag (very basically) is how long the server takes to process a single "server step" (i.e. update the environment, make new map blocks, reply to all clients... stuff like that). Let's call that server_step_time. Every time server_step_time is greater than twice the current max_lag then max_lag becomes that new server_step_time. | ||
| + | > | ||
| + | >Once the CPU processing spike goes away the max_lag decreases by .02% every server_step (unless it goes up again) until it again reaches the "normal" server_step time. This can take a while (maybe 5-10 minutes). So even if max_lag is showing, say, 5.6s the current server lag may be (and probably is) a lot less. | ||
| + | > | ||
| + | >Anyway, from a client perspective RTT is the value you should be looking at, and that's for your client only. The minimum value for RTT is at least server_step_time, so it *is* kind of associated with max_lag for a particular instant but because of the way max_lag is calculated and decreased slowly it's not very well correlated at all (unless max_lag is constant). | ||
| + | > | ||
| + | >Err, it's kind of complicated isn't it :/ max_lag is not really useful from a client's perspective at all because there is nothing the client can do about it. It's really more useful for people running a server and tuning server-side values. Even then, because max_lag is a weighted average (in effect) using a fixed value for the weight it's uses are (currently) limited (IMO) | ||
| + | |||
| + | ==== Zálohování DB bez restartu MT serveru ==== | ||
| + | |||
| + | http://irc.minetest.ru/minetest/2015-01-19#i_4121156 | ||
| + | |||
| + | vitaminx: | ||
| + | >btw. i just found a method to safely backup map.sqlite *without* stopping the server | ||
| + | >create a file called "backup.sql" and put this inside: | ||
| + | <code> | ||
| + | begin immediate; | ||
| + | .shell cp $HOME/.minetest/worlds/world/map.sqlite $HOME/map.sqlite_backup | ||
| + | rollback; | ||
| + | </code> | ||
| + | >then tell your backup script to execute this line: | ||
| + | <code> | ||
| + | echo ".read backup.sql" | sqlite3 -echo .minetest/worlds/world/map.sqlite | ||
| + | </code> | ||
| + | >DB stays consistent and user stay logged in - they probably notice a short lag while the DB file is copied, thats all | ||
| + | twoelk: | ||
| + | >vitaminx: doesn't rollback freeze youre server? | ||
| + | vitaminx: | ||
| + | >it gets a lock on the DB, so minetest has to wait with it's writes - thats what I mean with short lag | ||
| + | >i will test it today, lets see if its really noticeable | ||
| + | >having a short lag is probably still better then to disconnect all players | ||
| + | |||
