Continuous profiling
A profile every few minutes, and a capture whenever CPU spikes.
Continuous profiling
A profile you capture by hand shows the moment you pressed the button. Continuous profiling keeps one of every few minutes, so when something was slow at 03:12 there is a profile from 03:10 to read, and when CPU spikes, a profile is captured while it lasts.
Both are off until you switch them on, per Service, in the Continuous profiling section of its Performance tab.
Profile continuously
Capture 10 seconds of CPU every 10 minutes and keep a day of them. Both numbers can be changed:
| Setting | Choices |
|---|---|
| Each capture | 10 or 20 seconds |
| How often | Every 5, 10, 15 or 30 minutes |
The form says how much of the time that samples, for example "Sampling runs 2% of the time", at about 1% of one CPU while it does. Nothing is restarted.
The first capture runs within a minute of saving. Continuous captures always answer What is using the CPU. They are kept for 24 hours, then removed, and they do not fill your list of past profiles.
If the server is already capturing something else when one is due, that capture is skipped, not queued; the next minute tries again.
Capture on a CPU spike
When CPU reaches 80% of one CPU, capture 15 seconds and tell me what it found. The threshold can be set from 30% to 400%; above 100% means more than one core.
- CPU is read once a minute, the same reading Live usage shows.
- Past the threshold, a 15 second CPU capture starts while the spike is still happening.
- When it finishes, the Workspace owner gets an alert in the inbox, and by email when email is set up, for example:
CPU spike on billing: profile captured billing reached 96% CPU, above the 80% threshold, so SlideOps captured a CPU profile while it lasted. Over 15 seconds, 73% of the CPU time was in serialize_orders.
- At most one spike capture every 30 minutes, so a long spike does not capture over and over.
Spike profiles are kept like profiles you capture by hand, and are marked Spike in every list.
The timeline
Once either is on, the section shows the last day as a bar chart: one bar per capture, its height the CPU cores the Service kept busy during it. A value of 1.0 is one core busy the whole time. Spike captures are red. Hover a bar for its time and its one-sentence answer; click it to open its flame graph.
A stretch of time as one flame graph
Open as one flame graph: Last hour, Last 6 hours, Last 24 hours adds every continuous and spike capture in that stretch into a single flame graph. The answer then reads, for example, "Across 6 captures, totalling 60 seconds, 62% of the CPU time was in build_report."
This is the clearest picture of what a Service spends its time on in general, rather than in one moment, and everything in Reading a flame graph applies to it.
Who can change it
Viewers can see the settings and the timeline. Switching either on or off, or changing them, needs a role above Viewer, and every change is recorded in the audit trail, because both run the profiler on your server without anyone pressing a button each time.