Re: 389-ds and Multi CPU's

Mark Reynolds <mareynol@xxxxxxxxxx> · Tue, 09 Dec 2014 10:25:30 -0500



    On 12/08/2014 05:43 PM, Fong, Trevor
      wrote:

    
      Hi Mike,
    
    It's Mark :-)  I get that a lot for some reason.

    
      Thanks for the reply.  The typical result of the result is:
      

        [08/Dec/2014:07:08:04 -0800] conn=130262 op=1 RESULT err=0
          tag=101 nentries=5 etime=0
      
    
    Yeah this looks fine.

    
        There are no notes=A/notes=U in the results.
      
    
    Do you mean in the entire access log, or just for that search?

    
    Can you run logconv.pl and post the results?   "logconv.pl -V
    <access logs>"

    
    Thanks Trevor,

    Mark

    
        Objectclass and member are both indexed.
        There were 30,000-odd searches on conn=130262, which took
          34 mins.
        

        Thanks,
        Trev
         
        
          From: Mark Reynolds
          <mareynol@xxxxxxxxxx>

          Reply-To: "mreynolds@xxxxxxxxxx"
          <mreynolds@xxxxxxxxxx>

          Date: Monday, December
          8, 2014 at 11:29 AM

          To: "389-users@xxxxxxxxxxxxxxxxxxxxxxx"
          <389-users@xxxxxxxxxxxxxxxxxxxxxxx>,
          Trevor Fong <trevor.fong@xxxxxx>

          Subject: Re:
           389-ds and Multi CPU's

        
            On 12/08/2014 02:08 PM, Fong,
              Trevor wrote:

            
              Hi Everyone,
              

              We’ve inherited a 389-ds system (1.2.11.15-48.el6_6)
                that is running on a VM provisioned with a single CPU.
                 We have been experiencing high CPU with a client that
                connects with a single connection, and then runs large
                amounts of queries of the form:
              

              SRCH base="ou=GROUPS,dc=<our dc>" scope=2
                filter="(&(objectClass=groupOfNames)(member=uid=<loginname>,ou=EMPLOYEES,<our
                dc>))" attrs=“1.1"
            
            Trevor,

            
            From the access log, what is the result of this search? 
            etime?  It there a notes=U/notes=A in the result?  It could
            be an unindexed search which would cause the high CPU. 
            

            Thanks,

            Mark

            
              We’re wondering if adding extra CPU’s to the vm will
                make things better.  The original engineer noted that at
                the time of implementation, he had come across some
                notes that indicated that the underlying process was
                single threaded and adding extra CPU’s would not make
                any improvement; in fact, on heavily loaded vm
                infrastructure like ours, may make things worse as the
                the vm would have to wait for the CPU to become
                available.  Is this still true?
              

              Thanks a lot,
              Trev
              

              --
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxxhttps://admin.fedoraproject.org/mailman/listinfo/389-users
            
            
      --
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
    
    
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users