Skip to content

runtime: instrument time spent in the scheduler #9112

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gopherbot opened this issue Nov 17, 2014 · 2 comments
Closed

runtime: instrument time spent in the scheduler #9112

gopherbot opened this issue Nov 17, 2014 · 2 comments
Milestone

Comments

@gopherbot
Copy link
Contributor

by yvesj@google.com:

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.
@ianlancetaylor
Copy link
Member

Comment 1:

Labels changed: added repo-main, release-go1.5.

@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014
@rsc rsc removed the repo-main label Apr 14, 2015
@rsc
Copy link
Contributor

rsc commented Jun 8, 2015

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.

@rsc rsc closed this as completed Jun 8, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants