[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-users] Large slow down when using IPA

On Sat, 2011-12-31 at 01:35 -0900, Erinn Looney-Triggs wrote:
> On 12/30/2011 07:19 PM, JR Aquino wrote:
> > 
> > On Dec 30, 2011, at 5:45 PM, Erinn Looney-Triggs wrote:
> > 
> >> I have been slowly rolling out FreeIPA to my systems, trying to track
> >> differences/changes. One of the most noticeable has been a large slow
> >> down in file access times.
> >>
> >> Let me explain as best as I can. I use AIDE to track the file system
> >> (think tripwire) and it runs checks once a day. During these checks it
> >> is scanning (almost) the entire file system and comparing it to a stored
> >> database. On a moderately powered system with ~151k files, an AIDE run
> >> will usually take ~30 minutes. After the system becomes an IPA client
> >> the same run will generally take ~90-120 minutes. Un-install the
> >> ipa-client, back to ~30 minutes for an AIDE run.
> >>
> >> Now clearly a lot of lookups are being done for user names and group
> >> names, and this will have a performance hit that is dependant on the
> >> network. However, the odd thing is that even when running on the IPA
> >> server itself the slowdown is still the same.
> >>
> >> Not sure if this is an IPA problem, an SSSD problem, a bit of both, or
> >> neither, perhaps it is just the way it is, but a slowdown of 3-4x seems
> >> a bit much to me. Clearly the results are not scientific, however, they
> >> have been generally reproducible since I started rolling IPA out.
> >>
> >> As a side note this slowdown has also broken bacula backups, as the
> >> bacula client is scanning the filesystem for change (using accurate
> >> backups) the director times out.
> >>
> >> Any thoughts, or opinions? Workarounds etc? I have checked to make sure
> >> that SSSD caching is enabled, and functional.
> >>
> >> Thanks,
> >>
> >> -Erinn
> > 
> > I am assuming that these are all running as local users.
> > 
> > From the sssd.conf man page in the nss section:
> > 
> > filter_users, filter_groups (string)
> >            Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the
> >            particular domain.
> > 
> >            Default: root
> > 
> > 
> > Try adding this to your sssd.conf:
> > 
> > [nss]
> >            filter_groups = root,bacula,aide,otherdaemonuser <-as needed
> >            filter_users = root,bacula,aide,otherdaemonuser <- as needed
> > 
> > Let me know if that solves your issue.
> > 
> Thanks for pointing that out, completely missed that option! Wouldn't it
> be sweet to have an option that say looked at /etc/login.defs and just
> didn't lookup anything under MIN_UID, on the assumption that those are
> system accounts? Certainly would stop a lot of lookups I imagine.

We already have range options (min_id/max_id), but unfortunately that
doesn't help when an application asks for information by name.
You either permanently blacklist such name or you have to do the lookup
and then find out it either a) does not exist, or b) it has to be
filtered out.

> Of course you would have to leave it as an option and probably default
> it to off given the odd things people do with their systems.

Indeed sssd used to enforce a min id range of 1000 and we turned it off
in the default configuration due to issues with weird configurations.

Can you try using both min_id and filter_users and see if it makes any
difference in your case ?


Simo Sorce * Red Hat, Inc * New York

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]