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@redhat.com<mailto:mareynol@redhat.com>>
Reply-To: "mreynolds@redhat.com<mailto:mreynolds@redhat.com>"
<mreynolds@redhat.com<mailto:mreynolds@redhat.com>>
Date: Monday, December 8, 2014 at 11:29 AM
To:
"389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>"
<389-users@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>>,
Trevor Fong <trevor.fong@ubc.ca<mailto:trevor.fong@ubc.ca>>
Subject: Re: [389-users] 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@lists.fedoraproject.org<mailto:389-users@lists.fedoraproject.org>https://admin.fedoraproject.org/mailman/listinfo/389-users