X

A blog about Oracle Technology Network Japan

  • January 23, 2012

津島博士のパフォーマンス講座  第14回 メモリ・チューニングについて

Guest Author

津島博士のパフォーマンス講座 Indexページ ▶▶

 


皆さん、明けましておめでとうございます。今年もよろしくお願いします。
今回は、前回のキャッシュ周りに続いてメモリ・チューニングについて説明しようと思います。これも性能に大きく影響するため大事なことですので、参考にして下さい。

■1. メモリ領域について
まずは、今さらと思いの方も多いかと思いますがOracleデータベースのメモリ構造について説明しましょう。
メモリ領域を大きく分けると、以下の図のようにSGA(System Global Area)とPGA(Program Global Area)になります。

SGAはOracleデータベース全体で使用する領域で、PGAはユーザ(セッション)毎に使用する領域です。そのため、PGAは同時ユーザ数や使用されるSQL文によってサイズが異なってきます。それに対してSGAは、ユーザ数などでは使用されるサイズが異なりませんが、使用されるSQL文(異なるSQL文)の数やアクセスするデータ量で必要なサイズが異なってきます。また、共有サーバー接続を使用するとSGAを多く使用するようになります。どちらも非常に重要な領域ですので、効率良くメモリを割り当てる必要があります。ただし、どのように使用されるかはシステム(アプリケーション)によって異なってきますので、設定(サイジング)するのはなかなか難しいものです。そのために、誰にでも簡単に設定できるようにアドバイス機能や自動メモリ管理機能などが追加されてきたのだと思います。

img_tsushima_120124_01.gif

(1)SGAについて
SGAには、性能に大きく影響するバッファキャッシュや共有メモリー、そしてログバッファなどが含まれます。バッファキャッシュはデータの物理I/Oを削減するためのものですが、共有メモリは第7回で説明したように様々なサイズのデータを格納しますので、性能的にも大きいですが「ORA-4031:共有メモリーのstringバイトを割当てできません」を防止することも大事になります。そのためには、他の領域を効率良く使用することも大事になります(例えば、ラージプールを使用することができるのに共有プールを使用するなどしないようにしましょう)。

(2)PGAについて
PGAには、一般的にプロセスごとにスタック領域とセッション情報(SQLで使用されるソート領域やハッシュ領域などの作業領域で、UGA:User Global Areaともいいます)が確保されます。このUGAは、SQL文によって使用するサイズは大きく異なってきますので注意して下さい。一般的にはOLTPなどの索引を使用するようなシステムではあまり使用しなく、DWHなどの大量にアクセスするシステム(非定型で複雑なSQL文など)では多く使用されます。専用サーバー接続であればUGAがPGAに確保されますが、共有サーバ接続であれはSGA内のラージプール又は共有プールに確保されます(共有プールを使用すると断片化になり易くなるので使用しないようにして下さい)。共有サーバ接続についてはまたの機会とさせていただきます。

(3)メモリ割り当てについて
次に、Oracleデータベースのメモリ割り当て(配分)について説明します。

SGAのバッファキャッシュが不足すると物理I/Oが増加して性能ダウンになります。また、PGAが不足すると一時表領域へのI/Oが増加して性能ダウンします。そのため、ディスク配置などにも影響してきますので、どちらが性能に多く影響するかを検討する必要があります(複数のユーザで一時表領域を使用するのであれば、そこがボトルネックになりますので、あまり発生しないようにするか一時表領域を増やすなどが必要になります)。

一般的には複雑でないSQL文(または定型的なSQL文)を使用するシステム(OLTPシステムなど)ではPGAは小さくSGAを大きくするようにします(ソート処理などをさせずにすべて索引を使用するようにするためです)。

それ以外のシステム(DWHシステムなど)ではSGAは小さくPGAを大きくするようにします(フルスキャンが多いためバッファキャッシュを大きくしてもキャッシュヒット率が向上しないためです)。ただし、SGAとPGAの配分をどのくらいにするのが良いかはシステムによって異なってきます(結構な数のテストをしないと明確にはならないため、このテストが大変な訳です)。そのため、Oracle9iからはメモリに対する様々なサポート機能(アドバイス機能、自動PGAメモリ管理)が追加されましたので、非常に楽になったと思います(これを上手く利用することで設定が簡単にできるため、非常に便利になったと思います)。それよりも楽にできるのが第3回で簡単に説明した自動メモリ管理機能ですので、できるだけ使用された方が良いと思います。

(4)その他に注意すること
次に、その他に気を付ける必要があることについて少し説明します。

