<div dir="ltr">Thanks!! After some debugging I spotted that the orgUnit was being removed, assigned, then updated because of case sensitivity issues. I went in and updated all the mapping related to transform to uppercase. That was the main time killer because that change also triggers updates to be pushed to resources dependent on dn. There are a few more but not time spent on this mapping.<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">JASON</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 21, 2019 at 6:30 AM Wojciech Staszewski <<a href="mailto:wojciech.staszewski@diagnostyka.pl">wojciech.staszewski@diagnostyka.pl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Jason!<br>
<br>
This is also my case.<br>
I was trying to debug operations executed by reconciliation tasks, so I ran "simpleResourceObjectNotifier" with output to a log file<br>
and noticed much more updates/modifications on the remote databases than I expected.<br>
<br>
The first cause was simple in my case: matching rules in the attribute outbound mapping, eg. "givenName", mapped to the uppercase<br>
on the resource, but matching rule id midPoint was "default", so midPoint was updating these attributes everytime.<br>
There was a lot attributes like that with incorrect matching rules, after corrections reconciliation tasks runs a little faster.<br>
<br>
Except that, I noticed that non-tolerant entitlement associations works strange.<br>
I mean that for every user every time operation "DELETE" is executed for not assigned entitlements (eg. group membership),<br>
even if the user is NOT a group member on the target system.<br>
<br>
Log:<br>
The account has been successfully modified on the resource. Modified attributes are:<br>
...<br>
   - Associations:<br>
      - DELETE:<br>
         - name: zabbixGroups<br>
         - identifiers:<br>
            - ConnId Name: Zabbix administrators<br>
         - shadowRef: Zabbix administrators (shadow) on ZABBIX  [default]<br>
      - DELETE:<br>
         - name: zabbixGroups<br>
         - identifiers:<br>
            - ConnId Name: GROUP1<br>
         - shadowRef: GROUP1 (shadow) on ZABBIX  [default]<br>
      - DELETE:<br>
         - name: zabbixGroups<br>
         - identifiers:<br>
            - ConnId Name: GROUP2<br>
         - shadowRef: GROUP2 (shadow) on ZABBIX  [default]<br>
      - DELETE:<br>
         - name: zabbixGroups<br>
         - identifiers:<br>
            - ConnId Name: GROUP3<br>
         - shadowRef: GROUP3 (shadow) on ZABBIX  [default]<br>
      - DELETE:<br>
         - name: zabbixGroups<br>
         - identifiers:<br>
            - ConnId Name: GROUP4<br>
         - shadowRef: GROUP4 (shadow) on ZABBIX  [default]<br>
<br>
...and so on,for every not assigned group and for every account. I guess it slows down the reconciliation.<br>
But I don't know if I can do anything about that...<br>
<br>
<br>
Regards,<br>
WS<br>
<br>
<br>
W dniu 03.01.2019 o 20:50, Jason Everling pisze:<br>
> It may just be me but it seems like in 3.7 the ScriptedSQL connector is slower than previous versions. Script reload is also set to false.<br>
> <br>
> I am running a recon now and it is processing 1000 per 10min, previously I remember it only taking about 45min to process this resource is 3.4. This resource has 15k+ accounts so I am looking at about 2 1/2 -3 hours. This is a new server when I migrated it to 3.7 , running stand-alone, not container on Ubnt 18.04, TC 8.x, MySQL 5.7, VM resides on ssd clustered datastore, 12Gb ram. I am going to see what I can do on the mysql side in the meantime.<br>
> <br>
> Any have any pointers to speed it up or maybe you have done something to improve it?<br>
> <br>
> Thanks!<br>
> <br>
> _______________________________________________<br>
> midPoint mailing list<br>
> <a href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a><br>
> <a href="http://lists.evolveum.com/mailman/listinfo/midpoint" rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
> <br>
<br>
-- <br>
Wojciech Staszewski<br>
Administrator Systemów Sieciowych<br>
<a href="http://www.diagnostyka.pl" rel="noreferrer" target="_blank">www.diagnostyka.pl</a><br>
Diagnostyka Sp. z o. o.<br>
ul. Prof. M. Życzkowskiego 16, 31-864 Kraków<br>
Numer KRS: 0000381559 (Sąd Rejonowy dla Krakowa-Śródmieścia w Krakowie, XI Wydział Gospodarczy KRS)<br>
NIP: 675-12-65-009; REGON: 356366975<br>
Kapitał zakładowy: 33 756 500 zł.<br>
<br>
Pomyśl o środowisku zanim wydrukujesz ten e-mail.<br>
_______________________________________________<br>
midPoint mailing list<br>
<a href="mailto:midPoint@lists.evolveum.com" target="_blank">midPoint@lists.evolveum.com</a><br>
<a href="http://lists.evolveum.com/mailman/listinfo/midpoint" rel="noreferrer" target="_blank">http://lists.evolveum.com/mailman/listinfo/midpoint</a><br>
</blockquote></div>