目次


DB2で全メモリーを活用する!

Comments

はじめに

創造力のある緊張ということを聞いたことがありますか。相反する力が苦闘した末の副産物として何かを生み出すことができるという擬似精神的な哲学の1つです。言ってみれば漫画本の中に出てくる善と悪の戦いのようなものです。と言ってもすべてのソフトウェア・エンジニアが善人であるとか、ハードウェア・エンジニアが悪人であるというのではなく、彼らの間には創造力のある緊張があるのです。ジョセフ・キャンベルが言ったように、「科学に対するロマンチックな反感からコンピューター・チップに潜む仏を見失ってはいけない」のです。そして、ディスクから表全体がメモリーへと潮流のように移動することほどロマンチックなことはほかにあるでしょうか。

ソフトウェア・エンジニアは、速度の遅いディスクが搭載されたマシン、小さなメモリー・セット、のらりくらりとしたクロック速度など、ハードウェアの進歩の遅さを嘆くことがよくあります。(しかし、ハードウェアがソフトウェアに追いつくと、Javaアプリケーションが遅かったことを忘れます。) ハードウェアの新世代が出現するとともに、オペレーティング・システムの担当者がまずそれに順応しますが、その他のユーザーは32ビットのアーキテクチャーで16ビットまたは8ビット (想像できますか) の DOS アプリケーションを実行するというもどかしさを味わうことになります。今やプレッシャーはソフトウェア・エンジニアにかかっています。いつになったらアプリケーションを再コンパイルして新しいデータ・タイプと、新規ハードウェアによって可能になったメモリーのアドレスを利用するのでしょうか。最終的には、8086上のBASICと24-Way SMP上で実行されているC++と比較した場合、「Hello World」プログラムの書き込みに、ほぼ同じ時間がかかります。

しかし、データベースの役割は「Hello World」をディスプレイに出力することだけではありません。Webサーバー・ソフトウェアがさらに高速な回線を待ち望んでいるのと同様に、データベース・ソフトウェアもディスク速度、容量、およびアドレス指定可能メモリーにおけるすべての進歩を最大限に取り入れます。アプリケーション・プログラマーは、すでに快適に機能している 16ビット・プログラムを32ビット・マシン用に再コンパイルしなければならないことについて不満かもしれませんが、データベース・エンジニアは必要なデータをソートしたり、集計したり、ユーザーに送信したりする前に、ディスクではなくメモリーにそれを保存できるということを考えただけでも嬉しくて仕方がないでしょう。I/Oは大量ワークロードの多くを実現できない原因です。5テラバイトのディスクに1テラバイトを分散させるのはそのためです (より多数のディスク = より多数のスピンドル、これは少なくともベンチマーク界ではより多数の並列I/Oを意味します)。

64ビット・アーキテクチャーは、RISCおよびSparcの世界では標準になりつつあり、AIX、HP-UX、およびSolarisなど、商用の Unix 系プラットフォームはリレーショナル・データベースに多量のメモリーを提供できるようになっています。32ビットのメモリーのアドレス可能度はおよそ4ギガバイトに相当しますが、Unixマシンの多くは20〜100ギガバイトのメモリーを搭載して出荷されます。このメモリーを確実に使用するようにしたいものです。Intel の世界もこれに遅れをとってはいません。64ビットの Intelチップで稼動する Linux や Windows 2000は、オペレーティング・システム、コンパイラー、およびデータベース・ソフトウェア研究所では現実になっており、身近なWebサイトで販売される日も間近です。

それでは、ハードウェアとオペレーティング・システムが大容量メモリーに対応可能となり、データベースがそれを利用できるとしたら、これらをどのように組み合わせれば効果的に機能させることができるのでしょうか。DB2バージョン7でまず認識する必要があることは、DB2が初めから32ビット・メモリーとハードウェアを前提としていることです。大容量メモリーを利用するには、それが利用可能であることと、その使い方をDB2に知らせる必要があります。DB2クライアントとDB2サーバーの多くは当分の間は32ビットIntelマシンで稼動するのですからDB2のせいにはしないでください。マシン上に96GBのメモリーがあることをDB2が感知したとしても、それをほかのアプリケーションと共用せずにDB2が独占していいとは限りません。

