[midPoint] MidPoint and server hardware utilization

Mon Feb 18 16:38:38 CET 2019

Wow, this is incredible hardware setup! Memory (in terms of Xmx for mp
java) seems really excessive. The main factor of your deployment seems
number of resources, number of users is quite low.

Difficult to say if cluster is the right way without knowing more info. I
spent lot of time tuning midPoint myself, so here are some tips:
- As Arnost suggested switching off Consistency check will *greatly *(e.g.
5x) improve recomputing users with many projections. See
https://jira.evolveum.com/browse/MID-4982
- Switch on *midPoint's profiling*. Recommended setting on screenshot
below, its actually very helpful.
- Are your perf. problems coming from GUI only? Or it might be delayed e.g.
from user recompute? That would imply connector problems (what are e.g. GET
stats for accounts?) Provide env. stats tab.
- Do you have some special problems in Org Tree? This is common and there
are some tricks to improve it as well.
- Common problem is bad DB. Is it really configured right to utilize all
memory to cache data?
- One of biggest causes of perf issues are big XML objects (in terms of
KB). Mostly Users. Do you have any user, which when exported to file has
>1MB size? You can easily print stats with below task Object size check.
- Run latest mp 3.9-support... it contains lots of perf and stability fixes.

Profiler (dont forget enabling it in config.xml):
[image: image.png]

Print object size stats to midpoint.log:
<task xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3">
    <name>Object size check</name>
    <extension xmlns:mext="
http://midpoint.evolveum.com/xml/ns/public/model/extension-3">
        <mext:objectQuery>
            <!-- put object query here, if needed -->
        </mext:objectQuery>
    </extension>
    <ownerRef oid="00000000-0000-0000-0000-000000000002" type="UserType"/>
    <executionStatus>runnable</executionStatus>
    <handlerUri>
http://midpoint.evolveum.com/xml/ns/public/model/object-integrity-check/handler-3
</handlerUri>
    <recurrence>single</recurrence>
</task>

*Martin Lízner*
chief solution architect

gsm: [+420] 737 745 571
e‑mail: martin.lizner at ami.cz

*AMI Praha a.s.*
Pláničkova 11, 162 00 Praha 6

tel.: [+420] 274 783 239 | web: www.ami.cz

[image: AMI Praha a.s.]

Textem tohoto e‑mailu podepisující neslibuje uzavřít ani neuzavírá
za společnost AMI Praha a.s.
jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně
písemnou formu.

Tento e‑mail je určen výhradně pro potřeby jeho adresáta/ů a může obsahovat
důvěrné nebo osobní
informace. Nejste‑li zamýšleným příjemcem, je zakázáno jakékoliv
zveřejňování, zprostředkování
nebo jiné použití těchto informací. Pokud jste obdrželi e‑mail neoprávněně,
informujte o tom prosím
odesílatele a vymažte neprodleně všechny kopie tohoto e‑mailu včetně
všech jeho příloh. Nakládáním
s neoprávněně získanými informacemi se vystavujete riziku právního postihu.

po 18. 2. 2019 v 16:21 odesílatel Arnošt Starosta - AMI Praha a.s. <
arnost.starosta at ami.cz> napsal:

> Hi Wojciech,
>
> that's a lot of HW and i have no true solution to this problem.
>
> but ... there is a tiny magic configuration setting that might help you
> right now,
>
> GUI > Internals Configuration > Internal Configuration > check consistency
>
> i think it's switched off by default in 3.9-support and master, but not
> before.
>
> unchecking this may speed things up. beware that it's on again after
> restart.
>
> arnost
>
> po 18. 2. 2019 v 16:03 odesílatel Wojciech Staszewski <
> wojciech.staszewski at diagnostyka.pl> napsal:
>
>> Hello!
>>
>> I am curious about your opinion and experience about optimal server
>> hardware for midPoint deployment.
>>
>> At the moment I have over 7000 users, 190 active resources, 422 Org
>> Units, 2793 roles, 111 reconciliation tasks.
>> Our midPoint is working slow. GUI became very slow, if user has over 20
>> projections the user details page opens dramatically slow.
>> Hardware: 26 CPU cores, 256GB RAM (128G reserved for Tomcat, 50G for DB),
>> 8 x SSD RAID10 for the DB.
>> Database: MySQL, DB size: 17GB.
>>
>> At the moment I moved all server tasks to evening hours and weekends to
>> enable GUI routine works for end users.
>> But I wonder if this is a good moment to start thinking about second
>> midPoint node to make a cluster...
>>
>> And this is still pre-production time (production launch is planned on
>> 07.2019r).
>> Will the second node be a cure for slow GUI? Or maybe move the connectors
>> to a separate host?
>> Maybe re-planning server tasks?
>>
>> Thanks,
>> WS
>>
>> --
>> Wojciech Staszewski
>> Administrator Systemów Sieciowych
>> www.diagnostyka.pl
>> Diagnostyka Sp. z o. o.
>> ul. Prof. M. Życzkowskiego 16, 31-864 Kraków
>> Numer KRS: 0000381559 (Sąd Rejonowy dla Krakowa-Śródmieścia w Krakowie,
>> XI Wydział Gospodarczy KRS)
>> NIP: 675-12-65-009; REGON: 356366975
>> Kapitał zakładowy: 33 756 500 zł.
>>
>> Pomyśl o środowisku zanim wydrukujesz ten e-mail.
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>
>
> --
>
> *Arnošt Starosta*
> solution architect
>
> gsm: [+420] 603 794 932
> e‑mail: arnost.starosta at ami.cz
>
> *AMI Praha a.s.*
> Pláničkova 11, 162 00 Praha 6
>
> tel.: [+420] 274 783 239 | web: www.ami.cz
>
> [image: AMI Praha a.s.]
>
> Textem tohoto e‑mailu podepisující neslibuje uzavřít ani neuzavírá
> za společnost AMI Praha a.s.
> jakoukoliv smlouvu. Každá smlouva, pokud bude uzavřena, musí mít výhradně
> písemnou formu.
>
> Tento e‑mail je určen výhradně pro potřeby jeho adresáta/ů a může
> obsahovat důvěrné nebo osobní
> informace. Nejste‑li zamýšleným příjemcem, je zakázáno jakékoliv
> zveřejňování, zprostředkování
> nebo jiné použití těchto informací. Pokud jste obdrželi e‑mail
> neoprávněně, informujte o tom prosím
> odesílatele a vymažte neprodleně všechny kopie tohoto e‑mailu včetně
> všech jeho příloh. Nakládáním
> s neoprávněně získanými informacemi se vystavujete riziku právního postihu.
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20190218/a09bc2e8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 22166 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20190218/a09bc2e8/attachment.png>