2

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

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

我不相信 - 如果所有会话都忙于等待客户，CPU 怎么会这么高？我们无法始终如一地重现这些事件，所以我们真的在这里处于黑暗中......

有没有人见过这样的事情或有任何想法，建议这可能是由什么引起的？

谢谢

4

2 回答 2

1

您所描述的是“连接风暴”。配置不当的连接池将通过打开新连接来服务等待请求来“处理”缓慢响应的连接。这些额外的请求给已经承受压力的服务器带来了更大的压力（如果没有压力，初始连接就不会滞后）。这会引发一个糟糕的响应循环，从而产生额外的连接，最终杀死服务器。

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

一旦你阻止了连接风暴，你就可以专注于导致最初减速的数据库进程。

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

于 2012-12-26T18:06:33.613 回答
1

我遇到了一个类似的问题，我在这里记录了：Unkillable Oracle session waiting on "SQL*Net message from client" event。CLOB就我而言，问题是由绑定到CLOBs 似乎在 Oracle 中引起严重问题的位置的类型绑定变量引起的。以下语句产生与您观察到的相同行为：

CREATE TABLE t (
  v INT, 
  s VARCHAR2(400 CHAR)
);

var v_s varchar2(50)
exec :v_s := 'abc'

MERGE INTO t                      
USING (
  SELECT 
    1 v, 
    CAST(:v_s AS CLOB) s 
  FROM DUAL
) s 
ON (t.s = s.s) -- Using a CLOB here causes the bug.
WHEN MATCHED THEN UPDATE SET
  t.v = s.v        
WHEN NOT MATCHED THEN INSERT (v, s) 
VALUES (s.v, s.s);

可能在其他情况下，其他语句也会MERGE暴露这种行为，从而产生僵尸会话，因为 Oracle 似乎运行了一些无限循环，从而产生了观察到的 CPU 负载。

于 2015-07-24T09:30:54.217 回答