Oracle Databaseでの Hugepage設計について 株式会社 日本総合研究所 カード業務システム本部 部長 兼 シニアエキスパート 佐脇 秀登 2025年1月24日 【JPOUG#11】

Copyright (c) The Japan Research Institute, Limited 自己紹介 佐脇 秀登(SAWAKI Hideto) • 株式会社 日本総合研究所においてクレジットカードシステム(オープン系)開発を所管する本部の 部長（オンプレのOpenShift上に構築したAPIを提供するシステムや、一日数千万件のデータを扱う Oracle Exadata など、ミッションクリティカルで大規模なシステム基盤の責任者） • また、社内でシニアエキスパート（ITアーキテクト）としての職位に認定され、全社の大規模案件の アーキテクチャ検討支援を行うとともに、技術相談やログ解析などトラブルシューティング支援にも従事 • 本部内の新人研修も企画、運営 保有資格 • ORACLE MASTER Platinum 8i • 高度情報処理技術者試験 x 8 • ネットワークスペシャリスト • プロダクションエンジニア • データベーススペシャリスト • セキュリティ（今の情報処理安全確保支援士相当） • アプリケーションエンジニア（今のシステムアーキテクト相当） • プロジェクトマネージャ • ITサービスマネージャ • ITストラテジスト

Copyright (c) The Japan Research Institute, Limited はじめに Linux の Huge Page という用語をご存じでしょうか。 大容量メモリを搭載するシステムのためのチューニング項目です。 Oracle Database でも使用できますので、その概要、設定方法、見積方法、注意点を ご紹介します。 （主に x86_64アーキテクチャの RHEL 8, Oracle Linux 8, Oracle Database 19c を対象に調べた内容です。 アーキテクチャやバージョンにより当てはまらないこともあるためご注意ください） 本資料は JPOUG Advent Calendar 2024 の18日目の記事をベースに補足を加えたものです。

Copyright (c) The Japan Research Institute, Limited Huge Page とその効果について Linux(x86_64アーキテクチャ)では物理メモリと仮想メモリのマッピング(ページテーブル)を (デフォルトでは)4KByteサイズのページ単位で管理します。マッピング1レコード分をページ テーブルエントリ（以下PTE）と呼びますが、PTEもメモリ内に格納されます。 大容量メモリを搭載したシステムではこのPTEが大量に必要になることと、PTEをCPU内で キャッシュするTLB (Translation Lookaside Buffer) のキャッシュのミスが増えるオーバー ヘッドによりパフォーマンスが低下します。

Copyright (c) The Japan Research Institute, Limited Huge Page とその効果について Huge Page という機能を用いることで、ページサイズを2MByte単位などに変更することが でき、以下の効果が期待できます。 •メモリ使用量の減少 •パフォーマンスの向上 詳しく仕組みを知りたい方は、Redhat社 や Oracle社の該当ドキュメントを参照ください。 •Redhat 社公式サイト 「RED HAT ENTERPRISE LINUX 8 システムのスループット、レイテンシー、および電力消費の最適化」第36章 huge page の設定 •Oracle 社公式サイト 大規模データベースのためのx86メモリ性能の設定方法

Copyright (c) The Japan Research Institute, Limited Huge Page とその効果について(Oracle Databaseの場合) • SGA 8GBを4KB単位で管理すると PTEは200万超のレコード数にもなる • SGAは共有メモリなので1プロセス毎 （専用サーバ接続なら≒1セッション毎）に それだけのPTEが必要になり、 ・100プロセスなら100倍必要 ・1プロセス毎にSGAの0.2%程度※ →100プロセスならSGAの20% →500プロセスならSGAと同じサイズ! ※観察してみたところ4KB毎に8Byteのエントリが必要らしく 8÷(4×1024)=0.2% なお、プロセスの状態により0.2%以下の場合もありました。 Huge Page を設定して2MB単位に ↓ PTEのレコード数は512分の1になる （メモリ使用率減少） ↓ 大容量メモリをアクセスする際にCPUが色 んなところを参照するという仕事も減る （パフォーマンス向上）