まずは、領域不足でエラーにならないようにする必要があるということです。性能ダウンだけであればシステムとしては動作しますが(これも非常に大きな問題になる場合もありますが)、エラーが発生する場合には動作できなくなる場合があるからです。これに代表されるものがORA-4031(共有プールの不足)になると思います(共有プールは第7回で説明したように様々な用途で使用されますので、できるだけ領域を有効利用するようにすべてのメモリを使用して不足したら再利用するようになっています。同時ユーザが増えると解放できなくなる場合がありますので注意して下さい)。共有プールは様々なプロセスで(バックグランド・プロセスなどにも)使用されますので、非常に大切な領域になります(最悪な場合にはインスタンス・ダウンにもなりえます)。そのため、領域不足にならないように十分なテストを行う必要があります。

それから、当たり前のことですが使用しないところに割り当てない(使用する領域だけを割り当てる)ようにするということです。メモリは不足している領域ではサイズを大きくすればするほど性能が良くなりますので、効率の良いところにできるだけ多く割り当てるようにすることが最適なことになります(ただし、これ以上増やしても性能が向上しないという限界があることも知っておく必要があります)。そのため大き過ぎないようにする必要がありますが、この値を決めるのが難しいのです(これがテスト回数が増えてしまう要因です。そのためアドバイス機能が有効な訳です)。これが出来ないとメモリがいくらあっても足りないことになりますから、非常に大事なことになりますので、忘れないようにして下さい。

■2. アドバイス機能と自動メモリ管理について
ここからは、メモリの設定を非常に簡単にするアドバイス機能と自動メモリ管理機能について説明します。

Oracleデータベースのメモリに対する機能には様々なものがあります。その代表的なものがアドバイス機能と自動メモリ管理になります(メモリ以外にも様々なものに対するアドバイザ機能や自動機能がありますが、メモリ以外についてはまたの機会とさせていただきます)。

アドバイス機能はサイズをこの値に設定すると動きがこのように変化するというようなことを教えてくれる機能に対して、自動メモリ管理はその情報を基に自動調整までしてくれる機能になります。

基本はこの自動メモリ管理機能で問題ないと思いますが、完璧な状態にはならない場合もありますので(特にメモリ容量が少ない場合などは注意が必要です。ただし、ベストではないがそれなりの性能にはなりますので、大規模システム以外はあまり気にしなくて問題ないと思います)、それが困る(問題な)場合はアドバイス機能を参考に手動で設定することが良いと思います。ただし、あまり良く知らない方が手動で設定しますと自動より遅くなる場合もありますので注意して下さい。ここでは、それぞれの機能についてと、それの有効的な使用方法を紹介しようと思います。

(1)アドバイス機能
アドバイス機能には、Oracle9iからのバッファキャッシュ、共有プール、PGAなどがあります(第3回でバッファキャッシュの「Buffer Pool Advisory」と共有プールの「Shared Pool Advisory」については紹介しましたので、ここではPGAについて紹介します)。

以下はStatspackの「PGA Memory Advisory」の出力例です(「Size Factr」の1.0が現行サイズです。「Estd P Cache Hit %」が各サイズで見積もった一時表領域へのI/O回数をPGAキャッシュヒット率として表した値になります。これが100%だとすべてメモリで行ったことになります)。この機能は、自動PGAメモリ管理を使用したときにPGA_AGGREGATE_TARGETの値をアドバイスしてくれる機能です。

img_tsushima_120124_02.gif

 このアドバイス機能が提供されたときには、メモリ・チューニングが非常に簡単にできるようになったので、とても驚きました。それまでは、何回も設定を変えて動作テストを行う必要があったので非常に時間が掛った記憶があります。

この機能は、サイズを変更した場合の動作をシュミレーションしてくれるようなものですので、設定を何度も変更してテストを行う必要がなくなりますので、手動でメモリ設定を行うのであれば是非とも使用した方が(これを参考にして設定値を決めるのが)良いと思います。ただし、アドバイスしてくれることが完全ではない場合もありますので、変更後のテストは必ず行う必要があります(例えば、設定を変更するとアドバイスも変わる可能性があります)。Oracle Database 10gからは「SGA Target Advisory」、Oracle Database 11gからは「Memory Target Advisory」が提供されています。それぞれ自動共有メモリ管理と自動メモリ管理のアドバイス機能になります。

(2)自動メモリ管理
自動メモリ管理はOracle Database 11gから提供された機能で、以下の図のようにSGAとPGAを自動的に調整してくれる機能です(自動共有メモリ管理と同様にMMANプロセスが30秒間隔で調整します)が、SGAとPGAについては、それぞれに対して自動共有メモリ管理と自動PGAメモリ管理が動作しますので、詳細はそちらで説明します。

