首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >活动Azure Sql连接超过了连接池限制。

活动Azure Sql连接超过了连接池限制。
EN

Stack Overflow用户
提问于 2017-06-24 04:27:00
回答 3查看 17.8K关注 0票数 13

当Azure SQL数据库性能显著下降时,我们会在生产中解决这个问题。我们知道其中一个表上有锁,但是这些锁不是死锁,它们是长锁,大约一个小时后性能恢复正常。我们正在试图找到关于如何获得这些长锁的所有可能的场景(每个查询都非常快,所有性能分析器都可以向我们展示导致长锁的原因)。提出这一问题的原因如下:

Out连接池设置只允许200个连接池。大多数情况下,我们与数据库之间有大约10-20个开放/池连接。然后,突然之间,一些活跃的连接开始增长,池被完全占用。当一些池连接保持在200以下时,我们看到一些使用sp_who2的活动连接达到1.5k-2k连接(有时是4k-5k)。

我使用Azure Portal监控工具构建了相同的图表。它有不同的聚合期,但显示出相同的问题:

我们使用的连接字符串:

数据安全( Data Source=server.database.windows.net;initial catalog=database;persist security info=True;user info=True;user Timeout=30;Max Pool Size=200;Pooling=True;App=AppName )

怎么可能考虑到200个连接的连接池限制?

ps:没有定期任务、长时间运行的查询或其他工具来执行任何操作,我们用sp_who2检查了所有到数据库的活动连接。

EN

回答 3

Stack Overflow用户

回答已采纳

发布于 2017-06-28 13:15:08

这是一个长篇大论的评论,而不是一个回答。

我确实有几个主机连接到同一个数据库,但是每个主机都有200个连接的相同限制。

连接池为per (连接字符串,AppDomain)。每个服务器可能有多个AppDomains。每个AppDomain每个连接字符串都有一个连接池。因此,在这里,如果您有不同的用户/密码组合,它们将生成不同的连接池。因此,没有什么真正的谜团,为什么有可能有超过200个连接。

那你为什么有这么多人脉?可能的原因:

连接泄漏。

如果您未能释放DbContext或SqlConnection,则该连接将在托管堆上徘徊,直到最后确定,并且不可重用。当连接池达到极限时,新的连接请求将等待30秒才能获得连接,然后失败。

在此场景中,您将不会在服务器上看到任何等待或阻塞。会议都将是空闲的,而不是等待。并且不会有大量的请求

代码语言:javascript
复制
select *
from sys.dm_exec_requests 

请注意,会话等待统计现在是在Azure上运行的,因此查看实时阻塞和等待要容易得多。

代码语言:javascript
复制
select *
from sys.dm_exec_session_wait_stats

封锁。

如果传入的请求开始被某些事务阻塞,而新的请求继续启动,那么会话的数量就会增加,因为新的请求会得到新的会话,启动请求并被阻塞。在这里,您会看到很多阻塞的请求

代码语言:javascript
复制
select *
from sys.dm_exec_requests

缓慢的查询。

如果请求由于资源可用性(CPU、磁盘、日志)而需要很长时间才能完成,您可以看到这一点。但这不太可能,因为在这段时间内,DTU的使用率很低。

因此,下一步是查看这些连接在服务器上是否处于活动状态,表示阻塞,还是在服务器上显示存在连接池问题。

票数 7
EN

Stack Overflow用户

发布于 2017-07-04 07:59:59

您可以检查dbcontext对象是否正确使用它们,并将对象配置为将连接返回到连接池。

首先,您要从代码中创建dbcontext。检查object对象的每个创建范围周围是否有一个using语句。类似于:

代码语言:javascript
复制
using (var context = new xxxContext()) {
    ...
}

这将在上下文自动超出作用域时释放它。

其次,您正在使用依赖项注入来注入object对象。确保您使用的范围:

代码语言:javascript
复制
services.AddScoped<xxxContext>(

然后DI将处理您的上下文对象。

接下来,您可以检查是否有未提交的事务。检查所有事务是否都在使用块内,以便在超出范围时它们将提交或回滚。

票数 2
EN

Stack Overflow用户

发布于 2019-06-18 07:58:09

这个问题可能与“池碎片化”有关。

在许多Web应用程序中,池碎片是一个常见问题,在这些应用程序中,应用程序可以创建大量直到进程退出才释放的池。这会导致大量连接打开并占用内存,从而导致性能低下。

由于集成安全*连接而造成的池碎片将根据连接字符串和用户标识进行池。因此,如果在网站上使用基本身份验证或Windows身份验证以及集成的安全登录,则每个用户将获得一个池。尽管这提高了单个用户的后续数据库请求的性能,但该用户无法利用其他用户所做的连接。它还导致每个用户至少有一个连接到数据库服务器。这是特定Web应用程序体系结构的副作用,开发人员必须权衡安全性和审计要求。

资料来源https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql-server-connection-pooling

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/44732740

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档