データベースIOが遅いかどうかを判断する方法

1. 引言#

プロジェクトのデータベースの応答が遅い問題は、結論としてオペレーティングシステムレベルでの IO パフォーマンスの悪さに起因しています。どのようにしてより説得力を持たせることができるでしょうか。一般的に、IO パフォーマンスを測定するために主に 2 つの指標を使用します。応答時間：操作を完了するのに必要な時間をマイクロ秒で測定します。これは一般的に Oracle によって収集され、統計されます。スループット：単位時間あたりに完了する操作の数で測定します。これは一般的にオペレーティングシステムのツールを使用して統計されます。この記事では、Oracle の観点から IO が遅いかどうかを判断する方法について説明し、スループットおよびその測定方法については詳しく説明しません。

2. どうすれば IO が「遅い」と見なされるか#

IO が遅いというのは非常に主観的な用語であり、ユーザーのシステムやハードウェアに対する期待と実際の差に依存します。この差は比較的主観的な感覚であり、具体的なパフォーマンス指標に量化すると、エンタープライズプラットフォームでは、IO リクエストの応答時間が 10ms を超えると、ユーザーは敏感になり始めます。ただし、応答時間は常に変動する可能性があり、データがファイルシステムから共有ストレージに移動する場合や、ストレージデバイスに異常が発生する場合、またはビジネスの成長により IO パフォーマンスがピークに達する場合があります。これにより、応答時間という指標に対して多次元的な測定が必要になります。

3. 応答時間#

ハードウェアはすべての IO リクエストに対して同じ反応を示す必要はありません。常にピークと谷が存在する可能性があります。したがって、平均値を使用することは応答時間を測定する一般的な方法です。
注意：このピーク / 谷の異常シナリオによる問題を緩和するために、サンプルデータの量は比較的大きくする必要があります。サンプルデータの量は、少なくとも毎時 1000 回の操作であるべきであり、これは決定的な測定に対してより信頼性が高く実用的な根拠を提供することを目的としています。

IO のタイプ

平均応答時間は具体的な IO タイプに直接関連しています：

読み取りまたは書き込み

単一ブロックまたは複数ブロック

単一ブロックIOは、一度に1つのブロックのみを読み取ることを指します。たとえば、セッションが単一ブロックIOを待機している場合、典型的な待機イベントは「db file sequential read」であり、必要なブロックを待機していることを示します。
複数ブロック読み取りは、一度に複数のブロックを読み取ることを指し、2から128のOracleブロックまでの範囲で、ブロックのサイズとオペレーティングシステムの設定に依存します。通常、複数ブロックリクエストの容量には1MBの制限があります。たとえば、セッションが一度に複数ブロックIOを待機している場合、典型的な待機イベントは「db file scattered read」であり、必要なブロックを待機していることを示します。

同期または非同期

同期（ブロッキング）操作は、ハードウェアが物理IOを完了するのを待機し、完了後に通知を受け取り、操作の成功または失敗を合理的に管理します（成功した読み取りの場合、結果を受け取ることができます）。システムコールの結果を待つ必要がある場合、プロセスの実行はブロックされます。
非同期（ノンブロッキング）操作では、IOリクエストがハードウェアに渡されるか、オペレーティングシステムのキューに入れられると（典型的な状況は物理IOが開始される前）、システムコールはすぐに戻ります。プロセスの実行はブロックされず、システムコールの結果を待つ必要がないため、引き続き実行できます。IO操作に結果があるときにのみ受け取ります。

応答時間の閾値

典型的な複数ブロック同期読み取り 64x 8k（合計 512KB）の平均時間は、IO が遅くならない場合、約 20 ミリ秒であるべきです。小さなリクエストはより速く（10-20 ミリ秒）、大きなリクエストの消費時間は 25 ミリ秒を超えてはなりません。非同期操作は、少なくとも同期操作と同じくらい速く、さらにはそれ以上であるべきです。単一ブロック読み取りは、少なくとも複数ブロック読み取りと同じくらい速く、さらにはそれ以上であるべきです。「log file parallel write」、「control file write」および「direct path writes」の待機時間は 15 ミリ秒を超えてはなりません。データファイルの書き込みの測定は、読み取りほど単純ではありません。DBWR はバッチ方式で（「db file parallel write」）非同期にブロックを書き込みますが、現在、書き込み操作の応答時間の標準はありません。DBWR（複数ブロックまたは単一ブロック、IO スレーブの有無にかかわらず）が十分に速くて汚れたブロックをクリアできれば、他の待機イベントや統計情報が明らかになります。一般的なルールとして、上記の待機イベント時間を超える待機イベントは詳細に分析する必要があり、以前の時間消費と比較して明らかな変化がある場合は特に注意が必要です。

注意：システムがこれらの最大閾値を下回っている場合でも、他の調整方法がないわけではありません。#

応答時間はシステムによって異なります。たとえば、次のいくつかの項目は正常な平均値と見なすことができます：

