Server Features

Revision as of 22:04, 25 May 2012

New Server Commands

These commands are new to Hack/Mine as of version 0.6 (not officially released yet.) Smart name matching has been added as well, so players can be searched for via the first few letters of their name, both case and 1337 insensitively.

If chunkX and chunkZ aren't specified, the player's current chunk is assumed. Dimensions may be -1, 0, 1, or 10 for the Nether, the surface, the End, and the mystery dimension respectively. The surface is assumed when not specified.

Chunk coordinates can be calculated from block coordinates if they're divided by 16 and floored (e.g. block coords of (26, -113) are inside chunk (1, -8)). Your current position in block coords can be found by opening the debug menu with F3 and taking "x" and "z" (your height being "y").

Flagged chunk data is saved to "flaggedChunks.txt" and can be edited while the server is off for quick flagging. Possible flags are protect-blocks, allow-pvp, and prohibit-pvp.

The Area Cache

"areaCache.properties" contains advanced settings for Hack/Mine's area cache, and fine-tuning them may improve performance and stability for your H/M server. Also, Frizzil needs people to mess with it in hopes of finding better numbers (if you screw it up or aren't sure about your changes, just delete the file and H/M will generate a new one for you.) Fine-tuning is really only necessary if your server is at 20+ people. However, the larger your server is, the more significant fine-tuning your area cache will become. You'll want to enable "verboseLogging" when experimenting and disable it otherwise, to avoid console clutter. If you find settings that work, post them along with your system and server specs on the discussion page!

Things to consider when tuning, from most to least important: How fast is my file I/O? What's the speed on my CPU? How much RAM do I have?

Basically, the area cache is a place in memory where Areas are stored for quick access. A "cache miss" is when a request is made for an area that isn't in the cache, resulting in it being loaded from disk and into the cache-- you're trying to minimize these as much as possible, since file I/O is VERY expensive (unless you've got SSD like a boss!) Obviously, areas must be loaded at least once, but the trick is storing areas that will likely be used again and removing those that won't to make room. More recently referenced areas are kept, whereas less recently referenced ones are removed. A larger cache helps, but results in slower "victim selection", and at extreme sizes results in general lag and high RAM consumption.

Each tick, the ratio of cache queries that were misses is calculated and stored in "pctMiss." This number is extremely small (generally peaking in E-4), but is still significant given that a cache miss can be over 1000 times slower than a cache hit. The exponential average of this number is stored in "avgPctMiss." I.e. avgPctMiss is set to avgPctMiss * w + (1-w) * pctMiss each tick, where w is "avgPctMissPastWeight" This gives three important numbers for you to tweak-- avgPctMissThreshold and pctMissThreshold, which "grow" the cache when exceeded, and "avgPctMissPastWeight", which is "how significant are recent values?" and effectively smooths out avgPctMiss as it approaches 1.00 (at 20 ticks/second, slight variations of this number from the default make dramatic differences.) If your past weight is too low, your cache will be too sensitive to minor fluctuations and grow too frequently, eventually crashing your server from RAM consumption or massive lag. If your past weight is too high, your cache will be too resilient to fluctuations, resulting in "area thrashing" as the need for areas exceeds the size of the cache, causing needed areas to be saved and loaded with each tick (This will cause massive lag and may also crash your server.) Basically, fine tune these numbers to get the perfect amount of responsiveness to cache misses, only growing when necessary to support the increased needs of players.

When the cache "grows", it takes a moment to copy it's data into a new, larger location in memory. "growthFactor" determines how much larger this location should be than the last location. Larger values result in less copying and hence lag, but more poorly associate the right cache size with your needs. E.g. a factor of 2 makes for little copying but potentially twice the resources consumed than needed if you just barely trigger a resizing. Values closer to 1 may result in good matching of resources, but will result in excessive copying (and even slow response to needs), especially at larger cache sizes.

For you fellow computer science geeks, this is an aging page replacement algorithm (except not pages), using a 64-bit "age" for each cache entry, shifting once every tick (about 20 times a second) further reading. The "growthFactor" tradeoffs are directly associated with that of a dynamic array's.

Remember to test this stuff out! If you're testing with a large player base, gradually make changes and see how they go so you don't piss everyone off. Take notes even-- save old "areaCache.properties" and write notes at the bottom of it, so you can go back to good settings once you've found them. Finally, good settings on one machine aren't necessarily good another, especially if the system specs are drastically different (SSD vs Harddisk, low-end CPU vs monster CPUs, etc)

And most importantly, enjoy speeding up your server and improving its stability!