gpt4 book ai didi

Oracle 更新/插入卡住,数据库 CPU 占用 100%,并发性高,来自客户端的 SQL*Net 等待消息

转载 作者:行者123 更新时间:2023-12-05 05:28:07 25 4
gpt4 key购买 nike

我们有一个针对 Oracle 11g 数据库在 Weblogic 上运行的 JavaEE 应用程序,使用瘦 JDBC 驱动程序。最近我们在生产中发生了一系列事件,更新和插入某个表时卡住或花费的时间比正常情况长得多,没有明显的原因。这导致应用程序使用越来越多的数据库连接(通常在连接池中空闲),数据库 CPU 和并发性激增(如在 OEM 中所见),整个数据库陷入停顿。在这些事件中,DBA 找不到插入和更新卡住的任何原因(没有数据库锁)。他们确实看到了很多“来自客户端的 SQL*Net 等待消息”事件。

他们的理论是,应用程序(jdbc 客户端)在插入/更新语句期间由于与数据库无关的原因以某种方式卡住了,同时没有确认数据库对这些语句的响应。事实上,应用程序继续发出越来越多的此类语句,占用越来越多的连接,这就是 CPU 和并发性飙升,导致数据库无响应的原因。

我不相信 - 如果所有 session 都忙于等待客户端,CPU 怎么会这么高?我们无法始终如一地重现这些事件,所以我们真的一无所知...

有没有人见过这样的事情或者有任何想法,这可能是由什么引起的?

谢谢

最佳答案

您所描述的是“连接 Storm ”。配置不当的连接池将通过打开新连接来为等待请求提供服务来“处理”响应缓慢的连接。这些额外的请求给已经承受压力的服务器带来了进一步的压力(如果没有压力,初始连接就不会滞后)。这会启动一个不良响应循环,产生额外的连接,最终杀死服务器。

您可以通过将数据源的最大容量设置为合理的值来避免连接 Storm 。 “合理”的定义会根据您的服务器的能力而有所不同,但它可能比您想象的要低。最好的建议是将最大容量设置为与初始容量相同的值。

一旦阻止了连接 Storm ,您就可以专注于导致初始速度变慢的数据库进程。


来自客户端的大量SQL*Net wait message 事件表明客户端正在做一些事情而没有联系数据库。这就是为什么您的 DBA 认为问题出在应用程序上。

关于Oracle 更新/插入卡住,数据库 CPU 占用 100%,并发性高,来自客户端的 SQL*Net 等待消息,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14043668/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com