hibernate - 我怎样才能阻止 h2 如此频繁地阻止我的 hibernate 查询

Question

我已经通过 hibernate 为我的应用程序使用 h2 (1.3.172) 一段时间了，在解决了一些非 h2 性能问题之后，我的性能瓶颈是 h2。我的数据库非常简单，有 10 个表，每个表的记录量不到 100,000 条记录，在 h2 功能范围内也是如此，但我认为问题出在多线程上。

我实际上是在使用 hibernate/h2 来控制我的应用程序中的内存消耗。我的应用程序使用管道方法处理文件，对可以处理的文件数量没有限制，因此如果我将数据存储在内存中，我会很快遇到 OutOfMemory。每个文件通常经过十个处理阶段，每个阶段都有自己的执行器服务，当文件从一个阶段移动到另一个阶段时，它会作为相关执行器服务上的作业添加。内存中存储的数据很少，而是在执行程序上启 Action 业时从数据库中检索有关文件的数据，并在作业完成时将数据写回数据库。我们有 10 个执行器，每个执行器都有机器内核大小的线程池，所以在 4 个机器内核上，理论上我们可以随时向数据库发出 40 个请求，但通常情况下我们只有不到 10 个。所以我们有许多事务正在进行主要同时涉及少量行。

我的应用程序是多线程的，如果我对其运行分析器，我会发现大部分时间我的线程处于阻塞状态，等待 executeQuery() 或 executeUpdate()。我读到 h2 是单线程的，所以我认为问题是由 h2 同步请求引起的，而不是锁定，但我可能误解了这一点。我已经设置了 MVCC=TRUE 以便 h2 进行行锁定而不是表锁定，但我仍然会遇到偶尔的超时 - 是否可以设置一些东西来检查正在使用的锁。

我读到有一个 MULTI_THREADING 选项，但它不能与 MVCC 一起使用，这很遗憾，因为我觉得如果我删除 MVCC=TRUE 我需要两个选项，这意味着 h2 将在我每次插入或插入时锁定表更新，因为我只有几个表，它们几乎总是被锁定。

所以，我觉得可以大大减少阻塞，但我不清楚潜在的问题是什么以及如何进行

测试这是我的起点，测试用例需要 3 分 14 秒

3:14,FILE_LOCK=SOCKET;MVCC=TRUE;DB_CLOSE_ON_EXIT=FALSE

我尝试了各种组合，例如

3:02,FILE_LOCK=SOCKET;MVCC=TRUE;DB_CLOSE_ON_EXIT=FALSE;LOG=0;CACHE_SIZE=65536;LOCK_MODE=0;
2:56,FILE_LOCK=SOCKET;MVCC=TRUE;DB_CLOSE_ON_EXIT=FALSE;LOG=0;;CACHE_TYPE=SOFT_LRU;LOCK_MODE=0;
1:05,FILE_LOCK=SOCKET;DB_CLOSE_ON_EXIT=FALSE;LOCK_TIMEOUT=10000

我发现唯一产生巨大差异的是删除了 MVCC=TRUE 选项，但不幸的是我的锁超时次数从几乎为零增加到加载，所以不幸的是一些所需的处理没有发生，这可能是总时间更快的原因 因为应用程序中的某些阶段未完成，或者使用 MVCC 会减慢速度。

我尝试使用 MULTI_THREADED=TRUE 但它似乎对我根本不起作用

关于在多核系统中的使用

我刚刚阅读了 MULTI_THREADED 选项的解释 https://groups.google.com/forum/#!topic/h2-database/VoE3AU7mSuM

托马斯说

The default is "not multi-threaded" meaning only one statement can run at any time (per database). There is a synchronized block around running a statement. When multi-threaded is enabled, then the synchronized statement is on the session (connection) instead of on the database object.

The option is to increase concurrency, not throughput. The default setting is usually not a problem except if you have long running queries.

如果我理解正确，这意味着当禁用时，虽然 h2 可以接受多个连接，但它一次只会处理一个查询，但即使启用它，它也会在查询中途交换，但实际上仍然只是一次处理一个查询，即它可以开始处理查询 1，然后交换到查询 2，然后返回查询 1 等等，但永远不会实际使用 cpu 并行处理查询 1 和查询 2。

所以在任何一种情况下，尽管在 cpu 之间切换，它在任何时候都只会使用一个 cpu。因此，如果您有一台功能强大的机器，例如有 16 个内核，而瓶颈是数据库，那么添加更多内核根本无济于事因为 h2 一次只使用一个内核？

这似乎是一个真正的限制，我想知道它与 Derby 或任何其他嵌入式 Java 数据库相比如何。

Answer 1

有些线程被阻塞，可能是，是的，但我会首先专注于那些未被阻塞的线程，这意味着它们正在消耗 CPU时间或磁盘 I/O。那些陈述是什么？他们是不使用索引的查询吗？你有索引吗？或者您是否不必要地插入/删除行？另请参阅有关 how to analyze performance problems 的文档.