🚀 go-pugleaf

>>>>> On 7 Aug 92 21:00:27 GMT, kiernan@eros.Berkeley.EDU (Mike
kiernan> Kiernan) said: NNTP-Posting-Host: eros.berkeley.edu

kiernan> We are currently experiencing a problem under Ultrix 4.2A in
kiernan> which named processes configured as "slaves" and running on
kiernan> our workstations are growing in size without any bound.  The
kiernan> problem does not occur on our servers.  The size of the named
kiernan> process does not appear to be related to the number of
kiernan> entries that are cached.  Slave named's running on different
kiernan> machines, with approximately the same number of entries in
kiernan> their caches, have different memory sizes, ranging anywhere
kiernan> from 5Mb to 30+Mb.

kiernan> After talking with some people at DEC, I found out there are
kiernan> documented memory leaks in named, but the known causes do not
kiernan> apply in our environment.  Has anybody else had similar
kiernan> problems?  If so, have you been able to track down the cause?

For our standards user login, GID==UID, so that everyone starts out
with a private environment.  As soon as we started running the DEC
named slaves serving hesiod, we found that the named processes would
blow up in size (not on the servers, as you note).  The problem is
that the GIDs are not all in the group database.  The slave must lose
track of the GIDs it is caching if the lookup fails in group.  I guess
we could fix it by installing GID entries in group for the 3,600 login
IDs.

Of course, if there are other memory leaks, then this one may not
match yours, either.