Did some testing with what lags the server most. It seems to be entity-acting blocks such as sand, gravel etc. Blocks which fall down. If I remove a lot of sand (which I did to make the stronghold for 1.0) the server lags up and if I don't stop dies, reboots itself and comes back up. Maybe someone with more understanding on servers can connect the dots why things such as falling sand do this?
That's pretty interesting and weird, it won't stop your progress on the stronghold any though, right? :<
I'll also poke qaz about this
Consider me poked.
Just as a clarification, the server doesn't actually reboot by itself. As far as I can tell, this is what's happening:
A little background knowledge first, minecraft and the minecraft server both save loaded chunks once every two seconds if they've changed at all. As far as I know, this includes redstone state and lever/button state, anything which alters block data. This would usually be okay (a bit too often IMO, but whatever) but minecraft is programmed that the save function, physics and rendering all occur in the same thread. This is particularly noticeable in single player on heavily fragmented disks or disks with low I/O as the game pauses while chunks are saved to disk and is commonly known as "the lag spike of death". Multiple mods exist which seperate the chunk saving into a seperate thread, one of the most prominent being optimine/optifine. What I believe is happening is due to the large amounts of physics that occurs, the write is put off for a fraction of a second, causing more block data to have changed. This leads to a longer write cycle and more block data sent to the client, giving the player a longer period of time in which to mine more physics based blocks, leading to an even longer write cycle... Ad infinitum, or until the combined latencey caused by lots of physics calculations and writes to disk leads to the server taking so long to respond to network requests that the client believe the server to have died and kicks you from the game. While the player is offline, all chunks surrounding the player are unloaded from memory once the physics has finished and saved a final time before the server is able to respond again, this usually happens quicker than if connected because the server no longer has to send block updates to the client. (Another thought here, number of block updates really shouldn't affect write time, should it? I mean, the file is compressed, so most of the latency should come from the compression/decompression, not the actual writing of blocks, no matter how many blocks in a 32x32 chunk space are edited, it still has to decompress and compress an entire MCregion)
The same thing happened before 1.6 (not sure, fire nerf update) when you set fire to large forests. I was looking at a plugin that reduced how often the game saves to the hard drive among other things but by default it likes putting a lot of chunks in vram (somthing which the server literally has none of) and so it crashed the server repeatedly quite fantasticaly with out of memory errors. I'll try re-enabling it and disabling chunk caching.
EDIT:
Did some testing with what lags the server most. It seems to be entity-acting blocks such as sand, gravel etc. Blocks which fall down. If I remove a lot of sand (which I did to make the stronghold for 1.0) the server lags up and if I don't stop dies, reboots itself and comes back up. Maybe someone with more understanding on servers can connect the dots why things such as falling sand do this?
it might be RAM. last i remember, you folks had only 512 megs total in any case, right?
we've got 1GB of RAM now
it also could be the physics cause large RAM usage and the garbage collection working overtime, but I rarely see spikes in ram usage.
