nkjmkzk.net

powered by Kazuki Nakajima

Archive for the ‘tmem’ tag

Xenでメモリをオーバーコミットする(Transcendent Memoryセットアップ編)

概要

  • 管理者は多かれ少なかれメモリをある程度オーバープロビジョニングする
  • 結果、性能は確保されるものの定常的に使われていないメモリが出てくる
  • これを特にサーバ仮想化環境で見ると相当量のメモリが「未使用」となり、「もし、メモリ割り当てを最適化できればあと数VM収容できるのに」となる。実際、メモリは現在唯一VMの収容数を絶対的に制限するハードリミットとなっている
  • この最適化を行うのがTranscendent Memory(以後tmem)。使われていないメモリをかき集めてtmem poolとして再配布可能とする
  • ゲストOSはtmemを有効にしてビルドされたカーネルで起動することによって、従来のpage cacheに格納していたページをtmemを使って読み書きするようになる

環境

  • Xen: 4.0.0
  • ゲストOS: Oracle Enterprise Linux 5.4 x86_64

セットアップ手順

dom0にログインし、Xen(4.0.0)でtmemを有効にする。grub.confを編集してカーネル行に「tmem」を追加しdom0を再起動する

[root@vmserver]# vi /etc/grub.conf
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Xen 4.0.0 (2.6.32.11-1.2.97.xendom0.fc12.x86_64)
	root (hd0,0)
	kernel /xen-4.0.gz dom0_mem=1024M loglvl=all guest_loglvl=all tmem
	module /vmlinuz-2.6.32.11-1.2.97.xendom0.fc12.x86_64 ro root=/dev/mapper/vg_x4-lv_root
	module /initramfs-2.6.32.11-1.2.97.xendom0.fc12.x86_64.img

[root@vmserver]# init 6

次にゲストOSにログインしtmemを有効にする。tmemはまだカーネルのメインラインにはマージされていないのでディストリビューションが公開しているカーネルSRPMにtmemパッチ当て、カーネルを再構築する。

tmemパッチ入手先:http://oss.oracle.com/projects/tmem/files/

カーネルSRPM入手先:http://public-yum.oracle.com/repo/EnterpriseLinux/EL5/5/base/x86_64/

公開されているtmemパッチはvanillaカーネル用なのでディストリビューション付属のカーネルに当てるといくつかHunk, Failがでるが手作業で直せるレベルなので手で直す。

[root@guest]# rpm -ivh kernel-2.6.18-194.3.1.0.1.el5.src.rpm
[root@guest]# cd /usr/src/redhat/SPECS
[root@guest]# rpmbuild -bp kernel-2.6.spec
[root@guest]# cd /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64
[root@guest]# patch -p1 < /var/opt/tmem-linux-2.6.18-xen-855-090408.patch

*4つ程Failするので手作業で直す

[root@guest]# cp configs/kernel-2.6.18-x86_64-xen.config .config

任意だが、わかり易いようにカーネル名を変更しておく

[root@guest]# vi .config
CONFIG_LOCALVERSION="-tmem"
[root@guest]# vi Makefile
EXTRAVERSION = -194.3.1.0.1.el5xen

ビルドする

[root@guest]# make -j8

*tmemについて有効化するか訊かれるので全て「Y」として有効化する

カーネルモジュールをインストールする

[root@guest]# make modules_install

カーネルをインストールする

[root@guest]# make install

initial ramdiskを作成する

[root@guest]# mkinitrd -v -f initrd-2.6.18-194.3.1.0.1.el5xen-tmem.img 2.6.18-194.3.1.0.1.el5xen-tmem

initial ramdiskをインストールする

[root@guest]# cp initrd-2.6.18-194.3.1.0.1.el5xen-tmem.img /boot/

新しいカーネルで起動するようにgrub.confを編集する

[root@guest]# vi /etc/grub.conf
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Enterprise Linux (2.6.18-194.3.1.0.1.el5xen-tmem)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-194.3.1.0.1.el5xen-tmem ro root=/dev/VolGroup00/root rhgb quiet
    initrd /initrd-2.6.18-194.3.1.0.1.el5xen-tmem.img
title Enterprise Linux (2.6.18-164.el5xen)
    root (hd0,0)
    kernel /vmlinuz-2.6.18-164.el5xen ro root=/dev/VolGroup00/root rhgb quiet
    initrd /initrd-2.6.18-164.el5xen.img

再起動し、新しいカーネルで起動する

[root@guest]# init 6

Demo



Reference

with one comment

Written by 中嶋 一樹

5月 20th, 2010 at 2:18 pm

Posted in Uncategorized

Tagged with ,

Xenでメモリをオーバーコミットする(Self-Ballooningセットアップ編)

概要

  • self-ballooningはゲストOS自らメモリをある条件に基づいて動的に返却する/獲得ことによって実質的にメモリをオーバーコミットするための仕組み
  • xenballoondはゲストOSで動くbashベースのデーモン。これがself-ballooningを制御する
  • xenballoondはdom0へのメモリ情報提供を担うことも計画されている
  • xenballoondは/proc/meminfoのCommitted_ASの値をベースに最低限必要なメモリ容量を判別する