img_tsushima_120124_03.gif

 これは初期化パラメータMEMORY_TARGET を設定することで動作します。DBCA(Database Configuration Assistant)を使用してデータベースを作成する際に基本インストール・オプションを選択すると自動メモリ管理が使用可能になります(デフォルト値は物理メモリの40%です)。この値は以下のようなSQL文を使用して(v$memory_target_adviceを使用して)ベストな値に調整して下さい(以下の出力例は値を変えても性能は変わりませんが使用方法の参考にはなると思います)。これはMEMORY_TARGETの値をアドバイスしてくれる機能です(「MEMORY_SIZE_FACTOR」の1.0が現行サイズです。「ESTD_DB_TIME」が各サイズで見積もったDB Timeになります。この値が少なくなるということは性能アップするということです)。

img_tsushima_120124_04.gif

 自動メモリ管理について「すべてOracleに任せるのは心配だから使用しない」などとたまに聞きますが、ORA-4031の防止にもなりますので上手く使用すると良いと思います(第7回で説明した存続期間によるサブプール分割を行いますので、断片化の防止にもなります。これは自動共有メモリ管理でも行われます)。ここからは、それぞれのメモリがどのように調整されるかと、どのように使用するかを簡単に説明しますので、使い方の参考にして下さい。

①自動PGAメモリ管理
これはOracle9iから提供された機能で、PGAとして全体でどれくらい使用するか指定でき、指定が非常に簡単になります。PGAはセッション毎に領域が確保されますので、手動で設定する場合(SORT_AREA_SIZEなど)は、各プロセスで使用できる最大値を指定することになります。そのため、同時ユーザ数が増えると物理メモリが不足する場合もありましたので、設定が非常に難しいものでした(ただし、大きいサイズを指定しても使用するサイズしか確保はされません)。

この機能は、初期化パラメータPGA_AGGREGATE_TARGETを設定することで動作します(10gからはSGAサイズの20%としてデフォルトで有効になります。ただし、自動メモリ管理を使用した場合は最低サイズとなるため設定されません)。この値はAWRやStatspackの「PGA Memory Advisory」などを使用してベストな値に調整して下さい(メモリ内だけで行うことができない場合は、最低でもone-passで行うように調整して下さい)。ただし、1プロセスで使用できる最大サイズの上限がありますので、注意が必要になります。これは、全体でのサイズになるため、それぞれが使用するサイズと最大のプロセス数が予測できないので、このように制限しているためです。どうしてもSQL文で使用する作業領域が多く必要な場合は、パラレル処理を行ってパラレル度を増やして実行すると利用サイズを増やすことができます。これは、プロセスの最大サイズはパラレルスレーブプロセスごとにも使用できるため、パラレル度が増えるとプロセスが増えるため全体的に使用できる領域も増やすことができるからですので、知っておくと便利かと思います。

共有サーバ接続の場合は、UGAがSGAに確保されるため自動PGAメモリ管理を利用しませんでしたが、Oracle Database 10gからは自動PGAメモリ管理機能が利用されるようになりました。ただし、UGAが確保されるのはSGAのままとなりますので、全体として使用するサイズによる調整を行うということで、それを割り当てできるかどうかはSGAコンポーネントのサイズによるということになります。

②自動共有メモリ管理
自動共有メモリ管理はOracle Database 10gから提供された機能で、以下の図のようにSGA(System Global Area)のバッファキャッシュ(標準ブロックサイズ)とその他のプール(共有プール、ラージ・プールなど)間で自動調整されます。これは初期化パラメータSGA_TARGETを設定することで動作します。ただし、DB_nK_CACHE_SIZE、DB_KEEP_CACHE_SIZE、DB_RECYCLE_CACHE_SIZE、LOG_BUFFER(デフォルト値はCPU数とSGAサイズなどから算出されます)は自動調整されないので注意して下さい。

この機能により難しいメモリ・チューニングを行わなくて良くなりました。SGAは重要な領域が多くありますので、メモリチューニングを手動で行うのは何回もテストを繰り返して行う必要があり、非常に難しいものです。これによって非常に簡単になったと思います。

img_tsushima_120124_05.gif

 これは初期化パラメータSGA_TARGETを指定することで動作します(自動メモリ管理を使用している場合は、この値を設定すると最低サイズになりますので注意して下さい)。この値はAWRやStatspackの「SGA Target Advisory」などを使用してベストな値に調整して下さい。これも「Memory Target Advisory」と同じようにSGA_TARGETの値をアドバイスしてくれる機能です。

