vManage Configuration DB slowness

 In NMS (vManage) releases 20.3.1, 20.3.2, 20.3.2.1, 20.4.1, some customers started experiencing slowness. The slowness was in the form of general user experience: Navigating through vManage pages was slow, GUI pages sometimes did not come up and timed out, and tasks submitted such as template push took significantly longer.

 

After investigation of why some customers were experiencing that, a resolution was identified where a vManage configuration-db setting change to be made. This setting change will become permanent in NMS (vManage) software 20.3.3, 20.4.1 IR, 20.5.1 and subsequent releases.

 

The setting change was made under CSCvw76649.

 

The change causes the query planner to use the ”slotted” runtime, which is different from the default runtime setting. It results in additional optimizations causing improvements to both the performance and memory usage of the query.

 

Given that slowness is a generic symptom, there is a need to identify whether this issue in the bug above is the needed remedy. To check, view the file /var/log/nms/query.log and check the planning phase duration. Example is "planning: 5000" which means that the planning took 5000 msec. Any query with planning phase taking around 5000 msec is considered very high. And the setting introduced in this change is appropriate.

 

The change is done by stopping app servers on all cluster instances, stopping config-dbs on all cluster instances, viewing the file /opt/web-app/etc/config_templates/neo4j.conf of all config-db instances, then adding the following at the end of the file: "unsupported.cypher.runtime=slotted". Then starting config-dbs. When checking the file /var/log/nms/debug.log on config-db instances, you should see the following string being printed out: “unsupported.cypher.runtime=slotted”. Finally, start app-servers.