[MUD-Dev] Wild west (was Guilds & Politics)

[JC Lawrence]

On Tue, 23 Dec 1997 07:15:57 PST8PDT 
Mike Sellers<mike at online-alchemy.com> wrote:
> At 10:53 PM 12/22/97 PST8PDT, coder at ibm.net wrote:

>> As mentioned earlier I log everything.  Be careful of that word
>> "log".  This does not mean that I create text files which record
>> past doings, but that I log DB activity amd the event sequences
>> such that any prior point in time for that BD can be created
>> __exactly__ as it was then, with the addition that that point in
>> time can be rolled forward thru time such that __exactly__ the same
>> things as ahppened back then, now happen again.
...

> Social engineering aside, what does this do to performance?  

As I mentioned at the start of this thread, that is part of my current
problem.  The real problem I have is a bandwidth one.  The sheer rate
of data production that I need to store challenges even the
theoretical limits of my IO devices (currently fast SCSI II).  When
you add the fact that the DB is on disk an merely cached in RAM, the
added IO for more normal processes puts the load way over the top.

I've been concentrating my technical attentions on this aspect almost
exclusively.  My currently planned implementation, __theoretically__, and
given a large enough DB cache in RAM, should work with a moderately
active world atop fast SCSI II devices.  Just.  Sorta.

Currently I have the following base model:

  All state changes to the DB are preserved.  This is done as a matter
of DB rollbacks.  Any time an object state changes enough data is
stored, with a timed key, to ressurect that prior state and time.

  All IO is preserved in a similar fashion.  Anything an object
attempts to output as a textual message to another object (ie SAY and
TELL and their variations), or anything an object "hears" as a result
of such an event (ie receiving a SAY or TELL) is recorded in the DB as
if it were an object state change.

The actual data stored in any of these cases is minimal.  As close as
possible it is atomic as vs object level, and is done ala context diffs.

The original intention for this feature was as an enhancement for
administrative use in game balance, modeling, tracking, etc.  Then the
time travel idea occurred to me, and proved far more interesting.

> It
> seems like if your mud was of any significant size and/or you have
> more than a few people on, the DB writes alone could grind you to a
> halt.  How have you dealt with this?

Cacheing, minimum sized compressed log entries for past object
states, and an object model design that devolves to base atoms which
are then tracked individually for state changes.

> And on that note, what's the "state of the thinking" (which seems to
> precede the "state of the art" in muds by a couple of years or so ;)
> ) on holding world state totally in RAM, writing to a DB via a large
> temporary RAM cache, or writing directly to a DB?  RAM-based systems
> are faster, but suffer from having "memory loss" in case of an
> unexpected shutdown (both M59 an UO suffer from this, to the
> *immense* annoyance of their users).

Marcus Ranum fairly effectively demonstrated that disk based DB's can
often be faster than in-RAM DB's.

I discussed this area on r.g.m.* some months back.  The simple reason
is page faulting and the definition of a MUD's working set.  

Given a MUD which is able to represent the entire working set of the
game in RAM as versus a MUD which stores everything on disk and reads
from disk on an as-needed basis, the in-RAM model of necessity will be
faster due to less IO overhead alone.  However, few are willing to
afford the several Gig's of RAM needed for such a model, with the
result that the performance benefits of in-RAM vs on-disk devolve to
the question of the performance penalty of the page faults generated
by the use of the working set of the MUD for in-RAM, and the IO
overhead of the DB reads and writes for the on-disk model.

The real underlieing problem is that very few system designs, MUD or
otherwise, have effective working set memory page management
techniques.  Ideally, the system would observe the use pattern of the
applicaiton's working set, and migrate objects in RAM such that the
working set of the application occupied the minumum number of memory
pages and thus generated the minumum page fault rate.  The result
would be that a mimimal RAN usagae system could operate at near
perfect speeds.

Disk based DB's with caches have an advantage here as the smaller size
of the cache tends to ensure close-to-minimal page faulting for
popular objects in the cache.  It is almost a back door approach to
migrating in-RAM objects to be page proximate.  Ranum did this with
Unter, and Gillespie and company hve continued the demonstration with
ColdX.  

Conclusion?  If you can afford the resources to have everything in
rewal physical RAM, then there is going to be nothing faster.  If you
can't afford that, there is a rather twisty set of performance trade
offs and equations based on your working set definition, IO overhead,
page fault generation rate, page fault expense, etc as to the optimal
strategy.

My approach?  I expect my DB to quickly be in the few dozen Gig range.
I'm not about to require a system with that quantity of physical RAM.
I use a large DB cache and keep everything on disk.

--
J C Lawrence                               Internet: claw at null.net
                                           Internet: coder at ibm.net
----------(*)                        Internet: jc.lawrence at sun.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...