こんにちは、関根です。

ある日、「何やら遅いですね...」という知らせが届きました。

どうやら全体的にスローダウンしているようです。
特にエラーが発生しているわけでもないようです。

おもむろに本番端末室に入り、おもむろにvmstatを叩いてみます。

構成はExadata 4ノードのRAC構成ですが、CPU使用率は全サーバとも8%～9%程度。
CPUは問題なさそうです。
I/Oも問題ありません。

Enterprise Manager Cloud Control 12cから、
長時間実行されているSQLがないか覗いてみます。
 
こういうときだけは、Enterprise Managerは便利です。
（Exadataの監視用として使うと最低ですが・・・）

あれ、Enterprise Managerにはログインできるけど、各Exadataサーバにはログインできない（時間がかかっているようだ）。。。

CPU使用率は相変わらず8%～9% ・・・
4台とも・・・
ほぼ固定・・・
増えもせず、減りもせず・・・

んーーー

・・・おかしい・・・

・・・これは、もしや・・・

「CPU使いきってますねー」

そう、今後複数のDBが追加される予定だったので、
他のDBに影響を及ぼさないようにインスタンスケージングの設定をしていました。
インスタンスケージングとは、インスタンス毎にリソースの使用制限ができる機能です。

具体的には、初期化パラメータで以下の設定を入れていました。
cpu_count=2
（4ノード合計で8）

Exadata（X2-2)のコア数は24（Hyper-Thread込み）です。

さて、電卓を起動して計算してみましょう。

2/24=0.08333333333333333333333333333333

ゾッとしますね。

8.3%

ですって。

 

一時的にインスタンスケージングを外してみます。
やり方は簡単。オンラインでできます。

alter system set cpu_count=24;

実行直後、CPU使用率が上がりだしました。
最高で45%くらい。

インスタンスケージングを使用した場合の見かけのCPU使用率には注意しましょう！

 

で、終わりではありません。
CPUを高騰させているSQLが存在するに違いありません。
CPUは足りるはずなのです。
そういう見積もりなのです。
そうでなくては困るのです。

ようやくEnterprise Managerからログインできたので調べてみると・・・
いました。
Index Range Scan でやたら時間がかかっているSQLがいくつかあります。

ExadataでIndex Range Scanと言えば、Index削除！です。

Smart Scanを効かせましょう。
他のベンダに真似できないものを1つ挙げろと言われたら、これ。Smart Scan。

その話はまたどこかで。

Indexを削除したら、無事速くなりました。
CPU使用率もほぼ5%以下。

よかったよかった。