51857 - Gargamel is slow and orange

Status: VERIFIED WONTFIX

(SeaMonkey :: Build Config, defect, P3)

Description

[jim_nance]

Gargamel takes 12 hours to build :-(  Do you know if its
swapping itself to death or is the problem elsewhere?
File system creation/deletion is slow on Tru64 4.X because
its synchronous.  If thats the problem upgrading to 5.0 will
improve things.  If its just lack of memory, you just have
to cope (or find more).

Its orange because it fails autoregistration.  This is because
there is a limit on the maximum number of shared libs Tru64
can load, and its less than the 200 that mozilla needs for
autoreg.  You can get around this problem by running mozilla
2 or 3 times, and it will eventually get all the libs registered.
Here is an explanation from the bottom of the dlopen man page:

  The maximum number of shared libraries that can be loaded simultaneously by
  a single process is approximately 60.  This limit can be raised by reconfi-
  guring the kernel's vm-mapentries parameter.  This parameter should be set
  to at least three times the desired maximum number of shared libraries that
  can be loaded by a process.  See the manual System Administration for
  instructions on reconfiguring the vm-mapentries parameter.

You can reconfigure this by editing the file /etc/sysconfigtab
and adding or modifying it such that it contains a section
that looks like this:

   vm:
               vm-mapentries = 1000

and then rebooting the machine.  There is also a dxkerneltuner
program which will let you do this graphically, but its easier
to do it with vi.  I have attached a sysconfigtab file from
a machine I use at compaq which has a similar modification at
the bottom.  It sets the limit to 1000000 which is a lot more
than we need, but I am only including it for the syntax.

Comment 1

[jim_nance]

Attachment: example of modified /etc/sysconfigtab file

Comment 2

[cls]

Ok, I added the vm-mapentries to /etc/sysconfigtab and rebooted. 

Wrt memory, how much is enough?  Gargamel has 256 megs.  The output from vmstat
shows that 254 of 256 megs physical are in use right after reboot but that may
be normal.  Supposedly, 24826 of the 32768 pages are free so maybe mem isn't the
problem.

Granrose, is there any chance of us being able to upgrade to 5.0 ?

Comment 3

[Jon Granrose]

There's always a chance, but it's not a very big one right now.  This is DecOSF,
right?  We have a DEC contact around here somewhere that we might be able to get
the OS and tools and licenses, but I wouldn't have the time to work on it for
quite a while as we currently have 3 tier 1 systems still waiting to be
configured, not to mention branch/trunk builds, tb, etc.

Comment 4

[cls]

Setting milestones to Future.

Comment 5

[cls]

We need a new resolution: CANTFIX.  I think somewhere along the line gargamel
lost its build drive ontop of everything else.

Comment 6

[Jon Granrose]

on top of it all, we may be giving this system the boot in the near future.

verified wontfix.