[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: zmailer getpw* routines

> Guy Middleton:
> > Is it really "handled elsewhere"?
> No.  The worst case behavior is always triggered by
> 	$(homedirectory "$user")
> This always does a linear search, which is especially awful if you're
> using YP.  This is the single slowest part of routing a local user.

  Linear ?
Try   ypmatch  $USER passwd.byname

On Suns (SunOS 4.1+) this is implemented by opening NDBM (or alike) file
/var/yp/<domain>.2, and then going from there.  Quite non-linear in my

Using library call getpwnam() does the same...  (On Suns very least)
There doing  setpwent()  can have very positive effect too :)

Of course the YP database must be synced to actual user data..

> The real problem is interaction between the router's memory-allocation
> pattern and some implementations of malloc.  Calling getpwnam() is
> going to call fopen/fclose, which is going to malloc/free an 8k
> buffer.  The 8k chunk is later split to satisfy some other malloc
> request, which means the next time you call getpwnam() you need
> *another* 8k buffer.  Your data segment slowly grows without bound,
> until you're out of vm.

  Yes, this behaviour happens with standard library which parses

> You can avoid this problem by using a malloc that never splits chunks,
> like the BSD/Caltech malloc.

  Very true, and can help elsewere as well.

	/Matti Aarnio <mea@utu.fi>