389-users June 2017

389-users@lists.fedoraproject.org

19 participants
25 discussions

Replication strategy
by Alberto Viana 06 Jun '17

06 Jun '17

I have been using 389 for a while and so far my replication strategy is: 389 <=> AD Replicating whole domain dc=my,dc=domain - OU=user -user1 -user2 - OU=people -user1 -user2 - OU=apps -user1 -user2 - OU=externos -user1 -user2 ... But this specific "OU=externos" does not exists on AD side (and I need to keep this). My version in production is: 389-Directory/1.3.2.19 B2014.201.1231 And I have no problem on this scenario. I'm testing newer versions of 389 (to update my production version) and I realized, maybe, that's not the better strategy. Why? Because 389 fails to start the full replication when the OU just exists on 389 side ( https://pagure.io/389-ds-base/issue/48841). So, can you give a clue what should I do when I need a specific OU to be outside of my replication? Thanks.

2 5

enabled account policy plugin and incrace changelog db size
by Alparslan Ozturk 06 Jun '17

06 Jun '17

Hi, two 389-ds running with multimaster replication. and dbbackup size 66MB but when I have enabled "account policy plugin" for tracing lastlogintime of users. but now I see changelog db size incraced 3GB ... the database size is now 3,8G May 25 10:17 74c37b82-3ef411e7-ac57be37-2d84af6b_55dc8a41000000010000.db ... How can I fix the changelog db size problem. [root@mhrsldap1 changelogdb]# cat /etc/redhat-release CentOS Linux release 7.3.1611 (Core) [root@mhrsldap1 changelogdb]# rpm -qa |grep 389 389-admin-console-doc-1.1.12-1.el7.noarch 389-adminutil-1.1.22-1.el7.x86_64 389-ds-base-libs-1.3.5.10-20.el7_3.x86_64 389-ds-base-1.3.5.10-20.el7_3.x86_64 389-admin-console-1.1.12-1.el7.noarch 389-ds-console-doc-1.2.16-1.el7.noarch 389-console-1.1.18-1.el7.noarch 389-ds-base-devel-1.3.5.10-20.el7_3.x86_64 389-adminutil-devel-1.1.22-1.el7.x86_64 389-ds-base-snmp-1.3.5.10-20.el7_3.x86_64 389-ds-console-1.2.16-1.el7.noarch 389-admin-1.1.46-1.el7.x86_64

4 16

Re: Performance Degradation with Split Database
by Paul Whitney 05 Jun '17

05 Jun '17

LOL, that is ironic. Well we also discovered a significant boost by increasing the normalize DN cache limits from 20MB to 1GB. While 1GB may be overkill, without any real metric to compare against, we have the RAM to use and figure lets just give it a large cache. Our metrics improved dramatically again. Our average look ups are now mostly in the sub-second times. Running pstack against the dirsrv PID provided us the tidbit to look further into the DN normalizing cache. (http://directory.fedoraproject.org/docs/389ds/design/normalized-dn-cache.ht…) Paul M. Whitney E-mail: paul.whitney(a)mac.com Sent from my browser. On Jun 04, 2017, at 09:25 PM, William Brown <wibrown(a)redhat.com> wrote: On Fri, 2017-06-02 at 19:14 +0000, Paul Whitney wrote: Not sure to what type of deployment the tuning guide is written to, but I think in an enterprise environment the numbers are too low. Perhaps it is based on a small lab/office environment and not an org with just under a million entries with non-static groups or users. It would be nice if there were a table that provided numbers (customer-based survey) comparable to an organizations size/number of concurrent hits/etc. Funny you say this: Upcoming in 1.3.6 we released autotuning out of the box. I've known for a long time tuning of threads and memory has been a pain point for users and admins. I rewrote out platform memory detection code to be accurate with regard to hardware, rlimits and cgroups, and made autotuning the default. You can read more here: http://www.port389.org/docs/389ds/design/autotuning.html It also includes thread autotuning :) So there is no need for a table, the server will scale up and down based on your hardware and limits provided. In the future we hope to add more improvements in the parallel performance of threads in the server, so hopefully you should see greater benefits in the future too from this type of change, Hope that helps, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

2 1

Re: Performance Degradation with Split Database
by Paul Whitney 04 Jun '17

04 Jun '17

Hi Mark, Thanks for responding to my query. I am in a somewhat constrained environment where posting any kind of log is not practical or permitted. However, after much digging in the various tuning guides out there, I think I found the issue. By default, the directory server is configured for a maximum of 30 concurrent threads (nsslapd-threadnumber). While the tuning guide recommends threads should be set to 2 X CPU, I set it to 200. This made all the difference in performance. Drastically. We are still working on fine-tuning to improve groupRoot type queries response-times. Not sure to what type of deployment the tuning guide is written to, but I think in an enterprise environment the numbers are too low. Perhaps it is based on a small lab/office environment and not an org with just under a million entries with non-static groups or users. It would be nice if there were a table that provided numbers (customer-based survey) comparable to an organizations size/number of concurrent hits/etc. Nevertheless, thank you! This forum has definitely proven helpful in the past and look forward to future postings. Regards, Paul M. Whitney E-mail: paul.whitney(a)mac.com Sent from my browser. On May 31, 2017, at 02:38 PM, Mark Reynolds <mareynol(a)redhat.com> wrote: On 05/31/2017 02:36 PM, Paul Whitney wrote: Still in migration mode from RHEL5/DS 8.2 to CentOS7/DS10 (389-ds-base 1.3.5.10-20). Our one instance is setup with two databases (userRoot and groupRoot). We are seeing some really high etimes when performing mods/search on the second database (groupRoot). Wondering if anyone else has experienced this issue and what was done to overcome them? Can you provide some access log snippets showing some searches & mods from start to finish with the high etimes? Also, what kind of "mods" are you doing? Thanks, Mark Server is vmware VM with 4 CPU, 64GB RAM, plenty of disk space. CentOS 7 is "tuned" for virtual-guest. Paul M. Whitney E-mail: paul.whitney(a)mac.com Sent from my browser. _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

2 1

changing supplier
by Fabrice Teissedre 02 Jun '17

02 Jun '17

Hi, I'm new too 389DS. I want to use it for a LDAP / AD replication. My university has an openldap with all the accounts (around 30000). How can I change the supplier in 389-Ds to put the openldap directory as the source ? I don't kow if it's possible.. Thanks. Regards. -- *************************************** Fabrice TEISSEDRE FSI SYSTEME ET RESEAUX Tel : 05.61.55.62.17 Mel : fabrice.teissedre(a)univ-tlse3.fr ***************************************

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users June 2017