DX Infrastructure Management

When selecting Actions-> 'Show Historical' alarms in USM, I get an out of memory error. Knowledge base solutions recommend increasing memory, installing a hotfix, etc. Which solution is recommended?

This is the error:

An unknown error has occurred.
Refreshing your browser may resolve the issue.

Details:
com.firehunter.ump.exceptions.DataFactoryException : null

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at reflectasm.java.lang.OutOfMemoryErrorConstructorAccess.newInstance(Unknown Source)
at com.esotericsoftware.kryo.Kryo$DefaultInstantiatorStrategy$1.newInstance(Kryo.java:1237)
at com.esotericsoftware.kryo.Kryo.newInstance(Kryo.java:1090)
at com.esotericsoftware.kryo.serializers.FieldSerializer.create(FieldSerializer.java:570)
at com.esotericsoftware.kryo.serializers.FieldSerializer.read(FieldSerializer.java:546)
at com.esotericsoftware.kryo.Kryo.readObjectOrNull(Kryo.java:730)
at com.ca.monitor.transport.kryo.KryoUnmarshaller.read(KryoUnmarshaller.java:37)
at com.ca.monitor.transport.kryo.KryoUnmarshaller.read(KryoUnmarshaller.java:28)
at com.ca.monitor.transport.kryo.KryoUnmarshaller.read(KryoUnmarshaller.java:17)
at com.ca.shift.client.RemoteInvocation.invoke(RemoteInvocation.java:79)
at serviceProxy$com.nimsoft.events.api.AlarmService.getClosedAlarms(Unknown Source)
at com.nimsoft.events.client.EmsClient.getClosedAlarmsFromService(EmsClient.java:99)
at com.nimsoft.events.client.EmsClient.getClosedAlarms(EmsClient.java:90)
at com.firehunter.usm.alarms.EmsAlarmProvider.getClosedAlarms(EmsAlarmProvider.java:175)
at com.firehunter.usm.AlarmUtils.getClosedAlarmsFromDb(AlarmUtils.java:408)
at com.firehunter.usm.AlarmUtils.getClosedAlarms(AlarmUtils.java:96)
at com.firehunter.usm.DataFactory.getClosedAlarms(DataFactory.java:994)
at com.firehunter.usm.DataFactory.getClosedAlarms(DataFactory.java:987)

This is a known limitation of fetching USM alarm history. When the history is called it will attempt to pull all the alarm data into memory. wasp has to be configured with enough memory.

Note that when a user clicks in USM to 'Show Historical' alarms its pulling the alarms from the nas_transaction_summary table.

Check the number of rows in the nas_transaction_summary table.

     select count(*) from nas_transaction_summary (which in this case showed approx. 275k rows)

Initially increasing the wasp memory to 12G did not resolve the issue.

We changed the wasp memory settings under startup to a min of 10G (10240) and a max of 12G (12228)
(max was already set but min was previously set to 2048)

We modified the nas transaction summary retention in the nas probe nis bridge to 45 (from the default of 90).

After changing it, the total rows in the nas_transaction_summary table was reduced to ~158k.

After wasp started up we then logged in to UMP and tested the response a number of times and it was now very fast to display all historical alarms for either a given node/device or all alarms for all groups.