環境

  • Xen: 3.4.0(Oracle VM Server 2.2.1)及び4.0.0(Fedora 12)で確認
  • ゲストOS: Oracle Enterprise Linux 5.4 x86_64

セットアップ方法

Xen側には特殊な設定は必要ありません。すべてゲストOSでの作業です。

まず、ゲストOS上でxen-4.0.0.tar.gzをxen.orgからダウンロードし展開します。これはxenのtarボールの中に必要なスクリプトがあるからです。(恐らくXen 3.3以降であれば必要なツールが含まれているはず)

[root@guest]# tar xvfz xen-4.0.0.tar.gz

展開されたディレクトリ中から3つのファイルをそれぞれインストール(コピー)する

[root@guest]# cp xen-4.0.0/tools/xenballoon/xenballon.conf /etc/sysconfig/
[root@guest]# cp xen-4.0.0/tools/xenballoon/xenballond /usr/bin/
[root@guest]# cp xen-4.0.0/tools/xenballoon/xenballond.init /etc/init.d/xenballoond

bashファイルを実行可能なようにパーミッションを変更する

[root@guest]# chmod 755 /usr/sbin/xenballoond
[root@guest]# chmod 755 /etc/init.d/xenballoond

必要に応じて設定ファイルを編集する

[root@guest]# vi /etc/sysconfig/xenballoon.conf

*特にXENBALLOON_SELF=falseはtrueに変更する必要がある

xenballoondデーモンを起動する

[root@guest]# service xenballoond start

検証結果

  • self-ballooning有効化によって動的にメモリ容量が縮小されるか? => yes
  • self-ballooning有効化によって動的にメモリ容量が拡張されるか? => yes(ただしユーザプロセスがメモリを予約した場合。page cacheでは拡張は発動しない)

使用したツール

mem_allocate.c(メモリを確保し、60秒後に解放するツール。適当に作った。)

#include 
#include 
#include 

int main(int argc, char **argv) {
       char *str;
       int i;

       if (argc == 2) {
               sscanf(argv[1], "%d", &i);
               printf("Allocating %d Bytes for 60 seconds...\n", i);
               str = (char *)malloc(i);
               memset(str, 1, i);
               sleep(60);
               free(str);
       } else {
               printf("This program needs exactly 1 argument.\nYou can set the bulk of RAM to allocate with integer.\n");
       }
       return 0;
}

Demo



Reference

without comments

Written by 中嶋 一樹

5月 19th, 2010 at 9:04 am

Posted in Uncategorized

Tagged with , ,

Xenでメモリをオーバーコミットする(概要編)

サーバ仮想化環境ではいろいろなリソースをオーバーコミットしてリソース稼働率を高めることができます。「オーバーコミット」は、本来的には物理リソース以上のリソースをさもあるかのようにみせかけて擬似的に割り当てることですが、サーバ仮想化環境で言う場合のオーバーコミットとは実際的には「リソースを共有すること」と考える方が正しい解釈であり、意義のある活用方法だと思います。

スクリーンショット(2010-05-16 14.46.59)

XenはCPUに関しては上図のようなオーバーコミットを古くからサポートしています。なので物理的なCPU数が仮想マシン収容数についてハードリミットとなることはありません。同様にネットワーク帯域やディスク帯域は共有することが基本的な考え方なのでこれらについても仮想マシン収容数のハードリミットになることはありません。しかしXenはメモリのオーバーコミットはサポートしないとしていました。したがって物理メモリは唯一仮想マシン収容数を制限するハードリミットということになります。

現在I/Aサーバ用サーバ仮想化技術において、メモリのオーバーコミットには大別すると下記のような実装方法があります。

  • SWAPディスク
    • ディスクをメモリに模倣して仮想マシンに割り当てる
    • しかし実際はディスクなので堪え難い性能劣化が発生する
  • 重複排除
    • 複数の仮想マシン間で重複するメモリを検出して一つにまとめる
    • 同一メモリページが多いと想定される環境(同一構成の仮想マシンを多数起動するような環境)では効果を期待できる
    • 重複判定処理にはオーバーヘッドが予想される。加えて、必ずしも重複排除できる可能性が高くない。
  • メモリ動的増減(Self-Ballooning)
    • 仮想マシンが必要に応じて能動的にメモリを獲得、解放する
    • オーバーサイジングされている環境ではかなりの効果を期待できる
    • しかし動的なメモリの獲得・解放は必ずしも十分高速でない

実はXenはバージョン3.3からSelf-Ballooningを用いたメモリの実質的なオーバーコミットが利用可能となっています。(ゲストOS側にSelf-Ballooning用ツールをインストールし、デーモンを起動する必要があります。)厳密にはこれはオーバーコミットというよりメモリを「増減」させる機構ですが、結果的には各仮想マシンのドメイン定義ファイルで設定されているメモリ量の総和が物理メモリを超えることができ、オーバーコミットと同様の効果をもたらします。

