cancel
Showing results for 
Search instead for 
Did you mean: 

Serious performance issues in Java frontend

Henrik1
Participant
0 Kudos

Hi,

I am currently facing an issue with woeful performance on our production system, when accessing through the frontend. Going to change identity task takes a good 30 seconds, and the same again when clicking save.

If I kick off a mass-load task in the backend, it runs with no issues, so I'm thinking the problem is in the java stack.

The dev and QA systems are not experiencing the same issues, and they perform quite well.

The basis team has seen the below in the logs as queries taking very long to run.

We have tested the running of queries directly on the database, and that is performing as expected, i.e. very fast

Does any of this sound familiar to anyone? Any thoughts on what could cause this?

Input much appreciated!

IdM 7.2, sp6 on Win 2008 server, 16GB RAM, with MS SQL on server farm.

/henrik

EntryUtil:searchExistingRefValues:Executing SQL:select mcUniqueId,mcLinkType,mccontextmskey,mcthismskey,mcthisentrydisplayname,mcothermskey,mcotherentrydisplayname,mcthisentrytype,mcOtherEntryType,mcLinkState,mcValidFrom,mcValidTo,mcReason,mcAssignedDirect,mcexecstate,mcexecstatehierarchy,mcmodifynewvalidfrom,mcmodifynewvalidto,mcdirvalidfrom,mcdirvalidto,mcassigneddirect,mcexecstate,mcmodifyreason,mcAssignedDynamicGroup,mcAssignedInheritCount,mcAssignedMasterPrivilege,mcOrphan,mcAssigner,mcAddedTime,mcModifyTime,mcAttrId from mxiv_link_entry VALS WHERE ( (mcLinkType=2 AND (mcLinkState=0 OR (mcLinkState=1 AND (mcExecState>=512 OR mcExecState=2 OR mcExecState=4 OR mcAssignedDirect=1 OR mcAssignedDynamicGroup=1)))) OR (mcLinkState<>2 AND mcLinkState=0) ) AND mcAttrId=?  AND mcThisMskey=? and mcAssignedDirect=1 AND EXISTS (SELECT mcMskey FROM mxiv_entry E WHERE mcMskey=VALS.mcothermskey and ((mcACEntry=0) or (mcACentry=1 AND ((? IN (SELECT MemberMskey FROM idmv_members WHERE EntryMskey=E.mcMSKEY)) OR (? IN (SELECT OwnerExpandedMskey FROM idmv_owners WHERE EntryMSKEY=E.mcMSKEY)))) or ( mcACEntry=2 AND ? IN (SELECT OwnerExpandedMskey FROM idmv_owners WHERE EntryMSKEY=E.mcMSKEY)))) :: Parameters:[765, 5066, 57, 57, 57]

EntryUtil:searchExistingRefValues:Executing SQL:select mcUniqueId,mcLinkType,mccontextmskey,mcthismskey,mcthisentrydisplayname,mcothermskey,mcotherentrydisplayname,mcthisentrytype,mcOtherEntryType,mcLinkState,mcValidFrom,mcValidTo,mcReason,mcAssignedDirect,mcexecstate,mcexecstatehierarchy,mcmodifynewvalidfrom,mcmodifynewvalidto,mcdirvalidfrom,mcdirvalidto,mcassigneddirect,mcexecstate,mcmodifyreason,mcAssignedDynamicGroup,mcAssignedInheritCount,mcAssignedMasterPrivilege,mcOrphan,mcAssigner,mcAddedTime,mcModifyTime,mcAttrId from mxiv_link_entry VALS WHERE ( (mcLinkType=2 AND (mcLinkState=0 OR (mcLinkState=1 AND (mcExecState>=512 OR mcExecState=2 OR mcExecState=4 OR mcAssignedDirect=1 OR mcAssignedDynamicGroup=1)))) OR (mcLinkState<>2 AND mcLinkState=0) ) AND mcAttrId=?  AND mcThisMskey=? and mcAssignedDirect=1 AND EXISTS (SELECT mcMskey FROM mxiv_entry E WHERE mcMskey=VALS.mcothermskey  and ((mcACEntry=0) or (mcACentry=1 AND ((? IN (SELECT MemberMskey FROM idmv_members WHERE EntryMskey=E.mcMSKEY)) OR (? IN (SELECT OwnerExpandedMskey FROM idmv_owners WHERE EntryMSKEY=E.mcMSKEY)))) or ( mcACEntry=2 AND ? IN (SELECT OwnerExpandedMskey FROM idmv_owners WHERE EntryMSKEY=E.mcMSKEY)))) :: Parameters:[769, 5066, 57, 57, 57]

EntryUtil:getEntry:Executing SQL:SELECT attr_id, attrname, aValue from idmv_jmx_entries where mskey=? AND attr_id in ( ?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) :: Parameters:[5066, 0, 0, 388, 390, 468, 446, 445, 447, 449, 0, 482, 483, 0, 771, 0, 0, 0, 0, 543, 393, 444, 0, 433, 434, 0, 0, 0, 0, 0, 0, 489, 488, 0, 0, 389, 436, 437, 0, 0, 464, 465, 467, 466, 0, 0, 435, 439, 440, 441, 458, 0, 573, 459, 575]

EntryUtil:getValueOfUser:Executing SQL:SELECT attr_id,aValue from idmv_jmx_entries where mskey=? and attr_id in (?) :: Parameters:[5066, 543]