このメモリーを使用する場合、いくつかのオプションがあります。最も明らかなのは64ビットDB2インスタンスを作成することです。これは AIX、Solaris、および HP-UX上のDB2バージョン7でサポートされています。バージョン 7.1 をご使用の場合は、Fixpak1をダウンロードして64ビット DB2ライブラリーをインストールする必要があります。バージョン7.2以上をお持ちの場合は、64ビットDB2インスタンスの作成にfixpakをインストールする必要はありません。64ビット DB2インスタンスを作成するには、db2icrtコマンドを使用してパラメーター -wに64という値を指定します。たとえば次のように指定します。

db2icrt -w 64 -u db2fenc1 db2inst1

64ビット環境でのDB2の使い方を説明したマニュアルは以下のサイトにあります。

http://www.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/document.d2w/report?fn=db2q9e71frm3toc.htm

1 + 1 = 2、2 の 32 乗 = 多量

各32ビットDB2インスタンスは4GBのメモリーをアドレス指定できます。通常は、このメモリーの大半をバッファー・プール専用に割り当てることが望まれます。しかし、AIX、HP-UX、Windows で発生するメモリーのセグメント化により、最大のバッファー・プールのサイズは4GB以下に制限されます。32ビットの世界で非常にクリーンなメモリー・モデルを持つSolarisでさえも、DB2バッファー・プールのアドレス指定可能なメモリーには3.35GB以下しか割り当てることができません。4GB境界の下の残りのメモリーは、DB2のその他の用途である共用メモリー専用にする必要があります。(幸いなことに64ビット世界のすべてのオペレーティング・システムではメモリー・モデルがさらにクリーンになっています。) HP-UXでは、32ビットDB2インスタンスを使用して作成できる最大のバッファー・プールは約800MBです。HP-UXでは1GB以上を利用できますが、32ビット HP-UX のメモリーウィンドウで複数のインスタンスが稼動している場合に限られます。(HPメモリーウィンドウについてはDB2 リリース・ノートで説明しています。) バッファー・プールは Windowsでは3GBに、AIXでは1.75GB、そしてLinuxでは約1GBに制限されています。次の図1と2は、それぞれAIXとSolarisの32ビット・メモリー・モデルを示しています。

図 1. AIX 上の DB2 32 ビット・メモリー・モデル
図1
図1
図 2. Solaris 上の DB2 32 ビット・メモリー・モデル
図2
図2

32ビットDB2が稼動している大規模メモリー・システムはバッファー・プールに大量のメモリーを割り当てるには、DB2エンタープライズ拡張エディション (EEE) 構成で複数の論理DB2インスタンスを稼動させることが最も単純な方法です。オペレーティング・システムにインスタンスを1つ稼動させる必要があるだけです。そのため、オーバーヘッドが低減し、DB2インスタンスはTCP/IPや通信スイッチを介さずに、共用メモリーを通して相互に通信できます。DB2のシェアード・ナッシング・アーキテクチャーでは、各インスタンスは4GBのメモリーを独自のデータベース区画を使用して楽にアドレス指定できます。300GB以上のデータベースで意思決定支援照会を実行する DB2 EEEを備えたたいていのDB2 TPC-Hベンチマークでは、大規模SMPは各DB2ノード用の4GBに分割されます (各ノードは、それぞれ独自の DB2インスタンスが稼動するデータベース区画です)。
DB2が大容量メモリー・マシンを活用する方法はその他に3つあります。AIX、Solaris、および Windowsでは、DB2は拡張記憶域 (ESTOREとして知られています) をサポートします。これにより、DB2 はシステム一時表 (ソートに使用) や読み取り専用ユーザー・データなどに 32 ビット・メモリー・モデルの最大使用可能メモリー以上のメモリーを使用することができます。ディスクからデータを取得する際に読み取り専用データを識別するのはDB2次第ですが、DB2 でESTOREを使用するように構成するのはユーザーです。

ここで典型的な事例を取り上げてみましょう。データベースを設計していて、1つの表をできるだけメモリーに保存したいとします。まず、以下のようにデータベース・マネージャーの構成を更新し、使用するESTOREセグメントの数 (num_estore_segs) を指定します。これはデフォルトではゼロに設定されます。n に指定する値は、表の大きさ、使用可能なメモリー、この表に割り当てるメモリー量によって異なります。たとえば、6GBのメモリーでSolarisが稼動しているとします。4GB限界を超えた2GB分のメモリーがESTOREに使用されます。

