godoc in Go 1.2: too many processes

[Peter Kleiweg]

With Go 1.2, when I run godoc as a web server, at start up, my processor load jumps up to 60 or more.

This is... annoying.

It also starts up much slower than the version with Go 1.1.

What's is going wrong?

[Jan Mercl]

Are you using the full index flag? If so it might the culprit. In any case, godoc must initially scan the whole stdlib and GOPATH trees which must show some CPU load burst.

-j

[Peter Kleiweg]

Op zondag 17 november 2013 17:51:59 UTC+1 schreef Jan Mercl:

Are you using the full index flag? If so it might the culprit. In any case, godoc must initially scan the whole stdlib and GOPATH trees which must show some CPU load burst

I don't use the index option. 

[Dave Cheney]

What is the command line you are using to invoke godoc?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Peter Kleiweg]

go version go1.2rc3 linux/amd64

Op zondag 17 november 2013 19:59:54 UTC+1 schreef Dave Cheney:

What is the command line you are using to invoke godoc?

godoc -http=:6060  &

 

[minux]

How many processor cores do you have? How large is your $GOPATH?

Have you tried to empty GOPATH before starting godoc?

GOPATH= godoc -http=:6060

Does it make a difference on system load? 

[Andrew Gerrand]

I am unable to reproduce this with go1.2rc4:

curl https://go.googlecode.com/files/go1.2rc4.darwin-amd64-osx10.8.tar.gz | tar xz

cd go/bin

./godoc -http=localhost:6060

And checking the CPU usage in top, godoc uses around 40-60% of a core for a few seconds then goes down to ~0%.

Please check that you are not using an old version of godoc. Check your GOPATH's bin directory, if that appear before $GOROOT/bin in your PATH.

Andrew

[Peter Kleiweg]

Op maandag 18 november 2013 01:56:28 UTC+1 schreef Andrew Gerrand:

I updated to  go1.2rc4, reinstalled all additional packages, I set GOMAXPROCS=4 (exported), godoc is up to date

With GOPATH unset, godoc with -http jumps load to 18

With GOPATH set, the load jumps to 60.

Why doesn't setting GOMAXPROCS solve the problem? It looks like the value is ignored, and godoc uses tens of system threads instead of just 4.

Is the problem in godoc or in go?

go version go1.2rc4 linux/amd64

I have 2 processors

[DisposaBoy]

unless I misunderstood something .. GOMAXPROCS is a limit on the number if active threads, not the total number of threads

[Peter Kleiweg]

Any news on this?

If the cause is a change in godoc, I can live with it, though it is annoying.

If it is because of a change in Go 1.2, then there is a serious problem.

[Brad Fitzpatrick]

No news on this.

We made godoc more parallel in recent months so it will start up and finish indexing quicker rather than dragging on for a long time.  Maybe you see more CPU usage up front now, but it's just while it's indexing the world.  You can disable indexing.

--

[Peter Kleiweg]

Op donderdag 21 november 2013 18:39:56 UTC+1 schreef bradfitz:

No news on this.

We made godoc more parallel in recent months so it will start up and finish indexing quicker rather than dragging on for a long time.  Maybe you see more CPU usage up front now, but it's just while it's indexing the world.  You can disable indexing.

If you mean the option -index, I keep that off. With -index on, it quickly runs out of memory. I have only 3.8 Gb.

It is this the ordinary start-up without indexing that seems to spawn many tens of threads, bringing most other processes to a crawl.

[Andrew Gerrand]

This is really weird, and I am unable to reproduce it at all.

Are you sure you are using the new godoc binary?

Try "which godoc".

--

[Dave Cheney]

Hi Peter,

I wonder if your godoc is scanning more than you expect. How large is your $GOPATH/src ? Does it contain symlinks elsewhere? Does it contain lots of non go source? Is your GOPATH on a network volume ?

Could you please start godoc, wait til you think it has reached a crescendo of load then hit the process with cntl-\ (or SIGQUIT) and make the full stack dump available. It should be pretty easy to figure out what is going on from that. 

[Andrew Gerrand]

On 22 November 2013 10:38, Dave Cheney <da...@cheney.net> wrote:

I wonder if your godoc is scanning more than you expect. How large is your $GOPATH/src ? Does it contain symlinks elsewhere? Does it contain lots of non go source? Is your GOPATH on a network volume ?

Could you please start godoc, wait til you think it has reached a crescendo of load then hit the process with cntl-\ (or SIGQUIT) and make the full stack dump available. It should be pretty easy to figure out what is going on from that. 

This is a red herring. I have a huge GOPATH and godoc scans the whole tree in a few seconds. My main suspicion is that Peter has an old broken version of godoc in his PATH that had indexes on always (there was one such version a couple of months ago).

[Brad Fitzpatrick]

No, I can reproduce.

With a warm cache, godoc -http starts up in under a half second with no GOPATH, and only uses 5 threads.

But if you drop your cache,

$ sudo bash -c 'sync && echo 1 > /proc/sys/vm/drop_caches'

Then it takes 9 seconds and uses 322 threads on this machine, and the desktop gets quite laggy.  (but then again: we just dropped all the caches).

With a large GOPATH (like I have), it's even worse.

So yes, it's a problem I guess.

The indexing doesn't matter.  This is in dirtrees.go treeBuilder.newDirTree, called via Corpus.newDirectory via Corpus.initFSTree via Corpus.Init.

[Dave Cheney]

And it 322 threads because you have 322 directories, each of which has
a goroutine stuck in Read (or ReadDir)

[Brad Fitzpatrick]

Which seems kinda sane to me, but maybe we need a safety cap.  This fixes it:

https://codereview.appspot.com/30620043

But not for Go 1.2.

[Andrew Gerrand]

I stand corrected. I guess my SSD is just fast :-)

[Dmitry Vyukov]

"Async" file IO was raised several times before, and I've got several
questions about it on Moscow users meetups.
There is no reason we can't do the same as in net package, and consume
only 1 goroutine per outstanding file IO request.
It's time to at least file an issue:
https://code.google.com/p/go/issues/detail?id=6817