EntryUtil:searchExistingRefValues:Executing SQL:select mcUniqueId,mcLinkType,mccontextmskey,mcthismskey,mcthisentrydisplayname,mcothermskey,mcotherentrydisplayname,mcthisentrytype,mcOtherEntryType,mcLinkState,mcValidFrom,mcValidTo,mcReason,mcAssignedDirect,mcexecstate,mcexecstatehierarchy,mcmodifynewvalidfrom,mcmodifynewvalidto,mcdirvalidfrom,mcdirvalidto,mcassigneddirect,mcexecstate,mcmodifyreason,mcAssignedDynamicGroup,mcAssignedInheritCount,mcAssignedMasterPrivilege,mcOrphan,mcAssigner,mcAddedTime,mcModifyTime,mcAttrId from mxiv_link_entry VALS WHERE ( (mcLinkType=2 AND (mcLinkState=0 OR (mcLinkState=1 AND (mcExecState>=512 OR mcExecState=2 OR mcExecState=4 OR mcAssignedDirect=1 OR mcAssignedDynamicGroup=1)))) OR (mcLinkState<>2 AND mcLinkState=0) ) AND mcAttrId=? AND (mcValidFrom IS NULL OR mcValidFrom<=getdate()) AND mcThisMskey=? and mcAssignedDirect=1 AND EXISTS (SELECT mcMskey FROM mxiv_entry E WHERE mcMskey=VALS.mcothermskey  and ((mcACEntry=0) or (mcACentry=1 AND ((? IN (SELECT MemberMskey FROM idmv_members WHERE EntryMskey=E.mcMSKEY)) OR (? IN (SELECT OwnerExpandedMskey FROM idmv_owners WHERE EntryMSKEY=E.mcMSKEY)))) or ( mcACEntry=2 AND ? IN (SELECT OwnerExpandedMskey FROM idmv_owners WHERE EntryMSKEY=E.mcMSKEY)))) :: Parameters:[569, 5066, 57, 57, 57]

Accepted Solutions (0)

Answers (6)

Answers (6)

Henrik1
Participant
0 Kudos

Hi,

We have SAP on site to look at the issue, and true to form, IdM is behaving itself with no performance issues. Typical! 🙂

The db server was restarted, so maybe something got flushed during that.

The short of the long is that the performance is not as it should be, but we have no idea what caused it originally.

Thanks all for your input!

/henrik

Former Member
0 Kudos

If it happens again you should request reports from the DB team; object execution statistics and top transactions by lock count to start with. Perhaps they can peek into the activity monitor as well to see if there's something running for a long time slowing down the rest of the system as well.

Br,

Chris

Henrik1
Participant
0 Kudos

Thanks all for the input. Australia day weekend here, so just back today 🙂

@Matt: IdM 7.2, sp6 on Win 2008 server, 16GB RAM, with MS SQL on server farm.

The database is also used for GRC, and it's running quite well.


Will have a look at the configuration analyzer as well.

@Steffi, Christopher: I hear what you are saying - but we hardly have any data in the system. The setup is exactly the same as our QA box, which is running fine.

@Krishna, nothing strange on the server side, with the exception of the queries mentioned.

Will have to keep digging and see if the config analyzer can shed any light on this

/h

0 Kudos

Hi Henrik,

We have a similar problem, with the same statement, and it is driven by the MX_ASSIGNMENT/ MXREF_MX_ROLE / MXREF_MX_PRIVILEGE attributes on the UI. We could see this very clearly by removing those attributes from the UI, and we saw it speed up, so a simple test for you.

It is tricky to see at the DB level as the statement itself is actually speedy in our case, it is just run lots of times per UI task opening.

We are working with SAP Development on a fix - they assure me it is fixed on SP8,  and AS Java 7.3. We are running our UI on AS Java 7.0 as it supports GRC, in I guess the same configuration you have?

We have been strongly advised by SAP to switch to AS Java 7.3 for the UI, and if possible get up to SP8 or SP9 when it comes out.

Let me know if taking those attributes off helps.

Cheers,

Ian

former_member2987
Active Contributor
0 Kudos

Hi Henrik!

I'd look on the IDM database end.You don't mention what database you're using or version of IDM.  But I'd look at the following:

1. Download the Configuration Analyzer. And take a look at its results.  It will refer you to queries that can be optimized and "choke points"

2. Also check the admin console if you're running 7.2.  Later SPs also have some configuration analyzer functionality to check for queries that are taking a long time (configurable) to run.

Matt

ChrisPS
Contributor
0 Kudos

Hello Henrik,

                   if you are displaying the MX_ASSIGNMENT attribute in the task you can switch off

the 'List entries on load' checkbox in the Presentation tab of the attribute defintion under the identity Store schema in the MMC. If the users exist in many repositories then this can cause slow performance sometimes on the display.

Something to rule out in any case.

Regards,

Chris

PS - oops only noticed Steffi kind of mentioned this too 😉

Steffi_Warnecke
Active Contributor
0 Kudos

Hello Henrik,

the history-tab on those UI-tasks is also a big timekiller. Do you have that activated in the Presentation-tab of the UI-tasks in the MMC?

Also having attributes like MX_ASSIGNMENT, MXREF_MX_PRIVILEGE and MXREF_MX_ROLE on "List entries on load" does slow the whole thing down a lot. That why we have a seperate UI mask just for those and are not showing them in the normal user masks with the other information.

Maybe that helps you a bit.

Regards,

Steffi.

Former Member
0 Kudos

Hi Henrik,

May be bringing down the application, clearing the cache might help in restoring the performance. (Ofcourse, only after business hours as it is PRD)

Can you also have a check on the resource consumption on the server... like RAM, Disk Space etc etc.

~ Krishna