大規模データベースのためのx86メモリ性能の設定方法

Linux HugePagesの使用

公開日: 2013年12月 著: Edward Whalen氏

この記事では、Linux HugePagesを使用して大規模データベースのx86メモリ・パフォーマンスを向上させる方法について説明します。

メモリ性能について

大規模なデータベース・システムのパフォーマンス・チューニングは難しいものです。オペレーティング・システム(OS)およびハードウェアによっては、AWRレポートやsar、top、iostatなどのOSツールといった、通常の分析手法では容易に発見できない性能問題が存在する場合があります。

x86環境におけるメモリ使用率は、容易に特定できない問題の1つです。しかし、適切に分析し構成することで、大幅な性能向上を実現することができます。

より大容量のメモリを搭載したシステムにおいて、メモリ使用量はこれまで以上に対処すべき重要な問題です。この記事では、大規模なデータベースのためにx86システムのメモリ性能を最適に構成する方法について説明します。

x86プラットフォームの仮想メモリ・アーキテクチャ

x86およびx86-64チップセットのメモリ・アーキテクチャは、当初から大幅に変更されましたが、デフォルトのメモリ・ページ・サイズは変更されていません。このため、データベースなどの大規模なアプリケーションで大量のメモリを使用する場合、非効率かつ過剰なオーバーヘッドが発生することがあります。

x86アーキテクチャは仮想メモリー・アーキテクチャであり、ハードウェアで物理的に使用できるよりも多くのメモリに対処できます。これは、各プロセスが対応する独自のメモリを持つことで実現されています。プロセスは、このメモリがプロセスの用途として利用可能なものであると判断します。これは、プロセスの仮想メモリと呼ばれます。このメモリは、実際にRAMチップ上に存在する物理メモリにすることも、スワップまたはページング領域と呼ばれる物理ディスク上の専用の領域に格納することもできます。

仮想メモリがRAMに格納されているかディスクに格納されているかはプロセスには分からず、メモリはOSによって管理されています。物理的に利用可能なメモリよりも多くのメモリが必要な場合、OSは一部のメモリをページング領域に移動させます。この動作は非常に非効率的であり、パフォーマンス問題の一般的な原因となっています。ディスクはRAMと比較して何倍も遅いため、「ページング」しているプロセスにおいて、重大なパフォーマンス問題が発生します。

Oracle DatabaseとLinuxのメモリ管理

システムで使用するメモリが多くなればなるほど、そのメモリを管理するためのリソースが必要になります。Linux OSでは、メモリ管理は、LinuxのkswapdプロセスとPage Tables メモリ構造を介して行われ、システム内に存在する各プロセスに対して1つのレコードが構成されます。各レコードは、そのプロセスが使用する仮想メモリの各ページと、その物理アドレス（RAMまたはディスク）で構成されています。このプロセスは、プロセッサの変換ルックアサイド・バッファ（TLB）、小さなキャッシュの使用によってサポートされます。

Oracle Databaseに大量のメモリを使用する場合、OSは仮想-物理変換を管理するために大量のリソースを消費し、その結果、Page Tables構造が非常に大きくなってしまうことがよくあります。各Page Tablesのエントリには、プロセスで使用されているすべてのメモリページの仮想-物理変換が含まれているため、非常に大きなSystem Global Area（SGA）の場合、各プロセスのPage Tablesエントリは非常に大きくなる可能性があります。例えば、8GB のメモリを使用する Oracle Database プロセスの場合、Page Tablesのエントリは 8GB/4KB または 2,097,152 レコード（ページ）となります。Oracle Databaseのセッション/プロセスが100個あるとすると、ページ数は100倍となります。このように、膨大な数のページを管理することになってしまいます。

繰り返しになりますが、Page Tablesのエントリーは、OSがシステム内のプロセスで使用するメモリを管理するために使用されます。Linuxでは、この管理を実行するOSプロセスはkswapdと呼ばれ、オペレーティング・システム・ツールで確認することができます。

TLBキャッシュは、パフォーマンスを向上させるために、Page Tablesのエントリーをキャッシュします。一般的なTLBキャッシュは4〜4,096エントリを保持します。数百万から数十億のPage Tablesのエントリがある場合、このキャッシュでは不十分です。

