Date: Tue, 8 Apr 2003 13:52:52 -0400 From: Dan Pelleg <daniel+bsd@pelleg.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: current@freebsd.org Subject: Re: NIS exhausts system resources Message-ID: <16019.3188.797715.762884@gs166.sp.cs.cmu.edu> In-Reply-To: <3E930195.4E25DDCE@mindspring.com> References: <u2sznn19jvw.fsf@gs166.sp.cs.cmu.edu> <3E92E509.A7A43986@mindspring.com> <16018.64453.390850.48895@gs166.sp.cs.cmu.edu> <3E930195.4E25DDCE@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes: > Dan Pelleg wrote: > > I'm not sure I understand this. First, if the server is down when the > > client boots, this will stop the client's boot sequence (or at least slow > > it significantly down). > > Not really. All it will do is cause requests for information > normally contained in NIS to fail, following some delay (for > example, for gethostbyaddr(), if the hosts file is NIS > distributed, it will cause a 3 minute delay on reverse address > resolution, before failing back to returning the IP address). > > For getpwnam(), the lookup will simply fail completely, after > the NIS server is judged to no be responding, which will only > occur after a connection attempt fails after a certain amount > of time. > This sounds plausible, thanks. However, In the past, when configuring NIS for the first time, I did see the machine go unresponsive on me as soon as I did a "domainname foo". This was probably at a time when the server wasn't set up correctly. But why would that immediately cause high resource usage? There shouldn't be any name or user lookups taking place. This is a very quiet machine - I don't think it was running more than very lightly loaded postfix and sshd at the time, and I was the only user logging in. Name lookups, by the way, should not go out anyway - the machine is running its own named. > > > sshd isn't given a chance to start. > > I mistakenly understood your original posting to say that it > "was the sshd problem reported here several times"; missed the > "NOT"; sorry. > > > The only sign of life from the machine at this point is ICMP replies > > and the sound of the grinding disk (probably syslogd). > > You also said there was another "sign of life": > > | kernel: file: table is full > | syslogd: /dev/console: Too many open files in system > | rpcbind: rpc: failed to open /etc/netconfig > | rpcbind: warning: /etc/hosts.allow, line 23: cannot open /etc/hosts.allow: > | Too many open files in system > These are lines I extracted from the log files after the machine went back up (I turned on the NIS server and rebooted the client). Sorry if this wasn't clear. > The "file: table is full" and the "Too many open files in system" > can be fixed by the method I describe: recompile your kernel with > a larger MAXUSERS. > > As far as the "too many open files", there are two possible > causes. The first is that so many things are piled up waiting > for NIS, that there are *really* "too many open files". Rasing > the MAXUSERS raises the definition of "too many". Raise it high > enough, and the problem will "go away" (e.g. if "too many" is "10", > you will have problems when you try to open 50 files, but if "too > many" is "100", you won't have that problem). > > > The second cause is probably that the "/etc/hosts.allow" file is > opened, the file read, the NIS checked, and then the file is > closed. If you changed the order of operation so that the file > was not held open while NIS was being checked, then you would not > have the problem, e.g.: > > Fails OK > Open A Open A > Read A Read A > Open B Close A > <wait a long time> Open B > Close B <wait a long time> > Close A Close B > > <2 files held open> <1 file held open> > > ... in other words, if you divide the number of open files by 2, > then maybe if (2*X > "too many"), just (X < "too many"). > > Make sense? > Yes, it does. > > > Next, this is a wimpy machine. 233Mhz processor and 64MB of RAM. I don't > > know if that matters or not, but I'm not confident of my ability to tweak > > the memory usage on it. > > cd /usr/src/sys/i386/conf > cp GENERIC MYKERNEL > vi MYKERNEL # Increase MAXUSERS by 2-3 times > config MYKERNEL > cd ../compile/MYKERNEL > make depend > make > make install > I was going to say "I have my MAXUSERS set to 0, which is still 0 after multipying by 3". But checking the config file it turns out that it doesn't have MAXUSERS defined at all. And neither does GENERIC (from a copy of which I probably started my own config file) nor NOTES. What is the equivalent of MAXUSERS on -CURRENT?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16019.3188.797715.762884>