Linux で大容量メモリページを持つ Oracle データベースを最適化する方法

序文

PC サーバーは今日まで発展を続け、パフォーマンスにおいて大きな進歩を遂げてきました。 64ビットCPUは、ハイエンドPCサーバーはもちろん、数年前から一般家庭用PCでも利用できるようになりました。プロセッサ大手のIntelとAMDの努力により、x86 CPUの処理能力は継続的に向上しています。同時に、製造技術の発展に伴い、PCサーバーに搭載できるメモリ容量もますます大きくなっています。現在では、数十GBのメモリを搭載したPCサーバーが至る所で見られます。 PC サーバーの処理能力がますます強力になり、パフォーマンスがますます高くなるのは、ハードウェアの発展のおかげです。安定性の面では、PCServer と Linux オペレーティングシステムの組み合わせにより、重要なビジネスシステムに求められる安定性と信頼性も満たすことができます。もちろん、コストの面では、業界のソフトウェアメーカーで働くネットユーザーの言葉を引用すると、「PC サーバーを使用せずにミニコンピュータを使用した場合、どうやって収益を上げることができますか?」初期購入、動作中のエネルギー消費、メンテナンスコストのいずれの点でも、PC サーバーは同じ処理能力を持つミニコンピュータよりもはるかに安価です。パフォーマンスとコストという 2 つの重要な要素の影響により、ますます多くのデータベースが PC サーバー上で実行されるようになっています。私がサービスを提供しているクライアントの中には、ハイエンドの PC サーバーを複数のマシンに仮想化し、各仮想マシンで Oracle データベースを実行しているところもあります。これらのデータベースの多くは、重要な本番システムを保持しています。

PC サーバー上で Oracle データベースを実行するのに最も適したオペレーティングシステムは間違いなく Linux です。 UNIX に非常によく似たオペレーティングシステムであり、安定性、信頼性、パフォーマンスの面で UNIX と同等の優れたパフォーマンスを備えています。しかし、AIX、HP-UX、その他のオペレーティングシステムと比較すると、Linux のメモリページング処理メカニズムには明らかな欠陥があります。この欠陥は、より大きな SGA を使用する Oracle データベースで特に顕著です。深刻な場合には、データベースのパフォーマンスに重大な悪影響を及ぼし、データベースが完全に応答しなくなることもあります。この記事では、この欠陥を事例から詳しく説明し、Linux で大きなメモリページを使用してこの問題を解決します。

1. 事例紹介

顧客のシステムの 1 つに深刻なパフォーマンスの問題が発生していました。問題が発生すると、システムは基本的に使用できなくなり、アプリケーション上のすべてのビジネス操作が完全に応答しなくなります。システムデータベースは、RHEL 5.2 (Red Hat Enterprise Linux Server release 5 (Tikanga)) で稼働する Oracle 10.2.0.4 Oracle Database であり、CPU は 4 コア Xeon プロセッサ (Intel(R)Xeon(R) CPU E7430 @ 2.13GHz) 4 基、つまり論理 CPU は 16 であり、メモリは 32GB です。障害発生中、データベースサーバーの CPU は長時間にわたって 100% のままでした。アプリケーションのすべての WebLogic Server をシャットダウンした後も、データベースサーバーの CPU 使用率は数分間 100% のままで、その後徐々に低下し、通常のアイドル状態になるまでに約 20 分かかります。この時点ではすべてのアプリケーションがシャットダウンされているため、CPU 使用率が非常に低い状態だけが通常の状態です。このシステムのデータベース保守担当者によると、この状況は何度も発生しており、データベースを再起動しても、1、2日以内に再びこのような障害が発生するとのことです。同時に、このシステムは最近大きな変更を受けていません。

障害報告を受け取った後、著者は SSH 経由でのデータベースへの接続が非常に遅く、接続にほぼ 1 分かかることを発見しました。まずはサーバーのパフォーマンスを簡単に見てみましょう。開発IOは極めて低く、メモリも1GB以上とまだ十分残っており、ページイン/ページアウトもありません。最も注目すべき現象は、CPU 使用率が非常に高く、常に 100% を維持していることです。同時に、CPU 使用率の SYS 部分は 95% を超えています。オペレーティングシステムの実行キューは常に 200 を超えています。サーバーのメモリ使用量は次のとおりです。

$cat /proc/meminfo

メモリ合計: 32999792 kB

