标签: timeout

我在我的应用程序（客户端）中将连接和命令超时设置为 10 分钟。

比我的应用程序运行一个简单的查询： SELECT pg_sleep(65)

在某些服务器上它工作正常，但其他服务器在 60 秒后关闭连接。

这可能是某种限制超时并忽略我的客户端设置的 PostgreSQL 服务器配置吗？

我是 sql DBA，正在学习 postgres ..在 postgres 日志中，我经常收到“无法从客户端接收数据：连接超时”我没有除此之外的任何其他日志

不知道如何排除故障？我检查了应用程序日志和 DBs 日志以比较时间，但我没有注意到任何异常。

有人可以指导我如何追踪这个问题。

谢谢

我们的 Ola Hallengren IntegrityCheck 作业由于在用户数据库上运行 DBCC CHECKDB 时发生缓冲区锁存超时而失败。

但是，报告的缓冲区锁存器超时位于 TempDB（数据库 ID 2）中。

作业的输出：

Date and time: 2022-01-22 09:04:15 [SQLSTATE 01000]
Database context: [master] [SQLSTATE 01000]
Command: SET LOCK_TIMEOUT 600000; DBCC CHECKDB ([SentryOne]) WITH NO_INFOMSGS, ALL_ERRORMSGS, MAXDOP = 4 [SQLSTATE 01000]
Msg 845, Sev 17, State 1, Line 1 : Time-out occurred while waiting for buffer latch type 2 for page (6:222), database ID 2. [SQLSTATE 42000]
Outcome: Failed [SQLSTATE 01000]
Duration: 12:40:32 [SQLSTATE 01000]
Date and time: 2022-01-22 21:44:47 [SQLSTATE …

问题

自今年年初以来，由于我们系统中的 SQL 超时，我们一直在经历高度的用户中断。

有问题的 SQL-Server 实例在工作时间内的 CPU 使用率非常高（所有 16 个内核的 CPU 使用率始终高于 90%）。

我们还注意到等待时间非常长：CXPACKET 和 LATCH_EX 的组合约占所有等待的 97%。这在 CXPACKET 和 LATCH_EX 之间分成大约 50/50。

占 LATCH_EX 绝大多数 (>95%) 的非缓冲闩锁等待是 ACCESS_METHODS_DATASET_PARENT。

这表明问题与并行性有关。

等待时间比例的一个例子是：

CXPACKET : 332,301,799 ms
LATCH_EX : 267,955,752 ms
PAGEIOLATCH_SH : 2,955,160 ms

这是 1 月 11 日 08:00-16:24 之间的时间段。

正在考虑的选项

1) 将 MAXDOP 从 0 更改为 4 到 8 之间的值

2) 将并行度的成本阈值从 50 修改为更高的数字

关于如何减轻我们所看到的非常高的 CPU 负载并减少超时的建议最受欢迎，特别是建议的行动方案是否明智，以及将 MAXDOP 和并行成本阈值更改为哪些数字。

背景资料

• SQL-Server 2008 R2 在 AMD Opteron 6180 SE …

我在 RHEL7 VM 上安装了 SQL Server

msodbcsql-13.1.1.0-1.x86_64
mssql-server-14.0.100.187-1.x86_64
mssql-tools-14.0.2.0-1.x86_64

# ls -al /opt/
total 4
drwxr-xr-x.  5 root root   52 Jan 13 08:31 .
drwxr-xr-x. 17 root root 4096 Jan 13 07:55 ..
drwxr-xr-x.  3 root root   22 Jan 13 08:31 microsoft
drwxr-xr-x.  4 root root   26 Jan 13 08:14 mssql
drwxr-xr-x.  4 root root   28 Jan 13 08:31 mssql-tools

systemctl 表示 SQL 服务器已启动并正在运行 / 绿色

