Please excuse the mistake in my previous message; the communication on port 389 is actually from the supplier nodes to the consumer nodes, not the other way around. What could be triggering traffic on port 389 if the replication agreements are strictly configured on port 636? Note that we are running an old version of 389-ds: 389-ds-base-1.3.10.2-10. Thank you in advance for your help. Best regards -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org 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/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Wednesday, June 3, 2026
Tuesday, June 2, 2026
[Test-Announce] Fedora 45 Rawhide 20260603.n.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora 45 Rawhide 20260603.n.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Notable package version changes: anaconda - 20260527.n.1: anaconda-45.5-1.fc45.src, 20260603.n.0: anaconda-45.6-1.fc45.src Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/45 You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Installation https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Base https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Server https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Cloud https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Desktop https://fedoraproject.org/wiki/Test_Results:Fedora_45_Rawhide_20260603.n.0_Security_Lab Thank you for testing! -- Mail generated by relvalconsumer: https://forge.fedoraproject.org/quality/relvalconsumer -- _______________________________________________ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-leave@lists.fedoraproject.org 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/test-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Monday, June 1, 2026
[389-users] Re: Fwd: retrieving 75K objects each with 77 attributes vs. all attributes
On 5/29/26 4:45 PM, Bob Green via 389-users wrote: > On Fri, May 29, 2026 at 6:46 AM Pierre Rogier <progier@redhat.com> wrote: >> Hi Bob, >> >> The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send. >> i.e calling send_all_attrs instead of send_specific_attrs >> >> in the first case it walks the attribute list of the given entry >> while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type) >> >> In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent) >> >> 75682 objects with 870191 attributes means around 12 attributes per entries >> ==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them. >> so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M >> strcasecmp are performed on 25 seconds >> Or 2.5 M strcasecmp per seconds >> IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck >> paging maybe, or other processes spending the bandwidth ? > Thank you for your analysis. I went back to take a closer look at > these ~76K objects and indeed there are approximately 77 attributes > being retrieved for each object, which makes the total attributes > retrieved when specifying all 77 explicitly a bit over 5.8 million. > When requesting all attributes the total per object is closer to 87 > attributes each. The 870191 number of total attributes I shared > initially is clearly wrong, I must have come up with this number by > parsing the output through sort | uniq which was incorrect. I'm > guessing now that I've clarified the actual number of attributes > returned from a query your strcasecmp analysis would indicate a CPU > bottleneck. Also note that the server returns values not only attributes. So if some attributes have a large set of values or large values (like jpeg, certs..) then the networks can be a bottleneck. You may redirect your search into a file to compute the amount of transfer data. > > Thank you for sharing these details. > Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org 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/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Friday, May 29, 2026
[389-users] Re: Fwd: retrieving 75K objects each with 77 attributes vs. all attributes
On Fri, May 29, 2026 at 6:46 AM Pierre Rogier <progier@redhat.com> wrote: > > Hi Bob, > > The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send. > i.e calling send_all_attrs instead of send_specific_attrs > > in the first case it walks the attribute list of the given entry > while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type) > > In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent) > > 75682 objects with 870191 attributes means around 12 attributes per entries > ==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them. > so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M > strcasecmp are performed on 25 seconds > Or 2.5 M strcasecmp per seconds > IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck > paging maybe, or other processes spending the bandwidth ? Thank you for your analysis. I went back to take a closer look at these ~76K objects and indeed there are approximately 77 attributes being retrieved for each object, which makes the total attributes retrieved when specifying all 77 explicitly a bit over 5.8 million. When requesting all attributes the total per object is closer to 87 attributes each. The 870191 number of total attributes I shared initially is clearly wrong, I must have come up with this number by parsing the output through sort | uniq which was incorrect. I'm guessing now that I've clarified the actual number of attributes returned from a query your strcasecmp analysis would indicate a CPU bottleneck. Thank you for sharing these details. Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org 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/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
[389-users] Re: retrieving 75K objects each with 77 attributes vs. all attributes
On Thu, May 28, 2026 at 3:48 PM Bob Green <wood.green.robert@gmail.com> wrote: > > On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol@redhat.com> wrote: > > > > Otherwise, in this case the only other option is to make sure your entry > > cache is large enough to hold all the entries. Note - running > > concurrent searches like this is not going to be performant because it > > has to process so many results. So I am not surprised the more > > concurrent searches you run the slower they all get. > > Am I correct that nsslapd-cachesize: -1 under dn: cn=userroot,cn=ldbm > database,cn=plugins,cn=config will "automatically size" the entry > cache? I ask because dsconf INSTANCE backend monitor --suffix > dc=example,dc=com reports: > > currententrycachesize: 2818570021 > maxentrycachesize: 2818572288 > > which is just about at the maximum, though perhaps this will grow in > size as needed? Or should I replace -1 with a larger value? To answer my question, if you want to manually set your nsslapd-cachememsize attribute you must make the following ldapmodify changes: dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cache-autosize nsslapd-cache-autosize: 0 dn: cn=userroot,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-cachememsize nsslapd-cachememsize: <new_value> Thanks again, and I apologize for my previous email which was forwarded rather than replied, due to me not noticing I had only replied to Mark and not the list previously. Bob -- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org 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/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
[389-users] Re: Fwd: retrieving 75K objects each with 77 attributes vs. all attributes
The difference between using allids and providing a list of 77 attributes is indeed when determining the list of attributes to send.
i.e calling send_all_attrs instead of send_specific_attrs
in the first case it walks the attribute list of the given entry
while in the second case for the 77 attributes it iterates on all the attributes to find the searched attribute (i.e performing strcasecmp on the attribute type)
In you case the 77 lookups spend 25 seconds more while sending less data over the network (because some attributes values are not sent)
75682 objects with 870191 attributes means around 12 attributes per entries
==> most of searched attributes are not in the entry meaning that it loops on all attributes to find them.
so in average something around 75682 * [ 65 * 12 + 12 * 6 ] i.e: 64 M
strcasecmp are performed on 25 seconds
Or 2.5 M strcasecmp per seconds
IMHO that seems a bit low so there is maybe something else than pure CPU bottleneck
paging maybe, or other processes spending the bandwidth ?
Regards
Pierre
On Thu, May 28, 2026 at 1:16 PM Mark Reynolds <mareynol@redhat.com> wrote:
>
> Hi Bob,
>
> What is in the access log for these searches? I suspect you're doing an
> unindexed search (check access log for notes=A or notes=U).
There are no notes=A or notes=U access events, just notes=P (paged
search) and a smattering of notes=N.
> This is not really an ideal way to test the server's performance. One
> thing to help with this type of search is to adjust the idscanlimit to
> at least 100000 (it might already be set really high)
>
> # dsconf slapd-YOUR_INSTANCE backend config get | grep
> nsslapd-idlistscanlimit
>
> If it's 4000 (or less than 100k) you can bump it up:
>
> # dsconf slapd-YOUR_INSTANCE backend config set
> --idlistscanlimit=100000 (this does not require a server restart to
> take effect)
nsslapd-idlistscanlimit is 2147483646.
> Otherwise, in this case the only other option is to make sure your entry
> cache is large enough to hold all the entries. Note - running
> concurrent searches like this is not going to be performant because it
> has to process so many results. So I am not surprised the more
> concurrent searches you run the slower they all get.
Am I correct that nsslapd-cachesize: -1 under dn: cn=userroot,cn=ldbm
database,cn=plugins,cn=config will "automatically size" the entry
cache? I ask because dsconf INSTANCE backend monitor --suffix
dc=example,dc=com reports:
currententrycachesize: 2818570021
maxentrycachesize: 2818572288
which is just about at the maximum, though perhaps this will grow in
size as needed? Or should I replace -1 with a larger value?
I also increased nsslapd-ndn-cache-max-size, dcsonf INSTANCE config
replace nsslapd-ndn-cache-max-size after seeing this with dsconf
INSTANCE monitor backend:
currentnormalizeddncachesize: 20971440
maxnormalizeddncachesize: 20971440
Thank you for the suggestions.
Bob
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
389 Directory Server Development Team
-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org 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/389-users@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Reminder about the sunset of pagure.io
Hello everyone, we aim to decommision our old forge pagure.io around the Flock conference. We encourage you to migrate all your repositories from Pagure to our new forge[1] or to any other Git hosting service. If you have any questions, you can contact us on Matrix[2] or open a ticket with the Forge team [3]. Discussion and feedback can be held in the Discourse topic[4]. New organisation requests can be filed on the Forge ticket tracker[3] On behalf of the Fedora Infrastructure Team Smolík Vít [1] https://forge.fedoraproject.org [2] https://matrix.to/#/#fedora-forgejo:fedoraproject.org [3] https://forge.fedoraproject.org/forge/forge [4] https://discussion.fedoraproject.org/t/decommissioning-of-pagure-io-anticipated-by-flock-2026/181997 -- _______________________________________________ announce mailing list -- announce@lists.fedoraproject.org To unsubscribe send an email to announce-leave@lists.fedoraproject.org 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/announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new