Django 多处理应用程序的最佳PostgreSQL隔离级别

我有一个应用程序，可以启动多个进程，从几个PostgreSQL表中读取大量数据进行数字运算，然后将结果存储在单独的表中

当我仅用一个进程进行测试时，它的速度非常快，占用了几乎100%的CPU，但当我尝试在一台8核机器上使用8个进程时，所有进程都占用了大约1%的CPU，整个任务似乎需要更长的时间

当我检查

pg_stat_activity

时，我看到几个连接被列为“in transaction”。根据一些建议，我查看了

pg_锁

，在几十个只读表上看到了数百个“AccessShareLock”锁。基于，我认为这是默认设置，但我认为这会导致进程彼此步履蹒跚，否定了多处理的任何好处

---

是否有更有效的隔离级别可供使用，或者有更好的方法来优化PostgreSQL以允许对多个进程进行更快的只读访问，从而使每个进程都不需要锁定表？具体来说，我使用Django作为我的ORM。

不确定是什么限制了多核，但它与隔离级别无关。即使您有并发写操作

使用MVCC并发控制模型的主要优点 而不是锁定是MVCC中为查询而获取的锁 （读取）数据与为写入数据而获取的锁不冲突， 因此，阅读永远不会阻碍写作，写作永远不会阻碍阅读。 PostgreSQL即使在提供最严格的 通过使用创新的 可序列化快照隔离（SSI）级别

我的

当然，阅读也永远不会阻碍阅读

也许您需要在服务器上重新配置？默认配置通常为保守配置。另一方面，在多用户环境中，某些参数不应设置得太高。我想到了。查看列表以了解更多信息

最后：

Django是我的朋友

---

ORM通常试图保持平台独立性，但未能充分发挥特定RDBMS的潜力。它们是原始的拐杖，不能很好地进行性能优化。

最好使用另一种存储。Postgres针对事务性系统进行了优化，而事务性系统可能位于问题域的另一侧。HDF呢？当你说“只读表”时，你是说这些表对你的应用程序是只读的，还是对所有应用程序都是只读的？很难说瓶颈是什么，但AccessShareLock肯定不是。“事务中空闲”表示瓶颈在应用程序中，而不是数据库中。“top”中的顶级流程是什么？他们在等吗？一般说来都是公平的，但最后一点我不同意。Django的ORM绝不是原始的或拐杖。