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

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 であり、メモリは 32​​GB です。障害発生中、データベース サーバーの 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 を応援していただきありがとうございます。

以下もご興味があるかもしれません:
  • LINUXでOracleデータベースユーザーを作成する方法の詳細な説明
  • Linux で Oracle データベースをバックアップするためのスケジュールされたタスクの設定に関するチュートリアル
  • Linux システムの Oracle データベースにおける ora12505 問題の解決方法
  • LinuxでのOracleデータベースの自動バックアップの詳細な説明
  • LinuxでOracleデータベースを作成する詳細なプロセス

<<:  WeChatアプレットでSVGアイコンを使用する方法

>>:  MySQL無料インストール版のパスワード設定に関する詳細なチュートリアル

推薦する

ウェブデザインでは、まずウェブサイトの包括的なイメージの位置付けが必要です。

⑴ 内容によって形式が決まります。まず内容を充実させ、次にブロックに分割し、トーンを決め、最後に細部...

Linux チェックアップ、Linux の状態 (ネットワーク IO、ディスク、CPU、メモリ) を把握

目次1. コアコマンド2. 共通コマンド3. コアコマンドの詳細な説明3.1、ps補助3.2 トップ...

vue-cropper コンポーネントは画像の切り取りとアップロードを実現します

この記事では、画像の切り取りとアップロードを実装するためのvue-cropperコンポーネントの具体...

vue-resource インターセプターの使用に関する詳細な説明

序文インターセプター最近のフロントエンド フレームワークでは、インターセプターは基本的に非常に基本的...

JS でモバイルのインタラクティブ エクスペリエンスを向上させる方法

目次1. 即時フィードバック1.1 ボタンからの即時フィードバック1.2 継続的なフィードバック1....

Mac での MySQL と Squel Pro の設定

Node.js の人気に応えて、最近、いくつかのサーバー側機能を実装するために Node.js を使...

CentOS での MySQL ログイン 1045 問題を解決する

アプリケーション全体を CentOS にデプロイする必要があるため、当然ながらデータベース操作は不可...

Net Core実装プロセス分析のDoc​​kerインストールと展開

1. Dockerのインストールと設定 #CentOS をインストールし、Docker パッケージを...

nginx で第 3 レベルドメイン名を設定する方法の例

問題の説明nginx を設定することで、異なるポートを介して異なる Web アプリケーションにアクセ...

Vueにおける仮想DOMの理解のまとめ

これは本質的に、ビュー インターフェース構造を記述するために使用される共通の js オブジェクトです...

VUE レンダリング機能の使い方と詳細な説明

目次序文レンダリングの役割レンダリング機能の説明レンダリングとテンプレートの違いレンダリング例要約す...

2018 年にリリースされる Apache Spark 2.4 の新機能は何ですか?

この記事は、2018 年 9 月 19 日に Adob​​e Systems Inc で開催された ...

SQL文におけるGROUP BYとHAVINGの使用に関する簡単な説明

GROUP BY 句と HAVING 句を紹介する前に、まず SQL 言語の特殊な関数である集計関数...

MySQLが内部一時テーブルを使用するタイミングについて簡単に説明します。

組合執行分析を簡単にするために、次のSQLを例として使用します。 テーブル t1 を作成します ( ...

Docker で Springboot プロジェクトを実行する実装

導入: springboot プロジェクトを実行する Docker の構成は実は非常にシンプルで、L...