Replication strategy
by Alberto Viana
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.
6 years, 10 months
enabled account policy plugin and incrace changelog db size
by Alparslan Ozturk
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
6 years, 10 months
Re: Performance Degradation with Split Database
by Paul Whitney
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....)
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
6 years, 10 months
Re: Performance Degradation with Split Database
by Paul Whitney
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
6 years, 10 months
changing supplier
by Fabrice Teissedre
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
***************************************
6 years, 10 months
