Postgres 和 .Net - 连接池 - 最佳实践
Postgres and .Net - Connection Pooling - Best Practices
我有一个 .Net Core (C#) 应用程序,它通过 websocket 接收用户请求,然后创建一个到 PostgreSQL 数据库的连接到 manipulate/handle 数据。
当用户向后端发出新请求时,调用的端点函数会创建一个新的 SQL 连接和 运行 查询:
// Endpoint available via Websocket
public async Task someRequest(someClass someArg)
{
/* Create a new SQL connection for this user's request */
using var conn = new NpgsqlConnection(connstr.getConnStr());
conn.Open();
/* Call functions and pass this SQL connection for any queries to process this user request */
somefunction(conn, someArg);
anotherFunction(conn, someArg);
/* Request processing is done */
/* conn is closed automatically by the "using" statement above */
}
此请求完成后,using
语句关闭连接。但是,此连接默认返回到 Postgres“连接池”并显示为空闲。
由于这里的每个新用户请求都会创建一个新的 SQL 连接,因此连接池中那些旧的“空闲”SQL 连接将不再使用。
目前:
- 由于这些空闲连接累积起来并达到最大池大小,我暂时将空闲连接超时设置得很低。否则这些空闲连接会堆积起来并达到打开连接的人为上限。
- 我也试过将
Pooling=false
添加到连接字符串。我的理解是,一旦 .Net 应用程序关闭,这将阻止连接空闲,但它似乎仍在空闲。
问题:在 .Net/C# 中处理 Postgres 连接池的最佳实践是什么?
- 如果我能更恰当地利用 Postgres 连接池,重用已打开的连接会比为每个用户请求创建一个新连接更有效。
- 我的想法是拥有一个功能来创建新的 Postgres 连接,跟踪它们,并在用户发出新请求时将它们分发给调用者。这是个糟糕的主意吗?
- 或者,我是否只是像现在这样保持池 disabled/a 非常低的空闲超时并为每个请求创建一个新的 SQL 连接?
除了我正在做的事情之外,我找不到很多正确使用 Postgre 连接池的例子。这个应用程序在任何时候平均有 3,000-4,000 个并发用户,所以我无法让一个静态连接处理所有事情。在 .Net 中处理此问题的最佳做法是什么?
编辑
所以看起来池化是 NPGSQL 而不是 Postgres 的原生方式。如果使用相同的数据库、用户和密码建立新连接,它将使用空闲的“池化”连接之一,而不是打开另一个连接。
问题是在我禁用池之前它似乎没有这样做。有一个垃圾邮件错误导致应用程序在晚上关闭了一个小时或更长时间。
The connection pool has been exhausted, either raise MaxPoolSize (currently 100) or Timeout (currently 15 seconds)
现在它可能确实需要同时有 100 多个活动连接...但我猜大多数连接都是空闲的,就像我之前看到的那样。
编辑#2
所以我现在尝试允许池化(默认),它似乎会立即启动空闲连接,因为它们是由请求创建的,但不会重新使用这些连接。一旦达到最大池上限,应用程序就会由于无法创建新的 connections/requests 而锁定。
DBeaver Img - 服务器会话:
这里的红色是活动连接,蓝色是空闲。
应用程序中的每个 SQL 连接都是从 single/shared 连接字符串环境变量创建的。
Host=IP;Port=somePort;Username=someUser;Password=somePass;Database=someDb;Maximum Pool Size=100
我能够保持应用程序 运行ning 的唯一方法是将 idle_in_transaction_session_timeout
设置为 '10s'
以经常清除空闲连接,因为池似乎不起作用。
当我让 postgres 清除与 idle_in_transaction_session_timeout
和 Pooling=false
的空闲连接时,这就是我的数据库 activity 的样子:
我也在我的代码中 运行 搜索,每个建立新 SQL 连接的实例也有 using
语句。如上面的代码示例所示。这应该可以防止任何类型的连接泄漏。
是否有某种 postgres 配置项会导致此问题?连接字符串每次都一样,每个连接都有C#using
语句。我不确定为什么 NPGSQL 在启用池时不重新使用这些空闲连接。
我已经在我的开发服务器上测试了循环发送垃圾邮件新连接,并且池似乎工作得很好。所以我可以说我使用的 using 语句格式没有问题。但是,如果我现在在我的生产服务器上启用池,空闲连接会立即向上发送垃圾邮件,如图所示并达到上限,不允许新连接。生产服务器的指标显示每秒约 1,000 t运行 次操作,每秒约 4-5 个活动 SQL sessions/connections。有没有可能我真的需要增加最大池限制?
问题最终似乎与 Postgres 数据库配置本身有关。我们收到了很多 pq: could not resize shared memory segment. No space left on device
个错误。
数据库在 Docker 容器中运行。我将容器的 shm_size
增加到 6gb
以利用它 运行 上的更多资源。
从那里开始,在数据库本身的 postgresql.conf
文件中,关于将 shared_buffers
和 max_connections
设置为什么似乎存在很多困惑。
对于 shared_buffers
,根据 postgres 文档,它被设置为 shm_size
的 1/4:1500M
。此 使用 设置为 128M
,这对于容器内存大小来说太低了。
对于 max_connections
,这已降低回默认值 100
。即使有约 3000-5000 个并发用户,后端在任何给定时刻也仅使用 5-10 个活动连接。
希望这些配置项可以在将来帮助其他人。
我有一个 .Net Core (C#) 应用程序,它通过 websocket 接收用户请求,然后创建一个到 PostgreSQL 数据库的连接到 manipulate/handle 数据。
当用户向后端发出新请求时,调用的端点函数会创建一个新的 SQL 连接和 运行 查询:
// Endpoint available via Websocket
public async Task someRequest(someClass someArg)
{
/* Create a new SQL connection for this user's request */
using var conn = new NpgsqlConnection(connstr.getConnStr());
conn.Open();
/* Call functions and pass this SQL connection for any queries to process this user request */
somefunction(conn, someArg);
anotherFunction(conn, someArg);
/* Request processing is done */
/* conn is closed automatically by the "using" statement above */
}
此请求完成后,using
语句关闭连接。但是,此连接默认返回到 Postgres“连接池”并显示为空闲。
由于这里的每个新用户请求都会创建一个新的 SQL 连接,因此连接池中那些旧的“空闲”SQL 连接将不再使用。
目前:
- 由于这些空闲连接累积起来并达到最大池大小,我暂时将空闲连接超时设置得很低。否则这些空闲连接会堆积起来并达到打开连接的人为上限。
- 我也试过将
Pooling=false
添加到连接字符串。我的理解是,一旦 .Net 应用程序关闭,这将阻止连接空闲,但它似乎仍在空闲。
问题:在 .Net/C# 中处理 Postgres 连接池的最佳实践是什么?
- 如果我能更恰当地利用 Postgres 连接池,重用已打开的连接会比为每个用户请求创建一个新连接更有效。
- 我的想法是拥有一个功能来创建新的 Postgres 连接,跟踪它们,并在用户发出新请求时将它们分发给调用者。这是个糟糕的主意吗?
- 或者,我是否只是像现在这样保持池 disabled/a 非常低的空闲超时并为每个请求创建一个新的 SQL 连接?
除了我正在做的事情之外,我找不到很多正确使用 Postgre 连接池的例子。这个应用程序在任何时候平均有 3,000-4,000 个并发用户,所以我无法让一个静态连接处理所有事情。在 .Net 中处理此问题的最佳做法是什么?
编辑 所以看起来池化是 NPGSQL 而不是 Postgres 的原生方式。如果使用相同的数据库、用户和密码建立新连接,它将使用空闲的“池化”连接之一,而不是打开另一个连接。
问题是在我禁用池之前它似乎没有这样做。有一个垃圾邮件错误导致应用程序在晚上关闭了一个小时或更长时间。
The connection pool has been exhausted, either raise MaxPoolSize (currently 100) or Timeout (currently 15 seconds)
现在它可能确实需要同时有 100 多个活动连接...但我猜大多数连接都是空闲的,就像我之前看到的那样。
编辑#2 所以我现在尝试允许池化(默认),它似乎会立即启动空闲连接,因为它们是由请求创建的,但不会重新使用这些连接。一旦达到最大池上限,应用程序就会由于无法创建新的 connections/requests 而锁定。
DBeaver Img - 服务器会话: 这里的红色是活动连接,蓝色是空闲。
应用程序中的每个 SQL 连接都是从 single/shared 连接字符串环境变量创建的。
Host=IP;Port=somePort;Username=someUser;Password=somePass;Database=someDb;Maximum Pool Size=100
我能够保持应用程序 运行ning 的唯一方法是将 idle_in_transaction_session_timeout
设置为 '10s'
以经常清除空闲连接,因为池似乎不起作用。
当我让 postgres 清除与 idle_in_transaction_session_timeout
和 Pooling=false
的空闲连接时,这就是我的数据库 activity 的样子:
我也在我的代码中 运行 搜索,每个建立新 SQL 连接的实例也有 using
语句。如上面的代码示例所示。这应该可以防止任何类型的连接泄漏。
是否有某种 postgres 配置项会导致此问题?连接字符串每次都一样,每个连接都有C#using
语句。我不确定为什么 NPGSQL 在启用池时不重新使用这些空闲连接。
我已经在我的开发服务器上测试了循环发送垃圾邮件新连接,并且池似乎工作得很好。所以我可以说我使用的 using 语句格式没有问题。但是,如果我现在在我的生产服务器上启用池,空闲连接会立即向上发送垃圾邮件,如图所示并达到上限,不允许新连接。生产服务器的指标显示每秒约 1,000 t运行 次操作,每秒约 4-5 个活动 SQL sessions/connections。有没有可能我真的需要增加最大池限制?
问题最终似乎与 Postgres 数据库配置本身有关。我们收到了很多 pq: could not resize shared memory segment. No space left on device
个错误。
数据库在 Docker 容器中运行。我将容器的 shm_size
增加到 6gb
以利用它 运行 上的更多资源。
从那里开始,在数据库本身的 postgresql.conf
文件中,关于将 shared_buffers
和 max_connections
设置为什么似乎存在很多困惑。
对于 shared_buffers
,根据 postgres 文档,它被设置为 shm_size
的 1/4:1500M
。此 使用 设置为 128M
,这对于容器内存大小来说太低了。
对于 max_connections
,这已降低回默认值 100
。即使有约 3000-5000 个并发用户,后端在任何给定时刻也仅使用 5-10 个活动连接。
希望这些配置项可以在将来帮助其他人。