none
Performance issues with FIM MAs RRS feed

  • Question

  • Hi,

    We are using FIM 2010 R2 version 4.1.3479.0.

    Been looking over threads and for performance issues and have not been able to work out why our instance of FIM has all of a sudden gone quite slow, particularly the AD MA. From a month ago the AD MA FIFS was about 20 mins to run and now it's over an hour. We've only added an extra 300 users to sync in that time, we are syncing about 22k users for the AD MA.

    As I write this the Full Import and Synchronization step is running at about an average 5 objects/s read rate.

    The FIM sync and the FIM service servers are both looking very unstressed as is the SQL server they are connected to.

    Have restarted the 2 FIM services and even the servers themselves.

    Question is if the performance of the sql and the OS looks ok, is there any way to pin point in the FIM app what could be slowing the MA's down? Something like perhaps a lot of fails and retries perhaps.

    Thanks!

    Monday, November 28, 2016 4:19 AM

All replies

  • My DBA ran a sql profiler on the fim DBs.

    Only thing that sticks out at present is the following on the FIM service DB, which we aren't sure what they are for:

    WAITFOR (RECEIVE message_body FROM [fim].[//Microsoft/ResourceManagement/Queue/NotificationReception]),

                    TIMEOUT @timeoutInMilliseconds; exec [fim].WaitForNotifications @timeoutInMilliseconds=29990

    and

    WAITFOR

        (

            RECEIVE TOP(1) message_body FROM [sync].[//Microsoft/ResourceManagement/Queue/ExportReception]

        ),

        TIMEOUT @timeoutInMilliseconds; exec [sync].ReceiveExportMessage @timeoutInMilliseconds=10000

    Also seeing long queries (~5 sec for 1 row) which seem to be taking longer than expected on the FIM sync db:

    select mms_timestamp from [mms_server_configuration]   update [mms_server_configuration] set [mms_timestamp_current] = 131248741121790000

    If anyone has any thoughts on the above would be great to hear, thanks!

    Tuesday, November 29, 2016 6:27 AM
  • Hi,

    The product left to its own devices will start to slow down if you don't perform three maintenance tasks:

    1. Periodically clearing the run history.  All things the same, the first thing I would look at is your Synchronization Service operational run history and make sure you have only a few weeks to a month of history.  Clear the rest.  Truth be told, the number of transactions (add, remove, deletes) each run step for each run determines how fast the database will grow, but the point here is not to let the DB continue to grow out of control.  Sometimes what happens is the database will hit its defined SQL size and the DB is configured to auto grow at a very small size (like 1MB at a time), so you will start seeing slow behavior as SQL keeps trying to slowly auto grow.

    2. Rebuild the full text indexes of the FIMService database

    3. Reindex the SynchronizationService database

    After that, I believe the trick to finding root cause is to try to rule out if the slowness has anything to do with FIMService.  For example, are you seeing the same slowness if you run just a delta import on the ADMA?  If so, that would tell me possible components could be:

    * domain controller

    * network between sync server and domain controller

    * the MA configuration (rule extension, join rule defined that is not indexed)

    * network connection to SQL (if the database is remote from the synchronization service)

    * the SQL configuration

    * disk writing to the FIMSynchronizationService database

    * hardware/hyper-v configuration

    There is not a silver bullet, quick tool for this kind of problem just like there's not one for PCs -- that truly work anyway.

    References:

    Clearing the run history

    Rebuild full text indexes on FIMService Database

    Reindex SynchronizationService Database

    Best,

    Jeff Ingalls

    Thursday, December 1, 2016 5:18 AM
  • Hi Jeff,

    Thanks for taking the time to reply.

    We think we are pretty ok on point one but will look at your other suggestions. If we get some success I'll report back.

    Wednesday, December 7, 2016 3:13 AM