メモリ空き容量: 1438672 kB

バッファ: 112304 kB

キャッシュ: 23471680 kB

スワップキャッシュ: 1296 kB

アクティブ: 19571024 kB

非アクティブ: 6085396 kB

合計高: 0 kB

上限空き容量: 0 kB

低合計: 32999792 kB

低空き容量: 1438672 kB

スワップ合計: 38371320 kB

スワップフリー: 38260796 kB

ダーティ: 280 kB

書き戻し: 0kB

匿名ページ: 2071192 kB

マップ済み: 12455324 kB

スラブ: 340140 kB

ページテーブル: 4749076 kB

NFS_不安定: 0 kB

バウンス: 0 kB

コミット制限: 54871216kB

コミット済み_AS: 17226744 kB

Vmalloc合計:34359738367 KB

Vmalloc使用: 22016 kB

Vmallocチャンク:34359716303 KB

現象の観点から見ると、SYS CPU が高いことは問題を分析するための重要な手がかりとなります。

オペレーティングシステムのパフォーマンスをできるだけ早く把握した後、すぐに Sqlplus を介してデータベースに接続し、データベース内のパフォーマンス情報を表示します。

(注: 以下のデータは、SQL、サーバー名、データベース名などに関して処理されています)

SQL> select sid,serial#,program,machine,sql_id,eventfrom v$session where type='USER' and status='ACTIVE';

SID シリアル番号 プログラム マシン SQL_ID イベント

-------------------- -------------------------------- ---------- -------------

519 4304 xxx_app1 0gc4uvt2pqvpu ラッチ: キャッシュバッファチェーン

459 12806 xxx_app1 0gc4uvt2pqvpu ラッチ: キャッシュバッファチェーン

454 5518 xxx_app1 15hq76k17h4ta ラッチ: キャッシュ バッファ チェーン

529 7708 xxx_app1 0gc4uvt2pqvpu ラッチ: キャッシュバッファチェーン

420 40948 xxx_app1 0gc4uvt2pqvpu ラッチ: キャッシュバッファチェーン

353 56222 xxx_app1 f7fxxczffp5rx ラッチ: キャッシュ バッファ チェーン

243 42611 xxx_app1 2zqg4sbrq7zay ラッチ: キャッシュ バッファ チェーン

458 63221 xxxTimer.exe APPSERVER 9t1ujakwt6fnf ローカル書き込み待機

...スペースを節約するために一部の内容は省略されています...

409 4951 xxx_app1 7d4c6m3ytcx87 他のセッションによって読み取られました

239 51959 xxx_app1 7d4c6m3ytcx87 他のセッションによって読み取られました

525 3815 xxxTimer.exe APPSERVER 0ftnnr7pfw7r6 enq: RO -fast オブジェクト reu

518 7845 xxx_app1 ログファイル同期

473 1972 xxxTimer.exe APPSERVER 5017jsr7kdk3b ログファイル同期

197 37462 xxx_app1 cbvbzbfdxn2w7 dbファイルシーケンシャル読み取り

319 4939 xxxTimer.exe APPSERVER 6vmk5uzu1p45m dbファイルシーケンシャル読み取り

434 2939 xxx_app1 gw921z764rmkc ラッチ: 共有プール

220 50017 xxx_app1 2zqg4sbrq7zay ラッチ: ライブラリ キャッシュ

301 36418 xxx_app1 02dw161xqmrgf ラッチ: ライブラリ キャッシュ

193 25003 oracle@xxx_db1 (J001) xxx_db1 ジョブQスレーブ待機

368 64846 oracle@xxx_db1 (J000) xxx_db1 ジョブQスレーブ待機

218 13307 sqlplus@xxx_db1 (TNS V1-V3) xxx_db1 5rby2rfcgs6b7 クライアントへのSQL*Netメッセージ

435 1883 xxx_app1 fd7369jwkuvty クライアントからのSQL*Netメッセージ

448 3001 xxxTimer.exe APPSERVER bsk0kpawwztnwSQL*dblink からのネット メッセージ


SQL>@waitevent

SID イベント SECONDS_IN_WAIT 状態

------------------------------------ --------------- -------------------

556 ラッチ: キャッシュ バッファ チェーン 35 待機時間 既知

464 ラッチ:キャッシュ バッファ チェーン 2 待機中

427 ラッチ:キャッシュ バッファ チェーン 34 待機時間が短い

