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

runtime: threadcreate profile is broken #6104

Open
dvyukov opened this Issue Aug 11, 2013 · 10 comments

Comments

Projects
None yet
5 participants
@dvyukov
Member

dvyukov commented Aug 11, 2013

With the new scheduler threadcreate profile is broken. Most of the threads are created
by sysmon thread, which stack is not very informative.
We need to either remove the profile, or capture stack of the blocking cgo/syscall that
caused new thread creation.
@rsc

This comment has been minimized.

Contributor

rsc commented Aug 13, 2013

Comment 1:

It would be nice to capture a useful stack but it may be okay to remove it
too. I can't remember ever using it.
@dvyukov

This comment has been minimized.

Member

dvyukov commented Aug 13, 2013

Comment 2:

What is a "useful stack"?
I've attached threadcreate profile from HTTP server FTR.
Lots of threads are created by sysmon (not useful).
Timerproc created 3 threads (not useful).
Creation of random goroutines caused thread creation up to GOMAXPROCS (not useful).
I can imagine an end user trying to figure out what threadcreate profile is trying to
say...
It must be centered around blocking syscalls and locked threads. But which exactly?
Probably all, because they all can trigger thread creation. It all needs to be rethought
and probably even renamed.
Probably now it's better to just remove it.

Attachments:

  1. threadcreate.txt (5407 bytes)
@rsc

This comment has been minimized.

Contributor

rsc commented Aug 13, 2013

Comment 3:

The idea was that if, for example, your program was creating 1000s of
threads because they kept getting blocked on cgo DNS lookups, you'd see the
cgo DNS call in the profile sample, because it is what blocked and
triggered the creation of a new thread.
@robpike

This comment has been minimized.

Contributor

robpike commented Aug 30, 2013

Comment 4:

Not for 1.2.

Labels changed: removed go1.2maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Nov 27, 2013

Comment 5:

Labels changed: added go1.3maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Nov 27, 2013

Comment 6:

Labels changed: removed feature.

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 7:

Labels changed: added release-none, removed go1.3maybe.

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 8:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@pradeepsawlani

This comment has been minimized.

pradeepsawlani commented Jun 26, 2017

Im currently debugging kubelet binary (too many threads) and need to get stack dump for the cause. Is threadcreate profile known to dump correct stack with golang 1.8 (go version go1.8.1.typealias linux/amd64) ? I tested out with simple cgo wrapper (C.sleep(100)) and currently threadcreate profile shows number of threads create but no stack dump.

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Jun 26, 2017

@pradeepsawlani To get help using Go please send use a forum, don't comment on an old issue. See https://golang.org/wiki/Questions . Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment