在昨天的博文中，我们坚持认为数据库连接数过万是阿里云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个数据库连接。
SELECT * FROM sys.sysprocesses WHERE loginame='xxx'
重启其中1台服务器上的站点，连接数立马从1528降到了391。什么情况？数据库连接池发飙了？
继续观察，当前数据库中大量的连接都是由运行在 Linux 上的 ASP.NET Core 站点产生的，而且会随着时间的推移保持增长。
数据库连接泄漏了，这还是第1次遇到！可我们在 APS.NET Core 应用中所有的数据库操作都用的是Entity Framework Core，不存在没有及时关闭数据库连接的情况，唯一可以怀疑的对象是在 System.Data.SqlClient 中实现的 ADO.NET 数据库连接池。
数据库连接池究竟出什么状况了？我们在数据库连接字符串中没有另外设置连接池，用的是默认设置（Min_Pool_Size = 0; 与 Max_Pool_Size = 100;）。而且更奇怪的是 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 服务器进行测试。
SELECT * from sys.sysprocesses where loginame='测试专用帐户'
如果连接池正常工作，第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 之后，效果是立竿见影！
67
0
? 上一篇：云计算之路-阿里云上：RDS数据库连接数过万引发故障，主备库切换后恢复正常
? 下一篇：上周热点回顾（4.3-4.9）
posted @ 2017-04-07 15:08 博客园团队 阅读(5431) 评论(49) 编辑 收藏
评论列表
厉害，虽然没有看得特别懂。不过感觉像打仗一样。
阿里云估计暗地里骂娘了，被博客园写得生来死去的。
直接贡献Github代码算了，微软就需要你们这样的贡献者
@ 沈赟
引用阿里云估计暗地里骂娘了，被博客园写得生来死去的。
看来阿里云也是不少背锅啊
我感觉吧，阿里是国内为数不多的靠谱的云了，一直比较信任吧，就是价格和服务还需要在提升提升。
微软开始紧张了
#7楼 2017-04-07 15:32 Flaming丶淡蓝
.Net Core刚出来 还不稳定。。。
好像昨天博客偶尔出现 无法访问
直接联系微软技术吧。来得快
微软说：谁让你们不用 Windows 部署呢！
#11楼 2017-04-07 16:08 feiyun0112
这个是已知bug,计划2.0.0解决
https://github.com/dotnet/corefx/issues/13422
niubi
牛
厉害了dudu大神，Core就需要你们这样勇敢的先行者...持续关注你们的Core系列~
#15楼 2017-04-07 16:39 JeffWong
原来是连接池的问题，学到了，但愿自己永远不需要这个经验
试用新东西，坑不少@feiyun0112
引用这个是已知bug,计划2.0.0解决
https://github.com/dotnet/corefx/issues/13422
目前可以通过禁用连接池的办法解决。
@ feiyun0112
大佬你说的太晚了....
以后麻麻再也不用担心公司转型到linux必须抛弃.net投靠java了。直接转型到.net core一样可以拥抱linux.
#20楼 2017-04-07 17:31 jiancaixing
希望大佬们找到解决方法共享出来。看了这个问题都不敢在正式系统里用asp.net core了。
可以自定义实现连接池解决吧。
这个坑赶紧填
这个bug我们在测试时也遇到，这也是导致暂时观望Core的重要原因。
@ feiyun0112
引用这个是已知bug,计划2.0.0解决
https://github.com/dotnet/corefx/issues/13422
人家解决方案已经给出来了，下最新的代码，编译一下好了。
https://github.com/dotnet/corefx/blob/master/src/System.Data.SqlClient/src/System/Data/SqlClient/SNI/SNITcpHandle.cs
/// <summary>
/// Dispose object
/// </summary>
public override void Dispose()
{
lock (this)
{
if (_sslOverTdsStream != null)
{
_sslOverTdsStream.Dispose();
_sslOverTdsStream = null;
}
if (_sslStream != null)
{
_sslStream.Dispose();
_sslStream = null;
}
if (_tcpStream != null)
{
_tcpStream.Dispose();
_tcpStream = null;
}
//Release any references held by _stream.
_stream = null;
}
}
http://www.cnblogs.com/cmt/p/6677613.html
延伸阅读
- ASP.NET Core Web API 最小化项目 2017-07-26 16:23:34.143
- 【原创】 Docker 中 运行 ASP.NET Core 站点 2017-07-26 16:10:49.503
- 扩展entity framework core 实现默认字符串长度,decimal精度,entity自动注册和配置 2017-07-26 15:52:06.747
- ABP从入门到精通（1）：aspnet-zero-core项目启动及各项目源码说明 2017-07-26 11:59:44.78
- .Net Core 系列：2、ADO.Net 基础 2017-07-26 11:54:44.893
- ASP.NET Core之跨平台的实时性能监控 2017-07-25 15:54:07.337
- 编写一个可配置的网页信息提取组件 （二）—— 优雅的.net core 配置系统 2017-07-25 14:33:29.213
- ASP.NET Core API 版本控制 2017-07-25 09:57:07.75
- ASP.NET Core Web 资源打包与压缩 2017-07-21 12:00:46.087
- ASP.NET Core 源码学习之 Logging[1]:Introduction 2017-07-21 11:59:01.053
ASP.NET Core Web API 最小化项目