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

[Par Winzell]

Koster, Raph writes:
 > > -----Original Message-----
 > > From: mud-dev-admin at kanga.nu  On Behalf Of Bruce
 > >
 > >> Now, if it doesn't, customers get very unhappy. Especially in the
 > >> case of something like UO, which like a MOO/MUSH, saves full world
 > >> state for *everything* in the game. That comes out at (last I
 > >> recall) 17 million objects per server, or in real time terms, a 3
 > >> hour boot time to read it off of disk. :)
 > 
 > > 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?

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.

To this approach, DGD adds a memory cache to which data is swapped
out before it goes to disk. I have not experimented much with this
cache, but I may do so in the future when I have to weigh the time
of swapping objects in and out against the time it takes to create
a full state dump. I imagine that having a large in-memory cache
of data in its swapped-out state is a boon when the time comes to
write the synchronized dump to disk... while swapping to memory
instead of to disk is a run-time speed boon.

Right now, on our rather puny run-time machine, the bi-hourly dump
takes about 20 seconds, swapping consumes practically no resources,
and a restart takes maybe two minutes.


So...

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?


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.

Zell





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