postgresql - jdbc-HikariCP:在DB/App cpu％仍然较低的情况下，看到较低的插入吞吐量

我已经设置了doobie+hikaricp，设置与默认设置类似。通过调试日志，我可以看到有多少连接处于活动/空闲状态，这也反映了pg_stat_activity通过这个查询返回的结果SELECT pid, query, query_start, stateFROM pg_stat_activity;HikariPool-1 - Pool stats (total=10, active=4, idle=6, waiting=0)我的应用程序主要通过在提交前通过一个包含3个插入和2个选择的事务将来自流的消息存储在数据库中来处理消息。以下是如何使用hikariCP创建交易人：val hikariConfig = new HikariConfig()hikariConfig.setJdbcUrl(dbUrl)hikariConfig.setDriverClassName("org.postgresql.Driver")hikariConfig.setUsername(dbUser)hikariConfig.setPassword(dbPassword)hikariConfig.setMaximumPoolSize(10)hikariConfig.setAutoCommit(false)hikariConfig.addDataSourceProperty("socketTimeout", "30")val dataSource: HikariDataSource = new HikariDataSource(hikariConfig)val transactor: HikariTransactor[IO] = HikariTransactor[IO](dataSource)然后，该事务处理程序被传递到任何地方以处理数据库事务：import doobie._import doobie.implicits._import doobie.postgres.implicits._val query = for { _ <- sql"insert into foo (id, value) values (fooId, 'b')".update.run _ <- sql"insert into bar (id, value) values (barId, 'b')".update.run _ <- sql"select * from bar where id = $barId".query[Bar].unique _ <- sql"insert into bazz (id, value1, value2) values (bazzId, fooId, barId)".update.run _ <- sql"select * from bazz where id = $barId".query[Bazz].unique} yield ()query.transact(transactor).unsafeToFuture()我看到的问题是查询看起来很快，但是插入吞吐量很慢。我注意到一些要点：在检查pg_stat_活动时，我看到许多提交查询（多于插入），每个查询的时间在~90ms-200ms之间。选择pid，now（）-pg_stat_activity.query_start作为duration，query，query_start，state FROM pg_stat_activity where state“idle”order by duration desc；上面的pg_stat_activity查询一次只返回4-8行，大多数结果是query='COMMIT'。从空流开始，吞吐量可以高达每分钟30k条消息。不过，15-20分钟后，吞吐量会下降到每分钟3k条消息，并且在流空了许多小时后才会重置恢复，因为重新启动应用程序或扩展应用程序的更多实例不会提高吞吐量。数据库和应用程序的CPU（10%）和Mem使用率（16%）都很低，因此理论上吞吐量应该会更高，有哪些领域值得研究？目前使用doobie 0.5.4，hikariCP 0.5.4更新：根据Laurenz的建议，在rds数据库上增加了commit_delay和commit_siblings设置，将高吞吐量的时间从长时间降低吞吐量之前的30分钟延长到60分钟。我开始测试提升max_wal_size，但这似乎会导致更高的吞吐量（有时非常低）不接近原始启动速率。 (adsbygoogle = window.adsbygoogle || []).push({}); 最佳答案 如果COMMIT需要很长时间，这显然表明您的I/O系统过载。如果问题不是I/O卷，那么可能是来自许多事务的许多WAL sync请求。一些选项：用更少、更大的事务执行工作。如果在发生崩溃的情况下，您能够承受丢失已提交事务的半秒，请将synchronous_commit设置为off。如果不能选择丢失提交的事务，请调整commit_delay和commit_siblings。这将使事务花费稍长的时间，但它可以减少I/O负载。 (adsbygoogle = window.adsbygoogle || []).push({});