2009年 7月 28日 火曜日
やっぱり Sun がスキ!
Solaris で Oracle を効率的に稼働させるための仕組み
はじめに
wikis.sun.com に Oracle on Sun に関する面白い情報がありましたのでご紹介したいと思います。Oracle データベースを Solaris 上で効率よく安定して稼働させるために、Solaris にどんな技術が実装されて来たのかが時系列でまとまっています。全ての技術を網羅している訳ではありませんが、皆さまのご参考になれば幸いです。元の文書に大きく加筆修正を施していますので、もしお時間があれば元文書もご覧下さい。
初期の技術革新
1993 年、Solaris 2.2 の ISM
Solaris 2.2 で ISM(Intimate Shared Memory) が実装されました。
ISM は、共有メモリ のアドレス変換テーブルをプロセス間で共有する機能です。ISM を使用しない場合は共有メモリのアドレス変換テーブルはプロセス毎に作成されますが、沢山のプロセスが同じ共有メモリを使用すると同じマッピング情報が重複して保持される事になり、カーネルメモリと TLB が無駄になります。SGA に接続する Oracle プロセスの数が多い大規模なシステムでは ISM の共有ページテーブル機能は非常に効果的です。また、ISM を使用して確保されるメモリページは物理メモリ上にロックされるという利点もあります。これにより ISM を使用する Oracle の SGA は常に物理メモリ上に常駐し、スワップアウトされないことが保証されます。これも大規模システムで性能を発揮するのに効果的です。ISM のもう一つの特徴として、大規模ページのサポートがあります。SPARC システムのデフォルトのページサイズは通常 8KB ですが、ISM を使用すると可能な場合は 4MB など、より大きなページサイズが適用されるようになります。大規模ページサイズを使用することでキャッシュミスを抑制し処理の効率が上がります。共有ページテーブル、大規模ページサポート、ページのロックという大規模システムでデータベースを効率よく実行するたに必要が技術が ISM によって実現しました。
試しに Oracle のサーバプロセスに pmap コマンドを実行すると "ism" が使用されていることが分かります。
# pmap -xs 21323
21323: oraclefoo (LOCAL=NO)
Address Kbytes RSS Anon Locked Pgsz Mode Mapped File
...
0000000380000000 2592768 2592768 - 2592768 4M rwxsR [ ism shmid=0x64 ]
# ipcs -ma
IPC status from as of Tue Jul 7 10:50:01 JST 2009
T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
Shared Memory:
m 100 0x8bba0d8c --rw-r----- oracle dba oracle dba 21 2654994432 423 4957 0:00:01 0:01:11 12:35:55
Jim Mauro が書いた Sun World の記事には ISM の詳細が解説されています。併せてご覧下さい。
ISM の実装は OpenSolaris のソースコードを "ISM" で検索して下さい。
"Oracle Database 管理者リファレンス" の中にも ISM に関する記述があります。
SDC(Solaris Developer Connection) にも ISM の使い方が詳解されています。
Java で ISM を使用する方法はこちらをご覧下さい。
ラッチ保有時のプリエンプション抑制
schedctl_init(3C) を始めとする schedctl API は Solaris のスケジューラによるプリエンプションを抑制するインターフェイスです。クリティカルなロックを保持しているスレッドがプリエンプトされてスレッドの優先順位の逆転が起きてしまうのを防ぎます。ロックを保持しているアプリケーションは schedctl API を使って、スケジューラに対してもう少し長い間 CPU を使用できるように依頼することができます。schedctl API は Oracle ではラッチで使用されています。ラッチを保持しているスレッドがスケジューラによって休眠させられて並列度が制限されることを防ぎます。
64bit Solaris
10 年以上前のことですが、Solaris は 2.7 から 64bit 実装が登場しました。64bit Solaris 上で 64bit Oracle を使用することにより、4GB 以上のメモリを搭載したマシンでもリソースを有効に使える様になりました。当時のフラッグシップだった Sun Enterprise 10000 は最大 64GB のメモリを搭載可能なマシンでした。一方、32bit 版の Oracle では genksms コマンドを使用して初めて 2GB 以上の SGA を確保する事が出来ました。
10 万 tpmC の壁を突破
1999 年、Sun と Oracle は TPC-C で 10 万 tpmC を超えて業界最高性能を達成しました。その時の記録は Sun Enterprise 10000 上の Solaris 2.7 と Oracle 8i の組み合わせで 115,395.73 tpmC です。この結果は、64bit Solaris, ISM, schedctl API 等、ここまで挙げて来た全ての技術革新の結実でした。
当時のプレスリリースはこちらです。
Solaris 9 が 2002 年に登場してから
DISM(Dymanic ISM)
DISM は共有ページテーブル、大規模ページサポートなどの ISM の機能に加えて、必要に応じてサイズを増やしたり、ページをロック/解除する機能を備えています。DISM は ISM の恩恵を受けつつ Oracle 9i から導入された動的 SGA を使用するために必要な機能です。Oracle の SGA_MAX_SIZE, MEMORY_TARGET または MEMORY_MAX_TARGET パラメータが適切に設定されている場合に DISM が使用されます。
また、Solaris の RCM(Reconfiguration Coordination Manager) のスクリプトと DISM, 動的 SGA を組み合わせることで、動的システムドメインからメモリを取り除く際も Oracle を停止せずに運用することが可能です。
Solaris 8 1/01 の機能比較表に DISM についての記載があります。
DISM には 共有ページテーブル、大規模ページサポート、ページのロックなど、 ISM と同じ特長があります。DISM ではこれに加え、他のアプリケーションに メモリを解放するためにページのロックが解除され、共有メモリセグメントの サイズを増やすために新たなページがロックされます。この機能により、Oracle データベースのパフォーマンスが著しく向上します。
Oracle 11g の管理者リファレンスにも DISM についての記載があります。
NUMA システムへの最適化
Solaris 9 9/02 から MPO(Memory Placement Optimization) という機能が実装されました。MPO は NUMA システム上でアプリケーションを効率よく動作させるための仕組みです。CPU からメモリまでの距離に応じて lgroup という区画を設定し、アプリケーションが使用するメモリの割り当て位置やスレッドがスケジュールされる CPU を 最適化します。lgroup へのインターフェイスとして lgrp_init(3LGRP) を始めとする lgroup API も実装されています。
Oracle では SGA のアクセスに lgroup API と madvise(3C) を使用することで NUMA マシンで性能が向上しています。これは Opteron や Nehalem を搭載した NUMA 構成のマシンでも非常に有効です。
Dual Core Opteron x4CPU のマシンで lgroup を表示させた例です。この場合は lgroup が 4 つ作成されています。
# uname -m i86pc # kstat -p 'unix:0:system_misc:ncpus' unix:0:system_misc:ncpus 8 # kstat -p 'lgrp:::cpus' lgrp:1:lgrp1:cpus 2 lgrp:2:lgrp2:cpus 2 lgrp:3:lgrp3:cpus 2 lgrp:4:lgrp4:cpus 2
MPO のドキュメントには Oracle を使用する際の MPO の利点が詳解されています。
Oracle と MPO の関係に関するプレゼンテーション資料もご覧下さい。
こちらは Jonathan Chew による MPO のオーバービューです。
大規模ページサポート
既に ISM, DISM の項で取り上げましたが、Solaris 9 より複数のメモリページサイズがサポートされています。この機能は MPSS(Multiple Page Size Support) と呼ばれ、プロセスが 8KB 以上のページサイズを使用することが可能になっています。特に Oracle の様にメモリの使用量が大きいソフトウェアでは MPSS を使用することで TLB ミスを抑制し、性能を向上することが可能です。
Sun SPARC Enterprise T5220 でサポートされているページサイズは以下の通りです。T5220 では最大 256MB までのページサイズを指定することが可能になっており、CMT マシンでは MPSS は特に有効です。
# uname -im sun4v SUNW,SPARC-Enterprise-T5220 # pagesize -a 8192 65536 4194304 268435456
Oracle の SGA が ISM, DISM により大規模ページサイズを使用していることは既にご紹介している通りです。Oracle 10g では memcntl(2) 関数を通じて PGA にラージページを使用することが可能です。Oracle のパラメータに "_realfree_heap_pagesize_hint=4M" を指定すると mmap() されたヒープがデフォルトの 8KB ではなく 4MB のページを使用する様になります。
MPSS についてはこちらもご覧下さい。
- http://www.solarisinternals.com/wiki/index.php/Multiple_Page_Size_Support
- http://blogs.sun.com/glennf/resource/fawcett.25kscale.pres.rev1.03.pdf
- http://dsstos.blogspot.com/2008/10/realfreeheappagesizehint-assessing.html
poll の改良
アプリケーションのスケーラビリティを高めるために poll インターフェイスにも改良が加わっています。Solaris 固有の機能として /dev/poll が用意されています。また Solaris 10 では Event Completion API が追加されました。
- /dev/poll デバイス
% ls -l /dev/poll lrwxrwxrwx 1 root root 29 Dec 12 2007 /dev/poll -> ../devices/pseudo/poll@0:poll
- http://developers.sun.com/solaris/articles/polling_efficient.html
- http://developers.sun.com/solaris/articles/event_completion.html
スケジューラの改善
Solaris のスケジューラにも改善が施されています。
FX (固定優先順位)スケジューリングクラスは、優先順位の逆転を軽減するために導入されました。FX スケジューリングクラスを使用すると Oracle LGWR プロセスを他の標準的なプロセスより高い優先順位を与えることが可能になります。優先順位の設定は priocntl(1) コマンドを使用します。設定したスケジューリングクラスは子プロセスにも継承されるので、Oracle のリスナープロセスに適切な優先順位を設定しておけば、サーバプロセスも同じ優先順位で実行されます。
また、Oracle CRS ではリアルタイムスケジューリングクラスを使用しています。Oracle RAC は LMS デーモンにリアルタイムクラス使用しており、キャッシュフュージョンは高い優先順位で行われます。
- Solaris で用意されているスケジューリングクラスの一覧
% priocntl -l
CONFIGURED CLASSES
==================
SYS (System Class)
TS (Time Sharing)
Configured TS User Priority Range: -60 through 60
RT (Real Time)
Maximum Configured RT Priority: 59
FX (Fixed priority)
Configured FX User Priority Range: 0 through 60
IA (Interactive)
Configured IA User Priority Range: -60 through 60
- Oracle 11g のドキュメント中の priority inversion の説明
UFS direct I/O の改良
UFS direct I/O は Solaris 2.6 から提供されていますが、Solaris 8 Update 3 から read / write 共に並列実行される様に改良されました。従来の direct I/O はファイル毎に書き込み時の並列度を 1 に制限するロックが設けられており、データベースの更新が多い場合は、このロックの取得が大きなオーバーヘッドになっていました。改善された direct I/O ではファイルサイズに変更がない場合は並列に処理されます。この改善により direct I/O は raw デバイスに対する I/O に近い性能を発揮できる様になりました。
Oracle で direct I/O を使用するには FILESYSTEMIO_OPTIONS 初期化パラメータに SETALL を指定するか UFS のマウントオプションに directio を指定します。
UFS direct I/O の並列処理について詳しくまとめられています。
Solaris Internals のフォローアップページにも詳しく記載されています。
MONITORING AND TUNING ORACLE のブループリントです。
以下は Oracle のドキュメントに記載されている FILESYSTEMIO_OPTIONS 初期化パラメータ情報です。
Solaris 10 が 2005 年に登場してから
MPSS サポートの拡張
MPSS がサポートするページサイズが 256MB まで拡大されました。この最適化はデフォルトで有効になっており、CMT サーバ上で Oracle を稼働させる際に特に性能が向上します。
Ravi の Blog には Sun Fire T2000 サーバ上でデータベースを稼働させた場合のラージページの恩恵がまとめられています。
プロセス間通信用パラメータの管理
project を利用することで、プロセス間通信のパラメータを reboot 無しに変更できる様になりました。Oracle 用のカーネルパラメータも project で管理します。
細かな変更点
その他の修正はこちらにも記載されていますので是非ご参照下さい。
dbwr が aio_waitn(3RT) API を使うときの効率性が上がりました。
- aio_waitn is desired : http://bugs.opensolaris.org/view_bug.do?bug_id=4503970
- http://docs.sun.com/app/docs/doc/817-0697/6mgfsdh34?q=aio_waitn
おわりに
ID 4503970 の レポート にある "There is also a request by Oracle..." という言葉が示しているように、データベースを効率よく動かすために Solaris に実装された仕組みは沢山あります。ここに挙っていない技術でも DTrace, ZFS, FireEngine, Crossbow, Zone, KAIO, libaio, proc tools, Sun Cluster, QFS 等、Solaris には Oracle を運用する上で便利だったり性能向上に貢献する技術が沢山含まれています。また、Solaris が元々備えている高いスケーラビリティや高負荷時の安定性、障害解析能力などの特徴はデータベースを稼働させるのに非常に役立ちます。こういった話もいずれ機会があればご紹介させて頂きたいと思います。
以上、Oracle と Solaris の歴史を機能実装的な側面からご紹介しました。何故 Solaris なのかという疑問が浮かんだ時に一つの答えとなれば幸いです。
Posted at 01:42午後 7 28, 2009 by Daisuke Homma in Sun | 投稿されたコメント[3]
「Sun が Oracle の為に実装した技術」この表現には???が3つほどつきますね。
OracleがSunで動くことにより、SunのOSとハードが売れたわけですから。SunがPCよりよかったのは、Sun3以降のSCSI等、しっかりしたバスをつかたわけで。
Oracleの歴史をみれば、もともとはDigitalのVMSで同様の機能や改造要求をだしながら成長してきたわですからね。
ちょっと、いまの若い人はOSに対する勉強がたりんですね。ここで書かれている機能の半分以上は、DigitalというかMITを中心とする東海岸で培われてきた技術なわけで。
Posted by 胡桃 on 7月月 29日, 2009年 at 12:50 午前 JST #
胡桃さん、ブログ記事を読んで頂いてありがとうございます。ご指摘頂いた表現は、『Sun 発祥の技術』という様に受け止められる方もいらっしゃるかもしれませんね。誤解を生じない様、訂正致しました。
Posted by Daisuke Homma on 7月月 29日, 2009年 at 10:54 午前 JST #
ちょっと辛口のコメントであいすみませんでした。
じつは、昔々は Sun のサポータ?だった(w。
WorldCup94(in USA)でSunがオフィシャルスポンサーの時のスポーツバッグをしっかりと某営業さんだった人から2個がめ、いま1個、埃かぶらないように袋入りのままもっておりんす(w。
Posted by 胡桃 on 7月月 29日, 2009年 at 03:54 午後 JST #