458 ローカル書き込み待機 63 待機中

403 書き込み完了待ち 40 WAITING

502 書き込み完了待ち 41 待機中

525 enq:RO - 高速オブジェクト再利用 40 WAITING

368 enq:RO - 高速オブジェクト戻り 23 WAITING

282 db ファイル シーケンシャル リード 0 待機中

501 dbfile シーケンシャル読み取り 2 短時間待機

478 db ファイル シーケンシャル リード 0 待機中

281 db ファイル シーケンシャル読み取り 6 待機時間 既知

195 db ファイル シーケンシャル読み取り 4 待機時間 既知

450 db ファイル シーケンシャル読み取り 2 待機時間 (既知)

529 db ファイル シーケンシャル リード 1 待機中

310 dbfile シーケンシャル読み取り 0 待機時間 既知

316 db ファイル順次読み取り 89 短時間待機

370 db ファイル シーケンシャル リード 1 待機中

380 db ファイルのシーケンシャル読み取り 1 短時間待機

326 ジョブQスレーブ待機 122 待機中

378 jobq スレーブ 待機 2 待機中

425 ジョブQスレーブ待機 108 待機中

208 SQL*Net データベースからさらにデータ 11 待機時間が短いリンク

537 ストリーム AQ: t 7042 待機中時間管理またはクリーンアップタスク

549 ストリーム AQ: qmn 座標 1585854 WAITING またはアイドル待機

507 ストリーム AQ: qmn スレーブ idl 1585854 待機中 e 待機

430 ラッチフリー 2 待機時間既知

565 ラッチ:キャッシュ バッファ lru 136 待機時間が短いチェーン

データベース内のアクティビティと待機イベントから判断すると、異常はありません。データベースサーバーの CPU 使用率が長時間 100% であったり、物理メモリが枯渇し、大量のスワップメモリがスワップインおよびスワップアウトされている場合は、特定の種類の待機イベントが CPU またはメモリ不足の結果であるかどうか、またはデータベース内の特定のアクティビティが過度の CPU またはメモリ枯渇の根本原因であるかどうかなど、データベース内のパフォーマンス現象を慎重に診断する必要があることに注意してください。

上記のデータから判断すると、アクティブなセッションは 50 未満とそれほど多くなく、バックグラウンドプロセスの数は、オペレーティングシステムで実行されている 200 とはまったく異なります。データベースには、主に 3 つの非アイドル待機イベントがあります。DB ファイルの順次読み取りなどの IO 関連の待機、DB リンク関連の SQL*Net の dblink からの追加データ、およびラッチ関連の待機イベントです。これら 3 つのカテゴリのうち、通常はラッチなどの待機イベントのみが CPU 使用率の増加を引き起こします。

AWR レポートを分析および比較すると、障害期間と通常期間のデータベースアクティビティに特に明らかな違いはありません。しかし、システム統計に関しては大きな違いがあります。

統計名 1番目 2番目の値

------------------------------------------------- -------------- ------------------------

ビジー時間 3,475,776 1,611,753

アイドル時間 2,266,224 4,065,506

IOWAIT_TIME 520,453 886,345

負荷 -67 -3

ナイスタイム 0 0

CPUソケット数 0 0

物理メモリバイト 0 0

RSRC_MGR_CPU_WAIT_TIME 0 0

SYS_TIME 1,802,025 205,644

ユーザー時間 1,645,837 1,381,719

上記データは、故障期間を含む1時間（1時間目）と通常期間の1時間（2時間目）のAWRの比較データです。障害分析の場合、特に障害の継続時間が短い場合、1 時間の AWR レポートでは障害期間中のパフォーマンスが正確に反映されません。しかし、トラブルシューティングを行う際にまず行うべきことは、さまざまなデータから方向性を見極めることです。前述のように、SYS セクションの CPU 使用率が高いことは重要な手がかりです。データベース内の他のパフォーマンスデータに大きな違いがない場合は、CPU から始めることができます。

2. オペレーティングシステムのCPU使用率の分析

では、オペレーティングシステムにおける SYS と USER の 2 つの異なる使用法は何を表すのでしょうか?あるいは、この 2 つの違いは何でしょうか?

