稼働率の高いシステムの査定 - Advanced SQL Engine - Teradata Database

CPUの飽和状態

頻繁に容量の限界またはほぼ限界で稼働するシステムは、多くの場合、リソースの消耗度を確認するための評定を受けることになります。

CPUが制約要因であって、システム上のリソースが不足している場合、システムの飽和が最も高いレベルを判別すると役に立ちます。最も高いレベルとは、システムを稼動し続けて、過負荷になってハングしたと思われる地点のことです。

システムは、そのレベルの飽和状態に達しても、「作業をこなす」ことはできますが、通常よりも時間がかかる場合があります。

ResUsageデータは、システムがCPUやCPUと入出力待ちで100%使用中になっていることを知るのに十分な情報ですが、CPUの飽和状態とシステムの混雑の程度を調べるには、他の情報も必要なことがあります。言い換えると、システムが最大限の能力で稼働していることは分かっても、過負荷の程度は分からないということです。

システムの稼働率が高くなったために、ログオンに時間がかかったりハングしたりする場合、他のツールも使わない限り、システムが実際にハングしているのか、または単に過負荷になっているだけなのかを、性能モニターだけで判断することはできません。

役に立つモニター技法

目標は、過負荷に陥らせないでシステムを最大限に活用することにあるので、CPU使用率が高いときには以下のような稼働レベルを査定するためのいくつかの方法を使用できます。

1. AWTの使用率を調べます。その数値が定常的に最大値であるかまたはそれに近ければ、次のようにします。
2. メッセージ フロー制御を調べます。明らかにフロー制御の下にあるタスクがある場合、次のようにします。
3. 実行待ち行列のResUsageSawt MailBoxDepthデータを調べます。実行待ち行列が長くなり続けている場合、システムは過剰稼働になって、急激に低速化することになります。

AWTカウントの高い高稼働率のシステムは珍しくありませんが、フロー制御が行なわれているということは、稼働率が極めて高いAMPにさらに作業を要求することになるタスクの一部が、現在はブロックされているということを意味します。

飽和状態のリソースの検出

/usr/pde/binディレクトリにある「Resource Check Tool」を使用して、飽和状態のリソースをチェックします。

mboxchkと他のPDE Resource Check Tool（nodecheckやsyscheckなど）の詳細については、マニュアル(Man)ページまたはpdehelpを参照してください。

高い入出力待機率

CPU不足を招かないためには、通常のデータベースのワークロードでの需要に合ったCPU対入出力帯域幅の比率の構成を推奨します。このガイドラインが順守されなかった場合や、入出力という点で顧客ワークロードが異常に高い場合、CPU不足はやはり発生する可能性はあります。これは、システムでは高い入出力待機率として示されます。

ResUsageデータで入出力待機率の上昇とCPU稼働率の低下が見られる場合、入出力が制限要因になっているため、システムが利用可能なCPUを使用できなくなっている状態を示しています。

入出力待機率が突然高くなった場合、次のようにします。

1. 入出力待機率が高くなった原因が、ディスク入出力、他のノードからのAMP待ち(スキューまたは共存の不均衡に起因するもの)、システム需要の低下、またはBYNET入出力のどれにあるかを判別します。

   CPU+WIOが90%に満たない場合、実際の入出力ボトルネックではなく、システム需要の低下を示しています。ノードの効率を調べて、入出力待機の原因はノード待機にあるかどうかを判別します。

2. sar -dを使って、実際のディスク入出力待ち行列を調べて、以下を確かめます。
   • avwait

     応答を待っている待ち行列上(FibreChannelドライバ待ち行列またはディスクの待ち行列で)で、転送リクエストがアイドル状態で待機するミリ秒単位の平均時間。

   • avserv

     サービスを利用する平均時間(シーク、ローテーション待機時間、およびデータ転送の時間も含む)。

   sarユーティリティの詳細については、Linuxオペレーティング システムのマニュアルを参照してください。