What is the purpose of the records in the "cirelationbsg" table added in SM9.61?

The release notes indicate that a manual step is required to "Initialize CI relationship" which populates this table after upgrade, however its not clear to me how the data is used and what it provides versus the cirelationship table.

There are a large number of records which is starting to impact performance when deleting CIs and relationships.

  • Suggested Answer

    The cirelationship table contains direct relationships of an CI to others. CIs and relationships are spanning a graph.

     

    In some formats, where the CI is input by user, the "Fill" button should present relavent candidates - that are for examples CIs closely, while not necessarily direct, related to the affected business service.

     

     

    This fill in pre SM 9.60 system is build on the fly from the cirelationship records: Because these contains only direct relationships, the script has to select multiple times and compile a list of candidats. As the link record requires a query, it then builds a query:

     

        logical.name isin {<long list of CI identifiers"}.

     

    This method is taking a lot of time. The response time of the system to the user is not good.

     

     

    The idea behind the solution implemented in SM 9.60 is: If we have a table containing for each two CI's one of the shortest paths - direct or indirect relationships - then link response comes down to a single Select operation against this table.

     

    If you are looking for each CI with a path to a given CI not longer as 4 relationships, then the query against cirelationbsg will be:

     

    parent=<CI> and level<=4

     

    This approach effectively reduces the response time to the user and prevents SM from generating these extremely long query strings.

     

    But there is a downsize: Like any index, this table has to be created, filled and updated when CIs and relationships are added/updated/deleted.

    For creation, a script needs to be executed manually: it cleans up cirelationbsg, and then calculates in memory the shortest distances using Dijkstra algorithm. Then it will write the cirelationbsg records. When the number of CIs is huge, this matrix can become very large and the processing will take a while.

    This takes time when this update happens: It is not only about inserting or deleting an existing record, but other records in cirelationbsg dbdict may need to be updated depending on if the new relationship allows a shorter path or a deleted relation causes the need for a work around.

     

    In order to prevent foreground or integration sessions to be affected by this time to update cirelationbsg tables, SM 9.70 uses a background process called "configuration" and a task queue dbdict called "cirelationbsgtask": So at time of updating a relationship, a record is written into cirelationbsgtask. The background scheduler will look for these tasks every  minute and apply the required changes into the cirelationbsg file.

    As the “configuration” scheduler consumes a lot of javascript heap, starting this process from sm.cfg file as separate SM process is helpful, when your system contains a large number of CIs and relations. Then the JS heap size can be increased specifically for this processes.

    The JS heap max size is controlled  by parm "jsgctrigger" which is in bytes. By default in SM 9.70 it is 48 MB.