8

我有两台服务器连接到PostgresSQL 9.6Azure 上托管的数据库。SELECT 1服务器正在做一件事——每 5 秒查询一次Postgres 数据库。

连接到 db 并获取数据的典型时间:

  • 节点:25 MS
  • .NET Core 3.1 使用 Npsql 4.1.1(我也尝试过 4.1.2,没有差异):500 MS

我的问题是我的 .NET Core 应用程序在获取数据方面比 Node慢 20 倍。相信.NET Core 出于某种原因没有汇集连接。在本地运行应用程序和在 Azure 应用程序服务上运行应用程序时都会出现这种缓慢 - 没有区别。我想解决 .NET --> Postgres 的缓慢问题。

请只浏览相关细节,不要在此之前阅读全部内容 - 我相信只有.NET Core代码是相关的。

APsPing从我的机器到数据库(应用程序Node.NET Core应用程序都在其上运行:

Connecting to foobarPostGres:5432 (warmup): from someIp: 19.98ms
Connecting to foobarPostGres:5432: from someIp: 1.65ms
Connecting to foobarPostGres:5432 from someIp: 1.18ms
Connecting to foobarPostGres:5432: from someIp: 1.23ms
Connecting to foobarPostGres:5432: from someIp: 1.06ms

为了完整起见,NODE时间示例如下所示(请注意,它第一次建立连接时也是“慢”):

Attempting to establish a connection...
Elapsed ms:  644.1334999799728
RESP:  { '?column?': 1 }
Elapsed ms:  22.76109904050827
RESP:  { '?column?': 1 }
Elapsed ms:  21.984400033950806
RESP:  { '?column?': 1 }
Elapsed ms:  26.043799996376038
RESP:  { '?column?': 1 }
Elapsed ms:  22.538798987865448
RESP:  { '?column?': 1 }

连接时间.NET Core如下所示:

5:13:32 PM: SLOW QUERY, CONN TIME: 4153, QUERY TIME: 18 
5:13:53 PM: SLOW QUERY, CONN TIME: 707, QUERY TIME: 17 
5:14:14 PM: SLOW QUERY, CONN TIME: 589, QUERY TIME: 16
5:14:35 PM: SLOW QUERY, CONN TIME: 663, QUERY TIME: 18 
5:14:56 PM: SLOW QUERY, CONN TIME: 705, QUERY TIME: 16 

注意超慢的初始连接时间和长时间建立后续请求的连接。

无论如何,因为我很绝望,我现在要转储我所有的代码,并附上解释。连接字符串如下所示:

public static string CONNECTION_STRING {
  get {
    return $"Server={HOST}; User Id={USER}; Database={DB_NAME}; Port={PORT}; Password={PWD}; SSLMode=Prefer";
  }
}

我的理解是,如果我使用这个连接字符串,我应该开箱即用地使用连接池。请注意,我已经尝试打开SSL两个数据库并将该行取出 - 它没有帮助。

我的健康检查控制器如下所示:

// GET api/health/getdbhealthselectone
[HttpGet]
[Route("getdbhealthselectone")]
public async Task<IActionResult> GetDbHealthSelectOne()
{
  int testData = await _healthCheckRepo.RunHealthCheckSelectOne();
  return Ok(testData);
}

我的健康检查回购方法如下所示:

 public async Task<int> RunHealthCheckSelectOne()
    {

      await using var conn = new NpgsqlConnection(AzureDbConnectionInfo.CONNECTION_STRING);

      var connTimer = System.Diagnostics.Stopwatch.StartNew(); // TODO: Remove this testing line
      await conn.OpenAsync();
      connTimer.Stop(); // TODO: Remove this testing line
      var msToConnect = connTimer.ElapsedMilliseconds; // TODO: Remove this testing line

      int testData = 999;
      var jobsQueryTimer = System.Diagnostics.Stopwatch.StartNew(); // TODO: Remove this testing line0
      await using (var cmd = new NpgsqlCommand("SELECT 1", conn))
      await using (var reader = await cmd.ExecuteReaderAsync())
      while (await reader.ReadAsync()) {
        testData = reader.GetInt32(0);
      };

      jobsQueryTimer.Stop(); // TODO: Remove this testing line
      var msToQuery = jobsQueryTimer.ElapsedMilliseconds; // TODO: Remove this testing line

      LogQueryIfSlow(msToConnect, msToQuery, _logger); // TODO: Remove this testing line

      return testData;
    }

请注意这里的计时器 -await conn.OpenAsync();到目前为止大部分时间都是如此,查询本身很快。另外,为了节省时间——我async之前没有运行过这段代码,没有区别。

最后,如果存在依赖注入问题,存储库位于类库中,API 项目引用它,并且:

services.AddSingleton<IHealthCheckRepository, HealthCheckRepository>();

这就是它的看法。

我相信这是所有相关信息 - 我一直在与 Azure 支持通话,他们发现 db 配置没有问题。.NET Core 应用程序非常轻巧,所以它不像是超载并且正在测试中,所以除了我的测试之外没有流量。

额外:为了完整起见,这是我的整个节点应用程序,它访问数据库并发布性能(取出连接数据)。

const { Pool, Client } = require('pg');
const { performance } = require('perf_hooks');

const pool = new Pool({
  user: 'SECRET',
  host: 'SECRET',
  database: 'SECRET',
  password: 'SECRET',
  port: 5432,
})


function runQuery(pool) {
  var t0 = performance.now();
  pool.query('SELECT 1', (err, res) => {
    if (err) {
      console.log('ERROR: ', err.stack)
    } else {
      console.log('RESP: ', res.rows[0])
    }
    var t1 = performance.now();
    console.log('Elapsed ms: ', t1-t0);
    //pool.end()
});

}

setInterval(() => {runQuery(pool)}, 5000);

编辑:对于后代,这是修复连接池超时后 .NET Core 中的时间 - 它比节点快,除了在初始连接上,这似乎需要一段时间,但我没有检查一些默认值:

CONN: 1710 QUERY: 18
CONN: 0 QUERY: 16
CONN: 0 QUERY: 16
CONN: 0 QUERY: 17
CONN: 0 QUERY: 16
CONN: 0 QUERY: 23
CONN: 0 QUERY: 16
CONN: 0 QUERY: 16
CONN: 0 QUERY: 23
CONN: 0 QUERY: 16
CONN: 0 QUERY: 16
4

3 回答 3

10

您需要设置最小池大小。这样做可确保无论池使用情况如何,此数量的连接都对数据库保持开放。

默认情况下(至少对于NPGSQL),最小大小为 0,因此如果有一段时间不使用连接,它将被关闭。

在您的测试中,您每 5 秒调用一次,这并不多,并且池可能会决定关闭未使用的连接。根据文档,它应该保持打开 300 秒,而不仅仅是 15

于 2020-01-23T15:40:37.380 回答
3

第一个电话几乎比其他电话长了 5 秒。对我来说,这看起来像是一个 IP 地址解析问题。它首先选择一个对给定服务器有缺陷的方法,然后在 5 秒后超时并选择另一种有效的方法。然后它会被缓存一段时间,因此会继续正常工作,直到缓存的条目过期。

要查看这是否是问题所在,请将数据库主机的 IP 地址硬编码到您的“主机”文件中,然后查看是否可以解决问题。如果是这样,那么根本原因将成为您的网络工程师的问题。

在数据库方面,您可以打开慢查询日志记录,log_min_duration_statement或者更好auto_explain.log_min_duration。但如果我的理论是正确的,这不会显示任何东西。数据库不知道您花了多长时间尝试查找其 IP 地址。

于 2020-01-05T19:32:04.890 回答
2

有可能第一次查询需要将大量数据从磁盘带入内存,而随后的执行发现所有内容都已在共享缓冲区中。你可以通过运行知道这一点

EXPLAIN (ANALYZE, BUFFERS) <your query>

“读取”和“命中”的数量将告诉您从磁盘读取了多少,以及在 RAM 中命中了多少。

于 2020-01-06T08:06:16.020 回答