Docker 中的 OOM 与 Spring Boot + H2 + JPA 和批处理答案

【问题标题】：OOM in Docker with Spring Boot + H2 + JPA and Batch ProcessingDocker 中的 OOM 与 Spring Boot + H2 + JPA 和批处理
【发布时间】：2020-06-18 13:29:27
【问题描述】：

java 应用程序在 docker 容器中运行。

rest 控制器和来自另一个微服务的文档临时存储在内部 H2 数据库中（在内存中）。然后在 tika 的帮助下处理这些并发送到下一个微服务。最后文件在内部数据库中被删除。

这一切都按预期工作。数据库中的文档大小在处理过程中不断增加和减少（在 H2 Web 控制台的帮助下进行控制）。

持久化文档类如下：

@Entity
@Table(name = "Document")
public class Document {
@Id
@GeneratedValue
Long id = 0L;
@Lob
private String content;
@Lob
private String contentHtml = "";
@ElementCollection
@MapKeyColumn(name = "name")
@Column(length=1000, name = "value")
@CollectionTable(name = "meta_attributes", joinColumns = @JoinColumn(name = "meta_id"))
@LazyCollection(LazyCollectionOption.FALSE)
private Map<String, String> metadata;
@Enumerated(EnumType.STRING)
private DocStatus status;

public Document() {
}

但问题是增加了 docker 容器的内存消耗。我们尝试使用 3 和 6GB 的 MEMORY_MAX。在这两种情况下，内存使用量都会缓慢增加，直到容器以状态 137（已杀死）退出。

处理了大约50000个文件后，表的状态如下：

借助 jmap 制作的关于容器内 jvm 的转储显示，大部分内存都被 MVMap（PageReferences）消耗，这似乎是从 H2 用于存储数据的：

我的问题：

这更可能是 H2 内部的一种内存泄漏，还是更可能是配置问题？我尝试将使用过的 JPARepository 方法从 .save() 更改为 .saveAndFlush() ，这并没有改变任何东西。我无法想象这与实体管理器有关，因为这都是由 Spring Boot 管理的。

【问题讨论】：

标签： java spring-boot docker spring-data-jpa h2

【解决方案1】：

更新：原因不在 H2 或 JPA 中，而是在错误的 docker-compose 配置中。我们确实为容器内运行的 JVM (-Xmx$MEMORY_MAX) 以及 docker 本身 (mem_limit) 分配了相同数量的内存。

将 JVM 的 MEMORY_MAX 设置为最大 mem_limit 的 80% 后，一切正常。

【讨论】：

【解决方案2】：

最可能的原因是你没有调用commit()，这意味着旧版本的数据永远不会被刷新

【讨论】：

在日志中激活休眠跟踪后，会发现很多语句，如下所示：删除持久实例 -> 提交 -> 自动刷新会话 -> 刷新：0 次插入，0 次更新，1 次删除1 个对象然后稍后：刷新实体和处理引用的集合 -> 删除集合：[ch.weblaw.textextractor.domain.Document.metadata#2] -> 通过 JDBC Connection.commit() 提交刷新和事务 -> 释放 JDBC 资源
所以，commiting 和 flushing 似乎到目前为止都有效，或者不能这样说吗？当然，要查看是否真的所有内容都已提交并不容易，但至少自动提交似乎正在工作。
而且不得不说我们项目中使用的是spring-boot-starter-data-jpa。所以我们只有一个扩展 JpaRepository 的 Repository 接口，然后使用 JpaRepository 附带的所有方法，如 save()、findAll()。这样就不用手动处理事务了，全部由Spring完成