Date: Mon, 18 Aug 2014 09:52:41 +0200 From: Stefan Esser <se@freebsd.org> To: Adam McDougall <mcdouga9@egr.msu.edu>, freebsd-current@freebsd.org Subject: Re: nscd not caching Message-ID: <53F1B0C9.8040303@freebsd.org> In-Reply-To: <53F0D3F3.4030804@egr.msu.edu> References: <FA0C5D1E-780A-4B01-8513-5A4B77DA051D@netapp.com> <D86D34C6-B5E8-4141-BD9F-FF88B056DF6B@netapp.com> <53F0D3F3.4030804@egr.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 17.08.2014 um 18:10 schrieb Adam McDougall: > On 08/17/2014 09:09, Eggert, Lars wrote: >> Nobody using nscd? Really? > > I would test for you, but we retired our NIS infrastructure at least a > year ago. I did have it working on a test client at some point, but I > didn't push it into production because I found a couple issues (below). [...] > The two main problems I recall were nscd making java crash, and nscd > holding on to negative cache lookups too long, causing failures while > installing ports that depend on adding users/groups for a following file > permission change. I can't remember if the latter issue was fixed at > some point. I also can't remember if I was receiving perfectly accurate > results from the cache either. I added the "negative-confidence-threshold" option to nscd, a few years ago. If set to a number > 1 (the default), then that number of failures are required to cause a negative cache entry. Setting this value to 3 should allow for 2 probes for the presence of a UID or username, before the cache returns a failure without bothering to re-check the source. The value should be low enough to prevent flooding of a remote source with requests, if an entry really does not exist. The default was left unchanged - you need to increase the value to see any effect of this threshold. 3 might be a reasonable default for the user database. But I never bothered to suggest and discuss an increased default value on the mail-lists ... [...] > I dabbled with nscd a bit after we switched from NIS to LDAP. I think I > recall lookups being slightly slower WITH the cache, plus I would get > some duplicated group entries returned on all but the first getent > group. The short version is we in no way seem to benefit or require a > cache of LDAP with our site size, so I'm just not using nscd. I didn't > make bug reports for these issues, I had to prioritize towards more > pressing issues. I'm trying to do better about reporting bugs. I also found that there were glitches, when I tested the extension to cache only the nth negative reply. The code is not easy to read and change (IMHO), and I did not succeed when I tried to reproduce and debug these glitches. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53F1B0C9.8040303>