Missing Statistics in Pulse?

Hi there,

What is the logic of logging cube memory statistics in Pulse? It appears the logging didn’t happen everyday, and customer was questioning on the logic.



Is there any logic of logging these statistics?

Hi @twong,

Does it happen often or did it occur only once?

Pulse updates the Cube Statistics when it runs the update documentation. By default, the update documentation happens at 1:45 am every day.

In the instance settings you can first check if all days are included:

If the cube statistics are missing, it could mean that Pulse was not able to connect to the TM1 instance at this time.



Hi Vincent,

What could be the reason of not connecting to TM1 instance?

It has been configured for all days, and it only capture when it “feels like”, appears to be, which is not logical.



Hi @twong,

Computers don’t have feelings so Pulse definitely doesn’t do it when it feels like! The statistics are updated every time the full documentation is run and when rules are changed.

To get the statistics Pulse does the following:

  1. Turns on Performance Monitor by the TM1 API
  2. Waits until the next minute ticks over (plus 5 seconds) on the system clock. (TM1 updates the stats every time a new minute starts when Performance Monitor is on)
  3. Extracts the contents from the stats cubes

It is possible that the stats are taking longer to update that 5 seconds, you could test this out yourself by turning it on manually and then checking }StatsByCube.

Hi @tryan,

This is what has been configured on Pulse, which in theory, every 3 hours, a full documentaiton would be executed, but still no statistic going in.


Hi @twong

The Documentation Update Time is a time not a frequency, in your case the documentation will run every day at 3:00 am and not every 3 hours. You can see the definition under the days (The time and days when the full document process is run):

Hi @twong,

I think setting it to 3.00 AM might be the issue here.

When the Performance Monitor is on, every hour, on the hour (as in exactly at X o’clock) it will run a background task to update its metadata and thus acquiring a metadata lock on the server (and possibly a read lock on the }Stats* objects).

From my experience, this background task can take up to 2-3 minutes to complete on large models - the task itself is invisible in TM1Top/Pulse, but you can see other tasks waiting for it.

Anyway, when this happens I suspect that Pulse might not “feel like” waiting that long and then fails to update the statistics.

Perhaps try setting the update time to 2:58 AM and see if it helps.