With Service Mapping in larger organisations, there can be lots of maps with lots of recomputation. Over time without the right settings applied these can contribute to a large amount of disk space being used on the instance, and the recomputation, and reaper jobs taking a long time to complete.
There are many options to configure and consider around the size.
- How many and how long to keep those checkpoints - those little 'pins' at the top of the map that indicates so in a Configuration item associated in the map or a topology change in the map. The default is 10,000 checkpoints to keep and a 3 month interval. These are stored in: svc_model_checkpoint table
- The larger of the tables is the 'svc_model_obj_service' table, which a Blob object storing all the goodness of the map, all the elements, relationships, paths and impact rules when it comes to Event Management. The default retention period is 30 days which is ideal.
The two tables are linked and contribute to the sizes of each other, as well as how long the Reaper jobs run every weekend. A bit more about how it all hangs together below.
From a standard operating procedure for a Service Mapping administrator, you may want to keep a track of the following, perhaps in a Performance Analytics indicator or similar:
- svc_layer - how many records have 'recomputation needed' to determine the backlog and impact on performance of the instance
- How long the 'Checkpoint Reaper' and 'Service Model Object Blob Reaper' jobs take over the weekend, as well as the size trajectory of the tables 'svc_model_checkpoint' and 'svc_model_obj_service' mentioned above.