③自動メモリ管理での確認について
ここまで説明してきたようにメモリ設定は非常に難しい作業です。このような機能を上手く利用することで誰でも簡単に設定できるようになりますので、使用することをお奨めします。ただし、自動機能にも限界はありますので(例えば、MEMORY_TARGETまでは自動調整されませんので、全体的にメモリ不足のときは効率良く調整することはできません)、そのことを十分に理解して使用して下さい。

すべてをOracleに任せるのは心配であるという方は、対象コンポーネントのメモリ領域に最低サイズを指定して使用すると良いと思います(自動メモリ管理を有効にして初期化パラメータでサイズを指定するとそれが最低サイズになります)。

最低サイズを指定した場合は、そのサイズよりは小さくならないようにしてくれます(このとき、どこのコンポーネントにも割り当てがない領域はデフォルトバッファキャッシュに割り当てられて、自動調整されるようになります)。ただし、領域不足(ORA-4031など)が発生してしまうような場合は、発生しないようにすることを優先しますので、その最低サイズより小さくなる場合がありますので、知っておいて下さい。

StatspackやAWRに以下のような「Memory Dynamic Components」があります。この情報により対象コンポーネントが期間中にどのように変化したかを見ることができます(「Max Size」が期間中での最大サイズです)。これを使用してテストでサイズを確認すると良いと思います(例えば、変動させたくないコンポーネントについては、これを使用して最低サイズを決めるなどすれば良いかと思います)。

img_tsushima_120124_06.gif

「Last Op Typ(LAST_OPER_TYPE)」は、最後の操作タイプがSHRink(縮小)、GROw(拡張)、STAtic(変化なし)を示しています。「Last Op Mod(LAST_OPER_MODE)」は、最後の操作モードがDEFerred(統計情報を基にMMANプロセスが30秒間隔で行う基本操作モード)、IMMediat(起動時または枯渇した際に緊急的に拡張させるための操作モード)を示しています。IMMediatモード時には、最低サイズが指定されていても、それ以下にする場合もありますので注意して下さい(例えば、ORA-4031が出力されそうになると、最低サイズを指定していてもバッファキャッシュからメモリを移動します)。このモードで操作したということは、そのコンポーネントは容量が不足しているということですので、ベストな状態に調整が必要になります。

■3. チューニング方法について
最後に、メモリ・チューニング方法についてまとめようと思います。

SGAのチューニングを手動で行うのは難しいものです。バッファキャッシュは性能を向上するためにはできるだけ大きくする必要がありますが、共有プールなどは性能にも影響しますが、領域が不足するとORA-4031などが発生してしまいます。ただし、共有プールなどは事前に見積もりできないのでベストなサイズを決めるのは大変になります。そして、バッファキャッシュと共有プールのベストな配分を決めるのも難しいです。また、使用状況が変化する場合などもあり、その都度手動で調整するのは限界も有り、大変な作業になります。

そのため、共有メモリの断片化を防止することにもなりますので(共有プールの管理が存続期間によるサブプール分割を行います)、自動メモリ管理を使用することをお奨めします。どうしても変動するのが気になる方は、最低サイズを上手に使用することで変動しない(変動し難い)ように設定することをお奨めします。このときの最低サイズなどはアドバイス機能などを上手く活用すると少ない時間で行うことができると思いますので、検討して下さい。

それから、自動メモリ機能を使用する場合でも使用しない場合でも十分なテストが必要であることは忘れないで下さい(自動メモリ管理を使用しても物理メモリ不足までは調整できませんから、実際の運用時と同等な負荷によるテストが必要になるということです)。そうでないと運用中に性能ダウンやエラーが発生するようなことになりますので注意して下さい。

便利な機能も使い方が正しくなければ意味がありません。正しくないためにこの機能は使えない(使わない)と判断してしまう技術者もいるかと思います。このような便利な機能を正しい情報を基に上手く活用して効率良く運用することを願っております。

■4. おわりに
今回はOracleデータベースのメモリ・チューニングについて説明しました。すべてを詳細に説明することはできませんでしたので、また機会があれば説明しようと思います。これが今年初めての連載ですが、皆さん良いお年をお迎えできましたか。私は、初詣で今年も続けられますようにと祈ってきました。今年も頑張りますのでよろしくお願いします。質問をお待ちしています。

それでは、次回まで、ごきげんよう。


ページトップへ戻る▲ 

 

津島博士のパフォーマンス講座 Indexページ ▶▶

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.