问题标签 [query-timeout]

我是 Cassandra 的新手，在本地机器上的 Cassandra 3 节点集群上运行用户定义的聚合。问题是，当我在较小的数据集上运行此聚合时，结果很好并且符合预期。

但是当数据太大时，查询失败并出现错误 -

OperationTimedOut: errors={'127.0.0.1': '客户端请求超时。见 Session.execute_async'}, last_host=127.0.0.1

我发现了与我的问题类似的以下问题，但没有得到解答。查找其他问题的链接 -

如何为大型用户定义的聚合查询设置超时和节流率

Cassandra CQLSH OperationTimedOut 错误=客户端请求超时。请参阅 Session.execute[_async](超时)

我已经修改了 cassandra.yaml 并且时间限制是 -

但这对我没有帮助。请指导这些时间的正确配置是什么，以便在没有查询超时的情况下在大型数据集上运行相同的查询。

聚合代码 -

谢谢并恭祝安康，

维巴夫

PS - 如果有人选择否决这个问题，请在评论中提及相同的原因。

持久性.xml：

询问：

查询返回 7000 行……但超时不起作用。

我开发了许多 .NET / SQL Server 应用程序，但我遇到了无法深入了解的 SQL 查询超时。我在查找有问题的查询并重新索引/重写它们方面有很多经验。我的 Web 应用程序使用用于 SQL Server 的 RDS 和用于 Web 应用程序的 EC2 托管在 AWS 上。我们每天有 100-200 个唯一用户，数据库大约 15GB，有几个表 > 1GB。

我一整天都看到异常消息：

遭受超时的查询与超时发生的时间一样随机。它似乎与任何明显的事情不符（备份在一夜之间运行等）。

我尝试从 C# 应用程序中获取每个查询并直接在 SQL 中运行它（使用与 Arith Abort 相同的 SET 选项），它们都运行得很好。有些本质上是较慢的查询，但最慢的查询在大约 2 秒内运行，并且具有约 400k 的逻辑读取。但是，我还看到在 15 毫秒内运行且逻辑读取次数小于 10 的查询超时。

我见过的最奇怪的事情是，我从 Web 应用程序中获取了一个查询并将其编码到一个控制台应用程序中，该应用程序已经运行了 24 小时，每秒调用一次查询。即使我已经看到主系统在运行期间对同一查询有超时，它也没有出现过任何异常/超时。

我最近将 RDS 服务器升级到 M5 Large 并且所有索引每天都会在一夜之间重建。我在某个时候运行了 DBCC FREEPROCCACHE，以确保没有过时的查询计划导致问题。

我觉得这是参数嗅探，或者我最后的想法是硬件/网络故障，但那真的是抓住了稻草！

我得到的堆栈跟踪看起来像是在查询中，而不是在连接阶段。

任何有助于了解这一点的技术将不胜感激，因为它令人不安，我担心它会突然变得更糟。

谢谢

编辑 1

我试图通过每 10 毫秒运行一次测试应用程序（如上）并同时在 SSMS 中运行缓慢的阻塞事务来在本地创建相同的问题。

从应用程序查询

SSMS 中的查询

当出现此错误时，我会在 SQL Profiler 中看到我通常期望看到的内容，其中应用程序查询恰好需要 30000 毫秒，并且在应用程序中出现异常。但是，有用的输出是堆栈跟踪与我在生产中看到的不同（上图）。

我正在阅读此堆栈跟踪，因为查询从未开始执行，因为它仍在尝试读取查询的元数据。但是，这与生产中的堆栈跟踪（在我看来）似乎处于从列读取数据的中间，但在执行过程中超时。

我也一直在阅读我们正在使用的 .NET 4.6.2 版本。我今晚会将所有内容升级到 4.7.2 以排除这种情况。（将 Web 服务器升级到 .net 框架 4.6.1 时与远程 SQL 服务器的连接中断）

我在设置应用程序的查询时间时遇到问题。我正在使用 spring-boot，我们实现了一个 Jdbc 模板来处理连接（连接池、Hikari、禁用）。我尝试通过以下方式在我的 DataSource 配置中设置查询超时连接：

jdbcTemplate.setQueryTimeout(10);

尽管我在调试应用程序时意识到设置已经完成，但这不起作用。似乎禁用了查询超时，因为我在查询中使用了 SLEEP 调用等待大约 5 分钟，并且没有收到查询超时异常。我在想也许是一些 DB2 驱动程序配置属性覆盖了我的连接配置。

我正在使用 ADODB interop DLL Version :6.0.0.0 连接任何类型的数据库。

CommandTimeout 为 3 秒 使用超时为 3 秒的命令对象打开记录集。

