[MUD-Dev] Server stability (was: Player statistics)

[Bruce]

Par Winzell wrote:
> Koster, Raph writes:
>  > Bruce wrote:
>  > > Ouch.  Sounds like your DB guys looked at MOO or
>  > > something. :)
>  >
>  > UO keeps everything in memory for speed, and dumps
>  > the entire world state to disk periodically. EQ also
>  > keeps everything in memory for speed, and dumps
>  > individual characters on a rolling basis to disk.
>  >
>  > > Cold hasn't got this 'problem', as it is a disk-based
>  > > system, and demand load objects from the on-disk
>  > > database.
>  >
>  > The concern is speed. Any perceptible delay in accessing
>  > this data is unacceptable in most cases, and our databases
>  > get very large. Everyone I know in the commercial industry
>  > is trying to do this for the next generation of games,
>  > but nobody knows how it'll perform in a live environment.
>  > EQ tried it prior to release, and couldn't get it fast
>  > enough.
> 
> I assume you're saying that everyone you know in the
> commercial industry is trying to switch to a system where
> objects can reside on disk?

And we catch up with the commercial database world ....

> We build on top of DGD, which, like Cold, is disk-based. If
> left alone long enough with no activity, all persistent data
> will get swapped out, and doing a full state dump to disk is
> instantaneous.
> 
> That said, however, 'disk-based' is a misnomer; in actuality this
> system is obviously a superset of a purely RAM-based one -- just
> set the swap rate infinitely low and everything stays in memory.

How does this work in DGD in more technical terms?

In Cold, objects sit in the cache until:
  * A cache sync is performed, either:
    * Prior to a backup
    * The sync() primitive is executed.
  * They are forced out to disk through
    the usual cache eviction means.
  * The cache cleaning thread (a real thread)
    writes them to disk because they are inactive.
    (This is a new feature in the unreleased
    dev tree.)

There aren't any timers that cause an object to get written out
just because things have been idle for a while. (Not that I see
any idle time any more.)  (Although, the cleaner thread will
write out inactive objects after a period of time has passed, but
that timing has more to do with the configuration of the cleaner
thread than with the length of time that an object has been
unused.)

In Cold, we can just make the object cache large enough such that
it can hold every object in memory.  But that's rarely a win for
reasons that are hinted at in JC's post.

> This perceptible access delay, is it the overhead of
> checking if an object is in-memory or needs to be swapped
> it? Is it the time consumed by actually swapping in
> long-unused objects? By swapping them out, perhaps? Do
> you know?

Typically the delays will be from:
  * Loading an object from disk
  * Writing an object out to disk if space
    in the cache was needed to be freed
    to have space for a new object.

> We're just reaching a 200-meg database on our Castle of Marrach
> so it is much too early to make any kind of comparisons against
> the large graphical games. That kind of comparison is probably of
> minor interest anyway; I expect a larger subset of objects need
> to be swapped in for a horizon-revealing game like EQ anyway?
> 
> I expect in a year we'll have 3-4 gig databases... we'll see how
> that goes.

Do you have just one file for all of your saved-state?  If so,
how do you plan on handling file size limitations (the 2 or 4 gig
file size limits on 32 bit OSes without LFS)? Or do you just run
an OS without silly limitations? :)

 - Bruce
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev