Subject: MOO on a Sun4

From: [email-masked]
Date: Mon, 7 Jun 1993 10:55:40 -0700

MagicDragon: what is the error in the log file when your MOO
crashes.

We are also having trouble with MOO on a Sun4.  I don't know if this is a
system management problem (I'm rotten at it) or a MOO problem; probably the
former.  We get "memory allocation" failed all the time, even though by my
calculations we should have plenty of memory available: I believe 36 Mb RAM
plus 100 Mb swap space.  The MOO process takes up about 17Mb memory (twice
that when it forks.)

> pstat -s
28984k allocated + 3824k reserved = 32808k used, 66568k available

> ps -aux
USER       PID %CPU %MEM   SZ  RSS TT STAT START  TIME COMMAND
MediaMOO  3793  7.8 40.81843613980 ?  R    00:26  60:08 ./moo MediaMOO.db MediaM

> top
last pid:  4457;  load averages:  0.60,  0.33,  0.04                   14:00:02
51 processes:  49 sleeping, 2 running
Cpu states: 23.0% user,  0.0% nice, 45.5% system, 31.5% idle
Memory: 32260K available, 32016K in use, 244K free, 1988K locked

  PID USERNAME PRI NICE   SIZE   RES STATE   TIME   WCPU    CPU COMMAND
 4301 lin        1    0  2644K 1496K sleep   0:48 25.03% 25.00% Xsun
 4315 lin        1    0   464K  368K sleep   0:16 15.55% 14.06% twm
 3793 MediaMOO   1    0 18620K 13928K sleep  60:30  0.78%  0.78% moo
 4457 MediaMOO  26    0   512K  804K run     0:00  0.00%  0.00% top

-- Amy

---

From: [email-masked] (Jonathan Bradshaw)
Date: Tue, 8 Jun 1993 12:40:53 -0700

> plus 100 Mb swap space.  The MOO process takes up about 17Mb memory (twice

This is a problem NeXT users have been having since I started back at 1.6.x
on a daily basis I will get an 'IOT trap' with 'malloc() failed' showing
in the log. The panic uses malloc() to expand the compressed code and so that
gives a recursive panic and aborts. Pavel informed me this was a 'NeXT' problem
and not his. I don't know enough to determine the exact cause. I have plenty
of swap available. I know 3 other NeXT Moo's with the same problem and now
it seems this also happens on Sun4. I personal idea is that the huge number of
tiny malloc() free() calls fragments too much but I know little of the internal
memory routines of Unix/Mach. My MOO takes 4-5MB of memory. 

This is not a flame. Pavel has created a wonderful platform but I wish we
would see 1.8.0, a disk based DB etc. soon. The delay on disk basing decides
the future of my MOO. A good question would be are you using the GNU malloc
or the system malloc() when compiling? NeXT must use their own system malloc().