「システム基盤構築のプロフェッショナル」レック・テクノロジー・コンサルティングJapanese | English

レック・テクノロジー・コンサルティング株式会社

技術ブログ

~技術ブログ ~

インスタンスケージングの罠 ~ cpu_count with Exadata ~

こんにちは、関根です。

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

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

おもむろに本番端末室に入り、おもむろに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がいくつかあります。

ExadataIndex Range Scanと言えば、Index削除!です。

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

その話はまたどこかで。

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

よかったよかった。

資料請求・お問い合わせはこちら

▲ ページトップに戻る

技術ブログ

2021年5月
« 2月  
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
採用に関するお問い合わせはこちら