Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!CAEN.ENGIN.UMICH.EDU!pha
From: pha@CAEN.ENGIN.UMICH.EDU (Paul H. Anderson)
Newsgroups: comp.sys.apollo
Subject: Re:  How can I get rid of Apollo IOT traps?
Message-ID: <4a452733b.000f088@caen.engin.umich.edu>
Date: 8 May 90 14:19:09 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 42


	 
	I am wondering if the registries cannot handle 30-50 changes per day over this
	length of time. Any other ideas?

We ran into several bugs of this nature - if the registry is up for long periods
of time, it starts having problems.  The fix for us consisted of two parts - a
fix to rgyd that eliminated a malloc/free problem where memory was allocated, but
never freed (hence you get large VM space used after large #'s of changes).  The
other part of the fix was a change in some inefficient hash structures that didn't
work at all well for UM.  The problem is we have 7000 accounts, but all in one
organization, and the registry was originally designed to assume maybe a few hundred
accounts per organization (%.%.org).

The first fix appears to have eliminated all IOT deaths of the registry, and the
second patch sped account updates up by a factor of several hundred.  The big speedup
comes when adding hundreds of accounts in a row - the old hash structure algorithm
broke down, making each new addition increasingly expensive.  By the time something
like 50 accounts had been added to our registry, each new account was taking an
hour or more.

These two problems still exist, even in the early beta SR10.3 that we have.
	 
	How do we get rid of this problem when it shows up? So far, the only way we have
	found to get rid of the problem is to completely rebuild the registries.

This sounds a little extreme - you should not have to go to this length to get
a working registry.  You might want to check that you are not running mixed SR10.1
and SR10.2 registry daemons, since they are incompatible.  Other things to try
are to use only one registry daemon for awhile, since the propogation algorithms
sometimes have problems in a flakey network.

	-- 
	Dave Williams                       |  My opinions are not necessarily those
	EDS Technical Systems Development   |  of my employer.
	williams@eds.com                    |
	UUCP: {uunet|sun|sharkey}!edsews!williams
	

Paul Anderson
CAEN Systems Programmer
University of Michigan