update db cfg for sample using num_estore_segs n

estore セグメントのサイズは、次のように ESTORE メモリー・セグメント・サイズ (estore_seg_sz) データベース構成パラメーターで定義します。

update db cfg for sample using estore_seg_sz 32000

次に以下のようにバッファー・プールを作成します。ここでは例として8Kページ・サイズを使用しますが、16Kと32Kページ・サイズも有効です。(これが Windows上であれば、2GB以上のメモリーを使用するために4K以上のページ・サイズを使用する必要があります。) バッファー・プールでは、ESTOREが使用可能になっている必要があります。これは EXTENDED STORAGEキーワードを使用して指定します。highmemはこのバッファー・プールのために筆者が選択した名前です。サイズ n は、このバッファー・プールが占めるメモリーの量によって異なります。

CREATE BUFFERPOOL highmem SIZE n
PAGESIZE 8K EXTENDED STORAGE

次に表スペースを作成し、それをバッファー・プールに割り当てます。

CREATE TABLESPACE highmem_tbsp PAGESIZE 8K
  MANAGED BY SYSTEM 
  USING ('C:\highmemdir) 
  BUFFERPOOL highmem

表スペースのページ・サイズはバッファー・プールのページ・サイズに一致する必要があること、およびバッファー・プールは名前で識別されることに注意してください。この表スペースに表を1つだけ作成した場合、バッファー・プールにこの表スペースしかなければ、この表のデータがアクセスされるとともに、それがメモリーに留まる可能性が高くなります。それでも表のソートが溢れる可能性があるため、同じページ・サイズのシステム一時表が必ず作成されるようにしてください。

CREATE SYSTEM TEMPORARY TABLESPACE highmem_temp PAGESIZE 8K
MANAGED BY SYSTEM 
USING ('C:\highmemtemp') BUFFERPOOL highmem

これで表スペースに表を作成する準備ができました。

create table memory_hog (col1 int) in highmem_tbsp

最高? 最悪? どちらでしょう

Windows 2000は、Microsoft Address Windowing Extensions (AWE) を使用して32ビットの世界で4GBを超えた部分のデータをマッピングできます。DB2バージョン7.2 (またはバージョン 7.1 に Fixpak 3 を適用) はこれをサポートしています。Windows 2000 Advanced Serverでは最高8GBまでのメモリーがサポートされ、Windows 2000 Data Center Server では最高64GBまでのメモリーがサポートされます。

最終的には、ハイパフォーマンス・データベース設計の方向性に逆らった選択を迫られる可能性もあります。上記の技法の適用が考えられるデータベースは、おそらく最適なパフォーマンスを必要とするでしょう。実際、パフォーマンスが重要でなければそれを多量のメモリーを備えたマシンに載せる必要はないはずです。そのようなデータベースは、コンテナーとしてロウ・デバイスを使用し、ユーザー・データをデータベース管理ストレージ (DMS) に保存している場合が多くあります。一般通念では、ハイプロファイルで要求の多いユーザーを持つ1つのデータベースを管理する場合、データの増大を予測し、ロウ・デバイス・コンテナー上の十分なスペースを割り当てることができるように調整と計画に時間をつぎ込むべきだとされています。この考え方では、システム管理ストレージ (SMS) 表スペースは、システム・データ (一時表スペースおよびカタログ表スペース) および数が多すぎるため設計や保守への多額の投資を正当化できない保守レベルの低いデータベースに対してのみ適切です。

では、両方の悪条件が重なった場合、すなわち高速であることが要求されるデータベースで、データの増大の予測もできず、保守に時間を費やすこともできない場合、どうすればいいでしょう。重要なものがあるならばDBAリソースをなぜそれに使用しないのだろうと考えるかもしれませんが、判断する上司も必ずしも論理的ではありません。幸い、大容量メモリー・マシンの使い方の決定に時間を費やしているのはリレーショナル・データベース設計者だけではありません。オペレーティング・システムの専門家もこの問題に取り組んでいます。思い切ってすべてのデータをSMS表スペースに入れ、コンテナーにファイル・システムを使用してみます。(これはDMSでもできますが、その場合でもコンテナーのファイル・サイズを定義する際にデータの増大を計画する必要があります。) その後は、4GB限界を超えた分のすべてのメモリーを確認してそれをファイル・システム・キャッシングに使用するのはオペレーティング・システムの役目です。幸いにも、大規模SMPで稼動する、アプリケーションの活用によってパフォーマンス目標を達成できるデータベースが多数あるために、オペレーティング・システム設計者は大容量メモリー・マシンの可能性を引き出して、頻繁にアクセスされるデータをメモリーに保存しておくことに意欲を燃やしています。そしてそれはデータベース・バッファー・プールの果たすべき役割なのです。つまり、頻繁にアクセスするデータをメモリーに保存し、残りをディスクのみに保管するということです。

これは家庭では試さないこと! (職場で上司のシステムを使って試しましょう)

メモリーに関する記事の最後に、残りのシステムを忘れないようにと言明しておきます。96GBものメモリーがあっても、多分96GB以上のデータがディスクを占めていることでしょう。これらのデータがあなたのシステムを圧倒してそれをページング地獄に追いやるのは時間の問題です。この記事の焦点は、できるだけ多くのメモリーを利用することにありました。なんといっても、メモリーに投資したのはあなたなのですから、それを活用して元を取るのが当然でしょう。この哲学にのっとり、購入した残りのハードウェアも忘れないようにしてください。ソフトウェアですべてのメモリーを使用するようにするわけですが、すべてのプロセッサー、またすべてのディスクもそれぞれの役割を果たすようにしたいものです。1MBのPC上で640Kに制限されるアプリケーションが使用可能なリソースを十分に活用できない (そしてそのために本来よりも速度が遅くなる) のと同様に、プロセッサーの1つが100%実行中で、残りが25%実行中の場合、ジレンマが発生します。すなわち、1つのプロセッサーでCPU集中型のワークロードがあるにもかかわらず、残りのプロセッサーは何もしないという事態です。(1人がシャベルで作業しているのに仲間は突っ立って見ているという工事現場にも似たシナリオです。) このようなとき、DB2 EEEはあなたの味方です。シェアード・ナッシング・アーキテクチャーはメモリー、CPU、使用可能なディスクにすべての作業とデータを分散するように設計されています。そのため、シェアード・ナッシング・アーキテクチャーは意思決定支援に最適です。トランザクションのワークロードの場合、ホット・スポットに注意する必要があります。CPUまたはディスクのサブセットが酷使されている場合、その原因は何でしょう。負荷の多いクライアントがすべて同じノードに接続されてはいませんか? 幸いなことに、EEEではクライアント接続をすべてのノードに分散させることができます。すべてのノードでハッシュされた大きな表ではなくノード上の多数の小さな表にデータを移動すべきでしょうか。小さな表の弱点は、各ノードからの行で作られる結果セットが欲しい場合にもUNIONを使用することです。また、シェアード・ナッシング・アーキテクチャーでOLTPを実行することに躊躇する必要はありません。この記事の執筆時点 (2001年4月) ではTPC-C結果のトップ 6は、クラスター化したシェアード・ナッシング・データベース上のものです。

ワークロード・バランシングもまた、複数のディスクが同時にデータを返せるように表スペースをすべてのディスクにわたって分散すること、したがって並列 I/Oを可能にすることを意味します。ここでは、ディスク、メモリー、およびプロセッサーという3つの変数間に創造力のある緊張があると言えます。恵まれた状況であれば、それぞれが豊富にあり、それらの間でワークロードを平衡化して、投入した時間と金額に値するシステムを構築できます。利用されないハードウェアはどうしましょう。少なくともハードウェアの販売担当者は多額のコミッションをもらってハワイのバケーションを楽しむことができたでしょう。そして、ほかに何の役に立たなくても、ハワイで釣りをしているときにあなたの小船が波にさらわれそうになってしまった場合に備えて、その余分なハードウェアとロープで立派な錨ぐらいは作れるでしょう。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=322923
ArticleTitle=DB2で全メモリーを活用する!
publish-date=07032001