Self-Ballooningを有効にするとゲストOSは下記のようなことが可能になります。

  • 不要なメモリ領域(完全な空き、またはpage cacheに費やされている領域)を識別して能動的にメモリをXenに返却する *厳密には/proc/meminfoのCommitted_ASをベースに解放範囲を特定します
  • メモリ確保が必要になった場合、Xenにメモリ割り当て要求を発行して能動的にメモリ領域を獲得する

xm mem-setコマンド等でdom0側からゲストOSのメモリ容量を調整することはよく行われていると思いますが、Self-BallooningではゲストOSが能動的にメモリ増減を行うというところが特徴的です。

ちなみに少し話しはそれますが、Xen 4.0.0においてman xmdomain.cfgをみると下記のように「Xenではメモリオーバコミットはできない」と明記されています。

Xen does not support overcommit of memory, so the total memory of all guests (+ 64 MB needed for Xen) must be less than or equal to the
physical RAM in the machine.

しかし、実際にはSelf-Ballooningによるオーバーコミットは可能です。Xen 4.0.0のtarボールに含まれるxenballoonのREADMEは下記のようにメモリオーバーコミットが可能であると記載されています。

Xenballoond runs in guest domains and both implements selfballooning and provides metrics to dom0 for (future) directed ballooning. Both capabilities provide a foundation for basic “memory overcommit” functionality.

このあたりは個々の開発者でオーバーコミットに対する定義に違いがあることも一因かもしれませんが、どちらかというとXenのmanがあまりきちんとアップデートされていないことが問題な気がします。

さておき、つまるところXenではSelf-Ballooningを用いたメモリオーバーコミットが可能なわけですが、Self-Ballooningには前述の通り「メモリの獲得・解放が高速でない」という問題があります。そして、この問題を解決する手段としてPVM用に「Transcendent Memory」という新機能がXen 4.0.0から組み込まれています。Transcendent Memoryをごく簡単に言うと「物理メモリを複数の仮想マシン間で共有する仕組み」です。

スクリーンショット(2010-05-16 17.04.30)

その実装はXenが余っているメモリを「Transcendenet Memory Pool」というプールにまとめ、そのプールを複数の仮想マシンがクラスタファイルシステムのようなイメージで共有するという仕組みです。ファイルシステムと違うところは仮想マシンは別仮想マシンがTranscendent Memory Poolに保存したデータを閲覧することは当然できないということです。

*別途メモリのデータを共有できるタイプのPoolも実装が予定されています。

また、Transcendent Memoryにはいくつかの用途が考案されていますが現在実装されているのはpage cacheとして利用するという形です。Transcendent Memoryを有効にするには、Xen側で起動オプションを設定しておくことと、ゲストOS側のカーネルがTranscendent Memoryを有効にしてビルドされている必要があります。構築手順について詳しくは別のポストで解説しようと思います。

*ちなみにXen 4.0.0ではPage Sharingという重複排除タイプのオーバーコミット機能も組み込まれています。こちらはHVMのみの対応です。

そしてTranscendent MemoryはSelf-Ballooningと併用することで威力を発揮します。つまりこうなります。

  • Self-Ballooningによって仮想マシンは不必要なメモリを能動的に解放する
  • 元々空き領域であったメモリやSelf-Ballooningによって解放されたメモリをXenが掻き集めて「Transcendent Memory Pool」を構成する
  • 各ゲストOSは自身に最低限必要なメモリ(カーネルやアプリケーションによって予約されている領域)だけを自身の専有メモリとして保持し、その他必要となるメモリ(page cache)についてはTranscendent Memory Poolを利用する

ゲストOSが全てのメモリを専有する従来の形と比べて下記のようなメリットがあります。

まず、Self-Ballooningを有効にすることで多くの仮想マシンはメモリを解放し始めます。これによってよりサーバとして空きメモリが拡大し、より多くの仮想マシンを起動できるようになります。しかしこれだけだと各仮想マシンはメモリ不足によって、あるいはメモリを動的に獲得する処理が遅延することによって性能が劣化する可能性があります。この問題を解決するためにサーバ全体としてある程度の空きメモリを用意しておき、それを遅延なく必要に応じて割り当ててあげる仕組みがTranscendent Memoryです。サーバ全体としてメモリプールを持つことでゲストOSが個別にすべてのメモリを保持する形態よりも少ないメモリで効率的なキャッシングが可能になります

もちろん環境によって効果に差異はあると思いますが、特にpage cacheを活用するファイルサーバ、アプリケーションサーバではこの二つを組み合わせることによって集約密度を上げながら性能劣化を抑えられる可能性があります。逆にpage cacheを活用しない傾向が強いデータベースサーバではTranscendent Memoryはそれほど効果がないでしょう。ただしSelf-Ballooningで不要なメモリを綺麗に削ぎ落として他の仮想マシンやTranscendent Memory Poolで利用できるようにすることは意義があると思います。

このSelf-BallooningとTranscendent Memoryついて具体的な構築手順を別ポストにて解説しようと思います。

without comments

Written by 中嶋 一樹

5月 16th, 2010 at 8:18 am

Posted in Uncategorized

Tagged with , ,