mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-10-26 21:47:20 +00:00
rcourtman
2494930f04
On a long-running install the alert history projection was the largest part of the Go heap: 36 of 78 MB live on the dogfood install, one merged alert per occurrence for the event log's 90 days (#1803). Every read then deep-copied the whole projection before applying its limit, so the attention summary's 500-row read copied all 1,895 occurrences, and every Since read (the 30-day alert-quality window, date-filtered history) built a fresh projection and re-decoded every snapshot in its window. Each occurrence now keeps one small mark per folded event (time, id and the LastSeen it contributed) and the index of its latest acknowledged snapshot. A Since window starts at the first event the log's own occurred_at >= since text comparison admits, takes LastSeen and acknowledgement from there and orders occurrences by their first in-window event, so it equals a walk of only the window. Overlay, sort and limit run on lightweight rows under the projection lock, and only returned rows are copied, once, by canonicalizeAlertHistoryForOutput. On a log shaped like the dogfood install's (about 1,900 occurrences, 40k events), a 30-day read went from 68.9 ms and 19.8 MB allocated to 5.2 ms and 2.8 MB, a 500-row read from 12.7 ms and 8.5 MB to 3.6 ms and 2.0 MB, and a full read from 20.8 ms and 12.9 MB to 13.4 ms and 6.9 MB. A randomized test holds every window and limit equal to an independent walk of only the window, across acknowledgements on both sides of the boundary, uneven fractional seconds, same-instant events, a history clear and live overlays. Negative controls: ignoring the window, a fresh fold per Since read and copying every row each fail their test. Related to #1803