Hi Class,
pstack is a gdb wrapper command to dump backtrace of all threads.
installing gdb you may get it.
I suspect that the culprit could be the evaluation of the filter over
the matching entries (~500 groups owning cn=sampleuser). Using
ldapsearch could you reproduce with '-e manageDSAit' option and check if
there is still a diff between 1.4.4 and 2.0.
Another investigation is to put a breakpoint on slapi_vattr_filter_test.
With such filter it should not be called.
Just for confirmation, you indexed 'uniqueMember' did you indexed in 'eq' ?
best regards
thierry
On 3/10/23 14:47, Claas Vieler wrote:
Hello Thierry,
I can confirm index on 'uniqueMember' for both versions. I also tried
to recreate and reindex 'uniqueMember', same result.
SRCH-records are inconspicuous, except high optime (no notes..)
What exactly do you want to see in pstacks. Do you mean the output
from pstack-tool?
regards
Claas
*Gesendet:* Dienstag, 07. März 2023 um 15:38 Uhr
*Von:* "Thierry Bordaz" <[email protected]>
*An:* [email protected]
*Betreff:* [389-users] Re: 2.x query performance problem
Hi Claas,
I do not recall a specific change 1.4.4 vs 2.0 that could explain this.
Do you confirm that 'uniqueMember' is indexed in equality on both ?
What are the SRCH records in the access logs (notes=A ?).
On 2.0, it lasts 2sec, you may try to capture few pstacks that would
give some tips.
regards
thierry
On 3/7/23 14:54, Claas Vieler wrote:
Hello,
we have a search performance problem when we migrated from
1.4.4.19 to 2.0.17.
Our environment has about 100k entries, about 15k users and about
10k groups. Also big groups with thousand of users, also users
with thousand of group membership. So I would call it a small instance
On 1.4.x query perfomance ist fine:
ldapsearch for
"(uniqueMember=cn=sampleuser,ou=People,dc=example,dc=com) dn " via
LDAPI on 1.4.x takes approx 0,01-0,03 sec.
This user is member of approx. 500 groups.
I tested two migration methods:
1. via replication
After initializing replica, the same query takes about _8_ sec.
So I reindexed db (dsctl .. db2index) and get durations for the
query from 2-3 sec.
2. via ldif export/import
after importing, the same query takes about 2-3 sec
But even with 2-3 sec, we talk about 2.x perfomance ten time
slower than 1.4.x.
Is this a know issue? I compared all cache-settings and found no
differences.
I have no more ideas how to optimize this. Should we wait for 2.x
when its adopted to new lmdb?
thanks
Claas
_______________________________________________
389-users mailing list [email protected]
To unsubscribe send an email [email protected]
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ 389-users mailing list
-- [email protected] To unsubscribe send an email to
[email protected] Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
389-users mailing list [email protected]
To unsubscribe send an email [email protected]
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List
Archives:https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report
it:https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
389-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
