Wednesday, August 7, 2024

[389-users] Re: Performance issue with 2.4.5

Yes, I'll try that, thanks!  However, where can I find the 2.4.6 RPMs (el9)?

 

Thanks!

 

- Shilen

 

From: Thierry Bordaz <tbordaz@redhat.com>
Date: Wednesday, August 7, 2024 at 12:15 PM
To: "General discussion list for the 389 Directory server project." <389-users@lists.fedoraproject.org>, Shilen Patel <shilen@duke.edu>
Subject: Re: [389-users] Performance issue with 2.4.5

 

Hi,

I wonder if it could be related to #6172 [1] that is fixed in 2.4.6. Could you test it ?
I suspect that in 1.3.10, we had an invalid accelerator that would skip the evaluation of the filter against the returned entries. It was later fixed in 1.4 and 2.x but with the extra filter burden.

[1] https://github.com/389ds/389-ds-base/issues/6172

thierry

On 8/7/24 17:30, Shilen Patel wrote:

Hello!

 

I have a cluster of VMs running 1.3.10 that I'm migrating to new VMs running 2.4.5.  The data is identical as there is replication set up.

 

I have a suffix (ou=groups,dc=example,dc=edu) that has 1 million group objects of objectClass groupOfNames.  A search that uses directory manager that tries to retrieve all group DNs of a user is significantly slower in 2.4.5 than it was in 1.3.10.  After restarting the directory, the initial query is always slow since I assume the data is being cached.  But afterwards, I see the following:

 

1.3.10:

 

[07/Aug/2024:11:01:28.227539168 -0400] conn=486373 op=1 SRCH base="ou=groups,dc=example,dc=edu" scope=2 filter="(member=uid=testuser,ou=people,dc=example,dc=edu)" attrs="distinguishedName"

[07/Aug/2024:11:01:28.230320235 -0400] conn=486373 op=1 RESULT err=0 tag=101 nentries=85 etime=0.003013701

 

2.4.5:

 

[07/Aug/2024:15:00:57.583606411 +0000] conn=1288 op=1 SRCH base="ou=groups,dc=example,dc=edu" scope=2 filter="(member=uid=testuser,ou=people,dc=example,dc=edu)" attrs="distinguishedName"

[07/Aug/2024:15:01:17.012764161 +0000] conn=1288 op=1 RESULT err=0 tag=101 nentries=85 wtime=0.000255898 optime=19.429163009 etime=19.429411947

 

 

You can see from the logs that 2.4.5 is significantly slower for the same query that returns the same data.  From the client perspective, when you factor in network latency/etc, it's about 60 times slower.  But based on those logs, it's about 6000 times slower.  I ran db2index just in case that would help but it didn't.  The cache settings are the same in both environments.  Any ideas on how to improve the performance here?

 

Thanks!

 

- Shilen



No comments:

Post a Comment