Hi Claas,
I was wrong stating that I reproduced locally similar issue. I was not
using 2.0.17 and was reproducing an issue related to
nsslapd-idlistscanlimit that is much larger in recent 2.x versions
I tried to mimic "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".
I made a given user an uniquemember of 1000 groups. Each group having
1000 users. Then the search retrieves the 1000 groups DN.
Could you share your dse.ldif (send me directly) ? Also could you
confirm you see the same perf hit with regular connection bound as
"cn=directory manager" ?
best regards
thierry
On 3/14/23 14:25, Claas Vieler wrote:
Hallo Thierry,
got newest version from https://github.com/389ds/389-ds-base dc565fd
<https://github.com/389ds/389-ds-base/commit/dc565fdacbde6e1fd333213d707aa2c5bca9cadf>(389-Directory/2.3.2
B2023.073.0958 )
I can confirm, manageDSAit makes no difference any more in query time,
got etimes with 0,9 sec after import and reindexing (with and without
option)
but a little difference to 1.4.x ist still present :) ( 0.0x sec vs
0.9 sec)
thanks and best regards
Claas
*Gesendet:* Montag, 13. März 2023 um 17:55 Uhr
*Von:* "Thierry Bordaz" <[email protected]>
*An:* [email protected]
*Betreff:* [389-users] Re: 2.x query performance problem
Hi Class,
First, thank you sooo much for your tests. This is really helpful.
So my understanding is that this same req was
* [10, 30]ms in 1.4
* [900, 1700]ms in 2.x
o A possibility is that the filter evaluation (against the 532
returned entry) is the responsible of the 1700ms (without
manageDSAit
In short it looks like there is a significant (>30 times slower)
regression in RHDS12 vs RHDS11 with that testcase. In RHDS12, the
handling of referral adds a 2 times slower but it is possibly fixed
with https://github.com/389ds/389-ds-base/issues/5598.
best regards
thierry
On 3/13/23 17:18, Claas Vieler wrote:
Hello William,
sorry, your mail was stuck in my spam filter, so I doesnt see it
here are the logs with and without option manageDSAit (as Thierry
mentioned)
without manageDSAit:
[13/Mar/2023:16:16:06.583644293 +0100] conn=32 fd=64 slot=64
connection from local to
/var/lib/dirsrv/slapd-389ds/slapd-389ds.socket
[13/Mar/2023:16:16:06.586619267 +0100] conn=32 AUTOBIND dn="cn=root"
[13/Mar/2023:16:16:06.589037720 +0100] conn=32 op=0 BIND
dn="cn=root" method=sasl version=3 mech=EXTERNAL
[13/Mar/2023:16:16:06.591155242 +0100] conn=32 op=0 RESULT err=0
tag=97 nentries=0 wtime=0.000078559 optime=0.004658221
etime=0.004734544 dn="cn=root"
[13/Mar/2023:16:16:06.591326840 +0100] conn=32 op=1 SRCH
base="dc=example,dc=com" scope=2
filter="(uniqueMember=cn=testuser,ou=People,dc=example,dc=com)"
attrs="distinguishedName"
[13/Mar/2023:16:16:08.321020181 +0100] conn=32 op=1 RESULT err=0
tag=101 nentries=532 wtime=0.000114773 optime=1.729694222
etime=1.729803880
[13/Mar/2023:16:16:08.321992532 +0100] conn=32 op=2 UNBIND
[13/Mar/2023:16:16:08.327041073 +0100] conn=32 op=2 fd=64 closed
error - U1
with manageDSAit:
[13/Mar/2023:16:16:22.324132867 +0100] conn=33 fd=64 slot=64
connection from local to
/var/lib/dirsrv/slapd-389ds/slapd-389ds.socket
[13/Mar/2023:16:16:22.326616612 +0100] conn=33 AUTOBIND dn="cn=root"
[13/Mar/2023:16:16:22.328594648 +0100] conn=33 op=0 BIND
dn="cn=root" method=sasl version=3 mech=EXTERNAL
[13/Mar/2023:16:16:22.331154393 +0100] conn=33 op=0 RESULT err=0
tag=97 nentries=0 wtime=0.000055269 optime=0.004608598
etime=0.004661499 dn="cn=root"
[13/Mar/2023:16:16:22.331366318 +0100] conn=33 op=1 SRCH
base="dc=example,dc=com" scope=2
filter="(uniqueMember=cn=testuser,ou=People,dc=expample,dc=com)"
attrs="distinguishedName"
[13/Mar/2023:16:16:23.244139238 +0100] conn=33 op=2 UNBIND
[13/Mar/2023:16:16:23.244725555 +0100] conn=33 op=1 RESULT err=0
tag=101 nentries=532 wtime=0.000081512 optime=0.913360154
etime=0.913438519
[1
*Gesendet:* Mittwoch, 08. März 2023 um 01:11 Uhr
*Von:* "William Brown" <[email protected]>
*An:* "[email protected]"
<[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
we need to see the exact filter that's being used, as well as the
access logs lines of the slow query to really help here.
--
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia
_______________________________________________
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
_______________________________________________
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
