stzPerfProfile

(sans commentaire dans la source : le nom se lit comme une phrase) initaucune extension

Re-anchor: the next answers cover a fresh interval from NOW. The timer's exact lifetime sum/count are anchored too, so the interval's mean R and the interval's D describe THE SAME requests -- mixing a lifetime R with an interval D would make the computing/waiting split compare different populations.aucune extension

(sans commentaire dans la source : le nom se lit comme une phrase) monitor qaucune extension

The interval factsaucune extension

Requests completed since the anchor.aucune extension

X -- requests per second over the interval.aucune extension

CPU actually consumed over the interval, in ms (all threads).aucune extension

U -- the fraction of the MACHINE this process used.aucune extension

D -- the diagnostic number: CPU-ms each request consumed. 0 when no requests crossed the interval (nothing to attribute).aucune extension

Where this machine saturates IF CPU is the constraint (req/s).aucune extension

The demand signal for elastic scaling (perf P6): how close this workload is to its CPU ceiling, X/Xmax in 0..1. This is what stzClusterSupervisor.ReportLoad() always wanted -- MEASURED, not hand-fed: FeedLoadFrom(tag, oProfile) closes the loop. 0 when nothing is measurable yet (no requests / no demand). (Named LoadRatio: `load` is a Haro keyword.)aucune extension

1 - X/Xmax: how much of the CPU ceiling remains (0..1).aucune extension

The self-checks ------------------------------------------ The utilization law, checked for real: anchor-computed U vs the monitor's independently SAMPLED utilization gauge. From one set of anchors U = X*D/cores is an identity (no information); two independent measurements agreeing is evidence the measurement itself is sound. Returns [ :computed, :sampled, :consistent, :message ]; sampled = -1 when the gauge is not watched/sampled.aucune extension

N -- the average requests in flight IMPLIED by Little's law (X * mean R). What you should see if you counted concurrency.aucune extension

Compare the implied N with a concurrency you MEASURED elsewhere (e.g. a worker pool's InFlight()). Same-scale consistency: within a factor of 3 (floored at 0.05 -- tiny numbers agree).aucune extension

R, and the computing/waiting split ----------------------- Mean R over THE INTERVAL (exact: the timer's anchored sum/count deltas) -- the same requests D is computed over. Percentile methods answer over the timer's retained window (stated in Explain); the mean is the interval's own.aucune extension

(sans commentaire dans la source : le nom se lit comme une phrase) response time p50aucune extension

(sans commentaire dans la source : le nom se lit comme une phrase) response time p95aucune extension

(sans commentaire dans la source : le nom se lit comme une phrase) response time p99aucune extension

Of each request's R, the part that was NOT computation: waiting on IO, locks, sleeps, the queue. R - D, floored at 0.aucune extension

The first question of every investigation -- busy or blocked? -- answered with the split: a request's time goes to CPU (D) or to waiting (R - D); the larger share names the constraint.aucune extension

Memory: trend and forecast ------------------------------- Bytes per hour the rss gauge is trending (needs WatchMemory + samples). Positive = growing: the slow-leak number.aucune extension

At the current trend, hours until rss reaches pnCeilingBytes. 0 = already at/past the ceiling; -1 = not growing (never, at this trend).aucune extension

The R-vs-X curve ----------------------------------------- Record one (X, R) point for the CURRENT interval -- drive different load levels and Snapshot() after each; Curve() shows where response time turns as throughput climbs.aucune extension

[ [ atMs, X, U, D, Rp95 ], ... ] in recording order.aucune extension

The narrated analysisaucune extension

(sans commentaire dans la source : le nom se lit comme une phrase) showaucune extension