Written by Thomas Speekenbrink
If you are running into problems where the Synchronizer uses a lot of CPU cycles (high CPU usage), follow this KB article.
- First of all stop the Synchronizer service
- Open the Synchronizer admin and go to the Options panel
As of version 3.2.19 there are some extra options and timers to set.
Option 1: Database mutation provider interval
Change the "Database mutation provider interval"
- By default it is set to 3 seconds
- Change this to 30 seconds
It means that the synchronization will take place every 30 seconds. Experiment with this value, for each environment is different.
Option 2: Database mutation provider inter-user interval
Change the setting "Database mutation provider inter-user interval"
- Change it to 5000 miliseconds
This means that the synchronizer will be idle for 5000 ms (5 seconds) in between the synchronization of each user.
Now restart the synchronizer and monitor the behaviour and CPU load. If improvements have been noticed, adjust the values, restart the service and try again.
When options #1 and #2 do not decrease your CPU load please use the following options:
Option 3: Move database intensive tasks to the house-keeping process
Move of database intensive tasks, like the synchronization of contacts, to the house-keeping process.
- Please tick the checkbox "Move database intensive tasks to the house-keeping process"
This House-keeping process runs each night at 02:00. This way intensive tasks like the synchronization of contacts will take place at a time of day when nobody is working in superOffice.
Note: with this option checked you will not have the event driven synchronization of contacts. Appointment synchronisation is not affected.
Option 4: update the SuperOffice Free Text Search table
Option 4 is the option to not update the SuperOffice Free Text Search table, as this might also be an CPU intensive task.
- Please check the option "Do not update the SuperOffice Free Text Search table"
Option 5: Check and change the Database Recovery Model
Preferably, this should be set to Simple mode. We often see that Full Recovery mode is chosen, but regular logfile backups are not performed, contributing to high CPU load. Also see point 6.
Option 6: Truncating and shrinking large SQL Transaction logfiles
Having large SQL Transaction logfiles contribute to high CPU Usage. Perform regular logfile backups when Full Recovery is chosen. If possible, truncate and shrink the SQL Transaction logfile.
Option 7: Truncating the Traveltransactionlog table
If SuperOffice is used very actively, then the TravelTransactionLog table will also be populated with a large number of records. When having millions of records, it will also affect the CPU usage.
Perform this simple SQL query to find out how many records exist in that table.
Please note: when using SuperOffice Travel functionality, please contact SuperOffice Support before truncating as this functionality might be affected.
Option 8: Create the following index
CREATE INDEX [ix_TRAVELTRANSACTIONLOG_type_tablenumber_traveltransactionlog_id_includes] ON [your database name].[crm7].[TRAVELTRANSACTIONLOG] ([type], [tablenumber], [traveltransactionlog_id]) INCLUDE ([ttime], [prev_record_id], [associate_id], [record_id])