[DGD] Hope someone can help

[Par Winzell]

Matt,

 > We are running our system on a Mac. We don't use the Kernel Lib at all.
 > We've built from scratch. We are building a fantasy based Mud (no yawns
 > please *grin*).

*cheer*


 > The way we understand it is that as more and more objects are loaded more
 > and more memory is taken up. So for example as more rooms are explored they
 > are stored in memory. I'm assuming after a while this will be too much for
 > the comp. And the mud will crash? I've seen the swap out function but not
 > really sure how to use it and how it works.

There are two main limits here -- the data in your configuration file,
which can be changed, and the limits of your hardware, which can only
easily be stretched so far. Luckily, any modern PC can run a gigantic
Mud, if the mudlib does things reasonably well.

DGD considers the natural state of a loaded object to be 'swapped out',
which means the bulk of it is not in memory, but rather stored in the
DGD swap file (the location of which you indicate in the config file).

When a swapped-out object is needed, it's swapped in. If left untouched
for long enough, it'll eventually get swapped back out. DGD attempts to
keep the most-used objects in memory.

Whenever something happens in the Mud, and DGD finishes doing the work
associated with that something, it takes a little extra time to swap a
couple of objects out. Specifically, it looks at the 'swap fragment'
integer in your configuration file. Somewhat simplified, if there are
10,000 objects currently NOT swapped out, and your swap fragment is 10,
DGD will swap out 1,000 of those objects. That's way too many -- it'd
completely saturate your disk I/O -- so if your Mud is so large that
you have 10,000 objects swapped in, your swap fragment should not be
something like 10. A large game will have a fragment of 2048 or so --
though the sensible value depends on many other factors as well.

Typically, you set the fragment as low as you can without satuerating
your disk I/O. This is a bit of an arcane art, but if you experiment
with cutting the fragment in half and the game feels like you poured
syrup into it, you know it's too low.

The advange of a LOW fragment is that the set of swapped-in objects
is as small as possible, which means A) they take up less memory in
your machine, and B) state dumps are much quicker. B) is vital in a
persistent game, since dumping state freezes the game and you'll want
to do it every hour or so if possible, lest somebody kick the machine
the wrong way and your players lose too much stuff.

The advantage of a HIGH fragment is that not much swapping happens,
so your disk I/O is not saturated. Having 5 objects swap out every
second is not a big deal. Having 50 objects do so is a big deal.

Swapping is automatic. You don't need to mess with swap_out() yet.


 > We want our mud to be persistent (run as long as possible without reboots
 > etc.) so that people could plant a seed and in a while it would grow into a
 > tree etc.

This is dumpfile/statedump territory. Basically, since DGD tries to
keep almost all its objects swapped out anyway, it is less of a chore
to swap the last bunch of objects out, add some extra data, and call
the swapfile a dumpfile. That's what the dump_state() function does.

It'll essentially freeze everything while it swaps out whatever is not
already swapped out, copies the swap file to another file called the
dumpfile (the location of which is indicated in the configuration file)
and then starts slowly building up the swapfile from scratch again.

The dumpfile can then be used to restart DGD from precisely where it
left off (excepting TCP/IP connections and open ports), which is how
you get persistence.


 > Could someone explain about memory and swap outs and what we need to do?

You should not really need to worry about this. A modern PC with 256
MB of RAM and IDE/66 or IDE/100 has so much memory and disk I/O that
unless you're talking 50,000 rooms, you don't have all that much to
worry about. Once you start pushing those limits things start to get
more complex -- adding RAM vs state dump times, perhaps using RAID to
maximize I/O throughput, blah blah.


 > Same sort of thing with r-limits ... Don't know what they are and how to use
 > them and couldn¹t find anything simple enough for my mind ;)

They're used when you want to be able to trust some code less than
other code. The most hard-core layers of your library will probably
run without using rlimits, which means they never run out of ticks
or stack. This means that a badly written loop can permently freeze
your process, and a bad recursion can crash it.

If you want to be able to relax a bit when you write less hardcore
systems, like pretty much all your actual game code, you make sure
all such code executes with reduced tick/stack quota.

If you have an LPMud style setup where you invent people to come
and code on your Mud, you -definitely- want to make sure they do
not accidentally (or maliciously) crash your game with their code.

To make sure all mudlib code runs with reduced tick/stack quotas,
you have to implement callout gateways in an auto object, as well
as take full control over user objects created by incoming telnet
connections etc etc. This is one of the services that the kernel
library supplies, and which you will spend an inordinate amount of
time trying to reimplement. :-)

To be honest, since you have full control of all the code, you can
probably just stick a bunch of rlimits in the right places and do
something about callouts.

 > We're also wondering how to 'save' our mud so that if a crash occurs we
 > don't lose too much time. Any help on that?

That's persistence. Call dump_state() regularly.


 > In fact if someone were to take a look at our code, maybe they could advise
 > us on improvements or whether it just won't work.

I suggest the only way you can make a large persistent fantasy
Mud is to hook up with a developer who is willing to really dig
into these complex issues -- especially if you're not doing it
with the kernel library.

Zell
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd