スキップしてメイン コンテンツに移動

IOUG (Collaborate11) in Florida 4th

 IOUGも3日目となり、ちょっと疲労も溜まってきましたが、何とか乗りきろうと思っています。

今日の目的は昨日に続いて、OraPubのShallahamerのセッションです。(結構、楽しく聞けるのと、非常に学術的なアンバランスが良い)



あとは、最初のIOUGで買ったOracle本がMike Ault著だったこともあり、IOUGに来ると何故か彼のセッションに出てしまいます。

ということで本日のセッションは以下。

Title      : Security Bootcamp: 60 Oracle Database Security Tips in 60 Minutes
Speaker    : Ursula Koski
Description: This session will be delivered in blazing speed. 60 Oracle Database Security Tips in 60 minutes.

Title      : Virtualization Bootcamp: Optimizing Oracle databases on VMware
Speaker    : Guy Harrison
Description: An increasing proportion of Oracle databases are running in virtual environments and many on VMWare ESX servers. Performance of databases in these virtual environments is subject to some unique considerations relating to the way VMware manages the shared CPU Memory and Disk resources.In this presentation well consider how to monitor and configure VMware to optimize Oracle database performance. Specifically well consider using memory reservations and limits to avoid ESX swapping and ballooning how to monitor VMware CPU overheads and how best to best to configure a high performance IO subsystem.

Title      : Unifying Time Base Performance Analysis
Speaker    : Craig Shallahamer
Description: N/A

Title      : Out of the Black Box - Validating your IO Subsystem
Speaker    : Mike Ault
Description: In this presentation I will show techniques to validate the IO subsystem. The presentation will discuss the various types of IO subsystem and their expected performance and will provide tools for validating the attendes systems.

Title      : Predictive Analytics for Management Oracle Exalogic and Exadata Cloud Environments
Speaker    : Boris Zibitsker
Description: Oracle Exalogic and Exadata x2-8 provides a base for private clouds and workload consolidation. Each workload has unique profile different seasonal peaks and different SLOs. It is easy to create a policy controlling resource management but difficult to find rules capable to satisfying SLOs of the individual workloads. In this presentation we will review several case studies for multi-tier distributed Oracle Exalogic and Exadata environment supporting mix workloads and will illustrate how predictive analytics evaluate options to justify strategic capacity planning tactical performance management and operational workload management decisions. We will review modeling results showing the interdependence between workloads and servers in multi-tier environment and will discuss best practice of organizing continuous proactive performance management process





言い忘れましたが、本日、始めてExa関連のセミナーに出たのですが、なんと講師含めて3人!

USではExaは、あまり流行じゃないのか!?と思わせる感じです。明日はExa周りを中心に出て、状況を確認したいと思います。



では、Shallahamerのセッションで印象に残ったことをつらつらと。

まず、チューニングにおけるメソッドの話から、Ratioベース、Timeベース ... ここまでは普通。
しかし、これらはClassic Methodに分類されていました。彼の提唱しているのは "Oracle Response Time Analysis"。
これだけ聞くと、ミクロの世界のレスポンスタイムを分析する(Method Rに近い)のかと思ってしまったのですが、
実は全然違う(という全く逆でした)

何かというと(私自身、完全に理解していないで書いていることをご了承ください...)現実世界のチューニングの
多くはCPUボトルネック、IOボトルネックに二分される。

CPU、IOボトルネック双方とも、レスポンスタイムと仕事量(彼はArrival Rate(work/time)と言っていたので、
きっとTransaction/Secのように取れると思って聞いていた)の関係を見ると、どこかスレッシュホールドがあり、
その時点までは、Transaction数を増やしても、レスポンスタイムは傾きの小さい正比例になる。
しかし、スレッシュホールドを超えるとN次曲線になり、一気にレスポンスタイムが悪化する。

CPUボトルネックとIOボトルネックだと上記N次曲線のNの部分が異なる。IOボトルネックの方が大きい数字になる。

が現実として仮定して、"Oracle Response Time Analysis"の話を展開していました。

また、重要な点は、ミクロを見るのではなく、ワークロードをベースとした(だから、CPUボトルネックとか
IOボトルネックと単純形にできる)マクロとしてチューニングを捉える。ただし、マクロの測定は従来の
Timeベースを基本とする。という点。

だんだん、難しくなってきました。

で、従来のTimeベースは以下のようにレスポンスタイムを定義していました。
(というか自分の中ではTimeベースは従来ではなく現在なのですが...)

ResponseTime = CPU + Wait(not Idle)

彼はこれを以下のように再定義しています。


ResponseTime = ServiceTime(CPU) + QueueTime(Wait(not Idle))

ほとんど、同じですが、ResponseTimeの意味を変化させています。

従来は
ResponseTime : ワークロードの概念がないので単純にデータベースが処理に費やした時間

変化後
ResponseTime : ワークロード(CPU/IO)を加味したモデル上での統計的な時間

この"統計的"がミソで、私自身の不勉強で全くの謎です(マジックナンバーにしか見えなかった)

これで、何が良くなるか(or 良くしようとしているか)というと

特定処理に対して、(例えば xxバッチ)、この処理のIO特性を考慮すると、統計的にレスポンスタイムと
処理量の関係が導出されて(グラフ化できて)、処理量をどのように変化させるとレスポンスタイムが
どのように変化すると推定が可能になる。

また、その時のスレッシュホールドも分かるので、「ここまで処理量を上げても大丈夫」とか言える。
逆に、この処理量でこのレスポンスタイムを目指すなら、IO特性をこう変える(要はチューニングして、変える)
必要がある。

みたいに言える。と説明してました。

正直、全く腑に落ちてませんが、また、新しいチューニングメソッドの誕生なのだと思って勉強が必要だと思ってます。
こんな内容を、笑いながら話されても、ちょっと。。。

ちなみに最初の画像は、上記の"統計的"ミソな部分の数式を書き留めておいたものですが、現状、意味不明です。

コメント