簡単に言えば、CPU 使用率の SYS 部分とは、オペレーティングシステムカーネル (Kernel) が使用する CPU 部分、つまりカーネル状態で実行されているコードによって消費される CPU を指します。最も一般的なのは、システムコール (SYS CALL) 中に消費される CPU です。 USER 部分は、アプリケーションソフトウェア自体のコードによって使用される CPU 部分、つまり、ユーザーモードで実行されるコードによって消費される CPU 部分です。たとえば、Oracle が SQL を実行する場合、ディスクから db バッファキャッシュにデータを読み取るための読み取り呼び出しを開始する必要があります。この読み取り呼び出しは、主にデバイスドライバコードを含むオペレーティングシステムカーネルによって実行されるため、CPU 消費量は SYS 部分に計算されます。Oracle がディスクから読み取ったデータを解析する場合、Oracle 独自のコードのみが実行されるため、CPU 消費量は USER 部分に計算されます。

では、SYS 部分で CPU を生成する操作やシステムコールは何でしょうか?

1. ファイルの読み取りと書き込み、周辺機器へのアクセス、ネットワーク経由のデータ転送などの I/O 操作。この操作の部分では、主にデバイスの IO 操作に時間がかかるため、通常は CPU をあまり消費しません。たとえば、ディスクからファイルを読み取る場合、ほとんどの時間はディスク内の操作に費やされ、消費される CPU 時間は I/O 操作の応答時間のごく一部を占めるだけです。同時 I/O が高すぎる場合にのみ、SYS CPU 使用率が増加する可能性があります。

2. アプリケーションプロセスによるオペレーティングシステムからのメモリの申請、オペレーティングシステムによるシステムの使用可能なメモリの維持、スペースページのスワップなどのメモリ管理。実際、Oracle と同様に、メモリが大きくなるほど、またメモリ管理操作の頻度が高くなるほど、CPU 消費量は高くなります。

3. プロセスのスケジュール設定。 CPU のこの部分の使用率は、オペレーティングシステムの実行キューの長さによって異なります。実行キューが長いほど、スケジュールする必要のあるプロセスが多くなり、カーネルの負荷が高くなります。

4. その他、プロセス間通信、セマフォ処理、デバイスドライバー内の一部のアクティビティなど。

システム障害時のパフォーマンスデータから判断すると、SYS CPU 使用率が高くなる原因はメモリ管理とプロセススケジューリングにある可能性があります。ただし、実行キューが 200 以上の場合、実行キューが高いために CPU 使用率が上昇しているのではなく、CPU 使用率が高いことが原因である可能性が高くなります。データベースから見ると、アクティブセッションの数は特に多くありません。では、CPU 使用率の高さがシステムメモリ管理の問題によって発生しているかどうかに注意する必要があります。

この記事の冒頭で /proc/meminfo に収集されたシステムメモリデータを振り返ると、重要なデータが見つかります。

ページテーブル: 4749076 kB

データから、PageTables メモリが 4637 MB に達したことがわかります。 PageTables は文字通り「ページテーブル」を意味します。簡単に言えば、プロセスの線形仮想アドレスと実際の物理メモリアドレス間の対応を維持するためにオペレーティングシステムカーネルによって使用されるテーブルです。

現代のコンピュータは通常、物理メモリをページ単位 (ページフレーム) で管理および割り当てます。x86 プロセッサアーキテクチャでは、ページサイズは 4K です。オペレーティングシステム上で実行されているプロセスがアクセスできるアドレス空間は仮想アドレス空間と呼ばれ、プロセッサのビット数に関連しています。 32 ビット x86 プロセッサの場合、プロセスがアクセスできるアドレス空間は 4 GB です。オペレーティングシステムで実行されている各プロセスには、独自の独立した仮想アドレス空間またはリニアアドレス空間があり、このアドレス空間もページによって管理されます。Linux では、ページサイズは通常 4KB です。プロセスがメモリにアクセスすると、オペレーティングシステムとハードウェアが連携して、プロセスの仮想アドレスを物理アドレスに変換します。 2 つの異なるプロセスの同じ仮想線形アドレスは、共有メモリなどの同じ物理メモリを指す場合もあれば、プロセスのプライベートメモリなどの異なる物理メモリを指す場合もあります。

次の図は、仮想アドレスと物理メモリの対応関係を示す概略図です。

