今度は予選で実施したTPC-Cについて書いていきます。競争条件については、下記の通りです。※TPC-Hのチューニングについてはここでは割愛します。事前準備で実施した内容から。NUMBER(24,2);それでは、本題です。以下の優先順位でチューニング実施し、CPUネック(待ちもない状態)の状態にしていくことを考えました。※ネットワークは今回は関係ないため省略しています。Diskアクセスについてです。TPC-CでDiskアクセスが多い個所と考えた時、真っ先に気になるのは、やはりREDOです。REDO生成量(更新量)が多いということは、UNDOも多いはずです。そこをポイントにチューニングしていきます。※チューニング前後のベンチマーク結果は記載できないため、代わりに効果(高,中,低)という表現で記載することをご了承ください。【REDOログの高速化】まずは、REDOログです。REDOログの書き込みを高速化する上で、大きく分けて方法は2パターンあります。書き込み速度を向上させるでは、それぞれに対し実施した方法です。書き込み量自体を減らす今回は、正攻法と邪道な方法の2つを考えました。まともなやり方でREDOログ生成量を減らす。邪道なやり方でREDOログ生成量を減らす。まともなやり方でREDOログ生成量を減らす。Undoを使用しました。邪道なやり方でREDOログ生成量を減らす。(効果:高)どう考えても、通常運用に耐えられませんが、REDOログ生成量を減らすとともに、COMMIT待ちも失くしました。書き込み速度を向上させる以下の2つを考えました。REDOログをRAMディスクに配置する。一度の書き込みを多くし、書き込み速度を高速化する。REDOログをRAMディスクに配置する。(効果:高)REDOログの生成量を減らし、待ちを失くした結果、RAMディスクにREDOログを配置した場合でも速度差が変わらない状況になりました。そのため、メモリリソース節約のために、REDOログはRAMディスクには配置しませんでした。一度の書き込みを多くし、書き込み速度を高速化する。(効果:低)ログバッファやチェックポイント間隔を調整し、少しでも一度の書き込みを多くしようと考えました。UNDO自体は、REDOログとは違い、(テーブル構成やSQLを変えられない条件では)DBの性質上減らそうにも減らせません。そのため、UNDOをRAM上に配置しました。※UNDO表領域のサイズ調整のため、undo_retentionも同時に変更しています。2000万トランザクションのデータがどれくらいのサイズになるか不明だったため、今回の環境ではデータファイルのリサイズが発生していました。リサイズが発生し始めたタイミングでパフォーマンスが落ち始めるため、事前にデータファイルを十分なサイズで作成し直しました。合わせてオブジェクトも事前に拡張しました。※実際には最初に作成したため、ALTERではなく、CREATEになっています。冗長化ポイントは、性能面のみ考えた場合は無駄なIOとなってしまうため、制御ファイルは1つにしました。Writerの数を調整しました。便利な機能は、内部で更新等が発生しているため、それなりに負荷をかけています。運用面を無視して速度のみを考えた場合はやはり停止したほうが速くなります。実際に実施した内容は、以下の3つです。統計収集の停止(効果:中)便利な分だけ、やはりかなり効果がありました。チューニングに必要になる情報がほぼ見れなくなるため、設定は最後に実施しました。内部チェック、アドバイザ系、便利な機能の停止(効果:低)こちらは、思ったほど効果がありませんでした。REPLICATION_DEPENDENCY_TRACKING=FALSE3.ダイナミック・サンプリングの無効化(効果なし)今回は、統計情報を事前に収集しているため、特に効果がありませんでしたが、統計情報を収集していない環境では問題になる場合もあるため、記載しておきます。影響度的には一番大きいですが、チューニングポイントというには微妙なので、記載しておきます。Diskとは関係ありませんが、SGA関連としてshared_pool_sizeの設定値も記載します。※それぞれ、TPC-Cを実行する上で必要な分を設定しました。ここまでで、大分Diskネックの状態は解消できました。次は、メモリアクセスについて考えます。実際、ここはそこまで手を出さなかった箇所でした。そもそも、実際に実行されているSQL自体も最速の実行計画で実行されていたため、indexと行とで2ブロックのアクセスで完結しているSQLだけでもどうにかできないか考えました。毎回、2ブロックしかアクセスされないオブジェクトを2KBのブロックサイズに変更(効果:低)DB自体は32KBのブロックサイズにしていたため(TPC-H環境と同居のため)、もう少し効果を期待したかったのですが、あまりありませんでした。db_2k_cache_size=104857600最後にCPUです。【CPUリソースの効率化】とにかく、無駄なオーバーヘッドや待ちを減らすことを考えました。結果、実施したのは以下の3つです。hugepageの設定(効果:中)hugepageを使用することで、ページ表(仮想メモリーから物理メモリーへのマッピング)は小さくなります。ページ表を最新状態に保つオーバヘッドがなくなることで、CPUネックになる環境では効果があります。PL/SQLの高速化(効果:低)HammerDBの処理方式を確認していたところ、PL/SQLを使用して処理が行われていました。そのため、HammerDBで作成されるプロシージャや乱数生成などのプロシージャの負荷を下げるために実施しました。latchの調整(効果:低)他にチューニングポイントはないかと待機イベントを眺めていたところ、latchが少し出ていたため、調整を行いました。発生自体少しだっため、やはり効果は少なかったです。_kgl_latch_count=9【おまけ:プロセスの優先度の調整(効果:なし)】DBWやLGWRなど、主にCPUを使用していたプロセスの優先度を調整して、更にパフォーマンス向上を目指せるかと思ったのですが、効果は出ませんでした。設定によっては、悪化している気配さえあり、少し検討に時間がかかりそうだったため、実施できませんでした。_highest_priority_processes以上がTPC-Cで実施した内容となります。reserved.トップページ企業概要プライバシーポリシ。