Subject: Re: Making file-based getXent quicker
To: Brian Ginsbach <ginsbach@NetBSD.org>
From: Thor Lancelot Simon <tls@rek.tjls.com>
List: tech-userlevel
Date: 03/20/2006 11:57:28
On Mon, Mar 20, 2006 at 09:12:50AM -0600, Brian Ginsbach wrote:
> On Mon, Mar 20, 2006 at 07:59:22AM +0000, Darren Reed wrote:
> > On Mon, Mar 20, 2006 at 10:42:35AM +1100, Luke Mewburn wrote:
> > > On Sun, Mar 19, 2006 at 08:41:14PM +0000, Darren Reed wrote:
> > >   | 
> > >   | In a discussion about how NetBSD opens and closes nls files way too
> > >   | often, it was brought up that there are similar problems with the
> > >   | name-number files like /etc/services and /etc/protocols.
> > >   | 
> > >   | So the problem is, what to do about it?  How can they be made quicker?
> > > 
> > > Have you profiled that these are a problem?
> > 
> > No, this is word of mouth from someone else.
> 
> I still fail to see what the big problem is even if many of these
> perform sub-optimally.  They really should be relatively low use.
> Why invent a very complicated system when it isn't really necessary?
> 
> Yes, it maybe cool to mmap files and all that but there are probably
> many unforeseen consequences.  Seems like effort could be better
> spent elsewhere.  I think it took SGI a while to get UNS, nsd(1M),
> right.  There may still be problems with it as I don't really follow
> IRIX that closely any longer.

There sure are still problems with it.  As of three years ago -- a *long*
time after SGI first made nsd mandatory -- I still found it necessary
to kill and restart nsd on my Irix fileserver three or four times a year,
to resolve issues either of complete failure to respond to requests, or
extreme and inexplicable response latency.

The experience made me very, very skeptical of the idea of making all
requests to any critical system database rely upon any such daemon
process.

One other thing I'm highly curious about here is why we should think
that most requests from these databases don't hit in every relevant cache
along the way to being resolved.  Is there really much performance benefit
to looking an entry up in shared memory when compared to retrieving it from
the filesystem cache, with the filename lookup handled by the name cache?

It seems intuitively obvious to me that a daemon like nsd is likely to
be _worse_ than either the "just let it hit the cache" or the "use shared
memory" solutions.

Thor