2 つのプロセス A と B があり、それぞれのメモリポインターがアドレス 0x12345 (0x は 16 進数) を指しているとします。たとえば、あるプロセスが別のプロセスをフォークまたはクローンすると、2 つのプロセスは同じメモリアドレスを指すポインターを持つことになります。プロセスがアドレス 0x12345 が指すメモリにアクセスすると、オペレーティングシステムはこのアドレスを物理アドレスに変換します。たとえば、プロセス A は 0x23456、プロセス B は 0x34567 です。この 2 つは互いに影響しません。それで、この物理アドレスはいつ取得されたのでしょうか?プロセス専用メモリの場合 (ほとんどの場合に当てはまります)、プロセスがオペレーティングシステムにメモリ割り当てを要求したときに取得されます。プロセスがオペレーティングシステムにメモリ割り当てを要求すると、オペレーティングシステムはページ単位でプロセスに空き物理メモリを割り当て、プロセスの仮想スレッドアドレスを生成し、仮想アドレスと物理メモリアドレスの間にマッピング関係を確立し、結果としてこの仮想アドレスをプロセスに返します。

ページテーブルは、プロセスの仮想アドレスと物理メモリ間の対応を維持するためにオペレーティングシステムが使用するデータ構造です。次の図は、比較的単純なケースのページテーブルの概略図です。

以下は、ページサイズが 4K の場合に、32 ビットシステムでオペレーティングシステムがプロセスの仮想アドレスと実際の物理アドレスを変換する方法の簡単な説明です。

1. ディレクトリテーブルは、ページテーブルのインデックスに使用されるデータ構造です。各ディレクトリエントリは 32 ビット (4 バイト) を占め、ページテーブルの場所を格納します。ディレクトリテーブルは、メモリの 1 ページ、つまり 4 KB を占有し、1024 個のディレクトリエントリを格納できます。つまり、1024 個のページテーブルの場所を格納できます。

2. ページテーブルエントリのサイズは 4 バイトで、物理メモリページの開始アドレスが格納されます。各ページテーブルも 4K のメモリを占有し、1024 個の物理メモリページの開始アドレスを格納できます。物理メモリページの開始アドレスは 4KB 単位で整列されるため、32 ビットのうちアドレスを表すのに必要なのは 20 ビットのみで、残りの 12 ビットは、メモリページが読み取り専用か書き込み可能かを示すなどの他の目的に使用されます。

3. 1024 ページテーブル。各ページテーブルには 1024 個の物理メモリページ開始アドレスがあり、合計 1M アドレスになります。各アドレスが指す物理メモリページのサイズは 4KB で、合計 4GB になります。

4. オペレーティングシステムとハードウェアが仮想アドレスを物理アドレスにマップする場合、仮想アドレスの 10 ビット 31 ～ 22 はディレクトリエントリから 1024 個のページテーブルの 1 つへのインデックスに使用され、仮想アドレスの 10 ビット 12 ～ 21 はページテーブルから 1024 個のページテーブルエントリの 1 つへのインデックスに使用されます。物理メモリページの開始アドレスはインデックスページテーブルエントリから取得され、仮想アドレスの 12 ビット 0 ～ 11 が 4 KB メモリページ内のオフセットとして使用されます。すると、物理メモリページの開始アドレスにオフセットを加えたものが、プロセスがアクセスする必要がある物理メモリのアドレスになります。

ディレクトリテーブルとページテーブルという 2 つのデータ構造がどれだけのスペースを占めるかを見てみましょう。ディレクトリテーブルは 4KB に固定されています。ページテーブルはどうでしょうか?ページテーブルは最大 1024 個あり、各ページテーブルは 4 KB を占有するため、ページテーブルは最大 4 MB のメモリを占有します。

実際には、32 ビット Linux のプロセスには通常、それほど大きなページテーブルはありません。プロセスが 4GB のアドレス空間をすべて使用することは不可能であり、1GB の仮想アドレス空間もカーネルに割り当てられます。同時に、Linux は一度にプロセスに対してこのような大きなページテーブルを作成しません。プロセスがメモリを割り当ててアクセスするときにのみ、オペレーティングシステムはプロセスに対応するアドレスのマッピングを作成します。

ここでは、ページングマッピングの最も単純なケースについてのみ説明します。実際には、ページテーブルと合わせて 4 つのレベルのページテーブルディレクトリが存在します。同時に、32 ビットまたは 64 ビットシステムで PAE が有効になっている場合、ページテーブル構造は上記の図よりも複雑になります。しかし、どのような場合でも、最後のレベルであるページテーブルの構造は一貫しています。

