Java应用程序正在docker容器中运行。
休息控制器和其他微服务接收到的文档临时存储在内部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容器的内存消耗。我们尝试使用3GB和6GB的MEMORY_MAX。在这两种情况下,内存使用缓慢增加,直到容器退出并显示状态137(已杀死)。
处理大约5万个文件后,表的状态如下:
借助jmap进行的有关容器内部jvm的转储显示,大多数内存已被MVMap(PageReferences)占用,似乎从H2用于存储数据:
我的问题:
这是否更可能是H2内部的一种内存泄漏,还是更有可能是配置问题?我试图将使用过的JPARepository方法从.save()更改为.saveAndFlush(),但没有任何改变。我无法想象这与实体管理器有关,因为它们全部由Spring Boot管理。
更新:原因不是在H2或JPA中,而是在错误的docker-compose配置中。我们确实为运行在容器内的JVM(-Xmx $ MEMORY_MAX)和docker本身(mem_limit)分配了相同数量的内存。
将JVM的MEMORY_MAX设置为最大mem_limit的80%后,一切正常。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句