<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 12/22/15 03:24, thierry bordaz
wrote:<br>
</div>
<blockquote cite="mid:567916C4.3020905@redhat.com" type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="moz-cite-prefix">On 12/21/2015 05:55 PM, Daryl
Fonseca-Holt wrote:<br>
</div>
<blockquote cite="mid:56782EFA.1090300@umanitoba.ca" type="cite">Hi
all, <br>
<br>
Environment: RHEL6 with IPA 3.0 at current RedHat level. 64-core
256-GB RAM Oracle x4470 M2. <br>
<br>
During our migration from NIS on Solaris 140,000+ accounts will
be added. After tuning per the guides dbmon.sh shows no roevicts
and we get high cache hit ratios. <br>
<br>
Per a previous discussion with the list the input is broken down
into batches of less than 1,000 users and the default IPA group
is changed before each batch. This helped greatly. <br>
<br>
Adding all the users takes many hours. Initially ipa user-add
takes an average 2.3 seconds per user but degrades by the time
there are 140,000 users to an average 6.7 seconds per user. <br>
<br>
In tracing it appears that a significant portion of the time ipa
user-add takes is not the add itself, it is the query at the end
that displays the resulting user account. Is there any legit way
to prevent this query? <br>
<br>
The length of time it takes to migrate is not a big concern. The
concern is the start of the fall school term when we typically
add approximately 1,300 accounts per hour during the
registration period with our current system. <br>
<br>
All suggestions will be appreciated. <br>
<br>
Regards, Daryl <br>
<br>
</blockquote>
<font face="Times New Roman, Times, serif">Hi Daryl,<br>
<br>
I can reproduce similar trend of user-add becoming slower and
slower.<br>
<br>
Now in my tests (etime=7s) the time was spent half by
authentication and half by ADD and MOD (update of ipausers
group). I agree there are many direct SRCH (~10) but they all
seems to be rapid.<br>
<br>
I know that the vast majority of the time is spent in DS
schema-compat plugin. Disabling it, during provisioning, reduce
the duration by ~3.<br>
Now I do not know if it is a valid option to disable this plugin
during provisioning. <br>
<br>
thanks<br>
thierry<br>
</font> </blockquote>
Thanks for validating my timings, it's good to know I'm not off
track somewhere. <br>
<br>
Not being sure what I will end up with if the DS schema-compat
plugin is disabled I'm not sure I'll end up with what we need. We
need NIS in the future and further out we will convert the clients
to LDAP and possible SSSD in the case of Linux clients.<br>
<br>
Thanks, Daryl <br>
<pre class="moz-signature" cols="72">--
--
Daryl Fonseca-Holt
IST/CNS/Unix Server Team
University of Manitoba
204.480.1079
</pre>
</body>
</html>