64 ビットシステムでは、ページテーブル内のページテーブルエントリのサイズが 32 ビットから 64 ビットに増加します。それで、これはどれほど大きな影響を与えるのでしょうか?プロセスが 1GB の物理メモリ、つまり 262144 のメモリページにアクセスする場合、32 ビットシステムではページテーブルに 262144*4/1024/1024=1MB が必要ですが、64 ビットシステムではページテーブルが占めるスペースは 1 倍、つまり 2MB に増加します。

ここで、Linux システム上で実行されている Oracle データベースの状況を見てみましょう。この場合、データベースの SGA サイズは 12GB です。OracleProcess がすべての SGA メモリにアクセスすると、ページテーブルサイズは 24MB となり、これは驚くべき数字です。 PGA はここでは無視されます。平均すると、各プロセスの PGA は 2M を超えず、SGA に比べて小さすぎるためです。 AWR レポートによると、セッションは約 300 個あるため、これらの 300 個の接続のページテーブルは 7200 MB に達しますが、すべてのプロセスが SGA 内のすべてのメモリにアクセスするわけではありません。 meminfo から確認できるページテーブルのサイズは 4637 MB です。このような大きなページテーブル領域は、300 セッションと 12 GB の SGA サイズによって生じます。

明らかに、ページテーブルはシステム内の唯一のメモリ管理データ構造ではありません。メモリを管理するために使用される他のデータ構造もあります。これらの過度に大きなメモリ管理構造は、間違いなくオペレーティングシステムカーネルの負担と CPU 消費を大幅に増加させます。ただし、負荷が変化したり、複数のプロセスが同時に大量のメモリを要求するなど、メモリ需要が大幅に変化すると、CPU が短期間でピークに達し、問題が発生する可能性があります。

3. 大きなメモリページを使用して問題を解決する

問題が過度に大きなページテーブルによって発生したことを証明するには、明確な証拠はなく、十分な証拠を収集する時間もありませんでした。そのため、30 分を超える複数のシステム使用不可障害に直面する必要がありました。しかし、現状から見ると、これが最大の疑わしい点です。そのため、システムのメモリ使用量を調整するために、まず巨大なメモリページを使用することが決定されました。

ラージメモリページは一般的な用語です。Linux の以前のバージョンでは Large Page と呼ばれ、現在の主流の Linux バージョンでは Huge Page と呼ばれています。以下では、Huge Page を例にして、Huge Page の利点とその使用方法を説明します。

大容量メモリページを使用する利点は何ですか。

1. ページテーブルのサイズを縮小します。各巨大ページは 2 MB の連続物理メモリに対応するため、12 GB の物理メモリには 48 KB のページテーブルのみが必要となり、これは元の 24 MB よりはるかに小さくなります。

2. 巨大ページメモリは物理メモリ内でのみロックでき、スワップ領域にスワップすることはできません。これにより、スワッピングによるパフォーマンスへの影響を回避できます。

3. ページテーブル数が減ったことにより、CPU 内の TLB (ページテーブルに対する CPU の CACHE とも言えます) のヒット率が大幅に向上します。

4. Huge Page のページテーブルはプロセス間で共有できるため、ページテーブルのサイズも削減されます。実際、これは Linux のページング処理メカニズムの欠陥を反映しています。 AIX などの他のオペレーティングシステムでは、共有メモリセグメントなどのメモリに対して同じページテーブルを共有するため、Linux ではこの問題が回避されます。例えば、筆者が保守しているシステムでは、接続数が5,000以上になることがほとんどで、インスタンスのSGAは60GB程度です。Linuxのページング方式を採用すると、システム内のメモリの大半がページテーブルで使い果たされてしまいます。

では、Oracle で巨大なページを有効にするにはどうすればよいでしょうか?これを実装する手順は次のとおりです。このケースに関係するデータベースは一定期間後に SGA を 18G に調整したため、ここでは 18G が例として使用されています。

1. /proc/meminfo をチェックして、システムが HugePage をサポートしていることを確認します。

巨大なページの合計: 0

HugePages_無料: 0

巨大ページ_予約: 0

巨大ページサイズ: 2048 kB

HugePages Total は、システムに構成されている巨大メモリページの数を示します。 HugePages Free は、アクセスされていない大きなメモリページの数を示します。ここでの「free」という言葉は誤解を招く恐れがあるため、後で説明します。 HugePages Rsvd は、割り当てられているがまだ使用されていないページの数を示します。 Hugepagesize は、大きなメモリページサイズを示します。ここでは 2MB です。カーネル構成によっては 4MB になる場合があることに注意してください。

