<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 07/05/2012 10:41 PM, Mark London wrote:
    <blockquote cite="mid:4FF65045.90805@psfc.mit.edu" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <title></title>
      <tt><tt><a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
            href="mailto:sgallagh@redhat.com">sgallagh@redhat.com</a></tt></tt>
      wrote:<br>
      <blockquote
        cite="midmailman.23.1341403205.799.sssd-devel@lists.fedorahosted.org"
        type="cite">
        <blockquote type="cite">
          <pre wrap=""><tt>Here is my solution to have a persistant uptodate local cache of all ldap entries, so as to avoid very long delays when a user issues a command that causes a large number of LDAP lookups, i.e. by doing a "ls -l /home":

 enumerate = true
 enum_cache_timeout = 86400 (every 24 hours)
 ldap_purge_cache_timeout = 0
 ldap_enumeration_refresh_timeout = 300

What I would like to know, is why long delays occur when doing an "ls -l /home".  Is it because it has to write out each entry into the local database?    </tt></pre>
        </blockquote>
        <pre wrap=""><!----><tt>How many users are we talking about, and are they all represented in /home?

The initial enumeration can take up to a few minutes the first time (after that we only update on differences). Once the full enumeration has been completed, it should take about 0.02 seconds per lookup against the local cache. On ordinary lookups, there are no writes going on. Writes to the cache only occur on cache misses.
</tt></pre>
      </blockquote>
      <br>
      "ls -l /home" is fast after enumeration.  But if I allow the
      enum cache to time out, then "ls -l /home" take minutes.  We
      have 430 directories.  I get around this problem, by setting the
      cache
      timeout to be very long.  However, it appears
      that using this configuration, both sssd_nss and sssd_be are
      constantly
      growing in size.  I.e., here are the memory size
      after about 3 days of use.  The resident memory has grown from
      about
      21m to over 200m.  The ldap
      refresh (every 5 minutes), appears to be constantly adding to the
      cache.  Or maybe there is a problem with my configuration that is
      causing
      this?  <br>
      <tt><br>
        10468 root      20   0  402m 236m  14m S  0.7  1.5   2:50.74
        sssd_nss           <br>
        10467 root      20   0  424m 222m 8164 S  0.0  1.4  10:20.20
        sssd_be<br>
        <br>
        Thanks. - Mark<br>
        <br>
      </tt></blockquote>
    <br>
    Mark, is there any way we can have a full description of the use
    case. Something is not right here so we would need to try to
    reproduce the issue. But we need a good overview of what is going on
    in your case and how things are configured. I know you provided big
    pieces of this information across multiple emails. Can you please
    consolidate it into one report and open a trac ticket or BZ?  <br>
    <br>
    <blockquote cite="mid:4FF65045.90805@psfc.mit.edu" type="cite"><tt>
      </tt>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
sssd-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a>
<a class="moz-txt-link-freetext" href="https://fedorahosted.org/mailman/listinfo/sssd-devel">https://fedorahosted.org/mailman/listinfo/sssd-devel</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
<a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a>


</pre>
  </body>
</html>