I keep dropping from taspringmaster.clan-sy.com, and sometimes reconnecting takes ages. What is up with the server, is it overloaded?

Me too. I blame Licho.

Massive overload of unknown source, overload seems to consists of millions of web requests, probably by file mirror system of springfiles because it also happens on mirror servers.

even for a troll you deserve to go to heaven forever, live in the middle of hippies and starcraft players

I haven't trolled in years :/

Stop trolling

on-topic tho, this connection problem is really annoying, we had a nice 6v6 ZK going then server dies and by the time it's up again everyone is gone and now there's no games

@Licho: is it possible to separate the lobby server from the webserver? If you have only 1 machine you could use virtualization for this. I have exp. with this, and can help, if wanted.

For the time being you could just [io]nice the webserver, so it cannot take down the lobby.

Overloaded lobbyserver wont affect games.

If you got disconnected from ZK, which is hosted as dedicated server on same machine, it was truly huge overloaded because it runs at negative nice/ionice and needs only minor disk writes to demo and infolog.

There is already VM on the machine, problem is host system is linux which itself gets overloaded taking everything with it..

Sometimes its slow for no visible reason and reboot helps.

Most common known causes of overload are buildbot and backups.

since a very long time i suffer constant (timeout assumed). is that me or server ?

If you get it always its mostlikely you. Do you try to connect to springrts.com ?

Also even now server gets hammered ..
buildbot atm:

well i try to connect to... whatever is set as default :'

thx for info that its me, time for format finally :c

The information displayed by top is a little off: the CPU time used by cppcheck and the summary line don't match. What's causing the I/O? If you use "dstat" you can get more consistent statistics.

The host system of a virtualized system should not run anything except SSH - that is very important for the performance of all VMs, as the host does all the I/O. It helps a lot to pin one or two cores exclusively to the host system, and let the other cores be shared by the VMs.
If you then move the buildbot to a VM it cannot effect the other VMs performance anymore (as it does not effect the hosts exclusive cores).

I get the same as Wombat, TASClient throws me a "timeout assumed" a few times a day, and I have to wait some minutes to be able to rejoin.

Also I was on skype with another Finnish player, and he got one of these the exact same time I did.

Only 4 out of the 17 load is due to buildbot in this image, rest is probably due to other processes being blocked on overloaded disk. (cppcheck uses barely any disk I/O, it is cpu bound and only reads some source files)

Virtualization sounds ok, problem would be porting all we have now to it. I mean its lots of custom scripts and setups probably many days of work.

So I would rather focus on addressing just the issue now (I could try moving some sites to windows VM which is just 2 processes and cannot cause load > 2) and later upgrade HW (when this one expires).

as there are lots of parts on the server, shouldn't it be possible to run each one on a different VM (maybe a single one for all the very low-load stuff)? this change could be done gradually, and VMs can be moved to run on other hardware quite easily, which might be a good idea anyway. having multiple small servers then one big one.

I think it should be relatively easy to move some webs to VM (while keeping mysql on linux). Or soemthow tweak apache to rape less.

the lobby server itself and probably the springies+spads could be moved to my dedi safely (which is mostly not used right now). this means games won't be affected by website, buildbot, etc.

I would rather move out the expensive stuff (buildbot, backups)

Than to reconfigure existing stuff.

your server is far better suited for buildbot etc. if we were to move it we'd need to move it somewhere just as powerful or more.