レック・テクノロジー・コンサルティング株式会社TECH BLOG

大容量メモリに潜むメモリ枯渇問題最終回 ~Linux HugePageの薦め~

こんにちは。
前回までの内容で標準の4KBページを使用した場合、最大でSGA/512=PTE/1セッションであることがわかりました。サーバに搭載するメモリ容量に比例して許容する接続セッション数を増加させることが多く、思わぬ落とし穴として本連載ではPTEを取り上げてきました。

さて、今回は Oracle Database を使用して HugePage と 4KB(標準) を使用した場合にメモリ使用効率がどのように変化するのかを確認したいと思います。

検証用に使用する環境は、以下の通りです。

RHEL 5.6 (2.6.32) 64bit
CPU: Intel Core i7-2600 CPU 3.40GHz
メモリ:5GB
Oracle Database EE 11gR2 (シングルインスタンス)
SGA:3GB

大容量メモリ云々といっておきながらかなり貧弱な環境ですが、HugePageの検証データを得る目的であれば問題ありません。

上記のサーバに疑似アプリケーションサーバからJDBC接続を行い、接続数に応じてメモリ使用がどのように変化するのかを確認したいと思います。

今回は、上記の貧弱なサーバにかなり極端ですが500セッション接続してみたいと思います。
※今回は、メモリ使用率の変化するのかをわかりやすく採取するためかなり無謀なことをしています。
クエリレイテンシなどのパフォーマンスは一先ず気にしません。
もちろん、こんな貧弱なサーバで 500 接続並列処理で通常は満足のいくパフォーマンスは得られません。
ちなみに、HugePageの使用は4KBページ比べTLBキャッシュヒット率向上などの副次的効果も期待でき、理論的にパフォーマンスが向上します。

では、早速はじめましょう。
デフォルトの設定ではOracle起動時にSGAの全領域はメモリ上に獲得されません。
そこで事前準備として、以下の初期化パラメータの設定により、インスタンス起動時にSGAの全領域をメモリ上にコミットしてしまいます(より本番に近い状態になりますね)。

alter system set pre_page_sga=true scope=spfile;

インスタンスを起動し、アプリケーションから500セッション接続(専用サーバ)を行ってみます。
SGA は3GBフルで使用しているため、サーバプロセスが使用するPTEのサイズは約6MB/1セッションとなり、搭載メモリでは対処できるものではないはずです。

結果が以下のグラフになります。

結果としては、200セッション前後で処理が停止してしまいました。
空きメモリのサイズ不足が主な原因となっています。

続いてHugePageを使用します。
HugePageの使用の前にいくつか事前準備が必要です。

1. カーネルパラメータの設定(/etc/sysctl.conf)
vm.nr_hugepages
HugePage数を指定します。必要なHugePage数の導出は、Oracleインスタンスが起動している状態で以下のURLにある算出用のスクリプトを使用するのがよいでしょう。
http://docs.oracle.com/cd/E16338_01/server.112/b56317/appi_vlm.htm
単純に共有メモリサイズ÷Pageサイズですので手計算でも可能です。
※SGAサイズ/2M+α(インスタンス起動後にHugePage数が足りない状態となった場合インスタンスは異常終了するので、安全係数を加算するとよいでしょう)

2. メモリロック可能サイズの変更(/etc/security/limits.conf)
soft memlock <SGAサイズ以上>
hard memlock <SGAサイズ以上>
HugePageに割り当てられた領域はスワップアウト対象外領域となるため、インスタンス起動ユーザのメモリロック可能サイズを設定する必要があります。SGAサイズ以上が必要となりますので、SGA+安全係数(今後の拡張幅なども加味)とするのがよいでしょう。

上記の準備が完了したらサーバを再起動し、インスタンスを起動してください。
起動後、/proc/meminfo を確認し以下の値が獲得されていれば完了です。

HugePages_Total (HugePage総数)
HugePages_Free (HugePage空数)
HugePages_Rsvd (HugePage使用数)

4KBページと同様の処理を実行してみます。実行した結果が以下の通りです。

特に滞りなく500セッション接続が可能という結果となりました。
4KBページ時と比較し劇的に改善したことが確認できます。

まとめ

 
昨今の大規模メモリ搭載サーバ上でOracleデータベースを運用した場合に陥りやすい障害例として本コラムでご紹介させていただきましたがいかがでしたでしょうか。
検証では極端な方法を行っていますが、実際によくある状況としてはインスタンス起動後、数日経過してメモリ不足に陥るケースが多いようです(使用時間によるSGAのコミットサイズ拡張とPTE数の増加)。今後Oracleデータベース設計を行う上で重要な設定要素となるのではないでしょうか。

注意!!!
HugePage使用の留意点としては以下のURLの「G.2.3 HugePages構成の制限」をご確認ください
http://docs.oracle.com/cd/E16338_01/server.112/b56317/appi_vlm.htm

この記事をシェアする

  • Facebook
  • X
  • Pocket
  • Line
  • Hatena
  • Linkedin

資料請求・お問い合わせはこちら

WEB説明会実施中!

各技術領域ごとの業務内容や取り組んでいる最新技術についてお話します。
カメラ・マイクオフでの参加OK!
気軽にご参加ください。

お申込みはこちら

Re:Qチャンネル

Re:Qの技術領域や、これまで培ってきた経験を元にIT技術についての解説動画などを投稿しています。
是非ご覧ください!

公式Youtubeはこちら

ページトップへ戻る