前述のように、大規模な SGA を使用するシステムでは、Page Tablesの構造が非常に大きくなる可能性があります。リスト1のLinux システムの出力例では、Page Tablesのエントリーが766 MBのRAMを占有していることが示されています。これは、システムの重大なオーバーヘッドになる可能性があります。私自身、Page Tablesのエントリーがギガバイトになっているのを見たことがあります。

Linux OSにおいて、HugePagesはカーネル機能であり、OSによって最新のハードウェア・アーキテクチャの大きなページサイズ機能をサポートすることが可能になります。Oracle Databaseでは、HugePagesを有効にして大きなページ・サイズを使用することで、オペレーティング・システムによるページ状態のメンテナンスを減らし、小さなページに対して多くのエントリを作成するよりも、大きなページに対して1つのページ・テーブル・エントリでより多くのメモリを管理することにより、TLBのキャッシュのヒット率を向上させることができます。Linuxでは、大きいページ・サイズは2MBです。

Oracle Linux 6またはRed Hat Enterprise Linux 6 (RHEL 6)では、リスト1に示すように、割り当てられたHugePagesの数を/proc/meminfoで使用することができます。

[root@ptc1 ~]# cat /proc/meminfo

MemTotal:      4045076 kB
MemFree:         14132 kB
Buffers:           656 kB
Cached:        1271560 kB
SwapCached:       6184 kB
Active:        2536748 kB
Inactive:       625616 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      4045076 kB
LowFree:         14132 kB
SwapTotal:     1052216 kB
SwapFree:            0 kB
Dirty:               0 kB
Writeback:           0 kB
Mapped:        2036576 kB
Slab:            49712 kB
CommitLimit:   3074752 kB
Committed_AS:  8054664 kB
PageTables:     766680 kB
VmallocTotal:536870911 kB
VmallocUsed:    263168 kB
VmallocChunk:536607347 kB
HugePages_Total:     0
HugePages_Free:      0
Hugepagesize:     2048 kB

リスト1

Oracle Linux 6では、リスト2に示すように、割り当てられたHugePagesが若干異なります。

AnonHugePages:         0 kB

HugePages_Total:    1508
HugePages_Free:       60
HugePages_Rsvd:       57
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       10240 kB
DirectMap2M:    16766976 kB

リスト2

Oracle Linux 6のHugePagesの値は、以下の通りです。

  • AnonHugePages。Anonymous HugePagesの数。このカウンターは、Oracle Linux 6.5で削除されました。Transparent HugePagesに関連します。（Transparent HugePages の詳細については、「Transparent HugePages と Oracle Databases」のセクションを参照してください。）
  • HugePages_Total。HugePagesの数。領域は、HugePages×2Mの数です。
  • HugePages_Free。まだ割り当てられていないプール内のHugePagesの数です。
  • HugePages_Rsvd。Reservedの略で、プールから割り当てられることがコミットメントされているが、まだ割り当てが行われていないHugePagesの数です。Reserved HugePagesは、たとえシステムがしばらく稼働していたとしても、アプリケーションが要求された時点でHugePagesのプールからHugePagesを割り当てることができることを保証するものです。
  • HugePages_Surp。surplusの略で、/proc/sys/vm/nr_hugepagesの値を超えるプール内のHugePagesの数です。surplus HugePagesの最大数は、/proc/sys/vm/nr_overcommit_hugepagesによって制御されます。これが0になることは珍しいことではありません。
  • Hugepagesize。HugePageのサイズです。これは現在2048または2MBです。

ソリューション

LinuxでHugePagesを有効にすると、ページ・サイズを大きくすることでTLBエントリーの数を減らすことができます。Linuxでは、HugePagesのサイズは2MBです。Oracle Database SGAに大きなページを使用することで、管理するページ数が大幅に削減されます。

リスト1の例では、1つのレコードの仮想-物理変換の数が2,097,152から4,096に減少しています。これにより、Page Tablesの構造のサイズが縮小され、TLBキャッシュのヒット率が向上し、kswapdの使用量も減少します。

注: HugePagesを有効にすると、パフォーマンスが劇的に向上することがあります。

LinuxにおけるHugePagesの有効化

Linux では、HugePages機能はLinux初期化パラメータvm.nr_hugepagesに Oracle Database SGA で利用可能にしたい2MBページ数を設定することで構成できます。このパラメータを設定すると、ページ数が大きくなるため、ページ数を減らすことができます。

