<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 16. 01. 2014 14:29, Dmitri Pal
      wrote:<br>
    </div>
    <blockquote cite="mid:52D7DECD.8060001@redhat.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      On 01/16/2014 05:29 AM, Mitja Mihelič wrote:
      <blockquote cite="mid:52D7B4A1.6070606@arnes.si" type="cite">Hi! <br>
        <br>
        We are running a CentOS6 server using SSSD that connects to
        389DS containing 70k user entries. Both servers are fully
        updated. <br>
        SSSD and 389DS package versions: <br>
        sssd-1.9.2-129.el6_5.4.x86_64 <br>
        389-ds-base-1.2.11.15-31.el6_5.x86_64 <br>
        <br>
        Authoconfig was used to enable sssd. <br>
         authconfig --enablesssd --enablesssdauth
        --ldapbasedn=dc=users,dc=company,dc=tld --enableshadow
        --enablemkhomedir --enablelocauthorize --update <br>
        PAM an NSS configs were updated as well. <br>
        I have attached our sssd.conf. <br>
        <br>
        The setup itself works allowing users to authenticate, but we
        are concerned about the performance. <br>
        At first we tried with enumeration enabled, but there was a
        significant responsiveness drop during enumeration. A simple
        getent -s sss passwd USERNAME took more than 15 seconds. Result
        paging did not help. <br>
        <br>
        Next we turned enumeration off and deleted the cache for a clean
        start. We tried simple getent requests with 1000 random
        usernames taken from a file. We ran the bash script
        consecutively a few times. The results: <br>
        - run 1: 0m10.831s <br>
        - run 2: 0m20.914s <br>
        - run 3: 0m31.422s <br>
        and so on. Each run took about 10 seconds more than the previous
        one. <br>
        During the test sssd_be was using 100% of one core. During this
        time 389DS was practically idling. Its load (CPU, I/O) hardly
        showed any change. <br>
        <br>
        What could be the reason for this performace issue? <br>
        How would we best go about tuning this system? <br>
        <br>
        Regards, Mitja <br>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
sssd-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:sssd-users@lists.fedorahosted.org">sssd-users@lists.fedorahosted.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.fedorahosted.org/mailman/listinfo/sssd-users">https://lists.fedorahosted.org/mailman/listinfo/sssd-users</a>
</pre>
      </blockquote>
      <br>
      Can it be due to group membership refresh?<br>
      Do you have a group that all 70K users are in?<br>
    </blockquote>
    All users except 27 out of 70k are members of the same group. The
    group is defined locally in /etc/group.<br>
    In /etc/nsswitch.conf we have group: files<br>
    <br>
    Regards, Mitja<br>
  </body>
</html>