Goroutines slowly creeping up

70 views
Skip to first unread message

sc28

unread,
Jun 15, 2015, 7:09:46 PM6/15/15
to mgo-...@googlegroups.com
I have a webserver running, and noticed that the number of goroutines associated with mgo seems to be creeping up every few days - just want to verify if this is as expected - from debug/pprof goroutine dump, I see these goroutines associated with mgo:


6 @ 0x4f0455 0x4ecd10 0x4ec1a8 0x6e0c67 0x6e0cd3 0x6e298f 0x6f509c 0x68bd65 0x68bf86 0x502da1
#	0x6e0c67	net.(*pollDesc).Wait+0x47			/usr/local/go/src/net/fd_poll_runtime.go:84
#	0x6e0cd3	net.(*pollDesc).WaitRead+0x43			/usr/local/go/src/net/fd_poll_runtime.go:89
#	0x6e298f	net.(*netFD).Read+0x40f				/usr/local/go/src/net/fd_unix.go:242
#	0x6f509c	net.(*conn).Read+0xdc				/usr/local/go/src/net/net.go:121
#	0x68bd65	gopkg.in/mgo%2ev2.fill+0x75			/home/ec2-user/go/src/gopkg.in/mgo.v2/socket.go:504
#	0x68bf86	gopkg.in/mgo%2ev2.(*mongoSocket).readLoop+0x126	/home/ec2-user/go/src/gopkg.in/mgo.v2/socket.go:521

Here a few days ago there were 4 goroutines, now there are 6 running. All my application calls Copy an existing mongo session and close it on exiting the function, i.e.,
sess := existingSession.Copy()
defer sess.Close()

Just curious about the seemingly slow increase in these goroutines and what causes additional ones to be added.



1 @ 0x4f0455 0x4f23dc 0x4f1872 0x65d8c6 0x502da1
#	0x65d8c6	gopkg.in/mgo%2ev2.(*mongoCluster).syncServersLoop+0x606	/home/ec2-user/go/src/gopkg.in/mgo.v2/cluster.go:392


2 @ 0x4f0455 0x4f04c8 0x4f70a5 0x667269 0x502da1
#	0x667269	gopkg.in/mgo%2ev2.(*mongoServer).pinger+0x169	/home/ec2-user/go/src/gopkg.in/mgo.v2/server.go:297



Gustavo Niemeyer

unread,
Jun 17, 2015, 9:29:43 AM6/17/15
to mgo-...@googlegroups.com
Hi there,

The difference between 4 and 6 goroutines is not indicative of any problems by itself. mgo will create as many goroutines as it needs to for satisfying the concurrency demands of the code using it. If more goroutines call it concurrently, it will create more goroutines to manage the connections necessary for dealing with these requests. These will eventually go away, though, as the concurrency demands reduce and the existing connections remain unused.

I'd be more worried if you have a steady increase of goroutines over a longer time span.

One hint if you want to check that your sessions are all being closed appropriately is to use this test server for your tests:


This server ensures that when Wipe or Stop are called, there are no more sessions alive.
 

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



--

sc28

unread,
Jun 17, 2015, 8:57:42 PM6/17/15
to mgo-...@googlegroups.com
Gustavo,

  Thanks - I'll try the test server as I want to to at least understand the ins and outs, since I see a few more mgo goroutines running with some running for several thousand minutes.  So I just just want to make sure I'm not running into future trouble :-)
Reply all
Reply to author
Forward
0 new messages