在昨天的博文中，我们坚持认为数据库连接数过万是阿里云RDS的问题，但后来阿里云提供了当时的数据库连接情况，让我们动摇了自己的想法。

帐户 连接数

A 4077

B 3995

C 741

D 698

E 519

上面这5个帐户产生了10030个数据库连接，当看前4个帐户（产生了9511个连接）的名称时，我们打了一个寒颤 —— 这些都是运行 Linux 上的 ASP.NET Core 站点。。。这不是巧合，其中必有蹊跷。

随后，我们观察了主备库切换后的 RDS 中数据库连接情况。有一个运行在 Linux 上的 ASP.NET Core 站点，用了3台服务器，却产生了1528个数据库连接。

sys.sysprocesses

重启其中1台服务器上的站点，连接数立马从1528降到了391。什么情况？数据库连接池发飙了？

继续观察，当前数据库中大量的连接都是由运行在 Linux 上的 ASP.NET Core 站点产生的，而且会随着时间的推移保持增长。

数据库连接泄漏了，这还是第1次遇到！可我们在 APS.NET Core 应用中所有的数据库操作都用的是Entity Framework Core，不存在没有及时关闭数据库连接的情况，唯一可以怀疑的对象是在 System.Data.SqlClient 中实现的 ADO.NET 数据库连接池。

数据库连接池究竟出什么状况了？我们在数据库连接字符串中没有另外设置连接池，用的是默认设置（）。而且更奇怪的是 Max_Pool_Size 的限制没起作用，不然只会报下面的错误，不会连接数一直增长。

Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.

我们想来想去，唯一能想得通的解释是 .NET Core 的数据库连接池发生了这样的状况 —— 连接池中已经创建的连接无法被重用，不仅如此，而且它们直接被 SqlClient 给无视了，都没有被计算在 Pool Size 中，所以根本触发不了 Max_Pool_Size 的限制，造成连接无限制，任由 SqlClient 建。更要命的是，这些被无视的连接却一直在保持着与数据库的连接。于是，连接泄露成了命中注定。

在有了这个唯一想得通的猜测后，我们今天开始在测试环境中进行验证。

部署一个 ASP.NET Core 站点，创建一个专用数据库连接帐户，然后用下面的 SQL 语句查看数据库连接是否被重用，同时在测试服务器用 tcpdump 进行抓包，并且分别用阿里云 RDS 与我们自己搭建的 SQL Server 服务器进行测试。

sys.sysprocesses

如果连接池正常工作，第1次访问，新建所需的数据库连接；第2次访问同样的页面，应该重用已有的数据库连接，不会创建新的数据库连接。

开始测试时，不管连接阿里云 RDS 还是我们自己的 SQL Server，连接池都工作正常，连接能被重用。

后来分析了一下，虽然生产环境中连接数一直在增长，但增长速度不是很快，可能问题的发生需要一定的时间间隔，或许连接闲置超过一定时间之后才不会被重用。

于是，我们间隔了10分钟左右进行访问测试，问题重现了！比如其中的一次测试，同一个页面第1次访问，产生了5个连接；过10分钟左右再访问，会新建3个连接变成8个连接；再过10分钟左右访问，连接增长到11个。这种连接不能被重用的情况通过 tcp 抓包也可以看出来。如果在很短的时间内访问，连接数保持不变（连接被重用）。

这个问题不仅在阿里云 RDS （SQL Server 2008 R2）可以重现，而且在我们自己搭建的 SQL Server 2014 也能重现，问题的真相随之水落石出。

数据库连接数过万问题不是阿里云 RDS 的问题，而是 .NET Core 中 System.Data.SqlClient 的连接池在 Linux 上的实现问题，我们错怪了阿里云，轻信了微软。这是我们使用阿里云以来对阿里云最大的一次误会，这是我们 .NET Core 迁移过程中遇到的最大的一个坑。

为什么最近才出现这个问题？是因为我们最近将更多站点迁移到了 ASP.NET Core ，而且将之前一些跑在 Windows 上的 ASP.NET Core 站点切换到了 Linux 。

如何解决这个问题？我们会察看一下 System.Data.SqlClient 的实现代码，看能否找到实现层面的线索。阿里云会进一步验证这个问题，如果确认是微软实现上的问题，会与微软沟通解决。

【16:55 更新】

我们在 Windows 上进行对比测试发现，在 Windows 上连接池中闲置的数据库连接过段时间会被自动关闭，与上面 Linux 同样的测试场景，间隔10分钟后查看，数据库连接全消失了。

【18:18 更新】

感谢 @feiyun0112 在评论中提供的线索，2016年11月7日就有人发现了这个问题，并且在 github 上提交了 issue 。

【18:41 更新】

我们在应用中使用的 System.Data.SqlClient.dll 版本是 4.3.0，是在2016年11月5日生成的，正好在这个 issue 之前。

【20:56 更新-成功解决】

通过手动替换 System.Data.SqlClient.dll 文件解决了这个问题。操作步骤如下：

1）在 https://github.com/dotnet/corefx/releases 下载 .NET Core 1.1 得到 corefx-1.1.0.zip 文件并解压。

2）在 corefx-1.1.0 文件中运行 init-tools.cmd 命令安装 build 工具

3）用 VS2017 打开 corefx-1.1.0\src\System.Data.SqlClient 中的 System.Data.SqlClient.sln 解决方案

4）打开 SNITcpHandle.cs ，去掉 private readonly NetworkStream _tcpStream; 中的 readonly ，在 Dispose() 方法中添加如下代码：

if (_tcpStream != null) { _tcpStream.Dispose(); _tcpStream = null; }

5）用 VS2017 以 Release 方式 build System.Data.SqlClient 项目。

6）将 corefx-1.1.0\bin\Unix.AnyCPU.Release\System.Data.SqlClient 文件夹中生成的 System.Data.SqlClient.dll 文件，在 git bash 中通过 scp 命令上传到 Linux 服务器上的 nuget 文件夹。

MINGW64 /c/Dev/GitHub/corefx-1.1.0/bin/Unix.AnyCPU.Release/System.Data.SqlClient $ scp System.Data.SqlClient.dll root@ubuntu-server:~/.nuget/packages/system.data.sqlclient/4.3.0/runtimes/unix/lib/netstandard1.3 System.Data.SqlClient.dll 100% 708KB 176.9KB/s 00:04

7）登录 Linux 服务器重启 ASP.NET Core 站点

8）第一次访问，在数据库中看到了这些新建的连接，然后停止访问。。。等了5-6分钟，这些连接全部消失，和在 Windows 上的表现一致，连接泄露的问题搞定！

连接泄露引起的数据库连接数过万的问题，仅仅是因为少写了1行 Dispose 代码。

附：我们 build 出来的修复这个问题的 System.Data.SqlClient.dll

【23:15 更新】

更新 System.Data.SqlClient.dll 之后，效果是立竿见影！