Everything on this page traces to a Pulse MCP call. The instance is idle with no waits, but server memory has risen about 555 MB a day for three weeks and the growth is not coming from TM1. Saturday should bring showers around the 11:00 data loads, a squall at 21:30 and a short storm during the 00:30 backup. By Wednesday the nightly memory peak is on course to pass 95% of RAM.
11 threads: 1 running (Pulse's own poll), 10 idle.
107,138 MB in use. The FPM instance holds 79,221 MB.
Daily average 30–36% this week.
20,970 MB of 204,015 MB. D: has 70,899 MB free.
}bedrock.chore.execution.check quits via ChoreQuit() every 5 minutes.
Sky colour follows the nightly memory peak as a share of RAM: showers below 94%, heavy showers from 94%, storm from about 95%. Alerts are the average for that weekday over the last three weeks. Confidence falls with distance.
Up about 555 MB a day.
Lands at the nightly backup, 00:40 Paris.
Nearly flat, about +36 MB a day.
Saturday average over the last 3 weeks.
Select a bar or a table row to see its run history, the thread evidence and what to change.
| Paris | UTC | Forecast | What drives it | Confidence |
|---|---|---|---|---|
| 06:31 → | 04:31 → | Drizzle | Error-log alerts (TM1ProcessError files found) after the 04:31, 13:5x, 14:0x, 16:01, 18:01 and 19:01 UTC chores. They fired on 16 of the last 21 days, 7 to 9 a day, but stopped on 25–27 Sep and on 1 Oct. | Medium |
| 11:00–11:13 | 09:00 | Showers | EO.Data Load.BE (avg 739 s) starts in the same minute as CUR.Load currency rates (avg 659 s). A wait alert over 100 s fired at 09:01–09:07 UTC on 21 of the last 21 days. | High |
| 14:00–14:35 | 12:00 | Clear | FIN.General Ledger Rountrip (avg 2,089 s). Server memory reached 116,459 MB in this window on 28 Sep. One wait alert in 21 days (24 Sep). | Medium |
| 15:00–16:05 | 13:00 | Light showers | MAV.Load Timesheets v2 (avg 3,847 s) overlaps TIM.Timesheets Load Fullv2 at 14:00 UTC. A wait alert around 14:0x UTC on 8 of 21 days, 1 of the last 3 Saturdays. | Low–medium |
| 21:00–21:35 | 19:00 | Clear | MAV.Load Allocations (avg 2,012 s). The MAV.SQL.Metadata Refresh steps failed with codes 9 and 7 on 30 Sep. | Medium |
| 21:30–21:40 | 19:30 | Squall | APQ.Dim.ControlObjects.Copy runs while Allocations is still loading. Wait alert on 13 of 21 days, 2 of the last 3 Saturdays. | Medium–high |
| 00:30–01:00 | 22:30 | Storm | APQ.Server.Backup (avg 1,727 s). Server CPU averaged 94–100% around 22:40 UTC, and the day's memory peak landed there on 29 Sep, 30 Sep and 1 Oct. | High |
Daily average and maximum, 11 Sep to 1 Oct, then the 3–9 Oct estimate (open points). The maximum line crosses 95% of RAM around 7 Oct.
Daily average. The FPM instance grew about 36 MB a day; the rest of the server about 520 MB a day.
Instance alerts, 11 Sep to 1 Oct. Error-log alerts fired 7–9 a day until 24 Sep, then only on 28–30 Sep.
Memory used outside the FPM instance went from 18,617 MB on 11 Sep to 28,989 MB on 1 Oct, about 520 MB a day. If the rise stays linear, the nightly peak passes 95% of RAM around 7 Oct and reaches total RAM around 19 Oct. Pulse doesn't show which process it is.high impact · low effort · check on the server itself (Task Manager or Resource Monitor)
Only 10% is free. One snapshot gives no trend, so there is no forecast for when it fills. Look for logs, dumps or backup copies first.high impact · low effort · needs whoever administers PRDTM101
EO.Data Load.BE and CUR.Load currency rates start in the same minute and a wait alert fires every day. Moving one by 15 minutes should clear the 11:00 showers.medium impact · low effort · chore schedule change in TM1
The MAV.SQL.Metadata Refresh failures on 30 Sep point at the SQL source. Confirm whether Saturday's 21:00 run errors again.medium impact · low effort · TM1ProcessError files in the server's log folder
Every figure on this page comes from one of the calls below, or from arithmetic on their results. No call changes anything in Pulse or TM1.
get_version (Pulse 8.0.1) and get_server_state to confirm the triple: Pulse environment PRDTM101, service workforce_and_fpm, TM1 server Workforce_and_FPM. This also showed a stopped duplicate service with the same TM1 server name. The current-conditions panel is this snapshot: memory, CPU, drives, thread list and the latest message log.feeds: current conditions
get_performance_server and get_performance_instance for 11–24 Sep and 25 Sep–2 Oct. The window is split in two because a single call over the full range timed out. Together they give daily average and maximum memory, CPU, threads and operations, the top consumption windows, and 209 instance alerts (76 wait-time, 133 error-log).feeds: pressure trends, 7-day outlook, alert counts
get_process_history (type TM1.Chore) lists the chores with their average run times. Then one search_process_history call per key chore, 11 Sep – 2 Oct, within the 31-day limit, returns each run's start, end and result. That is 21 runs each for nine chores. The complete history is logged under the duplicate service, so it was read from there.feeds: hour-by-hour timeline, run-time charts
list_system_alerts returns the seven alert definitions on this environment: Disk free, Memory, Error log, Server log (two), Shutdown and Wait time. The alert text gives the 100-second wait threshold used in the overlap charts.feeds: thresholds, what counts as a shower
Each alert timestamp is matched to the chore running at that minute. Wait-time alerts carry a thread snapshot (who is running, who is waiting, WaitingOn thread ID), which names the blocker. Overlap is the earlier chore's end time minus the later chore's start time, per day. This is how the 21:30 squall was tied to MAV.Load Allocations on 13 of 13 alert days.feeds: what drives it, thread evidence, what to change
Memory and CPU: a least-squares straight line over the 21 full days 11 Sep – 1 Oct, extended seven days. Percentages use total RAM derived from the snapshot (107,138 MB at 82%, about 130,656 MB). Alerts: how often the same alert fired on that weekday over three weeks. Tomorrow's timeline places each chore at its scheduled time with its average run time. Confidence drops with distance and with how irregular the pattern was.feeds: tomorrow and 7-day outlook, all marked ESTIMATE
All forecast figures are estimates. Memory and CPU use a least-squares line over the 21 full days 11 Sep to 1 Oct (the partial 2 Oct is excluded) and assume the trend continues unchanged; a restart, a cleanup or a new load would break it. Total RAM of about 130,656 MB is derived from 107,138 MB at 82%, so percentages are approximate. Alert forecasts repeat how often the same alert fired on that weekday over three weeks, which is only three samples per weekday. Chore history holds only 2–3 runs per daily chore, so weekday-only schedules can't be confirmed. Pulse also files some of this instance's log lines under a stopped duplicate service that shares the same TM1 server name.