たとえば、HugePages の合計が 11 GB の場合、SGA_MAX_SIZE は 10 GB、SGA_TARGET は 8 GB になります。データベースが起動すると、SGA_MAX_SIZE (ここでは 10 GB) に応じて HugePage メモリが割り当てられます。実際の空き HugePage メモリは 11-10=1G です。ただし、SGA_TARGET は 8GB しかないため、2GB はアクセスされず、HugePage_Free は 2+1=3GB、HugePage_Rsvd メモリは 2GB あります。実際には、他のインスタンスで使用できるのは 1 GB のみであり、つまり実際に空いているのは 1 GB のみであることを意味します。

2. 設定するメモリページ数を計画します。これまで、巨大ページは共有メモリセグメントなど、いくつかの種類のメモリでのみ使用可能でした。物理メモリが巨大ページとして使用されると、プロセスのプライベートメモリなどの他の目的に使用できなくなります。したがって、大きなメモリページとして、あまり多くのメモリを設定することはできません。通常、Oracle データベースの SGA として大容量メモリページを使用するため、大容量メモリページの数は次のようになります。

HugePages_Total = ceil(SGA_MAX_SIZE/Hugepagesize)+N

たとえば、データベースの SGA_MAX_SIZE が 18GB に設定されている場合、ページ数は ceil(18*1024/2)+2=9218 になります。

ここで N を追加すると、HugePage メモリスペースを SGA_MAX_SIZE よりわずかに大きく設定する必要があることを意味します (通常は 1 ～ 2)。 ipcs -m コマンドを使用して共有メモリセグメントのサイズを確認すると、共有メモリセグメントのサイズが実際には SGA_MAX_SIZE よりも大きいことがわかります。サーバー上に複数の Oracle インスタンスがある場合は、各インスタンスの共有メモリセグメントの追加部分を考慮する必要があります。つまり、N 値が大きくなります。さらに、Oracle データベースは、巨大なメモリページをすべて使用するか、まったく使用しないかのいずれかであるため、不適切な HugePages_Total はメモリの無駄遣いを引き起こします。

計算に SGA_MAX_SIZE を使用するだけでなく、ipcs -m で取得した共有メモリセグメントサイズを使用して、より正確な HugePages_Total を計算することもできます。

HugePages_Total = sum(ceil(share_segment_size/Hugepagesize))

3. /etc/sysctl.conf ファイルを変更し、次の行を追加します。

vm.nr_hugepages=9218

次に、sysctl –p コマンドを実行して設定を有効にします。

ここで、vm.nr_hugepages のパラメータ値は、手順 2 で計算された巨大メモリページの数です。次に、/proc/meminfo を確認します。HugePages_Total が設定された数より少ない場合、これらの大きなメモリページ用の連続した物理メモリが不足していることを意味し、サーバーを再起動する必要があります。

4. /etc/security/limits.conf ファイルに次の行を追加します。

オラクル ソフト メモリロック 18878464

オラクル ハード メモリ ロック 18878464

ここで、Oracle ユーザーがロックできるメモリのサイズを KB 単位で設定します。

次に、Oracle ユーザーとしてデータベースサーバーに再接続し、ulimit -a コマンドを使用して次の内容を確認します。

最大ロックメモリ (キロバイト、-l) 18878464

ここで memlock を無制限に設定することも可能です。

5. データベースが MANUAL メソッドを使用して SGA を管理している場合は、それを AUTO メソッドに変更する必要があります。つまり、SGA_TARGET_SIZE を 0 より大きい値に設定します。 11g では、HugePage は共有メモリにのみ使用でき、PGA には使用できません。そのため、AMM は使用できません。つまり、MEMORY_TARGET を 0 より大きい値に設定することはできません。SGA と PGA は個別にのみ設定でき、SGA は AUTO モードでのみ管理できます。

6. 最後に、データベースを起動し、/proc/meminfo をチェックして HugePages_Free が減少したかどうかを確認します。減少している場合は、HugePage メモリが使用されていることを示します。

しかし、障害が発生したデータベースサーバーの /proc/meminfo を確認すると、HugePage 関連の情報が存在しないことがわかりました。Sysctl -a はすべてのシステムパラメータをチェックしましたが、パラメータ vm.nr_hugepages は見つかりませんでした。これは、HugePage 機能が Linux カーネルにコンパイルされていないためです。 HugePage を有効にするには別のカーネルを使用する必要があります。

