记一次gorm连接池打满，连接不释放的问题

　　我们golang项目用的gorm，最近pre测试跑脚本时，总会出现504，某个接口不可用。分析了半天pprof，阻塞数量较多的goroutine，某些时候并不能看到真实问题的所在。

　　出现504，通过pprof:debug/pprof/goroutine?debug=2 或者debug/pprof/goroutine?debug=1 能看到阻塞的goroutine，处在io wait状态
　　检查下pod内，连接数(netstat)，发现http的连接数和mysql的连接数暴增!!!

导致mysql的连接数暴增常见的有三种：

一、使用事务，没有关闭！

tx:=db.conn后，err判断，直接return，没有进行tx.rollback。这时候mysql的conn_pool会+1，且不可复用。
错误的请求继续上涨后，就会出现连接数打满，继而新的请求一直阻塞，goroutine也会阻塞住。

此时杀死连接也没用，因为goroutine锁死在tx.awaitDone()里，也就是在等待done的chan返回。

只有调用tx.Commit或tx.Rollback才能使awaitDone返回，否则会造成conn闲置，协程溢出。

tx.Commit或tx.Rollback都会调用Tx.cancel和Tx.releaseConn。
正确使用：

conn, err := mysql.GetConn()

if err != nil {

    return

}

tx := conn.Begin()

defer func() {

    if r := recover(); r != nil {

        tx.Rollback()

    }

}()

......

......

if err != nil {

    tx.Rollback()

    return

}

tx.Commit()

二、使用rows方法请一定要关闭连接。

rows请一定要在err==nil的情况下使用，不然会导致空指针panic。

同样的协程等待Rows.awaitDone返回，需要通过Rows.Close调用Rows.cancel和Rows.releaseConn。

rows, err := db.rows()

if err != nil {

    return err

}

defer rows.close()

三、使用事务，切记使用新的tx变量

tx := conn.Begin()

//下面一定使用tx，不要用conn了！！！！

四、gorm.Open的变量不再使用后，记得close。

否则即使变量被垃圾回收，mysql连接也不会释放，最好是不用了主动调用close关闭。

被动的解决办法就是用golang的析构函数runtime.SetFinalizer，这样最差的情况是：在2分钟后的强制gc时连接会被释放。

    runtime.SetFinalizer(mysqlDB, func(obj *gorm.DB) {

        obj.Close()

    })

五、通过设置超时解决，mysql服务器超时或客户端超时。

例如设置mysql服务器的 wait_timeout 时间，此时到了超时时间后，mysql会主动关闭连接进入 FIN_WAIT2 状态，而gorm的连接进入 CLOSE_WAIT 状态，此时在mysql执行show processlist;已经看不到超时的连接。

SHOW GLOBAL VARIABLES LIKE '%timeout%';

SET GLOBAL wait_timeout=600;

如果不能登录mysql，可以通过gdb临时修改（重启后丢失）：

gdb -p $mysql_pid

(gdb) file /usr/sbin/mysqld

(gdb) p max_connections                      
$1 = 1000
(gdb) set max_connections=2000              
(gdb) p max_connections       
$2 = 2000
(gdb)

(gdb) p global_system_variables.net_wait_timeout
$7 = 2147483
(gdb) set global_system_variables.net_wait_timeout=600
(gdb) p global_system_variables.net_wait_timeout      
$8 = 600
(gdb)

--end--