我们最近使用Hibernate和EntityManager(没有Spring)实现了数据库绑定,以便将记录写入数据库。为简单起见,我将仅讨论仅插入的过程的变化。 (另一个非常相似的过程会更新现有记录一次以设置状态,但除此之外,只需插入一堆记录。)
此进程每个事务可以插入多达10,000条记录,但平均值小于该值,可能至少减半。我们可能会在同一个JVM下同时在不同的线程中运行这个进程的几个实例。
我们遇到了一个生产问题,其中运行该流程的服务是将机器上的所有24个核心锁定。 (他们增加了12只是为了试图适应这种情况。)我们已经将这种高利用率缩小到了Hibernate。
我花了几天时间研究,除了使用hibernate.jdbc.batch_size和hibernate.order_inserts之外,找不到任何可以改善我们性能的东西。不幸的是,我们使用IDENTITY作为我们的生成策略,因此Hibernate可以/不会批量插入这些插件。
我花了几天时间研究,在进行大量插入时没有找到任何其他性能提示。 (我已经看过很多关于读取,更新和删除的提示,但很少有关于插入的提示。)
我们有一个根JobPO对象。我们只需在其上调用merge,并通过级联注释处理所有插入。我们需要在一次交易中完成这项工作。
我们只插入了8个不同的表,但记录的层次结构有点复杂。
public void saveOrUpdate(Object dataHierarchyRoot) {
final EntityManager entityManager = entityManagerFactory.createEntityManager();
final EntityTransaction transaction = entityManager.getTransaction();
try {
transaction.begin();
// This single call may result in inserting up to 10K records
entityManager.merge(dataHierarchyRoot);
transaction.commit();
} catch (final Throwable e) {
// error handling redacted for brevity
} finally {
entityManager.close();
}
}
我们只创建一次EntityManagerFactory。
有什么想法吗?
附加说明:
没有人抱怨使用太多内存的过程
对于只进行插入的进程的变化,我们可以使用“persist”而不是“merge”。我们正在共享代码,所以我们进行合并。我试着转而坚持没有明显改善。
我们的注释会在一些字段上产生双向级联。我尝试删除这些,但对Hibernate不熟悉,无法正确保存。但据我所知,这似乎不会导致插件的性能下降。我没有使用明确的“反向”设置,因为这似乎对插入也无关紧要。不过,我对这两方面都有点不稳定。这个领域还有改进的空间吗?
我们在单个事务中运行SQL事件探查器。似乎没有什么不妥,我没有发现改进的余地。 (有大量的exec sp_prepexec语句,与插入的记录数大致相同。这就是报告的全部内容。)
在生产中表现出这种行为的代码是在commit()之前显式调用entityManager.flush()。我在本地环境中删除了该代码。它没有明显的改进,但我不会再添加它,因为我们没有理由调用flush()。
答案 0 :(得分:4)
如果您要为要保存的每个对象打开和关闭一个会话,那么对于10k个对象,您实际上是打开和关闭10k会话,刷新10k次并进入数据库进行10k次往返。
你至少应该batch multiple entities:
for (Object entity: entities) {
if(entity.getId() == null) {
entityManager.persist(entity);
} else {
entityManager.merge(entity);
}
if ((i % batchSize) == 0) {
entityManager.getTransaction().commit();
entityManager.clear();
entityManager.getTransaction().begin();
}
}
entityManager.getTransaction().commit();
em.getTransaction().commit();
在此示例中,您实际上使用的是一个数据库连接,因此即使您使用连接池,您也不必获取/释放10k数据库连接。达到batchSize
阈值后会清除会话,从而减少JVM垃圾回收。
如果您在会话中存储10k个实体并立即提交事务,则会遇到以下问题:
答案 1 :(得分:0)
那么,您应该避免在每次更新时打开和关闭连接,因为它会影响性能。相反,您可以将持久性提供程序配置为使用批处理并设置合理的数字,然后执行批量更新。
<persistence-unit name="pu" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.OracleDialect"/>
<property name="hibernate.connection.username" value="***"/>
<property name="hibernate.connection.password" value="***"/>
<property name="hibernate.connection.driver_class" value="oracle.jdbc.OracleDriver"/>
<property name="hibernate.connection.url" value="jdbc:oracle:thin:@***"/>
<property name="hibernate.jdbc.batch_size" value="100"/>
</properties>
</persistence-unit>
这允许在您更新/插入循环时在单个命令中向数据库发送多个更新查询(对您来说是透明的)。
Session session = SessionFactory.openSession();
Transaction tx = session.beginTransaction();
for ( int i=0; i<100000; i++ ) {
Employee employee = new Employee(.....);
session.save(employee);
}
tx.commit();
session.close();
参考文献:http://www.tutorialspoint.com/hibernate/hibernate_batch_processing.htm
答案 2 :(得分:0)
解决方案(或者至少是一种大大降低CPU使用率的方法)是从merge切换到persist。我在帖子中提到过,我曾尝试过转换为持续存在而没有明显区别。
我随后找到了一种更好的方法来分析重载,并且能够显示出改进。对于我正在运行的特定负载,从持久性切换到合并,将平均CPU百分比从16降低到5。
我们不需要合并。对于永久性修复,我们需要稍微重新编写代码,以便能够使用相同的EntityManager来加载根对象,然后将其持久化(然后将级联完整的“树”结构)。这样,我们的对象不会分离,我们不需要使用merge。
感谢ddalton指向那个方向。