/boot/grub/grub.conf を確認します。

# grub.conf は Anaconda によって生成されます

# このファイルを変更した後、grubを再実行する必要はありません。

#注意: /bootパーティションがあります。これは、

# すべてのカーネルおよび initrd パスは /boot/ からの相対パスです。例:

# ルート(hd0,0)

# kernel/vmlinuz-version ro ルート=/dev/VolGroup00/LogVol00

# initrd/initrd-バージョン.img

#boot=/dev/cciss/c0d0

デフォルト=0

タイムアウト=5

スプラッシュイメージ=(hd0,0)/grub/splash.xpm.gz

隠しメニュー

タイトル Red Hat Enterprise Linux Server (2.6.18-8.el5xen) RDAC 搭載

ルート (hd0,0)

カーネル/xen.gz-2.6.18-8.el5

モジュール /vmlinuz-2.6.18-8.el5xen roroot=/dev/VolGroup00/LogVol00 rhgb 静か

モジュール/mpp-2.6.18-8.el5xen.img

タイトル Red Hat Enterprise Linux Server (2.6.18-8.el5xen)

ルート (hd0,0)

カーネル/xen.gz-2.6.18-8.el5

モジュール /vmlinuz-2.6.18-8.el5xen roroot=/dev/VolGroup00/LogVol00 rhgb 静か

モジュール/initrd-2.6.18-8.el5xen.img

タイトル Red HatEnterprise Linux Server-base (2.6.18-8.el5)

ルート (hd0,0)

カーネル /vmlinuz-2.6.18-8.el5 roroot=/dev/VolGroup00/LogVol00 rhgb 静か

モジュール/initrd-2.6.18-8.el5.img

このシステムで使用されているカーネルには「xen」という単語が含まれていることがわかりました。このファイルを変更し、default=0 を default=2 に変更するか、最初の 2 つのカーネルを # 記号でブロックしてから、データベースサーバーを再起動しました。新しいカーネルはすでに HugePage をサポートしていることがわかりました。

データベースで大容量メモリページを有効にした後は、SGA が拡大されても、この記事で説明したパフォーマンスの問題は発生しませんでした。 /proc/meminfo データを観察すると、PageTables によって占有されるメモリは 120 MB 未満のままであり、元のメモリと比較して 4500 MB 減少しています。 HugePages を使用する前と比べて CPU 使用率も低下し、システム動作もかなり安定しており、少なくとも HugePages の使用によって発生するバグは発生していないことが確認されています。

テストの結果、OLTP システムの場合、Oracle データベースを実行している Linux で HugePage を有効にすると、データベースの処理能力と応答時間がさまざまな程度に向上し、最大で 10% 以上向上することが分かりました。

IV. 要約

この記事では、ケーススタディを使用して、Linux オペレーティングシステムのパフォーマンスを向上させるための大容量メモリページの役割と、大容量メモリページを有効にするために対応するパラメータを設定する方法を紹介します。この記事の最後で、著者は、この場合に発生するパフォーマンスの問題を回避するか、システムパフォーマンスをさらに向上させるために、Linux オペレーティングシステムで Oracle データベースを実行するときに大容量メモリページを有効にすることを推奨しています。 HugePage は、追加コストなしでパフォーマンスを向上できる数少ない機能の 1 つであると言えます。また、新しいバージョンの Linux カーネルでは Transparent Huge Pages が提供されており、Linux 上で実行されるアプリケーションが共有メモリだけでなく、大容量のメモリページをより広範囲かつ便利に使用できることも注目に値します。この機能によって生じる変化を待ちましょう。

出典: 「Oracle DBA Notes 3」 Linux 大容量メモリページ Oracle データベースの最適化著者: Xiong Jun

画像ソース: http://2.bp.blogspot.com/-o1ihxahkl0o/VQFhFj2lHwI/AAAAAAAAAV4/egUhLwaYtmc/s1600/oracle_linux.png

要約する

上記はこの記事の全内容です。この記事の内容が皆さんの勉強や仕事に一定の参考学習価値を持つことを願っています。ご質問があれば、メッセージを残してコミュニケーションしてください。123WORDPRESS.COM を応援していただきありがとうございます。

以下もご興味があるかもしれません: