[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
opinnion...
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
/etc/passwd..
> 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>