SQL Anywhere(9.0.2)で実行されるベンダーソフトウェアのパフォーマンスの問題を診断しているときに、I/O帯域幅に関するいくつかの興味深いデータに出くわしました。 9.0.2のマニュアルによると、データベースプロパティ「CurrIO」には「サーバーによって発行されたがまだ完了していないファイルI/Oの現在の数」が表示されます。ただし、ハードウェア構成やデータベースの使用率を考えると、この数値がどうあるべきかは不明です。
少し調べてみると、SQL Anywhere 10.0.0のマニュアルでは、パフォーマンスに関する章でもう少し詳しくこの設定が行われていることがわかりました。
I/O帯域幅が制限要因であるかどうかを検出するには、CurrIOデータベースの統計を確認してください。この統計がグラフに表示されない場合は、[統計の追加]ボタンをクリックして、[CurrIO]を選択します。この統計の最大の持続数を探します。たとえば、グラフで高いプラトーを探します。幅が広いほど、影響は大きくなります。グラフの持続値が3+データベースサーバーによって使用される物理ディスクの数以上の場合は、ディスクシステムがデータベースサーバーのアクティビティのレベルに追いついていないことを示している可能性があります。
これは、たとえば、サーバーに5つのディスクがある場合、この数は理想的には8未満である必要があるということですか?この値の背後にある意味は、バージョン9.0.2と10.0.0で同じですか?これを信じがたい理由は、次のコマンドの結果が私の特定のケースでは少しずれているためです。
SELECT db_property ( 'CurrIO' ), db_property ( 'MaxIO' )
上記のコマンドは、CurrIOの場合は9、MaxIOの場合は115を返します。私はこの数を数時間監視していて、平均はおよそ950(RisingRoadのFoxhoundモニターのおかげで) 。これらの読み取り値は、通常のデータベース負荷の下で取得されています。
私のI/O帯域幅は見た目と同じくらい不十分ですか、それともこれらの数値を誤って解釈していますか?
現在のサーバー構成は次のとおりです。
OS:Windows Server 2003 R232ビット
データベースバージョン:SQL Anywhere(Adaptive Server Anywhere)9.0.2.3381
CPU:4x Intel Xeon Dual Core 3.00GHz
RAM:26GB(SQL Anywhereキャッシュに22GBが割り当てられています)
HDD(C:/):OS +一時ファイルの場所
RAID 1
2x 36GB SCSI-320(15k RPM)
HDD(D:/):DBファイルの場所
RAID 5
4x 73GB SCSI-320(15k RPM)
HDD(E:/):OSページファイル+ログファイルの場所(ミラーログはありません)
RAID 5
4x 73GB SCSI-320(15k RPM)
注:RAID1と最初のRAID5(D:/)は同じRAIDコントローラー上にあります。 RAID10で両方のRAID5を146GB(15k RPM)ドライブにアップグレードすることを計画していました。その変更は、明らかなI/O帯域幅の問題に役立ちますか?
RAIDを扱う場合、perfmonの従来のディスクカウンターは誤解を招く結果を返す可能性があります。ディスクI/OではなくキャッシュI/Oが表示されます。したがって、% Idle Time
カウンターも確認してください。これはおそらく最も正確な結果になりますが、反転されます(パーセンテージが低いほどビジーディスクに等しい)
CurrIO統計は、SAではSMPセーフではありません。 Windowsperfmonが提供する「PhysicalDisk」カウンターを確認することをお勧めします。特に、「現在のディスクキューの長さ」、「平均ディスクキューの長さ」、「平均ディスク書き込みキューの長さ」、「平均ディスク読み取りキューの長さ」。
「3 +#disks」の値がどこから来たのかわかりません。ドライブで多くのIOが実行されることを期待している場合、そのドライブで未処理のIOをいくつか持つことは非常に合理的です。
データベースによって実行されているI/Oの量を確認する別の方法は、キャッシュ統計を調べることです。データベースがキャッシュから読み取っている場合、ディスクI/Oはそれほど多くありません。表示できる2つのdbプロパティは、次のように「CacheRead」と「CacheHits」です。
SELECT db_property ( 'CacheRead' ), db_property ( 'CacheHits' )
SQL Anywhere 10.0.0のマニュアルでは、少なくとも70%のキャッシュヒット率が推奨されています。それを下回る場合は、サーバーにより多くのキャッシュを割り当てる必要がある場合があります。次のように直接パーセンテージを取得できます。
SELECT STRING(((db_property ( 'CacheHits' ) / db_property ( 'CacheRead' )) * 100), '%')
私の特定のケースでは、データベースに22GBのキャッシュがある場合、ヒット率は約58%でした。キャッシュを55GBに設定した後、ヒット率は97%に上昇しました。 「CurrIO」および「MaxIO」プロパティの正確な数値は正しくない可能性がありますが、この変更後も相対的な低下は急激でした。