Copyright (c) The Japan Research Institute, Limited どう設定すれば良いか 大きく分けてLinuxとしての設定と、Oracle Database としての設定箇所があります。 •Linuxとしての設定 • カーネルパラメータ(/etc/sysctl.conf)に vm.nr_hugepages=value(ページ数) として利用したいHuge Pageのページ数を設定する • /etc/security/limits.conf ファイルの memlock を設定し、メモリ上にロックする アドレス空間のサイズをKBサイズで指定し引き上げる • 透過的な(Transparent)HugePagesを無効化する (Huge Pageはアプリケーションが意識して割り当てないと利用できないですが、 透過的なHugePagesはアプリケーションが意識しなくても利用できます ⇒ 二つの機能を同時に使うことは様々な問題が発生するため推奨されていません） • OS再起動を行い、設定値が意図通り永続化されていることを確認する

Copyright (c) The Japan Research Institute, Limited どう設定すれば良いか •Oracleとしての設定 • 自動メモリー管理(AMM)を無効化する（Huge Pageとは同時には使えません） 初期化パラメータ MEMORY_TARGET および MEMORY_MAX_TARGET の両方の設定を解除 • 初期化パラメータ USE_LARGE_PAGES を設定する 詳細な設定の仕方は以下を参照ください。 Oracle 社公式サイト 「データベース管理者リファレンス for Linux and UNIX System-Based Operating Systems」 A.7.4 LinuxでのHugePagesの構成

Copyright (c) The Japan Research Institute, Limited 必要なページ数(vm.nr_hugepages) の値はどう計算すれば良いか •先ほどのA.7.4 LinuxでのHugePagesの構成に記載されているスクリプト (hugepages_settings.sh)を実行して必要な容量を計測します。 (スクリプトは Oracle 社公式サイト My Oracle Support | id=401749.1 から取得します） •ざっくり説明すると、ipcs -m というコマンドの結果でOS全体で利用している (Oracle Databaseの利用かどうかに関わらない）共有メモリのサイズを合計し、 2MByteのページサイズで割って（＋最低限必要なわずかなページを足して） ページ数を計算しています。 余談ですがSGAは ・Fixed Size ・Database Buffers + Variable Size ・Redo Buffers などのセグメントとして確保されているようです。

Copyright (c) The Japan Research Institute, Limited 注意点その１ huge pageとして予約したページ分のメモリは、通常のページとしては利用できません。 使いもしない分を過剰に予約しないようにしましょう。 現在のページ数は grep Huge /proc/meminfo の HugePages_Total: 行で確認可能です。 ※ちなみに、ページテーブルの総使用量も /proc/meminfo で確認できます

Copyright (c) The Japan Research Institute, Limited 注意点その２ Oracle 社公式サイト My Oracle Support (https://support.oracle.com/epmos/faces/DocumentDisplay?id=401749.1)より引用 「ノート:このスクリプトを実行する前に、hugepagesを使用するすべてのアプリケーションが実行中 であることを確認します。」 とあるように、 実際に Huge Page を使う予定のプロセスが全て実行中であることが重要です。 例えば稼働する予定の Oracle インスタンスは全て稼働させた状態とします。 （例：2つのOSでクラスタを組み、1OS内に1インスタンスずつ稼働系を負荷分散させている 場合は、1OSに全てのインスタンスを片寄せして稼働させた状態にします） ×過少見積り ○この状態で計測する

Copyright (c) The Japan Research Institute, Limited 注意点その３ 必要量を算出する際は、Oracle Database 以外で Huge Page を使う予定のプロセスも 全て実行させましょう。 以下のような事例が発生したことがあります。 •全Oracleインスタンスを起動させてスクリプトで必要Huge Page数を算出し設定 •その後、OS再起動を実施するも、Huge Page 不足で Oracle インスタンスが起動しない

Copyright (c) The Japan Research Institute, Limited 注意点その３ 直接原因 原因を調査した結果、直接原因は以下の通りでした。 •OS再起動時にOracle以外(JavaVM)のプロセスが先に起動しHuge Pageを確保 •Oracleインスタンス起動時に 必要 Huge Page 数が確保できず Oracle インスタンスが起動しない (初期化パラメータ USE_LARGE_PAGES が ONLY に設定されている場合は Huge Pageの不足時には起動しない仕様)

Copyright (c) The Japan Research Institute, Limited 注意点その３ なぜ再起動するまで気づかなかったのか •必要 Huge Page を算出する際には該当プロセス(JavaVM)を起動させていなかったため、 見積りに含まれていなかった •また、後で JavaVM を起動させた際は「あれば Huge Page を使うし、なければ通常ページ サイズにフォールバック」という動きをしたためエラーにならず気づかなかった （参考：OpenJDK の開発に関わる Stefan Johansson さんの個人ページ Large pages and Java Java で Huge Page を使ったベンチマークも載っています。 このケースでは Java の処理が10%程度性能向上するらしいです。） どうすれば良かったのか •どのプロセスに Huge Page を使わせるかきちんと設計する •パフォーマンスを優先しない処理にはそもそも割り当てない（JavaVMに注意）

Copyright (c) The Japan Research Institute, Limited 注意点その４ 初期化パラメータ USE_LARGE_PAGES にはいくつかの設定値があります。 デフォルト値で良いかどうかはきちんと設計しましょう。 → 性能にこだわるなら ONLY が良いかと思います。 Huge Page を使うのに ONLY 以外に設定するなら不足分がフォールバックした旨アラートログ に出力されるので監視するようにしましょう。 Oracle社公式マニュアル [USE_LARGE_PAGES | Oracle 19c] (https://docs.oracle.com/cd/F19136_01/refrn/USE_LARGE_PAGES.html)

Copyright (c) The Japan Research Institute, Limited 注意点その４ USE_LARGE_PAGES は、ざっくり以下のような理解です。 •AUTO SGAに必要な Huge Page が足りなくても不足分はフォールバックして通常ページで確保 されてインスタンスは起動する •FALSE Huge Page を使用しない •ONLY インスタンス起動前に既に OS で確保済みの Huge Page から SGA に必要なページ数を 確保できなければインスタンスの起動に失敗する •AUTO_ONLY インスタンス起動時に Huge Page が不足していれば、OS の設定(vm.nr_hugepages） を動的に変更して確保し、それでも不足した場合はインスタンスの起動に失敗する （オンプレミスの Exadata の Oracle 19cのデフォルト）

Copyright (c) The Japan Research Institute, Limited 注意点その４ Oracle社公式 高可用性概要およびベスト・プラクティス | Oracle によると 「MAAのベスト・プラクティスは USE_LARGE_PAGES=ONLY です。 ノート：Exadataの USE_LARGE_PAGESの Oracle RDBMS 19c のデフォルトは AUTO_ONLY ですが、この値は今後非推奨になります」 とのことです。Exadata自動化ツールを使って設定すると ONLY になります。(19c) RDS for Oracle の場合に選択できる設定は、以下を参照してください。 AWS公式 サポートされている RDS for Oracle インスタンスで HugePages をオンにする

Copyright (c) The Japan Research Institute, Limited ご清聴ありがとうございました 本資料の内容は個人の見解であり、所属する組織の公式見解ではありません。