Analytics Center takes too long to generate visualization given high amount of data on instance - Known Error

Analytics Center takes too long to generate visualization given high amount of data on instance Description When using the Analytics Center's Q&A functionality, it can be the case that requests are taking rather long. This can be due to instance performance bottlenecks or having many records in the related Performance Analytics tables.

The workaround makes use of enabling a cache, that changes it such that the result of parsing these tables' schemas, is cached for future use. This can decrease the time it takes for Analytics Center's Q&A to give a result significantly, however, there is a drawback to using this property. Until the defect is fixed, requests made on the very first time will still take long , as the cache needs to be populated with the necessary information.

Steps to Reproduce

1. Log into a ServiceNow instance with a lot of Performance Analytics meta data, in particular, many breakdown relation mappings (between breakdown elements and records) 2. Go to the Analytics Center 3. Type in an utterance question such as "Number of open incidents in the last 60 days" 4. Wait for result

Expected : The answer comes back in a reasonable amount of time Actual : The answer comes back within often, 2 min or longer. Even a minute seems to be excessive; Or the instance node goes out of memory (you will see error logs such as the following)

AProcessor SEVERE *** ERROR *** Exception while executing request: Java heap space com.glide.rest.util.RESTRuntimeException: Exception while executing request: Java heap space at com.glide.rest.handler.impl.ServiceHandlerImpl.handleInvocationTargetException(ServiceHandlerImpl.java:76) at com.glide.rest.handler.impl.ServiceHandlerImpl.invokeService(ServiceHandlerImpl.java:49) at com.glide.rest.processors.RESTAPIProcessor.invokeService(RESTAPIProcessor.java:420) at com.glide.rest.processors.RESTAPIProcessor.processInternal(RESTAPIProcessor.java:406) at com.glide.rest.processors.RESTAPIProcessor.process(RESTAPIProcessor.java:391) at com.glide.processors.AProcessor.runProcessor(AProcessor.java:785) at com.glide.processors.AProcessor.processTransaction(AProcessor.java:328) at com.glide.processors.ProcessorRegistry.process0(ProcessorRegistry.java:187) at com.glide.processors.ProcessorRegistry.process(ProcessorRegistry.java:175) at com.glide.ui.GlideServletTransaction.process(GlideServletTransaction.java:58) at com.glide.sys.Transaction.run(Transaction.java:2998) at com.glide.ui.HTTPTransaction.run(HTTPTransaction.java:34) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:840) Caused by: java.lang.OutOfMemoryError: Java heap space at java.base/java.util.Arrays.copyOfRange(Arrays.java:3822) at java.base/java.lang.StringUTF16.newString(StringUTF16.java:1179) at java.base/java.lang.StringBuilder.toString(StringBuilder.java:454) at com.fasterxml.jackson.core.util.TextBuffer.contentsAsString(TextBuffer.java:505) at com.fasterxml.jackson.core.io.SegmentedStringWriter.getAndClear(SegmentedStringWriter.java:114) at com.fasterxml.jackson.databind.ObjectMapper.writeValueAsString(ObjectMapper.java:4041) at com.snc.par.nlq.pa.PAMetadataGenerator.getMetadata(PAMetadataGenerator.java:107) at com.snc.par.nlq.pa.PAMetadataFetcher.fetch(PAMetadataFetcher.java:92) at com.snc.par.nlq.visualization.service.PAVisualizationService.process(PAVisualizationService.java:103) at com.snc.par.nlq.visualization.processor.AnalyticsCenterVisualizationProcessor.process(AnalyticsCenterVisualizationProcessor.java:35) at com.snc.par.nlq.rest.NLQVisualizationConfigProvider.getVisualizationConfigurations(NLQVisualizationConfigProvider.java:22) at com.snc.par.nlq.rest.NLQVisualizationResource.getVisualizationConfigurations(NLQVisualizationResource.java:67) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:569) at com.glide.rest.handler.impl.ServiceHandlerImpl.invokeService(ServiceHandlerImpl.java:44) Workaround Workaround without the fix for this defect in place (Xanadu and before): Navigate to system properties Edit/Insert the property com.snc.par.nlq.pa.metadata.use_cache and set its value to true Workaround/adjustments with the fix for this defect in place (Yokohama and after): This is known to be a huge performance burden when the breakdown elements exponentially increase the size of the payload that stays in the instance's memory. Please set the property, com.snc.par.nlq.max_breakdown_elements_from_none_sys_choice_tables to 100 or lower (without this system property the default value is 256), in order to make the request stable. Further modifications to the property, after a successful request, require you to:

Run cache.do Evict the entries in the sys_analytics_schema_cache table, by setting evict=true for all records (there are only a few per language). Rerun the request as desired, to re-generate the cache contained within sys_analytics_schema_cache Related Problem: PRB1795659