# systemctl status mssql-server
mssql-server.service - Microsoft(R) SQL Server(R) Database Engine
   Loaded: loaded (/usr/lib/systemd/system/mssql-server.service; …

我运行了一个产生 25 个线程的多线程客户端来进行并发 API 调用并将数据插入到 AWS Aurora 服务器。

一段时间后，我开始看到超时错误：lock wait timeout exceeded try restarting transaction.我们对运行 MySQL 5.6.10 的服务器运行相同的测试，并没有发生锁等待超时。

有没有办法避免这种超时？

在 AWS Aurora 服务器上，SHOW ENGINE INNODB STATUS显示：

---TRANSACTION 8530565676, ACTIVE 81 sec setting auto-inc lock
mysql tables in use 2, locked 2
LOCK WAIT 6 lock struct(s), heap size 376, 2 row lock(s), undo log entries 1
MySQL thread id 405, OS thread handle 0x2ae270b03700, query id 11045 10.50.101.56 app_migration
INSERT INTO contacts_contactaudit (action,
    contact_id,
    date_created,
    date_updated, …

我们的数据库有一个 SQL Server 2008R2 企业版来支持前端应用程序。我们以前从未遇到过超时问题。最近，该公司决定将数据库升级到 SQL Server 2014 企业版，其中 2 个节点始终处于群集设置。新服务器比旧服务器具有更好的 CPU、内存。

升级后我做了所有必要的修改，检查数据库一致性，运行 DBCC UPDATEUSAGE，更新统计信息，重建索引，重新编译存储过程等等。数据库切换和迁移一切顺利。但是，我们的用户开始抱怨超时问题。

我一直在查看不同的文章、博客文章并进行了一些修改，例如更改连接字符串和添加 MultiSubnetFailover = 'True'，这似乎有很大帮助并最大限度地减少了超时频率，但问题仍然存在。有谁知道是什么导致了这个问题以及如何解决它？我非常感谢您提出的解决此问题的建议和建议。

我从我的 .net 应用程序中收到以下错误。

Source: xxx.Services.xxx.xxx.xxxx.xxxx.xxxxRequest
    ---
    System.Data.Entity.Core.EntityException: The underlying provider failed on Open. ---> System.InvalidOperationException: 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.

我看过几篇关于这个连接池错误的帖子。我已经阅读了其中的大部分内容，我明白为什么会发生这种情况，以及应用程序端的可能解决方案，比如关闭应用程序打开的连接。这些是我的理解：

1. 打开的连接并没有关闭，称为连接泄漏。
2. 正在使用 100 多个并发连接。如果我们有 100 个以上的并发用户，请增加连接字符串中的最大池大小。
3. 缓慢的查询或打开的事务会阻止新连接。当连接被慢速查询执行/打开事务保持打开时，而不是重用连接，新连接将打开并最终达到连接池最大值。

我如何从数据库端监控这一点。我看到了一些建议，例如使用 sp_who 或 sp_who2 查看现有会话。当我看到这些错误时执行 sp_who2 时，我看到很多活动会话，但是我怎么能看到连接池池下的信息和连接。问题：

1. 有什么方法可以跟踪打开的连接并将其与从数据库端创建的连接池相关联。

我注意到当问题发生时，通常运行得更快的查询会变慢。

2. 这是预期的吗？因为我怀疑慢查询是否导致连接池错误。

最近我发现（我必须声明我不是 DBA）可以在 SQL Serve 属性中配置超时（适用于 SQL Server 实例中的所有数据库）：

忽略图片显示0超时（我正在实验，不会是最终配置）；我很困惑，因为我知道应该将超时配置到连接到 SQL Server 实例的客户端中（连接超时和命令超时）。

现在我想知道如果 SQL Sever 配置规定超时为 10 分钟并且客户端使用 20 分钟的连接字符串（命令和连接）进行连接，会发生什么情况。应用哪种超时？

我们的系统通过大量测试生成 SQL。我怀疑在某些情况下，找到理想的执行计划需要很长时间。所以 SQL 只选择它迄今为止找到的最好的计划，然后需要很长时间才能运行。是否可以增加 SQL 搜索最佳计划的时间？

当我sys.sysprocesses在 SQL 2008R2 中签入时，存在许多阻塞会话。其中大部分是插入、更新和删除语句，具有与锁相关的等待类型。

这会导致超时问题吗？谁能确认这是否会导致超时/性能问题？