複数ブロック同期読み取り時間は 10 ミリ秒です。
単一ブロック同期読み取り時間は 5 ミリ秒です。
'log file parallel write' 時間は 3 ミリ秒です。

以上は、複数ブロック IO が単一ブロック IO よりも多くの IO サブシステムリソースを必要とするという前提に基づいています。これらの提案を受け入れる場合、redo ログは最も速いディスクに配置し、他の競合アクティビティがないことが望ましいです。

以下は各 IO 関連待機イベントの応答時間の閾値です：

Wait Event	R/W	Synchronous/ Asynchronous	Singleblock/ Multiblock	Elapsed Time
control file parallel write	Write	Asynchronous	Multi	< 15ms
control file sequential read	Read	Synchronous	Single	< 20 ms
db file parallel read	Read	Asynchronous	Multi	< 20 ms
db file scattered read	Read	Synchronous	Multi	< 20 ms
db file sequential read	Read	Synchronous	Single	< 20 ms
direct path read	Read	Asynchronous	Multi	< 20 ms
direct path read temp	Read	Asynchronous	Multi	< 20 ms
direct path write	Write	Asynchronous	Multi	< 15 ms
direct path write temp	Write	Asynchronous	Multi	< 15 ms
log file parallel write	Write	Asynchronous	Multi	< 15 ms

応答時間を特定する方法

10046 トレースファイル

10046トレースでレベル8または12を使用すると、関連する待機イベントの情報が含まれ、応答時間はelaフィールドに表示され、単位はマイクロ秒です。
WAIT #5: nam='cell single block physical read' ela= 672 cellhash#=2520626383 diskhash#=1377492511 bytes=16384 obj#=63 tim=1280416903276618
>> 672マイクロ秒 = 0.672 ms
WAIT #5: nam='db file sequential read' ela= 1018 file#=2 block#=558091 blocks=1 obj#=0 tim=10191852599110
>> 1018マイクロ秒 => 1.018 ms

システム状態ダンプ

各システムレベルのプロセスに対する待機情報は、プロセス情報に含まれます。通常、アクティブなwaiting for、または完了を待っているプロセスがCPUで実行されていることを示します。
ここでwaiting forはプロセスが待機状態にあることを示します。11g以前は、wait startedからの経過秒数フィールドを確認でき、プロセスがどれくらい待機しているかを表示します。11gR1以降は、「total」フィールドが待機時間を表示します。もしwaiting forがプロセスがIO関連の操作を待機していることを示し、seconds since wait started>0であれば、IOの損失が発生している可能性があり、セッションがハング状態にあることを示します。（平均的に受け入れられる時間は20ミリ秒であるため、IO待機時間が1秒を超える場合は注意が必要です）。
last wait forは11g以前のバージョンに関連し、プロセスが待機していないことを示します（たとえば、CPUを使用している場合）。待機時間は「wait_time」フィールドに記録されます。（11gではwait_timeがnot in waitに置き換えられました）

last wait for 'db file sequential read' blocking sess=0x0 seq=100 wait_time=2264 seconds since wait started=0 file#=45, block#=17a57, blocks=1
>> 2264マイクロ秒 => 2.264 ms

waited forはセッションが待機していないことを示します。通常、11gR1以降のシステムレベルのトレースで使用されます。totalフィールドは待機の総時間を示します。
0: waited for 'db file sequential read' file#=9, block#=46526, blocks=1
wait_id=179 seq_num=180 snap_id=1
wait times: snap=0.007039 sec, exc=0.007039 sec, total=0.007039 sec
wait times: max=infinite
wait counts: calls=0 os=0
>> 0.007039 sec => 7.039 ms

Statspack と AWR レポート

フロントエンドプロセスとバックエンドプロセスの待機イベント、平均応答時間は Wait Avg (ms) によって反映されます（ミリ秒単位の平均読み取り）。

表領域 IO
平均応答時間は Av Rd (ms) によって反映されます（ミリ秒単位の平均読み取り）。

待機イベントのヒストグラムは、これらの平均値を構成する書き込み操作時間の分布を提供します。すべての書き込み操作が平均値に近いか、いくつかのピークや谷があるかを示します。各列は、各バケット間の待機イベント時間分布の割合を示します。たとえば、<16ms の待機が < 8ms よりも多い場合です。最大の割合が < 1ms から 16ms の範囲内であれば、IO パフォーマンスは通常受け入れられます。

4. まとめ#

この記事の目的は、IO が遅くなる原因を特定することではなく、IO が遅いと判断する証拠を見つけることです。パフォーマンスが低下した場合、IO の遅さはパフォーマンス問題の潜在的な原因となる可能性があり、データベースの観点からどのようにサポート証拠を収集するかを分析する必要があります。潜在的な原因がオペレーティングシステムレベルの IO の遅さによるものであれば、IO サブシステムのエンジニアが診断と修正に参加する必要があります。