Usage Statistics?

[Aaron Goulet]

Being an administrator of a Diku-based MUD myself (currently still in the pre-release stages of development), I am curious: what kind of system resources does ArmageddonMUD consume?  I'm interested primarily in CPU usage (percentage value, both a rough average as well as a snapshot during peak play times), used bandwidth (monthly), and drive space occupied (current).

A strange question, I know, but I want to see what the behemoth Armageddon 1.0 demands of Ginka.

[Xygax]

Saikun can talk more about bandwidth than I can, though I'd be surprised if the mud process itself consumes more than a few k-bytes per second on average.

CPU hovers around 10-20% for the main mud process (and it wouldn't really take a lot of tuning to make this drop), but we run test and dev servers and a handful of other helper processes, including an instance of MySQL which parts of the mud use and lots of the website uses.  MySQL and apache is are both pretty greedy, in their own ways.

After almost 20 days of uptime, the main mud process is consuming approximately 470MB of ram (you can see from my graphs posted the other day that we're pretty solidly leak-proofed at this point.  There are a handful of places I know off the top of my head where we could save 10-20MB with some variety of optimization, but it isn't worthwhile really.  Ginka was a bit of a beast when we first bought it and is still easily keeping up with Arm's needs.

In terms of drive-space, we eat up a fair bit with each instance of the game we run.  The full "library" of the running game currently stands at about 1.6GB, most of which is a very large accounts directory (how long have we had the account system??  *boggle*) and a few runaway log files.  We could probably trim down to 500MB or even less very easily.  We have several copies of this library on ginka, and we take periodic backups.

-- X

[Xygax]

It's worth mentioning that once-upon-a-time, the running Armageddon process actually ate pretty much one full CPU (it makes only very light use of threads, even now), mostly due to its use of the spidermonkey javascript engine (it re-compiled scripts for every run, and ran several thousand scripts per heartbeat).  A smarter caching system improved this issue.

-- X