Subject: Re: dream hardware/minimal hardware (fwd)

From: Clay Luther <[email-masked]>
Date: Tue, 18 Aug 1992 07:26:29 -0700

Pavel says:

> 
> The dream machine has infinite CPU speed and infinite disk space.  The minimum
> for a moderately-large place with good backups is about 100 megabytes of disk
> and about 32 megabytes of physical memory; the CPU speed will likely be fine no
> matter what DEC machine you get.
> 

I'd have to disagree here on the ram reqs.  The GN is on a machine with 32mb
of physical memory and 57mb of swap.  After 3 months of being open to the
public, the GN's average memory consumption was about 30mbs, doubling 
during server dumps.

Because the machine is not a "mud-only" machine, this caused a lot of
thrashing as other processes vied for ram.  The result was that everything on
morticia slowed down enormously -- during server dumps, the only word to
describe the slowness would be painful.

However, during our long building phase (not open to the public), the moo 
was extremely well-behaved and unobtrusive.  I look forward to the disk-based
scheme soon to be released, as the GN is on haitus until we get that
functionality.

-- 
Clay Luther
[email-masked]

---

From: [email-masked] (Jay A. Carlson)
Date: Tue, 18 Aug 1992 09:30:39 -0700

> public, the GN's average memory consumption was about 30mbs, doubling 

I don't mean to reveal my ignorance, but should the fork for the dump
use all this memory on modern systems?  Seems to me that most of the
pages would be shared between the two processes.

---Jonny

---

From: Pavel Curtis <[email-masked]>
Date: Tue, 18 Aug 1992 11:41:51 -0700

> Date:	Tue, 18 Aug 1992 09:30:39 -0700
> From:	[email-masked] (Jay A. Carlson)
> 

Yes, well, you'd like that, but Sun Microsystems (apparently among others) in
its infinite wisdom decided not to implement copy-on-write virtual memory
sharing.  Thus, in order to do the fork, the system does indeed copy the entire
image of the forking process and thus doubles the swap space and physical
memory demand.

Sigh.

	Pavel

---

From: Mike O'Brien <[email-masked]>
Date: Thu, 20 Aug 1992 12:57:17 -0700

>image of the forking process and thus doubles the swap space and physical

Yah, as an ex-member of the DARPA Steering Committee that oversaw the development
of Berkeley UNIX, I can tell you we've only been waiting ten years for this
to go in.  It was originally a bug in the VAX 750 microcode that prevented this
from happening; not exactly a relevant excuse now.

However...

My impression was that the only reason you fork to write the database is to
ensure a consistent database while not locking out interactions.  With the
amount of page-thrashing caused by the fork of a large MOO, might it not be
a better idea to lock out the interactions, and update the database without
forking?  Overall response time MIGHT be improved by this!

Mike O'Brien

---

From: Pavel Curtis <[email-masked]>
Date: Thu, 20 Aug 1992 13:38:20 -0700

> Date:	Thu, 20 Aug 1992 12:57:17 -0700
> From:	Mike O'Brien <[email-masked]>

> forking?  Overall response time MIGHT be improved by this!

I think that it would be worse than the current situation for the MOO to be
*completely* unresponsive during the time it was checkpointing.  In any case,
the point will soon be moot, as of the end-of-September release that uses a
fully disk-based DB.

	Pavel