使用具有大量数据的 Oracle 数据库，当我输入选择查询时，它不会超时。

如何使执行查询超时？

我也尝试将命令超时设置为 1 秒，但仍然没有超时。

将连接超时设置为 3 秒（我知道这与命令超时不同，但仍然尝试过）

**在 MSSQl 数据库中，如果我在存储过程中插入 10 条缺少记录并在此之后进行选择查询，它实际上在执行过程时会超时，但如果我在过程中也只有选择查询，它不会超时。

当查询执行超过 3 秒时，我预计会出现超时错误。

在正常的 CRUD 操作中，我有一个带有少量繁重查询的应用程序。

我只是在解决一个问题，即一堆代码调用正在更改上下文的超时而不是重置它。在我运行我的长查询之后，我一般想留下正常的低超时。

对于大多数大型查询，管理超时非常简单，因为我将整个数据集拉入内存。所以我得到：

• 设置长超时
• 运行查询
• 完成查询
• 将内存中的数据具体化
• 将超时设置回它的旧默认值。

简单！吱。

但在一种情况下，数据集太大而无法一次性保存在内存中，因此我积极利用 EF 提供流式传输的事实 - 懒惰地迭代初始 IQueryable，将其作为 IEnumerable 传递，依次处理每个元素，使用 Linq 调用或yield return语句。

以前这很好，因为我设置了长超时，然后从不减少它（超时很大，所以它涵盖了查询的执行和所有处理）。但现在我想重置它。

如果我天真地这样做，代码执行将如下所示：

• 设置长超时
• 启动流式查询
• 将超时设置回它的旧默认值。
• 读取并使用返回的第一条记录。
• 读取并使用返回的最后一条记录。
• 流式查询已完成。

即超时重置后查询仍在执行。

我找不到任何关于 CommandTimeouts 如何与流式查询交互的文档。

有谁知道这是如何工作的？

上述元代码能否正常工作？

每个查询的命令超时是在查询启动时固定的，还是以其他方式完成的？

就此而言，我并不真正了解流式查询的实现细节。SQL Server 是否知道要对查询进行流式处理，还是什么？

我们可以全局设置查询超时吗（即在 DataSource 配置、spring 应用程序属性文件或某处）。因为我必须在我的项目中使用 Statement / PreparedStatement 的任何地方编写。

我只看到了两种设置查询超时的方法。但它一次只能使用一个preparedStatement/statement。见下面的代码。

我找不到任何解决方案。如果您知道在全局级别设置简单的 jdbc 查询超时，请告诉我

我需要通过一些代码运行查询。在 MSSMS 中运行查询需要一分半钟（对于超过 4M 的行不算太破旧）。在代码中，我打开连接

然后我可以创建CRecordset对象并运行查询。SELECT COUNT查询正常工作（给出〜4M）。第一个SELECT cols查询（获取一些属性）正常工作。它们各自CRecordset已正确关闭和清洁。第二个SELECT cols查询（返回 4M 行的大连接）每次尝试都会超时。

我不知道如何设置查询超时值，如何调用该参数，或者首先在哪里设置它。我在连接字符串中尝试了许多参数组合，我尝试编辑 ODBC 试点池选项。我对使用另一个 ODBC 连接对象不感兴趣，但我可以设置一个 DSN 并通过它进行连接，而不是使用直接连接字符串。

最坏的情况是最坏的情况，我只是将它全部分页，但现在很麻烦，而且由于查询可能超时，从逻辑上讲，也应该有一种方法来设置超时，我想知道它是什么。

我想知道我们需要传入的值的类型是public void setQueryTimeout(int queryTimeout)什么jdbcTemplate。文件说

想知道queryTimeout是否为milliseconds,seconds或minutes

我正在使用 Spring Boot 2.0.2.RELEASE 中的 spring-boot-starter-data-jpa，使用 spring-data-jpa。数据库是甲骨文。JDK 1.8。

我在@Transactional调用长时间运行的查询的方法之上使用。当事务超时设置为 1 时，事务在 1 秒内超时。当@Transactionnis to timeout > 1 时，没有超时异常。查询运行我们得到响应。这是我的代码的快照：

奇怪的是，当应用程序在调试模式下运行并且断点保留在对存储库方法的调用时，这会起作用。我试过以下

1. javax.persistence.query.timeout有提示也没有超时
2. server.connection-timeout=3s- 不工作
3. spring.jpa.properties.javax.persistence.query.timeout=10- 不工作
4. oracle.jdbc.ReadTimeout- 有效，但在指定时间不超时。

如果提到 100，那么它有时会在 1 分钟内抛出异常，有时会更少/更多。我们在 5 分钟后收到了 DB 的回复。我们想在此之前超时并向客户端发送超时响应。