Re: 389-ds and Multi CPU's

["Fong, Trevor" <trevor.fong@xxxxxx>]

Hi Mike,

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

There are no notes=A/notes=U in the results.

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