I run in updatefirst mode. Updating srcds tends to use a lot of system resources lately, so the load average will spike up. This doesn't seem to affect the performance of the server at all (especially since I force servers to a core, and force the update script to it's own), but it will cause map changes to take forever. I've only seen it cause issues in a few rare cases, namely when it updates a map that is currently being played, or if it's updating a binary mid map change.
I'm not sure why updating uses so many resources, even if it's waiting for an hour (or more!) to actually start downloading the file. I don't believe it's nemrun's fault, though. I've never bothered looking into it. On Mon, Dec 19, 2011 at 7:41 AM, PharaohsPaw <[email protected]> wrote: > > It is "nicer" on the content delivery system if we only do one download > > per cluster for the hundreds of machines we run. It is also easier to > deal > > with failures when they occur, since they only occur on the root server > > (what Fletcher called the master) of each cluster. We also do a bunch of > > config management and templating from these root servers. The system > > scales better this way and is more robust than each server doing their > own > > updates. Also, there are complications with running multiple games from a > > single directory and using -autoupdate. This currently isn't possible to > > do without breaking your servers. The -autoupdate isn't designed for > > people running games this way. Maybe it ought to? > > all of the above are why running nemrun (if you are using it this way, it > can be used in different ways) is a lot better for everybody. speaking of > folks who do run multiple games from one server install tree. You only > have to pester the steam content servers to update the game ONCE. The > update daemon nemrun instance writes a lock file into the tree and sends a > quit to each running server, which, since they are also running the nemrun > script instead of srcds_run, check for existence of that lock file. Since > it is there, they stay down until the lock is removed (while the update > daemon nemrun instance updates the tree). Once nemrun has "verified the > update" (particuarly, verifying a steam.inf file exists), it removes the > lock and the servers come back up. > > It has another mode where it updates the tree first (without taking the > games down) but I've never been adventurous enough to try it. Seems to be > asking for weird probs for those connected players, at least depending on > what the update contains. > > Speaking of nemrun, I have just finished making a bunch of changes to the > script (v1.8.5) which hopefully at least some of which some other people > might consider useful and maybe even some could be included in a future > version. Will post to the list as a separate topic with a couple example > .cfg files for alerting connected players. > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
