nscd, nslcd, and sssd all provide the same functionality, so you should
never have more than one of them running at once. RHEL5 used nscd. RHEL
6 eliminate nscd and replaced it with sssd, but included nslcd. I'm no
expert on nslcd (because I switched to sssd as soon as RHEL 6 came
out), but it appears to be the same or very similar to nscd, but only
for LDAP.
Prentice
On 10/26/2018 10:13 PM, John Hearns via Beowulf wrote:
Skylar, I believe that nscd does not work well with sssd and I
disabled it.
See
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/usingnscd-sssd
I believe that nscd is the work of Auld Nick himself and causes more
problems than it is worth on HPC nodes.
If you want to speed up cacheing with sssd itself you can put its
local caches on a RAMdisk. This has the cost of no persistence of
course and uses up RAM which you may prefer to put to better use.
On Sat, 27 Oct 2018 at 00:59, Skylar Thompson
<skylar.thomp...@gmail.com <mailto:skylar.thomp...@gmail.com>> wrote:
On Fri, Oct 26, 2018 at 08:44:28PM +0000, Ryan Novosielski wrote:
> Our LDAP is very small, compared to the sorts of things some
people run.
>
> We added indexes today on uid, uidNumber, and gidNumber and the
problem went away. Didn’t try it earlier as it had virtually no
impact on our testing system for whatever reason, but on a
different testing system and on production, it dropped “ls -al
/home/“ from ~90s to ~5s. I’m not sure if all three were
necessary, but I’ll look back at that later.
>
> We’ve run SSSD from day one, so that eliminates the nscld
question. We also moved CentOS 5.x to SSSD, FYI (I believe there
was someone else with some old systems around). Was pretty
painless, and SSSD eliminates a lot of problems that exist with
the older stuff (including some really boneheaded very large LDAP
queries that were happening routinely with the older nss-ldap
software if I’m remembering its name correctly).
Have you experimented with client-side caching services like nscd?
nscd has
its quirks (in particular, it does very poorly with caching
spurious negative
results from transient network failures), but it also is a big
performance
improvement since you don't even have to hit the network or the
directory
services.
--
Skylar
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
<mailto:Beowulf@beowulf.org> sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
