为什么在分区表上选择查询要锁定并卡住

Question

我们设计了一个数据库，以便它能够接受大量的数据。为此，我们使用了相当多的分区表(因为我们处理数据库中的贸易信息的方式可以利用分区系统)。

更准确地说，我们有带分区的表，也有分区(4个级别)。

 main table
   -> sub tables partitioned by row 1 (list)
        -> sub tables partitioned by row 2 (list)
             ...

有4个主分区表。每个分区具有从40到120 (子)分区。

获取锁并被其他人锁定的查询是一个SELECT，它可以对这4个表进行连接。(因此，将分区计算在大约250个表上)

到目前为止，我们还没有遇到任何问题，也许是因为贸易的增加。现在，选择使用这些表(通常在20 to内执行)的查询，可以等待10秒，锁定并等待。当请求pg_stat_activity时，我看到这些查询是：

• wait_event_type : LWLock
• wait_event : lock_manager

我问了dev，并且在读取日志(主日志和副本)时也确认了，除了在这些表上进行select和insert / update查询之外，没有其他运行。

这些查询，选择查询，正在副本服务器上运行。

我以前试图在互联网上找到，但我发现的一切都是:是的，在分区表上有排他性锁，但是当有一些操作时，比如drop，附加/ dettach分区。在我的服务器上没有问题的时候。

服务器是12.4版，运行在AWS Aurora上。

是什么使这些查询锁定并等待这个LWLock？我有什么办法来改善这种行为呢？(帮助我的查询不要被锁定.)

编辑:添加一些我被问到的细节，或者这可能很有趣：

连接数: second

• during

• 通常:在峰值(问题出现时)由秒

• 打开的10个连接:从40到100个由打开的连接问题，打开的连接的麻木程度从100到200.

不等。

数据库的

• 大小: 30 Gb -目前许多分区为空。

Answer 1

您可能正遭受数据库资源的内部争用，这是由于太多的连接都在竞争使用相同的共享数据结构。很难用所提供的很少的信息来精确地确定确切的资源，但是大量的连接是一个强有力的指示。

您需要的是一个连接池来维护少量的持久数据库连接。这将同时减少有问题的争用，并消除在打开大量短期数据库连接时浪费的性能。您的总体吞吐量将增加。

如果应用程序中没有内置连接池，请使用pgBouncer。