2

シンJDBCドライバーを使用して、Oracle 11g DBに対してWeblogicで実行されているJavaEEアプリがあります。最近、明確な理由もなく、特定のテーブルへの更新と挿入が停止したり、通常よりもはるかに時間がかかるという一連のインシデントが本番環境で発生しました。これにより、アプリケーションはますます多くの DB 接続を使用し (通常は接続プールでアイドル状態)、DB CPU と同時実行性が急上昇し (OEM で見られるように)、DB 全体が停止しました。これらのインシデントの間、DBA は挿入と更新が停止する理由 (db ロックなし) を見つけることができませんでした。彼らが目にしたのは、多くの「クライアントからの SQL*Net 待機メッセージ」イベントでした。

彼らの理論は、アプリケーション (jdbc クライアント) が、これらのステートメントに対する DB の応答を確認せずに、DB とは関係のない理由で挿入/更新ステートメント中に何らかの形でスタックしたというものです。そして、アプリがこれらのステートメントをますます発行し続け、ますます多くの接続を拘束したという事実が、CPU と同時実行性が急上昇し、DB が応答しなくなった理由でした。

私には確信が持てません。すべてのセッションがクライアントの待機でビジーだった場合、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。私の場合、問題は、Oracle で深刻な問題を引き起こすと思われるCLOB場所にバインドされた型のバインド変数が原因でした。CLOB次のステートメントは、観察したのと同じ動作を生成します。

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おそらく、オラクルが観測された CPU 負荷を生成する無限ループを実行しているように見えるため、ゾンビ セッションを生成するこの動作を公開する以外のステートメントで他の機会が存在する可能性があります。

于 2015-07-24T09:30:54.217 に答える