我们使用 SQL 身份验证(以减少连接池的数量)和 .NET 4.0 连接字符串连接到 Windows 2008 R2 Enterprise Server 上的 SQL Server Enterprise Edition 2012 SP1:
Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64)
2012 年 10 月 19 日 13:38:57
版权所有 (c) Microsoft Corporation
Enterprise Edition(64 位)在 Windows NT 6.1(Build 7601:Service Pack 1)上
我们使用大约 50 个服务器分成 8 个不同的组,网站的不同部分。
我们的网站正在使用此 SQL Server 来记录访问跟踪数据。在过去的几天里,它发出了有关重置连接池的以下消息:
客户端无法重用 SPID 1327 的会话,该会话已为连接池重置。失败 ID 为 46。此错误可能是由较早的操作失败引起的。在此错误消息之前立即检查错误日志中是否有失败的操作。
错误日志如下:
错误:18056,严重性:20,状态:46
。客户端无法重用 SPID 959 的会话,该会话已为连接池重置。失败 ID 为 46。此错误可能是由较早的操作失败引起的。在此错误消息之前立即检查错误日志中是否有失败的操作。
用户“xxxx”登录失败。原因:重新验证连接上的登录时,无法打开登录对象中配置的数据库“xxxxxxxx”。[客户:10.xx.xx.xxx]
经过一番挖掘,我在 CSS 博客上找到了这篇文档:它是如何工作的:错误 18056 – 客户端无法重用带有 SPID …
由于在这种模式下 pgbouncer 为每个入站连接创建出站连接,因此在我看来 pgbouncer 不能作为池化器工作。这只是1对1的映射。
我哪里错了?
MSDN 在线文章“ SQL Server 中的快照隔离”指出:
这不是自相矛盾的段落(“直到”与“保留”)吗?
那么,如果在关闭连接并将其返回到池后“保留了来自最后一个 SET TRANSACTION ISOLATION LEVEL 语句的隔离级别”,应该如何理解:
sql-server transaction isolation-level connection-pooling snapshot-isolation
来自 PostgreSQL 文档:
为了获得最佳吞吐量,活动连接的数量应该接近 ((core_count * 2) + Effective_spindle_count)
调整你的 PostgreSQL 服务器 -> max_connections
通常,良好硬件上的 PostgreSQL 可以支持几百个连接。
对我来说——不是一个有经验的 DBA——这里的某个地方存在差异,特别是查看一些 DB 即服务提供商的产品。
例如,此时 Amazon RDS 最大的机器 (db.r3.8xlarge) 有 32 个 vCPU,根据第一个公式,如果有很多磁盘,它可能会在池中有 100 个连接的情况下以最佳方式运行。使用第二个公式中的“几百个连接”,它会不会运行得很糟糕?
更极端的是另一家 DBaaS 提供商的差异,他们提出了一个具有 500 个并发连接的 2 核服务器。这怎么可能运作良好?
如果我误解了什么,请告诉我。非常感谢!
我们正在创建 SAAS,我们最多将拥有 50.000 名客户。我们正在考虑在 Postgres 数据库中为每个客户创建一个用户。我们会将登录我们服务的每个用户映射到数据库中的用户,以确保他们只能访问自己的数据。我们还希望通过此解决方案直接在数据库中实施审计跟踪,它利用触发器。如果每个客户都有自己的数据库用户,那么即使两个客户共享相同的数据,也很容易看出谁做了什么。
因为我们的数据库中有 50.000 个用户,我们会遇到一些意想不到的问题吗?性能方面或管理方面。也许连接池会更困难,但我真的不知道我们是否需要它。
下面是一个示例 pgpool 架构:
这意味着您只需要在单个服务器上拥有 pgpool;这是真的?当我查看配置时,我还看到您在其中配置了后端pgpool.conf
;所以它进一步暗示了这一点。但是,它并没有解释为什么我也在后端服务器上看到 pgpool。
在查看文档时,我还看到:
如果您使用的是 PostgreSQL 8.0 或更高版本,强烈建议在 pgpool-II 访问的所有 PostgreSQL 上安装 pgpool_regclass 函数,因为它被 pgpool-II 内部使用。
所以我不知道该怎么想;在所有后端或仅在专用服务器上使用 pgpool 是最佳实践吗?
postgresql architecture scalability pgpool connection-pooling
HickariCP 文档说:
HikariCP 在性能和可靠性方面都非常依赖精确的高分辨率计时器。您的服务器必须与时间源(例如 NTP 服务器)同步。特别是如果您的服务器在虚拟机中运行。不要依赖管理程序设置来“同步”虚拟机的时钟。在虚拟机内配置时间源同步。如果你来寻求支持,但结果证明是由于缺乏时间同步导致的,你会在 Twitter 上公开受到嘲讽。
您会选择其他哪些对虚拟机时间漂移不太敏感的连接池库?
我知道如果您根本不池化数据库连接,那么每次需要查询数据库时,您都要承担建立新数据库连接的开销,这会使您的应用程序变慢,并且您可以通过池化来节省该开销。
如果您将最大池大小设置得太小 - 比方说,最多 1 个连接 - 那么它的缺点是您的应用程序必须为所有请求共享该单个数据库连接,并且请求将不得不等待前一个连接完成数据库连接,然后才能从池中获取它并重新使用它。
但是,如果您只是将最大池大小设置得非常大,例如最大 1000 个连接,该怎么办。那么它不应该更倾向于重用连接而不是建立新连接,并且仅在实际需要时才最大化池大小以满足需求吗?
假设未使用的连接在空闲超时后关闭/从池中删除,使连接池大于满足应用程序需求所需的大小有什么缺点?
我正在使用 3 层应用程序 Microsoft Dynamics AX,其中中间层维护与 SQL Server 的连接。几个客户端连接到这个中间层服务器。
中间层服务器通常有几个连接到 SQL Server,所以我很确定它们正在池中,但是没有关于如何实现的文档。
通常情况下,我们可以不涉及SPID的用户或客户端应用程序,但在这里我们可以设置一个注册表项(具体到Microsoft Dynamics AX),这使得在提供这些信息的选择context_info
的领域sys.dm_exec_sessions
。
同样,没有关于如何实现的文档。我们在这方面的唯一信息是MSDN 上一个模糊的博客条目。
帖子提到
添加此信息的性能开销很小。
因此,我们不知道任何实现细节,例如:
有什么方法可以确定服务器端连接池的工作方式以及 context_info 的影响是什么?
更新:
从这里使用这个查询
SELECT des.program_name,
des.login_name,
des.host_name,
-- der.database_id,
COUNT(des.session_id) AS [Connections]
FROM sys.dm_exec_sessions des
INNER JOIN sys.dm_exec_connections DEC
ON des.session_id = DEC.session_id
WHERE des.is_user_process = 1
--AND des.status <> 'running'
GROUP BY des.program_name,
des.login_name,
des.host_name
-- ,der.database_id
HAVING COUNT(des.session_id) > 2
ORDER BY …
Run Code Online (Sandbox Code Playgroud) 以下是情况的简要说明:
我们正在创建一个真正的无状态应用程序前端(即改进遗留软件)。这意味着我们可以有许多(100 多个)应用服务器来处理用户流量,每个应用服务器可能需要连接到 50 多个服务器中的任何一个来随时提取数据。
拥有这么多应用服务器的原因是代码的计算量非常大。也许最终我们可以转向使用更强大硬件的更少应用程序服务器,但我们还没有做到这一点。
我的问题: 如何管理这种环境中的连接池情况?
如果我们想象一个“好”的连接池大约有 64 个连接,那么让每个应用服务器为每个数据库服务器生成一个连接池似乎是不可行的。这将导致对每个数据库服务器建立100+x64 = 6400 个持久连接......这太多了吗?
可以做什么?是否有某种可以使用的连接池代理软件?
postgresql ×4
sql-server ×4
architecture ×1
multi-tenant ×1
mysql ×1
performance ×1
pgbouncer ×1
pgpool ×1
scalability ×1
transaction ×1
users ×1