You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Can we add a runtime metric for the total CPU time spent inside the scheduler, or
alternatively the total wall time?
According to profiles, a large part of our server's CPU time is spent on the 'System'
section. But profiles are expensive so we can't leave them on all the time. They are
also sample based.
Go has expvars for the total time spent on go GC. It would be just as useful to find how
much time we're spending in the scheduler.
Ideally, we should have different metrics for 'cpu time' and 'wall time'.
'cpu time' would be more useful for our use case because we're trying to improve the raw
CPU cycles used by the server. But I'd guess that must be hard to implement.
In that case, a metric for the total time spend inside the scheduler (wall time) would
already be quite useful.
The text was updated successfully, but these errors were encountered:
You could find out how much time is spent in the scheduler using Linux's perf. I don't think it is very much. If you find evidence to the contrary, that would be interesting and maybe merit doing something here.
GC time is accounted because it is a quite significant fraction of overall runtime for many real programs, and it takes all the CPU for long periods of time (at least until Go 1.5). I am unaware of the same being true for the scheduler. The scheduler runs as lots of tiny operations separated by goroutine execution, so timing it could introduce significant overhead.
by yvesj@google.com:
The text was updated successfully, but these errors were encountered: