Npgsql 间歇性连接超时可能原因

问：

我在 .net v6 应用程序中使用 npgsql 7.0.4 在 AWS Redshift 集群中执行存储过程，并且出现间歇性但定期的连接超时 - 此超时默认为 15 秒。

它发生在大约 1% 的对 proc 的调用中，我正在研究可能的根本原因可能是什么，因为返回的内部异常是标准的“System.TimeoutException：读取尝试期间超时”。

我已经打开了详细日志记录，并捕获了发生它的一个实例的跟踪：-

[2023-11-03 00:25:06.749203 +00:00 1-65443de2-2239e7486dd5a15b308838fc VRB] Attempting to connect to "host:5439"
[2023-11-03 00:25:06.756942 +00:00 1-65443de2-2239e7486dd5a15b308838fc VRB] SSL negotiation successful
[2023-11-03 00:25:06.756966 +00:00 1-65443de2-2239e7486dd5a15b308838fc VRB] Socket connected to "host":5439
[2023-11-03 00:25:21.752520 +00:00 1-65443de2-2239e7486dd5a15b308838fc VRB] Breaking connection

为了进行比较，这是它正常工作时的痕迹：-

[2023-11-03 07:51:18.539383 +00:00 1-6544a676-1da16696002d39652848e4c4 VRB] Attempting to connect to "host:5439"
[2023-11-03 07:51:18.544360 +00:00 1-6544a676-1da16696002d39652848e4c4 VRB] SSL negotiation successful
[2023-11-03 07:51:18.544390 +00:00 1-6544a676-1da16696002d39652848e4c4 VRB] Socket connected to "host":5439
[2023-11-03 07:51:18.822990 +00:00 1-6544a676-1da16696002d39652848e4c4 DBG] Opened physical connection to "host":5439/"db" (in 283ms)

当它工作时，从“套接字已连接”到“打开的物理连接”只需要几毫秒 - 当它失败时，您可以看到“套接字已连接”之后的 15 秒超时开始发挥作用。我也有针对此异常的重试策略，但第二次尝试也在 15 秒时以完全相同的方式失败。

我正在查看相应的红移日志表/视图，以查看服务器端可能发生的情况，但尚未找到任何内容。

我假设该问题与网络无关，因为它成功完成了套接字连接和 ssl 协商步骤，因此我已经下载了 Npgsql 代码并查看了 NpgsqlConnector 类以查看此时会发生什么 - 我不完全理解代码，但看起来有许多操作使用该连接超时，例如 conn。身份验证，DataSource.Bootstrap。

有没有人遇到过这种问题，或者知道发生这样的连接超时时通常的嫌疑人是什么？

我最初认为它与网络有关，但日志反驳了这一理论。此外，我不确定它是否像集群过载一样简单，因为操作通常需要毫秒级，而当它超时时，它有 2 次尝试，每次 15 秒。

我仍在调查红移方面，我可能会尝试将超时时间从 15 秒增加到 15 秒，但目前我仍然处于黑暗之中，如果有人有任何建议或以前的经验可以提供:)我将不胜感激