none
High CPU usage RRS feed

  • Question

  • Hi,

    We have deployed a FIM configuration with 2 database sources for "input".

    Synchronization rules are working and "populating" the MV database. FIM output is also populated. In this "inbound" phase, all seems to work correctly, but when export to FIM is started, the FIM database server gets high CPU usage (95 to 100%).

    This state occurs during all the export phase.

    We have tried to separate FIMService and FIMSynchronization databases on different servers, and the only one impacted is FIMService.

    Is it known issue or configuration mistake that may explain this problem ?

    BR,


    Emmanuel IT

    Monday, September 26, 2016 9:49 PM

All replies

  • In addition :

    - high CPU is on backend SQL Server 2012 R2 (real FIM app server stays with few load), with little decrease with cpu add (vcpu on VM) but still high and export is still long

    - using a thousand entries for test from a database

    * import from db takes 20 seconds

    * sync from db MA space to MV takes 12 seconds (including "fim outbound populating")

    * export to FIM take 10 minutes !!!

    - SQL Server has passed the BPA tests from Microsoft and no event log error

    FIM version : 4.1.3419.0

    BR,


    Emmanuel IT

    Monday, September 26, 2016 10:24 PM
  • FIM is installed with SharePoint 2013 SP1 and the first "load" of FIM app is very very long to. Seems that the SharePoint server (so that FIM ?) is almost very slow.

    Anyway to check the SP config or BP ? Actually the FIM web app and moreover SharePoint admin center are very slow, which is not very "normal" at all no ?


    Emmanuel IT

    Monday, September 26, 2016 10:35 PM
  • This is a complex area that would be tough to troubleshoot through the forums.  These kinds of problems are almost always a conversation, gathering data, and reviewing.  I will give you some general advice though and hopefully it will lead you to the problem area.

    1. The version of FIM you are on is over 3 years old and there have been updates in terms of performance that you will want to take advantage of.  See this page for latest FIM/MIM updates

    2. When you export to FIM Portal, you are writing to the DB which could be kicking off other activities. For example, creating a user object may place it in a dynamic-based group or a set which could kick off one or more workflows. Look at the request history to see what other things are going on within the Portal beyond just exporting/creating users.  Dynamic-based sets and groups, if you are using them, should be as simple as you can.  Avoid using NOTs as much as possible.  My rule of thumb is to keep dynamic sets and groups under 5 criteria or less.

    3. Since export is the problem, look at SQL performance and overall performance of that SQL server. 

    4. The FIM Export Performance Guide is a good reference to review.

    Hope that helps a little.

    Best,

    Jeff Ingalls

    Tuesday, September 27, 2016 2:56 AM