Please review the following to help determine why replication is occurring slowly, . See Optimization for tips and tricks on how to optimize replication.
Bulk Sharing Performance
Please check the following to troubleshoot when bulk sharing is running and taking longer to process than normal.
Check how many nodes are available on this instance. Each node will have 8 background workers so ideally you only want to use 50% of the scheduled workers for running bulk shares so the instance can continue to run its other background jobs optimally. For example, if you have 4 nodes, then you would have a total of 32 workers available and you only want to use 16 of those workers for bulk shares. If you create a Scheduled Bulk Share
and execute it, then all bulk shares in it will execute concurrently. So in the above example, you would only want to have 16 bulk shares in a scheduled bulk share as otherwise anything above will affect performance of the instance in general.
In Perspectium > Control and Configuration > Properties, check if “Do you want replicator to add display value fields (prefixed with 'dv_') for reference and choice fields ?” is set to true. With this setting true, processing will take longer since it requires going through each record and adding display value fields into the XML before it is sent.
Check if Share child class only
is selected on a table's bulk share configuration. If you select a table that has many children tables (such as cmdb_ci) and has millions of records, it will take longer to process the records since it has to do a join of the table and its children tables in order to get each record's full record. For example, if it queries cmdb_ci and finds a record that is cmdb_ci_computer, it will then join the parent table cmdb_ci along with cmdb_ci_hardware and cmdb_ci_computer to get the entire XML for this record and replicate that over. And it is recommended to have the “Share Child Class Only” option selected so it gets the full record; that is if you're sharing cmdb_ci and don't have the option it will share only cmdb_ci records which may be missing fields that the child table cmdb_ci_hardware or cmdb_ci_computer have.
Check if you are running multiple bulk shares against tables that have the same parent. If you have multiple bulk shares running and they are for tables that have the same parent (such as two bulk shares where one is for the incident table and the other is for the problem table which both have task as their parent table), this will cause it to run slower as these bulk shares could be thrashing the database as they both query the same tables.
Please check the following to troubleshoot when your ServiceNow instance is subscribing and receiving messages much slower than usual.
In Perspectium > Control and Configuration > Properties, check if “Enable debugging to generate more log” is set to true. With this setting true, processing will take longer since logging will occur as each record is being received. Generally you only want this setting to be true if you are trying to troubleshoot an issue as otherwise you should leave it as false.
Check if the Perspectium logging table (u_psp_log_message) is being rotated correctly. If it isn't being rotated correctly, then the logging table can get rather large, slowing down performance if you enable debugging since it will take longer to log to this table as each record is received. To verify the logging table is being rotated correctly, go to “Table Rotations” and verify if “initialized” is true:
Then open up the u_psp_log_message entry and verify there are entries in the “Table Rotation Schecdule” related list at the bottom. If there are no entries, click “Synchronize Shards” so entries appear: