在 java 应用程序中使用 oracle jdbc 驱动程序获取 CLOB 时,temporaryLobs 中的内存会出现奇怪的增长

发布于 2025-01-17 15:03:38 字数 1002 浏览 3 评论 0原文

晚上大家。

varchar 字段切换为 clob oracle 数据库中的 clob 在Java应用程序中的 clob

(我们使用oracle.jdbc.driver带有bonecp连接池 + spring jdbctemplate)

heapdump显示(请参阅图片)

extremarylobscom。 jolbox.benecp.connectionPartition-> freeconnections

更精确地包含在 elemaryLobs.elementData 阵列中的数据,该数组不断增长(根据JVM指标,带有内存使用和手动堆积的JVM指标)。

ElementData看起来像

在OOM的时刻,池中的每个连接大约有50MB(30+实际连接),带有填充的 emermaryLobs ,因此我们仅获得1GB+数据,仅用于连接池。

似乎某种clob“缓存”?

我将尝试通过与闪光的调试中的库代码进行斗争,并找到正在发生的事情,但是MB对于某些属性和数据类型和这些温度群之间的情况可能会有某种众所周知的配置或某种比例。

提前致谢。

Goodday everyone.

Faced strange OOM after switching from reading varchar field to clob from Oracle database in java application.

(We are using oracle.jdbc.driver with bonecp connection pool + spring jdbctemplate)

Heapdump shows(see picture)

temporaryLobs in heapdump

that memory stays in temporaryLobs fields inside a com.jolbox.bonecp.ConnectionPartition->freeConnections

More precisely data contained in temporaryLobs.elementData array which constantly grows (according to jvm metrics with memory used and manual heapdumps).

elementData looks like
enter image description here

At moment of OOM, there was approximately 50Mb for each connection in pool (30+ actual connections), with populated temporaryLobs so we got 1Gb+ data only for connection pool.

It seems like some kind of clob "cache"?.

I will try to struggle through library code on debug with breakpoins and find what is going on, but mb there can be some kind of well known configuration for such scenario or some kind of ratio between some properties and datatypes and those temp lobs.

Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

陌路终见情 2025-01-24 15:03:38

我们的问题略有不同,但由于大量的障碍而引起的OOM。我们通过用clob.free()手动释放clobs来解决问题。
我们希望它们在关闭结果集后将其关闭/释放。因此,我们将它们存储在列表中,直到重新塑造关闭并检查了clobs的免费变量。仍然是错误的。我们的解决方案是通过clobs的列表进行迭代,并在关闭结果集后拨打每个列表。

也许这也将解决您的问题。

We had a slightly different problem but also OOMs due to a high amount of clobs. We solved the problem by freeing the clobs manually with clob.free()
We expected them to be closed/freed after closing the resultset. So we stored the them in a list up to the part where the resulset got closed and checked the free variable of the clobs. It was still false. Our solution is to iterate throuh the list of clobs and calling .free() on each of them after closing the resultset.

Maybe it will also solve your problem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文