/
Go back in Time using Pulse

Go back in Time using Pulse

 

  1. Identify the problematic thread(s)

    • Use Pulse’s historical views/logs to:

      • Find the time window of the issue.

      • Locate thread(s) with very long duration, high CPU, or “cancelling” state.

  2. Check what the thread was doing

    • From Pulse history, review:

      • User

      • Process / cube / view

      • Action type (TI process, query, Excel report, etc.)

    • This helps you understand why the operation was long-running.

  3. Check how cancellation behaved

    • Look for:

      • When a cancel request was issued (from Pulse or TM1Top).

      • How long the thread stayed in “cancelling”.

    • If the thread:

      • Eventually finished → cancellation worked, but was delayed by long internal work.

      • Stayed stuck for an extremely long time → it likely never hit a safe cancellation point before you restarted TM1.

  4. Decide the operational response (for future similar cases)

    • Preferred:

      • Request cancellation via Pulse or TM1Top.

      • Monitor in Pulse to see if CPU/elapsed time drops and the thread exits.

    • If it stays non‑responsive “forever”:

      • Plan a controlled TM1 restart (maintenance window, notify users).

      • Treat restart as last resort because it affects the whole server.

  5. Feed findings into your runbook

    • Document patterns you observe, for example:

      • Which processes or reports frequently cause long‑running or uncancellable threads.

      • Time-of-day or user patterns.

    • Use this to optimize problem TIs/queries

  6. Use OpenSearch (Pulse Explorer) to check performance

    • Select the incident time window in OpenSearch Discover (e.g., last 15–60 min around the slowdown).

    • Filter by environment/server to scope results (e.g., host.name:"TM1-PRD-APP01" or tags.environment:"prod").

    • Slow queries: message:("long running" OR "elapsed" OR "slow") AND app:pulse

    • Long threads: fields.threadDurationMs:>60000 OR message:"Cancelling"

    • High CPU: fields.cpuPct:>80 OR message:("high cpu" OR "busy")

    • Memory/GC: fields.heapUsedPct:>85 OR message:("OutOfMemory" OR "GC overhead")

    • Correlate with TM1 events: align timestamps with TI runs, chores, or user actions from Pulse Explorer.

    • Document findings: note time window, filters, top queries, impacted users/objects, and next actions.