注: Oracle Database 11g で導入された Oracle Database の自動メモリ管理機能には、Linux HugePagesとの互換性がありません。HugePagesによって提供されるパフォーマンス向上は、自動メモリ管理による使いやすさを凌ぐものです。

HugePagesの構成を実装するための詳細は、表1に示すMy Oracle Supportのドキュメントに記載されています。

表1.My Oracle Support Documents

My Oracle Support Document ID Document Name
1557478.1 "ALERT: Disable Transparent HugePages on SLES11, RHEL6, OEL6 and UEK2 Kernels"
361323.1 "HugePages on Linux: What It Is… And What It Is Not"
361468.1 "HugePages on Oracle Linux 64-bit"
749851.1 "HugePages and Oracle Database 11g Automatic Memory Management (AMM) on Linux"
1134002.1 "ASMM and LINUX x86-64 HugePages Support"
401749.1 "Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration"

vm.nr_hugepagesの構成に加えて、オプションのパラメータvm.hugetlb_shm_groupに、HugePages を使用する権限を持つOSグループを設定することができます。このパラメータはデフォルトで0に設定されるため、すべてのグループの権限でHugePagesを使用できます。このパラメータは、Oracle Databaseプロセスが含まれているOSグループ(oinstallなど)に設定できます。

Oracle Database インスタンスでLarge Pagesが有効であることの検証

アラート・ログを確認することで、データベース・インスタンスで大きなページが有効になっていることを確認することができます。インスタンスの起動時に、パラメータ一覧の前に、アラート・ログに次のようなエントリが表示されるはずです。

****************** Large Pages Information *****************

 Total Shared Global Region in Large Pages = 28 GB (100%)
 Large Pages used by this instance: 14497 (28 GB)
Large Pages unused system wide = 1015 (2030 MB) (alloc incr 64 MB)
Large Pages configured system wide = 19680 (38 GB)
Large Page size = 2048 KB

Transparent HugePagesとOracle Databases

最近、RHEL 6、Oracle Linux 6およびSUSE Linux Enterprise Server 11において、Transparent HugePagesという新機能が導入されました。Transparent HugePagesは、HugePagesの使用を自動的かつ動的にする試みです。残念ながら現在、Transparent HugePagesを従来のHugePagesと組み合わせて使用すると、パフォーマンスの問題やシステムの再起動を引き起こす可能性がある問題が生じています。My Oracle Support note 1557478.1 では、Oracle データベースと組み合わせてTransparent HugePages を使用しないよう推奨しています。

注: Oracle Linux バージョン 6.5 では、Transparent HugePages は削除されました。

結論

より大きなページを使用することで、Page Tablesのエントリ数が減少し、その結果、大きなオーバーヘッドが最小限に抑えられます。HugePagesの使用によって得られる改善効果は非常に大きく、システムのメモリ量とSGAのサイズに伴って増加します。

こちらもご覧ください

著者について

Edward WhalenはOracle ACEであり、データベースのパフォーマンス、管理、移行、仮想化、ディザスタ・リカバリのソリューションに特化したコンサルティング会社Performance Tuning Corporationのチーフ・テクノロジストで、25年以上の経験を有しています。また、最適なパフォーマンスを実現するシステム・アーキテクチャの設計に豊富な実績があります。これまで、さまざまな企業のハードウェア、OS、データベース、仮想化プロジェクトに携わっています。Oracleの製品に関する本を6冊、Microsoft SQL Serverに関する本を5冊執筆しており、Oracle PressのOracle Enterprise Manager Cloud Control 12c Deep Diveを書き上げたばかりです。また、Oracle製品とMicrosoft SQL Serverの両方で、数多くのベンチマークやパフォーマンス・チューニングのプロジェクトに携わってきました。

ストレージやハードウェア、ハイパーバイザー、OS、データベースに至るまで、クラウド/アプリケーション・スタックの全レイヤーで構成されるアーキテクチャに関する幅広い経験を有しています。この経験は、彼が過去に行ったシステム・アーキテクチャの仕事の基礎となりました。

Edward は、大学時代に高エネルギー物理学の実験物理学者として、Fermi研究所とStanford Linear Accelerator Centerの両方でプロジェクトに取り組みました。Superconducting Super Colliderで短期間働いた後、コンピューター・ソフトウェアに移り、その後、コンピューター・ハードウェアとOSの開発に従事し、データベース・パフォーマンス・エンジニアリングへとキャリアを歩んできました。