Too many TIME_WAIT after concurrent when using redigo pool

Question

I used github.com/garyburd/redigo for my application go routines concurrently reading and writing Redis. I used redigo NewRedisClient() in Singleton Pattern, and set MAXACTIVE=100, MAXIDLE=100, IDLETIMEOUT=60.

The application started and I found there are many TIME_WAIT to Redis Server growing. like:

root@goofy-27253489-lax5m:/# netstat -anltp | grep TIME_WAIT | wc -l
10466
root@goofy-27253489-lax5m:/# netstat -anltp | grep TIME_WAIT | wc -l
11776
root@goofy-27253489-lax5m:/# netstat -anltp | grep TIME_WAIT | wc -l
12554
root@goofy-27253489-lax5m:/# netstat -anltp | grep TIME_WAIT | wc -l
16017

And I also print the active count and idle count every time when I pool.Get(), it showed:

ActiveCount: 1, MaxActive: 100, MaxIdle: 100, Pool: 0xc420288580, Conn: 0xc420220000, IdleSize: 0
ActiveCount: 3, MaxActive: 100, MaxIdle: 100, Pool: 0xc420288580, Conn: 0xc42064e0a0, IdleSize: 0
ActiveCount: 3, MaxActive: 100, MaxIdle: 100, Pool: 0xc420288580, Conn: 0xc4202960a0, IdleSize: 0
ActiveCount: 3, MaxActive: 100, MaxIdle: 100, Pool: 0xc420288580, Conn: 0xc4206765a0, IdleSize: 0
ActiveCount: 3, MaxActive: 100, MaxIdle: 100, Pool: 0xc420288580, Conn: 0xc420296140, IdleSize: 0
ActiveCount: 3, MaxActive: 100, MaxIdle: 100, Pool: 0xc420288580, Conn: 0xc42034c0a0, IdleSize: 0
ActiveCount: 3, MaxActive: 100, MaxIdle: 100, Pool: 0xc420288580, Conn: 0xc42034c320, IdleSize: 0
ActiveCount: 3, MaxActive: 100, MaxIdle: 100, Pool: 0xc420288580, Conn: 0xc42064e280, IdleSize: 0
ActiveCount: 3, MaxActive: 100, MaxIdle: 100, Pool: 0xc420288580, Conn: 0xc42034c3c0, IdleSize: 0

Why there were so many TIME_WAIT ? Did I leak some connections ?

Answer 1

Are you returning connections to the pool when you're done with them, per the documentation ?

A request handler gets a connection from the pool and closes the connection when the handler is done:

func serveHome(w http.ResponseWriter, r *http.Request) {
    conn := pool.Get()
    defer conn.Close()
    ...
}

Not returning connections to the pool as shown above would result in the connection leak you're seeing.